微服务消息监控 什么是微服务架构主流的微服务如何实现

一、微服务消微服务架微服务何什么是息监微服务架构啊

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。构主系统中的实现各个微服务可被独立部署，各个微服务之间是微服务消微服务架微服务何松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。息监

微服务是构主指开发一个单个小型的但有业务功能的服务，每个服务都有自己的实现处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务消微服务架微服务何

微服务也指一种种松耦合的息监、有一定的构主有界上下文的面向服务架构。也就是实现说，如果每个服务都要同时修改，微服务消微服务架微服务何那么它们就不是息监微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的构主上下文场景使用条件，那么它就是一个有上下文边界的服务。

二、微服务框架之Spring Cloud简介

在了解 Spring Cloud之前先了解一下微服务架构需要考量的核心关键点，如下图：

对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud已经帮我们集成了，它使用 Spring Boot风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。

Spring Cloud所提供的核心功能包含：

Spring Cloud架构图

Spring Cloud子项目

Spring Cloud旗下的子项目大致可以分为两类：

如下：

1. Spring Cloud与 Spring Boot

Spring Boot可以说是微服务架构的核心技术之一。通过在 Spring Boot应用中添加 Spring MVC依赖，就可以快速实现基于 REST架构的服务接口，并且可以提供对 HTTP标准动作的支持。而且 Spring Boot默认提供 JackJson序列化支持，可以让服务接口输入、输出支持 JSON等。因此，当使用 Spring Cloud进行微服务架构开发时，使用 Spring Boot是一条必经之路。

2. Spring Cloud与服务治理( Eureka)

服务治理是 Spring Cloud的核心，在实现上其提供了两个选择，即 Consul和 Netflix的 Eureka。

Eureka提供了服务注册中心、服务发现客户端，以及注册服务的 UI界面应用。

在 Eureka的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机， Eureka客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。

3. Spring Cloud与客户端负载均衡( Ribbon)

Ribbon默认与 Eureak进行无缝整合，当客户端启动的时候，从 Eureka服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。

Spring Cloud通过集成 Netflix的 Feign项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign项目集成了 Ribbon，使得声明式调用也支持客户端负载均衡功能。

4. Spring Cloud与微服务容错、降级( Hystrix)

为了给微服务架构提供更大的弹性，在 Spring Cloud中，通过集成 Netflix下子项目 Hystrix，通过所提供的@HystrixCommand注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix也默认集成到 Feign子项目中。

Hystrix是根据“断路器”模式而创建。当 Hystrix监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。

而 Hystrix的仪表盘项目（ Dashboard）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。

5. Spring Cloud与服务网关( Zuul)

Spring Cloud通过集成 Netflix中的 Zuul实现 API服务网关功能，提供对请求的路由和过滤两个功能

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。

过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。

通过 Zuul，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API接口，屏蔽了服务端的实现细节。通过 Zuul的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul默认会与 Eureka服务器进行整合，自动从 Eureka服务器中获取所有注册的服务并进行路由映射，实现 API服务网关自动配置。

6. Spring Cloud与消息中间件( Stream)

Spring Cloud为简化基于消息的开发，提供了 Stream子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka和 RabbitMQ等消息中间件进行集成。

Spring Cloud Bus基于 Stream进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。

比如 Spring Cloud Config借助 Bus，可以实现配置的动态刷新处理。

7. Spring Cloud与分布式配置中心( Config)

针对微服务架构下的配置文件管理需求， Spring Cloud提供了一个 Config子项目。 Spring Cloud Config具有中心化、版本控制、支持动态更新和语言独立等特性。

在 Config子项目中将微服务应用分为两种角色：配置服务器（ Config Server）和配置客户端（ Config Client）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git、 SVN等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。

8. Spring Cloud与微服务链路追踪( Sleuth)

Spring Cloud中的 Sleuth子项目为开发者提供了微服务之间调用的链路追踪。

Sleuth核心思想就是通过一个全局的 ID将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。

因此，通过 Sleuth可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。

9. Spring Cloud与微服务安全( Security)

Spring Cloud Security为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。

Spring Cloud Security默认支持 OAuth 2.0认证协议，因此单点登录也可以非常容易实现，并且 OAuth2.0所生成的令牌可以使用 JWT的方式，进一步简化了微服务中的安全管理。

10. Spring Cloud的其他子项目

三、什么是微服务架构主流的微服务如何实现

简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。

主流的微服务包括：

1、SpringCloud

Spring Cloud,来自Spring，具有Spring社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。

- Eureka:服务注册发现框架；

- Zuul:服务网关；

- Karyon：服务端框架；

- Ribbon：客户端框架；

- Hystrix：服务容错组件；

- Archaius：服务配置组件；

- Servo：Metrics组件；

- Blitz4j：日志组件；

2、Dubbo

Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)

-远程通讯:提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；

-集群容错:提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；

-自动发现:基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo也是采用全 Spring配置方式，透明化接入应用，对应用没有任何 API侵入，只需用 Spring加载 Dubbo的配置即可，Dubbo基于 Spring的 Schema扩展进行加载。当然也支持官方不推荐的 API调用方式。

3、lstio

lstio作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。

目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry等其他环境增加支持。lstio将流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。

- HTTP、gRPC和 TCP网络流量自动负载均衡；

-提供了丰富的路由规则，实现细颗粒度的网络流量行为控制；

-流量加密、服务件认证，以及强身份声明；

-全范围（Fleet-wide）的策略执行；

-深度遥测和报告。

四、微服务架构的分布式事务问题如何处理

分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！

下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！

如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：

1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；

2、支付平台中创建支付订单（选银行卡支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；

3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；

4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；

5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；

如上图，支付平台收到银行扣款结果后的内部处理流程：

1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；

2、支付订单服务根据银行扣款结果更改支付订单状态；

3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；

4、调用积分服务给用户积分账户增加积分；

5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；

6、调用通知服务将支付处理结果通知电商平台；

如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：

/**支付订单处理**/

@Transactional(rollbackFor= Exception.class)

public void completeOrder(){

orderDao.update();//订单服务本地更新订单状态

accountService.update();//调用资金账户服务给资金帐户加款

pointService.update();//调用积分服务给积分帐户增加积分

accountingService.insert();//调用会计服务向会计系统写入会计原始凭证

merchantNotifyService.notify();//调用商户通知服务向商户发送支付结果通知

}

本地事务控制还可行吗？

以上分布式事务问题，需要多种分布式事务解决方案来进行处理。

订单处理：本地事务

资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。

会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）

商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）

参考资料:故障根因分析