分布式框架——微服务架构

1. Spring Cloud

1.1 服务注册与发现

• 分布式选举问题：https://www.cnblogs.com/bangerlee/p/5767845.html
• 分布式session问题：https://www.cnblogs.com/daofaziran/p/10933221.html
• 分布式锁问题：https://blog.csdn.net/wuzhiwei549/article/details/80692278
• 分布式事务问题：2阶段与3阶段：https://www.cnblogs.com/binyue/p/3678390.html
• 分布式事务问题：4种解决方案：https://www.cnblogs.com/mayundalao/p/11798502.html

Eureka（停更）

• 使用 Eureka 的客户端（包含Provider、Consumer）连接到 Eureka Server并维持心跳连接
  • Eureka Server 提供服务注册和发现
  • Service Provider 服务提供方将自身服务注册到Eureka，从而使服务消费方能够找到
  • Service Consumer 服务消费方从Eureka获取注册服务列表，从而能够消费服务
• 参考链接：https://blog.csdn.net/qwe86314/article/details/94552801

Zookeeper

• 领导者（leader），负责进行投票的发起和决议，更新系统状态
• 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
• Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
• 客户端（client），请求发起方
• 参考链接：https://www.cnblogs.com/raphael5200/p/5285583.html
  
  

Consul

• 服务发现（Service Discovery）：Consul提供了通过DNS或者HTTP接口的方式来注册服务和发现服务。一些外部的服务通过Consul很容易的找到它所依赖的服务。
• 健康检查（Health Checking）：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联(“webserver是否返回200 OK”)，也可以与本地节点相关联(“内存利用率是否低于90%”)。操作员可以使用这些信息来监视集群的健康状况，服务发现组件可以使用这些信息将流量从不健康的主机路由出去。
• Key/Value存储：应用程序可以根据自己的需要使用Consul提供的Key/Value存储。 Consul提供了简单易用的HTTP接口，结合其他工具可以实现动态配置、功能标记、领袖选举等等功能。
• 安全服务通信：Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。意图可用于定义允许哪些服务通信。服务分割可以很容易地进行管理，其目的是可以实时更改的，而不是使用复杂的网络拓扑和静态防火墙规则。
• 多数据中心：Consul支持开箱即用的多数据中心. 这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。

• Consul支持多个数据中心，每个数据中心都有一个被选中的服务器。该leader服务器负责处理所有的查询和事务。事务还必须作为协商一致协议的一部分复制到所有对等方。由于这个需求，当非leader服务器接收到RPC请求时，它会将其转发给集群leader。

Nacos

1.2 服务调用

Ribbon

• Ribbon是一个基于 HTTP 和 TCP 客户端的负载均衡器

• 提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起

• 它可以在客户端配置 ribbonServerList（服务端列表），然后轮询请求以实现均衡负载

Feign（停止更新）

• Feign是一个声明式的web service客户端，它使得编写web service客户端更为容易。
• 创建接口，为接口添加注解，即可使用Feign。
• Spring Cloud为Feign添加了Spring MVC的注解支持，并整合了Ribbon和Eureka来为使用Feign时提供负载均衡，Feign包含Ribbon

OpenFeign

1.3 服务降级

Hystrix

• 服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”

• Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

• “断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

  • 服务熔断：暂时停止对该服务的调用
  • 熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。
  • 服务降级：舍弃非核心的接口和数据请求
  • 服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

1.4 服务网关

• 职能

• 分类

Zuul

所有从设备或网站来的请求都会经过Zuul到达后端的Netflix应用程序。作为一个边界性质的应用程序，Zuul提供了动态路由、监控、弹性负载和安全功能。Zuul底层利用各种filter实现如下功能：

• 认证和安全 识别每个需要认证的资源，拒绝不符合要求的请求。
• 性能监测 在服务边界追踪并统计数据，提供精确的生产视图。
• 动态路由 根据需要将请求动态路由到后端集群。
• 压力测试 逐渐增加对集群的流量以了解其性能。
• 负载卸载 预先为每种类型的请求分配容量，当请求超过容量时自动丢弃。
• 静态资源处理 直接在边界返回某些响应。

Gateway

Gateway 可以看做是一个 Zuul 1.x 的升级版和代替品，比 Zuul 2 更早的使用 Netty 实现异步 IO，从而实现了一个简单、比 Zuul 1.x 更高效的、与 Spring Cloud 紧密配合的 API 网关。

1.5 服务配置：分布式配置中心

Config

Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。方便部署与运维。分客户端、服务端。

• 服务端也称分布式配置中心，是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口。
• 客户端则是通过指定配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。默认采用 git，并且可以通过 git 客户端工具来方便管理和访问配置内容。

1.6 服务总线：消息总线

Bus

Spring Cloud Bus通过轻量消息代理连接各个分布的节点。核心思想是通过分布式的启动器对spring boot应用进行扩展，也可以用来建立一个多个应用之间的通信频道。

大家可以将它理解为管理和传播所有分布式项目中的消息既可，其实本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka和RabbitMQ。

1.7 消息驱动

Stream

消息中间件组件，它集成了 kafka 和 rabbitmq

1.8 分布式请求链路跟踪

Slueuth

基本思路是在服务调用的请求和响应中加入ID，标明上下游请求的关系。利用这些信息，可以方便地分析服务调用链路和服务间的依赖关系。

2. Spring Cloud Alibaba

服务注册与配置中心

Nacos

• 一个更易于构建的云原生应用的动态服务发现、配置管理和服务管理的平台
• Nacos = 服务注册中心 + 服务配置 + 服务总线 = Eureka + Config +Bus

熔断与限流

Hystrix

• 需要手工搭建监控平台
• 没有一套web界面给我们进行更加细粒度化的配置：流量监控、速率控制、服务熔断、服务降级

Sentinel

• 单独一个组件
• 支持界面化的细粒度统一配置

分布式事务

Seata

• 单应用单库——单应用多库——应用拆分，多模块多库（下订单：订单库、减库存：库存库、物流：物流库）
• 导致全局数据一致性问题
• 官网地址

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。

• TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

• 流程：

  • TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID
  • XID在微服务调用链路中的上下文传播
  • RM向TC注册分支事务，该分支事务也被XID对应的全局事务管理
  • TM向TC发起针对XID的全局事务提交或回滚
  • TC调度XID下管辖的全部分支事务进行提交或回滚