0、SpringCloud 技术理论整理
01
Eureka：服务注册与发现
什么是服务治理
SpringCloud封装了 Netflix 公司开发的 Eureka 模块来实现服务治理
在传统的 RPC 远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，所以需要服务治理，管理服务与服务之间的依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册
什么是服务注册与发现
Eureka 采用了 CS 的设计架构，Eureka Server 作为服务注册功能的服务器，它是服务注册中心。而系统中其他的微服务，使用 Eureka 的客户端连接到 Eureka Server 并维持心跳连接。这样系统的维护人员就可以通过 Eureka Server 来监控系统中各个微服务是否正常运行。
Eureka 两组件
Eureka Server：提供服务注册服务。各个微服务节点通过配置启动后，会在 Eureka Server 中进行注册，这样 Eureka Server 中的服务注册表中将会存储所有服务节点的信息，服务节点的信息可以在界面中直接看到
Eureka Client：通过注册中心进行访问。是一个Java客户端，用于简化 Eureka Server 的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。在应用启动后，将会向 Eureka Server 发送心跳（默认周期是30秒）。如果 Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，Eureka Server 将会从服务注册表中将这个服务节点移除（默认90秒）
02
Zookeeper：服务注册与发现
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务（注册中心）。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
03
Consul：服务注册与发现
Consul 是什么
Consul 是一套开源的分布式服务发现和配置管理系统。由HaShiCorp公司用GO语言开发
提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能中每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网络，总之 Consul 提供了一种完整的服务网格解决方案
优点：基于raft协议，比较简洁；支持健康检查，同时支持HTTP和DNS协议，支持跨数据中心的WAN集群，提供图形化界面，跨平台，支持Linux、Mac、Windows
Consul 能干什么
服务发现：提供HTTP和DNS两种发现方式
健康监测：支持多种协议，HTTP、TCP、Docker、Shell脚本定制化
KV存储：key , Value的存储方式
多数据中心：Consul支持多数据中心
可视化Web页面
04
Ribbon：负载均衡服务调用
Ribbon 是什么
Spring Cloud Ribbon 是基于Netflix Ribbon 实现的一套客户端负载均衡工具
简单来说，Ribbon 是 Netflix 发布的开源项目，主要功能是提供客户端的软件负载均衡算法和服务调用。Ribbon 客户端组件提供一系列完善的配置项（如连接超时、重试等）。简单地说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon 会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们很容易使用Ribbon实现自定义的负载均衡算法。
Ribbon 能做什么
LB负载均衡（Load Balance）是什么
简单说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）。常见的负载均衡有软件Nginx、LVS、硬件F5等
Ribbon 本地负载均衡客户端 和 Nginx服务端负载均衡的区别
Nginx是服务器负载均衡，客户端所有的请求都会交给 Nginx，然后由 Nginx 实现转发请求。即负载均衡是由服务端实现的
Ribbon 本地负载均衡，在调用微服务接口的时候，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用技术
Ribbon 和 Nginx 区别举例：Nginx 是医院，所有看病的都去医院（Nginx ）；Ribbon 是医院里面的牙科，所有看病的去了医院要看牙科，牙科有多个牙科医生，Ribbon 就负责将病人分配给不同的医生。
集中式LB：即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件，如F5；也可以是软件，如Nginx），由该设施负责把访问请求通过某种策略转发至服务的提供方
前面使用Eureka时，使用了注解@LoadBalanced实现轮询的负载均衡。就是 负载均衡+RestTemplate 调用
05
OpenFeign：服务接口调用
OpenFeign 是什么
Feign 是一个声明式WebService客户端。使用 Feign 能让编写Web Service 客户端更加简单。
Feign 使用方法是定义一个服务接口然后在上面添加注解。Feign 也支持可插拔式的编码器和解码器。SpringCloud 对 Feign 进行了封装，使其支持 SpringMVC 标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡
OpenFeign 能干什么
Feign 旨在使编写Java Http客户端变得更容易。
前面在使用Ribbon + RestTemplate 时，利用RestTemplate 对HTTP请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign 在此基础上做了进一步的封装，由它来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它（以前是Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可），即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon 时，自动封装服务调用客户端的开发量
Feign 集成了 Ribbon
利用Ribbon维护了服务端的服务列表信息，并且通过轮询实现了客户端的负载均衡。而与Ribbon不同的是，通过Feign 只需要定义服务绑定接口且以声明式的方法，优雅而简单的实现了服务调用。
Feign和OpenFeign两者区别
Feign：Feign是SpringCloud组件中一个轻量级的RESTful 的HTTP服务客户端，Feign内置了Ribbon，用来做客户端的负载均衡，去调用服务注册中心的服务。Feign 的使用方式是：使用Feign 的注解定义接口，调用这个接口，就可以调用服务注册中心的服务
OpenFeign：OpenFeign是SpringCloud在Feign的基础上支持了SpringMVC的注解，如@RequestMapping等等。OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-feign</artifactId>
</dependency>
06
Hystrix：断路器
分布式系统面临的问题
复杂的分布式体系结构中的引用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败
如果一个请求需要调用 A、P、H、I 四个服务，如果一切顺利不会出问题，但是如果某个服务超时了，就会出现服务雪崩
服务雪崩：
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他微服务，这就是所谓的“扇出”，如果“扇出”的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，这就是所谓的“雪崩效应”
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比请求失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，一遍单个依赖关系的失败，不能取消整个应用程序或系统。
通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他模块，这样就会发生级联故障，或者叫做雪崩。
Hystrix 断路器是什么
Hystrix 是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖会不可避免的调用失败，比如超时、异常等。Hystrix 能保证在一个依赖出现问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免了故障在分布式系统中的蔓延、乃至雪崩
Hystrix 能干什么
服务降级
服务熔断
接近实时的监控
07
Gateway：网关
Gateway 概述
Gateway 是在Spring生态系统之上构建的API网关服务，基于Spring 5，SpringBoot2 和 Project Reactor 等技术
Gateway 旨在提供一种简单而高效的方式来对 API进行路由，以及提供一些强大的过滤器功能，例如：熔断、限流、重试等
SpringCloud Gateway 是 SpringCloud的一个全新项目，基于 Spring5.0+SpringBoot2.0和Project Reactor等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的API路由管理方式。
SpringCloud Gateway 作为Spring Cloud 生态系统中的网关，目标是替代 Zuul，在SpringCloud2.0 以上版本中，没有对新版本的Zuul2.0 以上最新高性能版本进行集成，任然还是使用Zuul 1.X 非Reactor模式的老版本。而为了提升网关的性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
SpringCloud Gateway 的目标提供统一的路由方式且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。
简单来说：Spring Cloud Gateway 使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架
可以看看Spring Cloud Gateway 的jar依赖中是已经引入了Netty的。
Gateway 作用：
反向代理
鉴权
流量控制
熔断
日志监控等
微服务框架
有了Zuul了怎么又出来了gateway
我们为什么选择Gatway?
neflix不太靠谱，zuul2.0一直跳票,迟迟不发布
一方面 Zuul 1.X 已经进入了维护阶段，而且Gateway是SpringCloud团队研发的。而且很多功能 Zuul 都没有用起来也非常简单便捷
Gateway 是基于异步非阻塞模型上进行开发的，性能方面不需要担心。虽然Netflix 早就发布了最新的Zuul 2.X，但是SpringCloud 貌似没有整合计划。而且Netflix 相关组件都宣布进入维护期，不止前景如何
多方面综合考虑Gateway 是很理想的网关选择
SpringCloud Gateway具有如下特性
基于Spring Framework 5，Project Reactor 和SpringBoot 2.0 进行构建
动态路由：能够匹配任何请求属性
可以对路由指定 Predicate（断言）和Filter（过滤器）
集成 Hystrix的断路器功能
集成SpringCloud 服务发现功能
易于编写的Predicate（断言）和Filter（过滤器）
请求限流功能
支持路径重写
SpringCloud Gateway与Zuul的区别
Zuul 1.X 是一个基于阻塞 I/O 的API Gateway
Zuul 1.X 基于 Servlet2.5 使用阻塞架构，它不支持任何长连接（如WebSocket）Zuul的设计模式，和Nginx较像，每次 I/O 操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx用C++实现，Zuul 用java 实现，而JVM本身会有第一次加载较慢的情况，使得Zuul性能相对较差
Zuul 2.X 历练更先进，想基于Netty 非阻塞和支持长连接，单SpringCloud目前还没有整合。Zuul 2.X性能较Zuul 1.X 有较大提升。在性能方面，根据官方提供的基准测试，SpringCloud Gateway 的RPS（每秒请求数）是Zuul 的1.6倍
SpringCloud Gateway 建立在Spring Framework 5，Project Reactor 和SpringBoot 2.0之上
Zuul1.x模型
SpringCloud 中所集成的Zuul 版本，采用的是Tomcat 容器，使用的是传统的Servlet IO处理模型
Servlet的生命周期：Servlet 由Servlet container 进行生命周期管理。
container 启动时构造servlet 对象并调用 servlet init()进行初始化
container 运行时接受请求，并未每个请求分配一个线程（一般从线程池中获取空闲线程），然后调用service()
container 关闭时调用 service.destory()销毁servlet
上述模式的缺点
servlet 是一个简单的网络 IO 模型，当请求进入servlet container 时，servlet container 就会为其绑定一个线程，在并发不高的场景下这种模型是适用的。但是一旦高并发（比如用Jemeter压测），线程数量就会大涨，而线程资源代价是昂贵的（上下文切换，内存消耗大），严重影响请求的处理时间。在一些业务场景下，不希望为每个request分配一个线程，只需要一个或几个线程就能应对极大的并发请求，这种业务场景下servlet模型没有优势
所以Zuul 1.X 是基于servlet之上的一个阻塞式处理模型，即Spring实现了处理所有request请求的一个servlet（DispatcherServlet）并由该servlet阻塞式处理。所以SpringCloud Zuul无法摆脱Servlet模型的弊端
GateWay模型
传统的Web框架，比如Struts2、SpringMVC等都是基于Servlet API与Servlet容器基础之上运行的。
但是在Servlet3.1 之后有了异步非阻塞支持。而WebFlux是一个典型非阻塞异步的框架，它的核心是基于 Reactor 的相关API实现的。相对于传统的Web框架来说，他可以运行在注入Netty 、Undertow及支持Servlet3.1的容器上。非阻塞式+函数式编程（Spring5必须使用java8）
Spring WebFlux是Spring5.0引入的新的响应式框架，区别于SpringMVC，它不需要依赖Servlet API，它是完全异步非阻塞的，并且基于Reactor来实现响应式流规范
GateWay 的三大核心概念
Route(路由)：路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由
Predicate（断言）：参考的是java8的java.util.function.Predicate开发人员可以匹配HTTP请求中的所有内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由
Filter(过滤)：指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。
总体：
web请求，通过一些匹配条件，定位到真正的服务节点。并在这个转发过程的前后，进行一些精细化控制
Predicate 就是我们的匹配条件
Filter就可以理解为一个无所不能的拦截器。有了Predicate 和Filter ，再加上目标URI，就可以实现一个具体的路由了。
08
Config 分布式配置中心
分布式系统面临的配置问题
微服务意味着要将单体应用中的业务拆成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、 动态的配置管理设施是必不可少的
SpringCloud 提供了一个ConfigServer 来解决这个问题，我们每一个微服务自己带着一个application.yml，所以可以将公共的配置放在ConfigServer 中
config分布式配置中心是什么
SpringCloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置
SpringCloud Config 分为服务端和客户端两部分
服务端也称为 分布式配置中心，它是一个独立微服务中心，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口
客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息，配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。
config分布式配置中心能干嘛
集中管理配置文件
不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release
运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置
将配置信息以REST接口的形式暴露，post、curl访问刷新均可....
与Github整合配置：由于SpringCloud Config默认使用Git来存储配置文件（也有其它方式，比如支持svn和本地文件，但最推荐的还是Git，而且使用的是http/https访问的形式）
09
Bus 消息总线
SpringCloud Bus总线实现分布式自动刷新配置功能：Spring Cloud Bus配合Spring Cloud Config使用可以实现配置的动态刷新
SpringCloud Bus总线是什么
SpringCloud Bus 是用来将分布式系统的节点与轻量级消息系统链接起来的框架，它整合了Java的事件处理机制和消息中间件功能。SpringCloud Bus 目前支持RabbitMQ 和 Kafka
SpringCloud Bus总线能做什么？
SpringCloud Bus 能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改，事件推送等，也可以当做微服务间的通信通道。
什么是总线：
在微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以称它为消息总线。在总线上的各个实例，都可以方便的广播一些需要让其他连接在该主题上的实例都知道的消息，
基本原理：
ConfigClient 实例都监听 MQ 中同一个 topic （默认交换器是springCloudBus）。当一个服务刷新数据的时候，它会把这个信息放入到Topic中，这样其他监听同一个topic 的服务就能得到通知，然后去更新自己的配置。
10
Stream 消息驱动
Stream消息驱动 是什么
官方定义 SpringCloud Stream 是一个构建消息驱动微服务的框架
应用程序通过 inputs 或者 outputs 来与 SpringCloud Stream 中的 binder 对象交互
通过我们配置来binding（绑定），而SpringCloud Stream 的 binder 对象负责与消息中间件交互。所以我们只需要搞清楚如何与SpringCloud Stream 交互就可以方便使用消息驱动的方式了。
通过Spring Integration 来连接消息代理中间件以实现消息事件驱动。
SpringCloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。SpringCloud Stream 目前只支持RabbitMQ和Kafka
简单来说：屏蔽底层消息中间件的差异，降低切换版本，统一消息的编程模型
官网：https://spring.io/projects/spring-cloud-stream#overview
SpringCloud Stream 是用于构建与共享信息传递系统链接的高度可伸缩的时间驱动微服务框架，该框架提供了一个灵活的编程模型，它建立在已经建立和熟悉的Spring和最佳实践上，包括支持持久化的发布-订阅、消费组以及消费分区这三个核心概念
具体API：https://cloud.spring.io/spring-cloud-static/spring-cloud-stream/3.0.1.RELEASE/reference/html/
Spring Cloud Stream中文指导手册：https://m.wang1314.com/doc/webapp/topic/20971999.html
设计思想
标准的MQ
生产者/消费者之间靠消息媒介传递信息内容：Message
消息必须走特定的通道：消息通道MessageChannel
消息通道里的消息如何被消费呢，谁负责收发处理：消息通道MessageChannel的子接口SubscribableChannel,由MessageHandler消息处理器订阅
标准的MQ图解：
为什么要用SpringCloud Stream
比如说我们用到了RabbitMQ 和 Kafka，由于这两个消息中间件的架构上的不同，像RabbitMQ 有 Exchange，Kafka 有Topic 和 Partitions分区。这些中间件的差异导致我们实际项目开发给我们造成一定的困扰，我们如果用了两个消息队列的其中一种，后面的业务需求，我们想往另外一种消息队列进行迁移，这时候无疑就是一场灾难，一大堆东西都要推到重新做，因为它跟我们的系统耦合了，这时候SpringCloud Stream 给我们提供了一种解耦合的方式。
SpringCloud Stream怎么统一消息中间件的底层差异
在没有绑定器这个概念的情况下，我们的SpringBoot应用要直接与消息中间件进行信息交互的时候，由于各个消息中间件的构建初衷不同，他们的实现细节上会有较大差异。通过定义绑定器作为中间层，完美地实现了应用程序与消息中间件之间的隔离。通过向应用程序暴露统一的Channel 通道，使得应用程序不需要再考虑各种不同的消息中间件的实现。
通过定义绑定器Binder 作为中间层，实现了应用程序 与消息中间件细节之间的隔离
binder
在没有绑定器这个概念的情况下，我们的SpringBoot应用要直接与消息中间件进行信息交互的时候，由于各个消息中间件的构建初衷不同，他们的实现细节上会有较大差异，通过定义绑定器Binder 作为中间层，实现了应用程序 与消息中间件细节之间的隔离。Stream对消息中间件的进一步封装，可以做到代码层面对中间件的无感知，甚至动态地切换中间件（RabbitMQ切换为Kafka），使得微服务开发的高度解耦，服务可以关注更多自己的业务流程
图解：
Stream中的消息通信方式遵循了发布-订阅模式：Topic主题进行广播
在RabbitMQ就是Exchange
在kafka中就是Topic
SpringCloud Stream 标准流程
Binder：很方便的连接中间件，屏蔽差异
Channel：通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过对Channel对队列进行配置
Source和Sink：简单的可理解为参照对象是Spring Cloud Stream自身，从Stream发布消息就是输出，接受消息就是输入
图解：
编码API和常用注解
Middleware：中间件，目前只支持RabbitMQ和Kafka
Binder：Binder是应用于消息中间件之间的封装，目前实现了RabbitMQ和Kafka的Binder，通过Binder 可以很方便的连接中间件，可以动态改变消息类型（对于Kafka的Topic，RabbitMQ的Exchange），这些都可以通过配置文件来实现
@Input：注解标识输入通道，通过该输入通道接受到的消息进入应用程序
@Output：注解标识输出通道，发布的消息将通过该通道离开应用程序
@StreamListener：监听队列，用于消费者的队列消息接收
@EnableBinding：指信道channel和Exchange绑定在一起
11
Sleuth 请求链路追踪
为什么会出现这个技术？需要解决哪些问题？
在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求的最后失败
SpringCloud Sleuth 是什么
官网：https://github.com/spring-cloud/spring-cloud-sleuth
Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案
在分布式系统中提供追踪解决方案并且兼容支持了zipkin
12
SpringCloud Alibaba-Nacos 服务注册和配置中心
Nacos 是什么
一个更易于构建云原生应用的动态服务发现，配置管理和服务管理中心。
Nacos就是注册中心+配置中心的组合。等价于Eureka+Config+Bus
Nacos能干什么
替代Eureka做服务注册中心
替代Config做服务配置中心
官方文档
Nocas 源码：https://github.com/alibaba/Nacos
Nocas 文档：https://nacos.io/zh-cn/index.html
各种注册中心比较
据说 Nocas 在阿里巴巴内部有超过 10 万的实例在运行，已经通过了类似双十一等各种大型流量的考验
13
SpringCloud Alibaba-Sentinel 熔断与限流
官网：
官网：https://github.com/alibaba/Sentinel
中文官网：https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D
Sentinel 是什么
随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。就相当于前面的 Hystrix
Sentinel 的能干嘛
Sentinel 怎么使用
服务雪崩
服务降级
服务熔断
服务限流
14
SpringCloud Alibaba-Seata 分布式事务处理
能干嘛：一个典型的分布式事务过程
分布式事务处理过程的-ID+三组件模型
Transaction ID XID：全局唯一的事务ID
3组件概念
Transaction Coordinator(TC)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚;
Transaction Manager(TM)：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议;
Resource Manager(RM)：控制分支事务，负责分支注册，状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚；
处理过程
TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID
XID 在微服务调用链路的上下文中传播
RM 向 TC 注册分支服务，将其纳入 XID 对应全局事务的管辖
TM 向 TC 发起针对 XID 的全局提交或回滚协议
TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求
图解：
下载：https://github.com/seata/seata/releases
怎么用
在 Spring 中控制本地事务使用 @Transactional 注解
在分布式服务中，使用全局 @GlobalTransactional
15
技术比较
CAP 概念
C:Consistency(强一致性)
A:Availability(可用性)
tolerance(分区容错)
CAP理论关注粒度是数据，而不是整体系统设计的策略
经典CAP图解
CAP 最多只能同时教好的满足两个
CAP 理论的核心是：一个分布式系统不可能同时很好的满足一致性、 可用性和分区容错性这三个需求。因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类
CA：单点集群，满足一致性、可用性的系统，通常在可扩展性上不太强大
CP：满足一致性、分区容错性的系统，通常性能不是特别高
AP：满足可用性、分区容错性，通常可能对一致性要求比较低
AP（Eureka）：
AP架构：当网络分区出现后，为了保证可用性，系统B可以返回旧值，保证系统可用性。
结论：违背了一致性 C 的要求，只满足可用性和分区容错性，即AP
CP(Zookeeper/Consul)
CP架构：当网络分区出现后，为了保证一致性，就必须拒绝接受请求，否则无法保证一致性
结论： 违背了可用性 A 的要求，只满足一致性和分区容错性。
扫码关注我
你们点点“分享”，给我充点儿电吧~