技术-2022-05-《Spring cloud Alibaba全解》
| 创建时间： | 2022/5/22 15:21 |
|---|---|
| 更新时间： | 2023/2/17 8:52 |
| 作者： | HelloXF |
| 标签： | 知识库, |
[](技术-2022-05-《Spring
cloud Alibaba全解》_files/spring cloud alibaba全解 (1).pdf)
第一章 微服务的介绍
1.1系统架构的演变
1.1.1单体应用架构
优点：
项目架构简单，小型项目的话， 开发成本低
项目部署在一个节点上， 维护方便
缺点：
全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
项目模块之间紧密耦合，单点容错率低
无法针对不同模块进行针对性优化和水平扩展
1.1.2垂直应用架构
随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会有比较大的访问量。
还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块的影响就比较小.那么此时我们希望只多增加几个订单模块，
而不增加消息模块.此时单体应用就做不到了， 垂直应用就应运而生了。
所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可以将上面电商的单体应用拆分成:
电商系统(用户管理 商品管理 订单管理)
后台系统(用户管理 订单管理 客户管理)
CMS系统(广告管理 营销管理)
这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。
1.1.3分布式架构
当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
优点：
抽取公共的功能为服务层，提高代码复用性
缺点：
系统间耦合度变高，调用关系错综复杂，难以维护
1.1.4 SOA架构(面向服务)
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA
Service OrientedArchitecture，面向服务的架构)是关键。
优点:
使用注册中心解决了服务间调用关系的自动调节
缺点:
服务间会有依赖关系，一旦某个环节出错会影响较大(服务雪崩)
服务关心复杂，运维、测试部署困难
1.1.5微服务架构
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。
优点：
服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
微服务之间采用Restful等轻量级http协议相互调用
缺点：
分布式系统开发的技术成本高（容错、分布式事务等）
1.2微服务架构介绍
1.2.1微服务架构的常见问题
一旦采用微服务系统架构，就势必会遇到这样几个问题：
这么多小服务，如何管理他们？(服务治理 注册中心[服务注册 发现 剔除])
这么多小服务，他们之间如何通讯？(restfulrpc) remote procedure call
这么多小服务，客户端怎么访问他们？(网关)
这么多小服务，一旦出现问题了，应该如何自处理？(容错)
这么多小服务，一旦出现问题了，应该如何排错? (链路追踪)
对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问
题提供了相应的组件来解决它们。
1.2.2微服务架构的常见概念
1.2.2.1服务治理
服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。
服务注册：服务实例将自身服务信息注册到注册中心。
服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提
供的服务。
服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。
1.2.2.2服务调用
在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于 HTTP的RESTful接口以及基于TCP的RPC协议。
REST(Representational State Transfer)：这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议
RPC（Remote Promote
Call）：一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
RPC可以通过 HTTP 来实现,也可以通过Socket自己实现一套协议来实现.
1.2.2.3服务网关
API网关直面意思是将所有API调用统一接入到API网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。
1.2.2.4服务容错
在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：
不被外界环境影响
不被上游请求压垮
不被下游响应拖垮
1.2.2.5链路追踪
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪
1.2.3微服务架构的常见解决方案
1.2.3.1 ServiceComb
Apache ServiceComb，前身是华为云的微服务引擎CSE (Cloud Service
Engine)云服务，是全球首个Apache微服务顶级项目。它提供了一站式的微服务开源解决方案，致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。
1.2.3.2 SpringCloud
Spring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如
服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等 ， 都可以用Spring Boot的开发风格做到一键启动和部署 。
Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring
Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
1.2.3.3 SpringCloud Alibaba
Spring Cloud Alibaba致力于 提供微服务开发的一站式解决方案 。此项目包含开发分布式应用微服务的必需组件，方便开发者通过
Spring Cloud编程模型轻松使用这些组件来开发分布式应用服务。
1.3 SpringCloud Alibaba介绍
1.3.1主要功能
服务限流降级：默认支持WebServlet、WebFlux，OpenFeign、RestTemplate、Spring
CloudGateway，Zuul，Dubbo和RocketMQ限流降级功能的接入，可以在运行时通过控制台
实时修改限流降级规则，还支持查看限流降级Metrics监控。
服务注册与发现：适配Spring Cloud服务注册与发现标准，默认集成了Ribbon的支持。
分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。
消息驱动能力：基于Spring Cloud Stream为微服务应用构建消息驱动能力。
分布式事务：使用@GlobalTransactional注解， 高效并且对业务零侵入地解决分布式事务问题。
阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任
何时间、任何地点存储和访问任意类型的数据。
分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于Cron表达式）任务调度服务。
同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有
Worker（schedulerx-client）上执行。
阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建
客户触达通道。
1.3.2组件
Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳
定性。
Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠
的消息发布与订阅服务。
Dubbo：Apache Dubbo™是一款高性能Java RPC框架。
Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心
产品。
Alibaba Cloud OSS:阿里云对象存储服务（Object Storage Service，简称OSS），是阿里云提
供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和
访问任意类型的数据。
Alibaba Cloud SchedulerX:阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精
准、高可靠、高可用的定时（基于Cron表达式）任务调度服务。
Alibaba Cloud SMS:覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速
搭建客户触达通道。
第二章 微服务环境搭建
第三章 Nacos Discovery--服务治理
3.1服务治理介绍
先来思考一个问题
通过上一章的操作，我们已经可以实现微服务之间的调用。但是我们把服务提供者的网络地址（ip，端口）等硬编码到了代码中，这种做法存在许多问题：
一旦服务提供者地址变化，就需要手工修改代码
一旦是多个服务提供者，无法实现负载均衡功能
一旦服务变得越来越多，人工维护调用关系困难
那么应该怎么解决呢， 这时候就需要通过注册中心动态的实现服务治理。
什么是服务治理
服务治理是微服务架构中最核心最基本的模块。用于实现各个微服务的自动化注册与发现。
服务注册：在服务治理框架中，都会构建一个注册中心，每个服务单元向注册中心登记自己提供服务的详细信息。并在注册中心形成一张服务的清单，服务注册中心需要以心跳的方式去监测清单中的服务是否可用，如果不可用，需要在服务清单中剔除不可用的服务。
服务发现：服务调用方向服务注册中心咨询服务，并获取所有服务的实例清单，实现对具体服务实例的访问。
通过上面的调用图会发现，除了微服务，还有一个组件是服务注册中心，它是微服务架构非常重要的一个组件，在微服务架构里主要起到了协调者的一个作用。注册中心一般包含如下几个功能：
1.服务发现：
服务注册：保存服务提供者和服务调用者的信息
服务订阅：服务调用者订阅服务提供者的信息，注册中心向订阅者推送提供者的信息
2.服务配置：
配置订阅：服务提供者和服务调用者订阅微服务相关的配置
配置下发：主动将配置推送给服务提供者和服务调用者
3.服务健康检测
检测服务提供者的健康情况，如果发现异常，执行服务剔除
常见的注册中心
Zookeeper
zookeeper是一个分布式服务框架，是Apache
Hadoop的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Eureka
Eureka是Springcloud Netflflix中的重要组件，主要作用就是做服务注册和发现。但是现在已经闭源
Consul
Consul是基于GO语言开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务发现和配置管理的功能。Consul的功能都很实用，其中包括：服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等特性。Consul本身只是一个二进制的可执行文件，所以安装和部署都非常简单，只需要从官网下载后，在执行对应的启动脚本即可。
Nacos
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。它是SpringCloud
Alibaba组件之一，负责服务注册发现和服务配置，可以这样认为 nacos=eureka+confifig。
Spring Cloud Alibaba Nacos Confifig是Spring Cloud Alibaba的子项目，而Spring Cloud
Alibaba是阿里巴巴公司提供的开源的基于Spring cloud的微服务套件合集，它致力于提供微服务开发的一站式解决方案，可以理解为spring
cloud是一套微服务开发的 标准 ，spring cloud alibaba与spring cloud Netflflix是实现。 使用 Spring
Cloud Alibaba方案，开发者只需要添加一些注解和少量配置，就可以将 Spring Cloud
应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。
3.2 nacos简介
Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。从上面的介绍就可以看出，nacos的作用就是一个注册中心，用来管理注册上来的各个微服务。
3.3.1搭建nacos环境
3.3.2将商品微服务注册到nacos
接下来开始修改shop-product模块的代码， 将其注册到nacos服务上
1在pom.xml中添加nacos的依赖
2在主类上添加@EnableDiscoveryClient注解
@SpringBootApplication
@EnableDiscoveryClient
public class ProductApplication
3在application.yml中添加nacos服务的地址
spring:
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848
log.info(">>客户下单，这时候要调用商品微服务查询商品信息");
//从nacos中获取服务地址
ServiceInstance serviceInstance=
discoveryClient.getInstances("service-product").get(0);
Stringurl=serviceInstance.getHost()+":"+serviceInstance.getPort();
log.info(">>从nacos中获取到的微服务地址为:"+url);
//通过restTemplate调用商品微服务
Product
product=restTemplate.getForObject("http://"+url+"/product/"+pid,Product.class);
log.info(">>商品信息,查询结果:"+JSON.toJSONString(product));
Order order=newOrder();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(product.getPid());
DiscoveryClient是专门负责服务注册和发现的，我们可以通过它获取到注册到注册中心的所有服
务
3.4实现服务调用的负载均衡
3.4.1什么是负载均衡
通俗的讲， 负载均衡就是将负载（工作任务，访问请求）进行分摊到多个操作单元（服务器,组件）上
进行执行。
根据负载均衡发生位置的不同,一般分为服务端负载均衡和客户端负载均衡。
服务端负载均衡指的是发生在服务提供者一方,比如常见的nginx负载均衡而客户端负载均衡指的是发生在服务请求的一方，也就是在发送请求之前已经选好了由哪个实例处理请
求。
3.4.2自定义实现负载均衡
//从nacos中获取服务地址
//自定义规则实现随机挑选服务
List
product");
i nt index = new Random().nextInt(instances.size());
ServiceInstance serviceInstance = instances.get(index);
String url = serviceInstance.getHost() + ":" +serviceInstance.getPort();
log.info(">>从nacos中获取到的微服务地址为:" + url);
3.4.3基于Ribbon实现负载均衡
Ribbon是Spring Cloud的一个组件， 它可以让我们使用一个注解就能轻松的搞定负载均衡
第1步：在RestTemplate的生成方法上添加@LoadBalanced注解
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
第2步：修改服务调用的方法
log.info(">>客户下单，这时候要调用商品微服务查询商品信息");
//直接使用微服务名字， 从nacos中获取服务地址
Stringurl="service-product";
//通过restTemplate调用商品微服务
Product
product=restTemplate.getForObject("http://"+url+"/product/"+pid,Product.class);
log.info(">>商品信息，查询结果:"+JSON.toJSONString(product));
Ribbon支持的负载均衡策略
Ribbon内置了多种负载均衡策略,内部负载均衡的顶级接口为com.netflflix.loadbalancer.IRule ,具体的
负载策略如下图所示:
我们可以通过修改配置来调整Ribbon的负载均衡策略，具体代码如下
3.5基于Feign实现服务调用
3.5.1什么是Feign
Feign是Spring Cloud提供的一个声明式的伪Http客户端， 它使得调用远程服务就像调用本地服务一样简单，
只需要创建一个接口并添加一个注解即可。
Nacos很好的兼容了Feign，Feign默认集成了Ribbon， 所以在Nacos下使用Fegin默认就实现了负载均衡的效果。
3.5.2 Feign的使用
1加入Fegin的依赖
2在主类上添加Fegin的注解
@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients//开启Fegin
public classOrderApplication{}
3创建一个service， 并使用Fegin实现微服务调用
@FeignClient("service-product")//声明调用的提供者的name
public interfaceProductService{
//指定调用提供者的哪个方法
//@FeignClient+@GetMapping就是一个完整的请求路径http://service-
product/product/{pid}
@GetMapping(value="/product/{pid}")
Product findByPid(@PathVariable("pid")Integerpid);
}
4修改controller代码，并启动验证
log.info(">>客户下单,这时候要调用商品微服务查询商品信息");
//通过fegin调用商品微服务
Product product=productService.findByPid(pid);
log.info(">>商品信息,查询结果:"+JSON.toJSONString(product));
第四章 Sentinel 服务容错
4.1高并发带来的问题
在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因
或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现
网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。
3接下来使用压测工具,对请求进行压力测试
下载地址https:/ /jmeter. apache.org/
结论: 此时会发现,由于order方法囤积了大量请求,导致ｍessage方法的访问出现了问题，这就是服务雪崩的 雏形
4.2服务雪崩效应
在分布式系统中,由于网络原因或自身的原因,服务一般无法保证100%可用。如果一个服务出现了问
题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等待， 进而导致服务瘫痪。
由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务 故障的“雪崩效应”。
雪崩发生的原因多种多样，有不合理的 容量设计 ，或者是 高并发下某一个方法响应变慢 ，亦或是某台机 器的 资源耗尽
。我们无法完全杜绝雪崩源头的发生，只有做好足够的容错，保证在一个服务发生问题， 不会影响到其它服务的正常运行。也就是＂ 雪落而不雪崩 ＂。
4.3常见容错方案
要防止雪崩的扩散，我们就要做好服务的容错，容错说白了就是保护自己不被猪队友拖垮的一些措施, 下面介绍常见的服务容错思路和组件。
常见的容错思路 常见的容错思路有 隔离、超时、限流、熔断、降级 这几种，下面分别介绍一下。
隔离
它是指将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。当有故障发
生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的系统服 务。常见的隔离方式有： 线程池隔离和信号量隔离．
隔离：
针对不同的服务资源做的限制不会影响到其它服务，例如商城应用有AB两个接口，A接口只允许10个线程访问，B接口允许20个，他们两个应该是互不干扰的服务资源，也就是A接口调用满了不会影响B接口调用。
如果不对AB两个接口做资源隔离，只对商城应用做一个大的限制（30）的话，有可能会因为A接口执行较慢，导致占满了30个线程，导致B接口不可用（因为整体应用只允许30）。
线程池隔离就是把请求扔给不同的资源（也就是要调用的服务，针对每个服务都创建线程池）的线程池，让线程池创建线程去调用服务执行任务，具体的线程数由线程池做限制，而使用信号量，真实的工作线程就是由我们自己创建的，执行任务时通过信号量做一个数量的限制。
如果限流与熔断的资源的粒度较细，例如接口级别或者一段代码，再用线程池做资源隔离的开销就会较大（要创建过多的线程池），同时大量的线程上下文切换会导致机器负载过高。
这时候如果用semaphore信号量针对每个小资源都做一个计数器，同时请求与处理结果返回都在一条线程（会阻塞），就不需要进行线程的上下文切换，开销就会小很多。
但是信号量隔离是同步请求，会阻塞调用方线程，自身不支持超时熔断，只能等待请求超时一般的限流熔断器组件都会有隔离方式可以配置选择，可以根据实际业务场景选择
超时
在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，就断 开请求，释放掉线程。
限流
限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行,一旦达到的需要 限制的阈值,就需要限制流量并采取少量措施以完成限制流量的目的
熔断
在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可
用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断
服务熔断一般有三种状态：
熔断关闭状态（Closed）
服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制
熔断开启状态（Open）
后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法
半熔断状态（Half-Open）
尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预期，则说明服
务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断关闭状态。
降级
降级其实就是为服务提供一个托底方案，一旦服务无法正常调用，就使用托底方案
常见的容错组件
Hystrix
Hystrix是由Netflflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联 失败，从而提升系统的可用性与容错性。
Resilience4J
Resilicence4J一款非常轻量、简单，并且文档非常清晰、丰富的熔断工具，这也是Hystrix官方推荐的替
代产品。不仅如此，Resilicence4j还原生支持Spring Boot 1.x/2.x，而且监控也支持和prometheus等 多款主流产品进行整合。
Sentinel
Sentinel是阿里巴巴开源的一款断路器实现，本身在阿里内部已经被大规模采用，非常稳定。
4.4 Sentinel入门
4.4.1什么是Sentinel
Sentinel (分布式系统的流量防卫兵)是阿里开源的一套用于服务容错的综合性解决方案。它以流量
为切入点,从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性。
Sentinel具有以下特征:
丰富的应用场景：Sentinel承接了阿里巴巴近10年的双十一大促流量的核心场景,例如秒杀（即
突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用 应用等。
完备的实时监控：Sentinel提供了实时的监控功能。通过控制台可以看到 接入应用的单台机器秒 级数据 ,甚至
500台以下规模的集群的汇总运行情况 。
广泛的开源生态：Sentinel提供开箱即用的与其它开源框架/库的整合模块,例如与 SpringCloud、 Dubbo、gRPC的整合
。只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。
完善的SPI扩展点：Sentinel提供简单易用、完善的SPI扩展接口。您可以通过实现扩展接口来快 速地定制逻辑。例如定制规则管理、适配动态数据源等
Sentinel分为两个部分:
核心库（Java客户端）不依赖任何框架/库,能够运行于所有Java运行时环境，同时对Dubbo /Spring Cloud等框架也有较好的支持。
控制台（Dashboard）基于Spring Boot开发，打包后可以直接运行，不需要额外的Tomcat等 应用容器。
4.4.2微服务集成Sentinel
1为微服务集成Sentinel非常简单,只需要加入Sentinel的依赖即可 1在pom.xml中加入下面依赖
2编写一个Controller测试使用
@RestController
@Slf4j public class OrderController3
{
@RequestMapping("/order/message1")
public String message1() { return "message1"; }
@ RequestMapping("/order/message2")
public String message2() { return "message2"; }
}
4.4.3安装Sentinel控制台
Sentinel提供一个轻量级的控制台,它提供机器发现、单机资源实时监控以及规则管理等功能。 1下载jar包,解压到文件夹
https://github.com/alibaba/Sentinel/releases 2启动控制台
直接使用jar命令启动项目(控制台本身是一个SpringBoot项目)
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -
Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.7.0.jar
4.4.4实现一个接口的限流
1通过控制台为message1添加一个流控规则
2通过控制台快速频繁访问,观察效果
4.5 Sentinel的概念和功能
4.5.1基本概念
资源
资源就是Sentinel要保护的东西 资源是Sentinel的关键概念。它可以是Java应用程序中的任何内容，可以是一个服务，也可以是一个
方法，甚至可以是一段代码。 我们入门案例中的message1方法就可以认为是一个资源
规则
规则就是用来定义如何进行保护资源的 作用在资源之上,定义以什么样的方式保护资源，主要包括流量控制规则、熔断降级规则以及系统保护 规则 。
我们入门案例中就是为message1资源设置了一种流控规则,限制了进入message1的流量
4.5.2重要功能
流量控制
流量控制在网络传输中是一个常用的概念，它用于调整网络包的数据。任意时间到来的请求往往是随机
不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。Sentinel作为 一个调配器，可以根据需要把随机的请求调整成合适的形状。
熔断降级
当检测到调用链路中某个资源出现不稳定的表现，例如请求响应时间长或异常比例升高的时候，则对这
个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联故障
Sentinel对这个问题采取了两种手段:
通过并发线程数进行限制
Sentinel通过限制资源并发线程的数量，来减少不稳定资源对其它资源的影响。当某个资源出现不稳定
的情况下，例如响应时间变长，对资源的直接影响就是会造成线程数的逐步堆积。当线程数在特定资源
上堆积到一定的数量之后，对该资源的新请求就会被拒绝。堆积的线程完成任务后才开始继续接收请 求。
通过响应时间对资源进行降级
除了对并发线程数进行控制以外，Sentinel还可以通过响应时间来快速降级不稳定的资源。当依赖的资
源出现响应时间过长后，所有对该资源的访问都会被直接拒绝，直到过了指定的时间窗口之后才重新恢 复。 Sentinel和Hystrix的区别
两者的原则是一致的,都是当一个资源出现问题时,让其快速失败,不要波及到其它服务但是在限制的手段上,确采取了完全不一样的方法:
Hystrix采用的是线程池隔离的方式,优点是做到了资源之间的隔离,缺点是增加了线程切换 的成本。
Sentinel采用的是通过并发线程的数量和响应时间来对资源做限制。
系统负载保护 Sentinel同时提供系统维度的自适应保护能力。当系统负载较高的时候，如果还持续让请求进入
可能会导致系统崩溃，无法响应。在集群环境下，会把本应这台机器承载的流量转发到其它的机器 上去。如果这个时候其它的机器也处在一个边缘状态的时候，
Sentinel提供了对应的保护机制， 让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求
Hystrix原理
执行流程讲解：
通过配置或注解的方式构建Hystrix的Command对象，调用执行方法
Hystrix会检查当前服务的熔断器是否开启，若开启，则执行降级逻辑Fallback方法。
若熔断器开关关闭，则Hystrix检查当前熔断器的线程池是否能接收新的请求，若线程池已满则拒绝请求，执行降级熔断逻辑，并上报Metrices。（注：不同熔断器可以共用一个线程池，线程池名称不同的话是相互隔离的，commandKey区分熔断器，threadPoolKey区分线程池）
若线程池接收请求，则Hystrix调用服务逻辑的run方法。
若服务执行失败则执行降级逻辑，并上传Metrices。
若服务执行超时则执行降级逻辑，并上传Metrices。
若执行成功则直接返回结果。
滑动时间窗口讲解
滑动时间窗口策略：不断收集数据，达到条件就熔断；熔断后拒绝所有请求一段时间
(sleepWindow)；然后放一个请求过去，如果请求成功，则关闭熔断器，否则继续打开熔断器。
滑动事件窗口配置。
metrics相关配置：
metrics.rollingStats.timeInMilliseconds
表示滑动窗口的时间(the duration of the statistical rolling
window)，默认10000(10s)，也是熔断器计算的基本单位。
metrics.rollingStats.numBuckets
滑动窗口的Bucket数量(the number of buckets the rolling statistical window is divided
into)，默认10. （注：每个Bucket中包含了请求的总数，失败数，超时数，拒绝数。滑动时间窗口内所有的Bucket的总的失败请求/总请求=失败率）
timeInMilliseconds和numBuckets可以计算出每个Bucket的时长。
metrics.rollingStats.timeInMilliseconds % metrics.rollingStats.numBuckets 必须等于
0，否则将抛异常。
熔断器的相关配置。
circuitBreaker.requestVolumeThreshold
滑动窗口触发熔断的最小请求数。如果值是20，但滑动窗口的时间内请求数只有19，那即使19个请求全部失败，也不会熔断，必须达到这个值才行，否则样本太少，没有意义。
circuitBreaker.sleepWindowInMilliseconds
这个和熔断器自动恢复有关，为了检测后端服务是否恢复，可以放一个请求过去试探一下。sleepWindow指的发生熔断后，必须隔sleepWindow这么长的时间，才能放请求过去试探下服务是否恢复。默认是5s
circuitBreaker.errorThresholdPercentage
错误率阈值，表示达到熔断的条件。比如默认的50%，当一个滑动窗口内，失败率达到50%时就会触发熔断。
讲解：
所有的请求不论请求失败成功都会上传至metrics，metrics就是用来记录请求状态的数据中心。是否开启熔断都是通过metrics中统计的请求失败率来计算的，就是滑动窗口时间内请求的失败率。如滑动事件窗口为10秒，熔断器熔断阈值为50%，这10秒内来了100个请求，失败了30个，没有达到条件，若失败了60则失败率为60%会打开熔断器。但如果设置最小请求数为20，即使总请求数为19并且全失败也不会触发熔断，这是为了保护因网络连接导致的请求失败问题。
服务有可能因各种原因失败，所以会有重新可用的可能性，Hystrix都在sleepWindowInMilliseconds时间后放过一个请求，若请求成功则关闭熔断器，若失败则继续过一段时间放过请求。
4.6 Sentinel规则
4.6.1流控规则
流量控制，其原理是监控应用流量的QPS(每秒查询率)或并发线程数等指标，当达到指定的阈值时对流
量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
第1步:点击簇点链路，我们就可以看到访问过的接口地址，然后点击对应的流控按钮，进入流控规则配 置页面。新增流控规则界面如下:
资源名：唯一名称，默认是请求路径，可自定义
针对来源：指定对哪个微服务进行限流，默认指default，意思是不区分来源，全部限制
阈值类型单机阈值：
QPS（每秒请求数量）:当调用该接口的QPS达到阈值的时候，进行限流
线程数：当调用该接口的线程数达到阈值的时候，进行限流
是否集群：暂不需要集群 接下来我们以QPS为例来研究限流规则的配置。
4.6.1.1简单配置
我们先做一个简单配置，设置阈值类型为QPS，单机阈值为3。即每秒请求量大于3的时候开始限流。接 下来，在流控规则页面就可以看到这个配置。
4.6.1.2配置流控模式
点击上面设置流控规则的编辑按钮，然后在编辑页面点击高级选项，会看到有流控模式一栏
sentinel共有三种流控模式，分别是：
直接（默认）： 接口达到限流条件时，开启限流
关联： 当关联的资源达到限流条件时，开启限流[适合做应用让步]
链路： 当从某个接口过来的资源达到限流条件时，开启限流
下面呢分别演示三种模式：
直接流控模式
直接流控模式是最简单的模式，当指定的接口达到限流条件时开启限流。上面案例使用的就是直接流控 模式。
关联流控模式
关联流控模式指的是，当指定接口关联的接口达到限流条件时，开启对指定接口开启限流。第1步：配
置限流规则,将流控模式设置为关联，关联资源设置为的/order/message2。
压测工具 postman jmeter
链路流控模式
链路流控模式指的是，当从某个接口过来的资源达到限流条件时，开启限流。它的功能有点类似于针对
来源配置项，区别在于：针对来源是针对上级微服务，而链路流控是针对上级接口，也就是说它的粒度 更细。 第1步：
编写一个service，在里面添加一个方法message
@Service public classOrderServiceImpl3{
@SentinelResource("message")
publicvoidmessage() { System.out.println("message"); } }
第2步： 在Controller中声明两个方法，分别调用service中的方法m
4.6.1.3配置流控效果
快速失败（默认）:直接失败，抛出异常，不做任何额外的处理，是最简单的效果
Warm Up：它从开始阈值到最大QPS阈值会有一个缓冲阶段，一开始的阈值是最大QPS阈值的
1/3，然后慢慢增长，直到最大阈值，适用于将突然增大的流量转换为缓步增长的场景。
排队等待：让请求以均匀的速度通过，单机阈值为每秒通过数量，其余的排队等待； 它还会让设 置一个超时时间，当请求超过超时间时间还未处理，则会被丢弃
4.6.2降级规则
降级规则就是设置当满足什么条件的时候，对服务进行降级。Sentinel提供了三个衡量条件：
平均响应时间 ：当资源的平均响应时间超过阈值（以ms为单位）之后，资源进入准降级状态。
如果接下来1s内持续进入5个请求，它们的RT都持续超过这个阈值，那么在接下的时间窗口 （以s为单位）之内，就会对这个方法进行服务降级。
异常比例 ：当资源的每秒异常总数占通过量的比值超过阈值之后，资源进入降级状态，即在接下的
时间窗口（以s为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0,1.0]。
异常数 ：当资源近1分钟的异常数目超过阈值之后会进行服务降级。注意由于统计时间窗口是分
钟级别的，若时间窗口小于60s，则结束熔断状态后仍可能再进入熔断状态。
4.6.3热点规则
第3步:分别用两个参数访问,会发现只对第一个参数限流了
4.7 @SentinelResource的使用
在定义了资源点之后，我们可以通过Dashboard来设置限流和降级策略来对资源点进行保护。同时还能
通过@SentinelResource来指定出现异常时的处理策略。
@SentinelResource用于定义资源，并提供可选的异常处理和fallback配置项。其主要参数如下:
定义限流和降级后的处理方法 方式一：直接将限流和降级方法定义在方法中
@Service
@Slf4j public class OrderServiceImpl3{
inti=0;
@SentinelResource(
value="message",
blockHandler="blockHandler",
//指定发生BlockException时进入的方法
fallback="fallback"
//指定发生Throwable时进入的方法
)
publicStringmessage() { i++;
if(i%3==0) { throw newRuntimeException();
}r eturn"message";
}
/ /BlockException时进入的方法
public String blockHandler(BlockException ex) { log.error("{}",ex);
return"接口被限流或者降级了..."; }
/ /Throwable时进入的方法
public String fallback(Throwable throwable) { log.error("{}",throwable);
return"接口发生异常了..."; } }
方式二:将限流和降级方法外置到单独的类中
4.8 Sentinel规则持久化
通过前面的讲解，我们已经知道，可以通过Dashboard来为每个Sentinel客户端设置各种各样的规则，
但是这里有一个问题，就是这些规则默认是存放在内存中，极不稳定，所以需要将其持久化。
本地文件数据源会定时轮询文件的变更，读取规则。这样我们既可以在应用本地直接修改文件来更新规
则，也可以通过Sentinel控制台推送规则。以本地文件数据源为例，推送过程如下图所示：
首先Sentinel控制台通过API将规则推送至客户端并更新到内存中，接着注册的写数据源会将新的规则 保存到本地的文件中
代码：略
4.9 Feign整合Sentinel
第1步:引入sentinel的依赖
第2步:在配置文件中开启Feign对Sentinel的支持
第3步:创建容错类
public class ProductServiceFallBack implements ProductService{
第4步:为被容器的接口指定容错类
第5步:修改controller
第6步:停止所有shop-product服务,重启shop-order服务,访问请求,观察容错效果
第五章 gateway服务网关
5.1网关简介
大家都都知道在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么
多的微服务呢？如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调用。
这样的架构，会存在着诸多 的问题 ：
客户端多次请求不同的微服务，增加客户端代码或配置编写的复杂性
认证复杂，每个服务都需要独立认证。
存在跨域请求，在一定场景下处理相对复杂。
所谓的API网关，就是指系统的统一入口，它封装了应用程序的内部结构，为客户端提供统一服务，一 些与业务本身功能无关的公共逻辑可以在这里实现，
诸如认证、鉴权、监控、路由转发 等等。 添加上API网关之后，系统的架构图变成了如下所示：
在业界比较流行的网关，有下面这些：
Ngnix+lua ：使用 nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用 ，lua是一
种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本
Kong：基于Nginx+Lua开发，性能高，稳定，有多个可用的插件(限流、鉴权等等)可以开箱即 用。
问题：只支持Http协议；二次开发，自由扩展困难；提供管理API，缺乏更易用的管控、配置 方式。
Zuul ：Netflflix开源的网关，功能丰富，使用JAVA开发，易于二次开发 问题： 缺乏管控，无法动 态配置
；依赖组件较多；处理Http请求依赖的是Web容器， 性能不如Nginx
Spring Cloud Gateway ：Spring公司为了替换Zuul而开发的网关服务，将在下面具体介绍。
注意：SpringCloud alibaba技术栈中并没有提供自己的网关，我们可以采用Spring Cloud Gateway 来做网关
5.2 Gateway简介
优点：
性能强劲：是第一代网关 Zuul的1.6倍
功能强大：内置了很多实用的功能，例如 转发、监控、限流 等
设计优雅，容易扩展
缺点：
其实现依赖Netty与WebFlux，不是传统的Servlet编程模型，学习成本高
不能将其部署在Tomcat、Jetty等Servlet容器里，只能打成jar包执行 需要Spring Boot 2.0及以上的版本，才支持
5.3 Gateway快速入门
要求:通过浏览器访问api网关,然后通过网关将请求转发到商品微服务
第1步：创建一个api-gateway的模块,导入相关依赖
第2步:创建主类
第3步:添加配置文件
第4步:启动项目,并通过网关去访问微服务
5.3.2增强版
第1步：加入nacos依赖
第2步：在主类上添加注解
第3步：修改配置文件
5.3.3简写版
第1步:去掉关于路由的配置
第2步:启动项目，并通过网关去访问微服务
这时候，就发现只要按照网关地址微服务接口的格式去访问，就可以得到成功响应
5.4 Gateway核心架构
5.4.1基本概念 路由(Route)是gateway中最基本的组件之一，表示一个具体的路由信息载体。主要定义了下面的几个 信息:
id，路由标识符，区别于其他Route。
uri，路由指向的目的地uri，即客户端请求最终被转发到的微服务。
order，用于多个Route之间的排序，数值越小排序越靠前，匹配优先级越高。
predicate，断言的作用是进行条件判断，只有断言都返回真，才会真正的执行路由。
fifilter，过滤器用于修改请求和响应信息。
5.4.2执行流程
执行流程大体如下：
- Gateway Client向Gateway Server发送请求
2.请求首先会被HttpWebHandlerAdapter进行提取组装成网关上下文
3.然后网关的上下文会传递到DispatcherHandler，它负责将请求分发给 RoutePredicateHandlerMapping
- RoutePredicateHandlerMapping负责路由查找，并根据路由断言判断路由是否可用
5.如果过断言成功，由FilteringWebHandler创建过滤器链并调用
6.请求会一次经过PreFilter--微服务-PostFilter的方法，最终返回响应
5.5断言
5.5.1内置路由断言工厂
SpringCloud Gateway包括许多内置的断言工厂，所有这些断言都与HTTP请求的不同属性匹配。具体 如下：
基于Datetime类型的断言工厂
基于Cookie的断言工厂
CookieRoutePredicateFactory：接收两个参数，cookie名字和一个正则表达式。 判断请求cookie是否
具有给定名称且值与正则表达式匹配。
基于远程地址的断言工厂
RemoteAddrRoutePredicateFactory：接收一个IP地址段，判断请求主 机地址是否在地址段中
基于Header的断言工厂
HeaderRoutePredicateFactory：接收两个参数，标题名称和正则表达式。 判断请求Header是否具有 给定名称且值与正则表达式匹配。
基于Host的断言工厂
HostRoutePredicateFactory：接收一个参数，主机名模式。判断请求的Host是否满足匹配规则。
基于Method请求方法的断言工厂
MethodRoutePredicateFactory：接收一个参数，判断请求类型是否跟指定的类型匹配
基于Path请求路径的断言工厂
PathRoutePredicateFactory：接收一个参数，判断请求的URI部分是否满足路径规则。
基于Query请求参数的断言工厂
QueryRoutePredicateFactory：接收两个参数，请求param和正则表达式， 判断请求参数是否具有给 定名称且值与正则表达式匹配
基于路由权重的断言工厂
WeightRoutePredicateFactory：接收一个[组名,权重],然后对于同一个组内的路由按照权重转发
内置路由断言工厂的使用
5.5.2自定义路由断言工厂
我们来设定一个场景:假设我们的应用仅仅让age在(min,max)之间的人来访问。 第1步：在配置文件中,添加一个Age的断言配置
第2步：自定义一个断言工厂,实现断言方法
5.6过滤器
三个知识点:
1.作用:过滤器就是在请求的传递过程中,对请求和响应做一些手脚
2.生命周期: Pre Post
3.分类:局部过滤器(作用在某一个路由上)全局过滤器(作用全部路由上)
在Gateway中, Filter的生命周期只有两个：“pre”和“post”。
PRE： 这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择 请求的微服务、记录调试信息等。
POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
Gateway的Filter从作用范围可分为两种: GatewayFilter与GlobalFilter。
GatewayFilter：应用到单个路由或者一个分组的路由上。
GlobalFilter：应用到所有的路由上。
5.6.1局部过滤器
5.6.1.2自定义局部过滤
5.6.2全局过滤器
全局过滤器作用于所有路由,无需配置。通过全局过滤器可以 实现对权限的统一校验，安全性验证 等功 能
5.6.2.1内置全局过滤器
5.6.2.2自定义全局过滤器
开发中的鉴权逻辑：
当客户端第一次请求服务时，服务端对用户进行信息认证（登录）
认证通过，将用户信息进行加密形成token，返回给客户端，作为登录凭证
以后每次请求，客户端都携带认证的token
服务端对token进行解密，判断是否有效。
如上图，对于验证用户是否已经登录鉴权的过程可以在网关统一检验。 检验的标准就是请求中是否携带token凭证以及token的正确性。
下面的我们自定义一个GlobalFilter，去校验所有请求的请求参数中是否包含“token”，如何不包含请求
参数“token”则不转发路由，否则执行正常的逻辑。
5.7网关限流
网关是所有请求的公共入口，所以可以在网关进行限流，而且限流的方式也很多，我们本次采用前面学
过的Sentinel组件来实现网关的限流。Sentinel支持对SpringCloud Gateway、Zuul等主流网关进行限 流
基于Sentinel的Gateway限流是通过其提供的Filter来完成的，使用时只需注入对应的
SentinelGatewayFilter实例以及SentinelGatewayBlockExceptionHandler实例即可
从1.6.0版本开始，Sentinel提供了SpringCloud Gateway的适配模块，可以提供两种资源维度的限流：
route维度：即在Spring配置文件中配置的路由条目，资源名为对应的routeId
自定义API维度：用户可以利用Sentinel提供的API来自定义一些API分组
第六章Sleuth--链路追踪
6.1链路追踪介绍
在大型系统的微服务化构建中，一个系统被拆分成了许多模块。这些模块负责不同的功能，组合成系
统，最终可以提供丰富的功能。在这种架构中，一次请求往往需要涉及到多个服务。互联网应用构建在
不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、
有可能布在了几千台服务器，横跨多个不同的数据中心，也就意味着这种架构形式也会存在一些问题：
如何快速发现问题？
如何判断故障影响范围？
如何梳理服务依赖以及依赖的合理性？
如何分析链路性能问题以及实时容量规划？
分布式链路追踪（Distributed Tracing），就是将一次分布式请求还原成调用链路，进行日志记录，性
能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器 上、每个服务节点的请求状态等等。
常见的链路追踪技术有下面这些：
cat由大众点评开源
zipkin由Twitter公司开源
pinpoint:Pinpoint是韩国人开源的基于字节码注入的调用链分析
skywalking:SkyWalking是本土开源的基于字节码注入的调用链分析
Sleuth:SpringCloud提供的分布式系统中链路追踪解决方案
注意：SpringCloud alibaba技术栈中并没有提供自己的链路追踪技术的，我们可以采用Sleuth +Zinkin来做链路追踪解决方案
第七章Rocketmq--消息驱动
7.1 MQ简介
7.1.1什么是MQ
MQ（Message Queue）是一种跨进程的通信机制，用于传递消息。通俗点说，就是一个先进先出的数 据结构。
7.1.2 MQ的应用场景
7.1.2.1异步解耦
异步解耦是消息队列MQ的主要特点，主要目的 是减少请求响应时间和解耦 。主要的使用场景就是将比
较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时，由于使用了消息队列
MQ，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即 解耦合 。
7.1.2.2流量削峰
流量削峰也是消息队列MQ的常用场景，一般在秒杀或团队抢购(高并发)活动中使用广泛。在秒杀或团
队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在处理如此大量的访问流量后，下游
的通知系统无法承载海量的调用量，甚至会导致系统崩溃等问题而发生漏通知的情况。为解决这些问 题，可在应用和下游通知系统之间加入消息队列MQ。
7.1.3常见的MQ产品
ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。扩展性好，开发比较灵活，采用C语言实
现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅
提供非持久性的队列，也就是说如果down机，数据将会丢失。
RabbitMQ 使用erlang语言开发，性能较好，适合于企业级的开发。但是不利于做二次开发和维护。 ActiveMQ
历史悠久的Apache开源项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻
松融合，实现了多种协议，支持持久化到数据库，对队列数较多的情况支持不好。
RocketMQ 阿里巴巴的MQ中间件，由java语言开发，性能非常好，能够撑住双十一的大流量，而且使用起来很简 单。
Kafka Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，相对
于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。
7.2.2 RocketMQ的架构及概念
如上图所示，整体可以分成4个角色，分别是：NameServer，Broker，Producer，Consumer。
Broker(邮递员) :Broker是RocketMQ的核心，负责消息的接收，存储，投递等功能
NameServer(邮局): 消息队列的协调者，Broker向它注册路由信息，同时Producer和Consumer
向其获取路由信息Producer(寄件人)消息的生产者，需要从NameServer获取Broker信息，然后与 Broker建立连接，向Broker发送消息
Consumer(收件人): 消息的消费者，需要从NameServer获取Broker信息，然后与Broker建立连 接，从Broker获取消息
Topic(地区): 用来区分不同类型的消息，发送和接收消息前都需要先创建Topic，针对Topic来发送 和接收消息Message
Queue(邮件)为了提高性能和吞吐量，引入了Message Queue，一个Topic可 以设置一个或多个Message
Queue，这样消息就可以并行往各个Message Queue发送消息，消费 者也可以并行的从多个Message Queue读取消息
Message :Message是消息的载体。
Producer Group:生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。
Consumer Group:消费者组，消费同一类消息的多个consumer实例组成一个消费者组。
7.3消息发送和接收演示
7.3.1发送消息
消息发送步骤:
1.创建消息生产者,指定生产者所属的组名
2.指定Nameserver地址
3.启动生产者
4.创建消息对象，指定主题、标签和消息体
5.发送消息
6.关闭生产者
7.3.2接收消息
消息接收步骤:
1.创建消息消费者,指定消费者所属的组名
2.指定Nameserver地址
3.指定消费者订阅的主题和标签
4.设置回调函数，编写处理消息的方法
5.启动消息消费者
//接收消息
public class RocketMQReceiveTest {
public static void main(String[] args) throws MQClientException {
//1.创建消息消费者,指定消费者所属的组名
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("myconsumer-
group");
consumer.setNamesrvAddr("192.168.109.131:9876");
consumer.subscribe("myTopic", "*");
//4.设置回调函数，编写处理消息的方法
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage(List
msgs,
ConsumeConcurrentlyContext
context) {
System.out.println("Receive New Messages: " + msgs);
//返回消费状态
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
consumer.start();
System.out.println("Consumer Started.");
}
}
7.4案例
接下来我们模拟一种场景:下单成功之后，向下单用户发送短信。设计图如下：
7.4.1订单微服务发送消息
7.4.2用户微服务订阅消息
5启动服务，执行下单操作，观看后台输出
7.5发送不同类型的消息
7.5.1普通消息
RocketMQ提供三种方式来发送普通消息：可靠同步发送、可靠异步发送和单向发送。
可靠同步发送
同步发送是指消息发送方发出数据后，会在收到接收方发回响应之后才发下一个数据包的通讯方式。
此种方式应用场景非常广泛，例如重要通知邮件、报名短信通知、营销短信系统等。
可靠异步发送
异步发送是指发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。发送方通过回调接口接收服务器响应，并对响应结果进行处理。
异步发送一般用于链路耗时较长，对RT响应时间较为敏感的业务场景，例如用户视频上传后通知启动转码服务，转码完成后通知推送转码结果等。
单向发送
单向发送是指发送方只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求不等待应答。
适用于某些耗时非常短，但对可靠性要求并不高的场景，例如日志收集。
//测试
@RunWith(SpringRunner.class)
@SpringBootTest(classes=OrderApplication.class)
public classMessageTypeTest{
@Autowired
privateRocketMQTemplate rocketMQTemplate;
//同步消息
@Test
publicvoidtestSyncSend() {
//参数一: topic， 如果想添加tag可以使用"topic:tag"的写法
//参数二:消息内容
SendResult sendResult=
rocketMQTemplate.syncSend("test-topic-1","这是一条同步消息");
System.out.println(sendResult);
}
//异步消息
@Test
publicvoidtestAsyncSend()throwsInterruptedException{
publicvoidtestSyncSendMsg() {
//参数一: topic,如果想添加tag可以使用"topic:tag"的写法
//参数二:消息内容
//参数三:回调函数,处理返回结果
rocketMQTemplate.asyncSend("test-topic-1","这是一条异步消息",new
SendCallback() {
@Override
publicvoidonSuccess(SendResult sendResult) {
System.out.println(sendResult);
}
@Override
publicvoidonException(Throwable throwable) {
System.out.println(throwable);
}
}
);
//让线程不要终止
Thread.sleep(30000000);
}
//单向消息
@Test
publicvoidtestOneWay() {
rocketMQTemplate.sendOneWay("test-topic-1","这是一条单向消息");
}
}
7.5.2顺序消息
顺序消息是消息队列提供的一种严格按照顺序来发布和消费的消息类型
//同步顺序消息[异步顺序 单向顺序写法类似]
publicvoidtestSyncSendOrderly()
{
//第三个参数用于队列的选择
rocketMQTemplate.syncSendOrderly("test-topic-1","这是一条异步顺序消息",
"xxxx");
}
7.5.3事务消息
事务消息发送步骤：
1.发送方将半事务消息发送至RocketMQ服务端。
- RocketMQ服务端将消息持久化之后，向发送方返回Ack确认消息已经发送成功，此时消息为半事务消息。
3.发送方开始执行本地事务逻辑。
4.发送方根据本地事务执行结果向服务端提交二次确认（Commit或是Rollback），服务端收到Commit状态则将半事务消息标记为可投递，订阅方最终将收到该消息；服务端收到Rollback状态则删除半事务消息，订阅方将不会接受该消息。
事务消息回查步骤：
1.在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查。
2.发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
3.发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行操作。
7.6消息消费要注意的细节
@RocketMQMessageListener(
consumerGroup="shop",//消费者分组
topic="order-topic",//要消费的主题
consumeMode=ConsumeMode.CONCURRENTLY,//消费模式:无序和有序
messageModel=MessageModel.CLUSTERING,//消息模式:广播和集群,默认是集群
)
public classSmsServiceimplementsRocketMQListener
}
RocketMQ支持两种消息模式:
广播消费:每个消费者实例都会收到消息,也就是一条消息可以被每个消费者实例处理；
集群消费:一条消息只能被一个消费者实例消费
第八章SMS--短信服务
8.1短信服务介绍
短信服务（Short Message Service）是阿里云为用户提供的一种通信服务的能力。
产品优势：覆盖全面、高并发处理、消息堆积处理、开发管理简单、智能监控调度
产品功能：短信通知、短信验证码、推广短信、异步通知、数据统计
应用场景：短信验证码、系统信息推送、推广短信等
8.2短信服务使用
第九章Nacos Config--服务配置
9.1服务配置中心介绍
首先我们来看一下,微服务架构下关于配置文件的一些问题：
1.配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。
2.配置文件无法区分环境。微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。
3.配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。
基于上面这些问题，我们就需要配置中心的加入来解决这些问题。
配置中心的思路是：
首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。
当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。
当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。
当加入了服务配置中心之后，我们的系统架构图会变成下面这样
在业界常见的服务配置中心，有下面这些：
Apollo
Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料也写的很详细。
Disconf
Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效的。
SpringCloud Confifififig
这是Spring
Cloud中带的配置中心组件。它和Spring是无缝集成，使用起来非常方便，并且它的配置存储支持Git。不过它没有可视化的操作界面，配置的生效也不是实时的，需要重启或去刷新。
Nacos
这是SpingCloud
alibaba技术栈中的一个组件，前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能，我们可以直接使用它作为服务配置中心。
9.2 Nacos Confifig入门
使用nacos作为配置中心，其实就是将nacos当做一个服务端，将各个微服务看成是客户端，我们将各个微服务的配置文件统一存放在nacos上，然后各个微服务从nacos上拉取配置即可。
接下来我们以商品微服务为例，学习nacos confifififig的使用。
1.搭建nacos环境【使用现有的nacos环境即可】
2.在微服务中引入nacos的依赖
3在微服务中添加nacos confifififig的配置
注意:不能使用原来的application.yml作为配置文件，而是新建一个bootstrap.yml作为配置文件
配置文件优先级(由高到低):
bootstrap.properties -> bootstrap.yml -> application.properties ->
application.yml
spring:
application:
name: service-product
cloud:
nacos:
config:
server-addr: 127.0.0.1:8848 #nacos中心地址
file-extension: yaml #配置文件格式
profiles:
active: dev #环境标识
4在nacos中添加配置
5注释本地的application.yam中的内容， 启动程序进行测试
如果依旧可以成功访问程序，说明我们nacos的配置中心功能已经实现
9.3 Nacos Confifig深入
9.3.1配置动态刷新
在入门案例中，我们实现了配置的远程存放，但是此时如果修改了配置，我们的程序是无法读取到的，
因此，我们需要开启配置的动态刷新功能。
在nacos中的service-product-dev.yaml配置项中添加下面配置:
config:
appName: product
方式一:硬编码方式
@RestController
public classNacosConfigController{
@Autowired
privateConfigurableApplicationContext applicationContext;
@GetMapping("/nacos-config-test1")
publicStringnacosConfingTest1()
{
return
(applicationContext.getEnvironment().getProperty("config.appName")
);
}
}
方式二:注解方式(推荐)
@RestController
@RefreshScope/只需要在需要动态读取配置的类上添加此注解就可以/
public classNacosConfigController{
@Value("${config.appName}")
privateStringappName;
/* 2注解方式*/
@GetMapping("/nacos-config-test2")
publicStringnacosConfingTest2()
{
return(appName);
}
}
9.3.2配置共享
当配置越来越多的时候，我们就发现有很多配置是重复的，这时候就考虑可不可以将公共配置文件提取
出来，然后实现共享呢？当然是可以的。接下来我们就来探讨如何实现这一功能。
同一个微服务的不同环境之间共享配置
如果想在同一个微服务的不同环境之间实现配置共享，其实很简单。只需要提取一个以
spring.application.name命名的配置文件，然后将其所有环境的公共配置放在里面即可。
1新建一个名为service-product.yaml配置存放商品微服务的公共配置
2新建一个名为service-product-test.yaml配置存放测试环境的配置
4添加测试方法
@RestController
@RefreshScope
public classNacosConfigController{
@Value("${config.env}")
private String env;
/* 3同一微服务的不同环境下共享配置*/
@GetMapping("/nacos-config-test3")
publicStringnacosConfingTest3()
{
return(env);
}
}
9.4 nacos的几个概念
命名空间(Namespace)
命名空间可用于进行不同环境的配置隔离。一般一个环境划分到一个命名空间
配置分组(Group)
配置分组用于将不同的服务可以归类到同一分组。一般将一个项目的配置分到一组
配置集(Data ID)
在系统中，一个配置文件通常就是一个配置集。一般微服务的配置就是一个配置集
第十章Seata--分布式事务
10.1分布式事务基础
10.1.1事务
事务指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销。简单地说，事务提供一种“要么什么都不做，要么做全套”机制。
10.1.2本地事务
本地事物其实可以认为是数据库提供的事务机制。说到数据库事务就不得不说，数据库事务中的四大特性:
A： 原子性(Atomicity) ，一个事务中的所有操作，要么全部完成，要么全部不完成
C： 一致性(Consistency)
，在一个事务执行之前和执行之后数据库都必须处于一致性状态(事务的一致性是指事务执行前后,数据都是正确的,不存在矛盾。)
I： 隔离性(Isolation) ，在并发环境中，当不同的事务同时操作相同的数据时，事务之间互不影响
D： 持久性(Durability) ，指的是只要事务成功结束，它对数据库所做的更新就必须永久的保存下来
数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚
10.1.3分布式事务
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
本质上来说， 分布式事务就是为了保证不同数据库的数据一致性。
10.1.4分布式事务的场景
多个微服务访问同一个数据库
多个服务需要调用一个数据库实例完成数据的增删改操作
多个微服务访问多个数据库
10.2分布式事务解决方案
10.2.1全局事务
全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction
Processing Reference Model。它规定了要实现分布式事务，需要三种角色：
AP: Application应用系统(微服务)
TM: Transaction Manager事务管理器(全局事务管理)
RM: Resource Manager资源管理器(数据库)
整个事务分成两个阶段:
阶段一:表决阶段，所有参与者都将本事务执行预提交，并将能否成功的信息反馈发给协调者。
阶段二:执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地执行提交或者回
滚。
优点
提高了数据一致性的概率，实现成本较低
缺点
单点问题:事务协调者宕机
同步阻塞:延迟了提交时间，加长了资源阻塞时间
数据不一致:提交第二阶段，依然存在commit结果未知的情况，有可能导致数据不一致
10.2.2可靠消息服务
基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。假设有A和B两个系统，分别可以处理任务A和任务B。此时存在一个业务流程，需要将任务A和任务B在同一个事务中处理。就可以使用消息中间件来实现这种分布式事务。
第一步：消息由系统A投递到中间件
1.在系统A处理任务A前，首先向消息中间件发送一条消息
2.消息中间件收到后将该条消息持久化，但并不投递。持久化成功后，向A回复一个确认应答
3.系统A收到确认应答后，则可以开始处理任务A
4.任务A处理完成后，向消息中间件发送Commit或者Rollback请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了
5.如果消息中间件收到Commit，则向B系统投递消息；如果收到Rollback，则直接丢弃消息。但是
如果消息中间件收不到Commit和Rollback指令，那么就要依靠"超时询问机制"。
超时询问机制
系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。当消息中
间件收到发布消息便开始计时，如果到了超时没收到确认指令，就会主动调用系统A提供的事务询
问接口询问该系统目前的状态。该接口会返回三种结果，中间件根据三种结果做出不同反应：
-
提交:将该消息投递给系统B
-
回滚:直接将条消息丢弃
-
处理中:继续等待
第二步:消息由中间件投递到系统B
消息中间件向下游系统投递完消息后便进入阻塞等待状态，下游系统便立即进行任务的处理，任务处理完成后便向消息中间件返回应答。
-
如果消息中间件收到确认应答后便认为该事务处理完毕
-
如果消息中间件在等待确认应答超时之后就会重新投递，直到下游消费者返回消费成功响应为止。
一般消息中间件可以设置消息重试的次数和时间间隔，如果最终还是不能成功投递，则需要手工干预。这里之所以使用人工干预，而不是使用让Ａ系统回滚，主要是考虑到整个系统设计的复杂度问题。基于可靠消息服务的分布式事务，前半部分使用异步，注重性能；后半部分使用同步，注重开发成本。
10.2.3最大努力通知
最大努力通知也被称为定期校对，其实是对第二种解决方案的进一步优化。它引入了 本地消息表来记录错误消息 ，然后加入 失败消息的定期校对功能
，来进一步保证消息会被下游系统消费。
第一步:消息由系统A投递到中间件
1.处理业务的同一事务中，向本地消息表中写入一条记录
2.准备专门的消息发送者不断地发送本地消息表中的消息到消息中间件，如果发送失败则重试
第二步:消息由中间件投递到系统B
1.消息中间件收到消息后负责将该消息同步投递给相应的下游系统，并触发下游系统的任务执行
2.当下游系统处理成功后，向消息中间件反馈确认应答，消息中间件便可以将该条消息删除，从而该事务完成
3.对于投递失败的消息，利用重试机制进行重试，对于重试失败的，写入错误消息表
4.消息中间件需要提供失败消息的查询接口，下游系统会定期查询失败消息，并将其消费
这种方式的优缺点：
优点：一种非常经典的实现，实现了最终一致性。
缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。
10.2.4 TCC事务
TCC即为Try Confifififirm Cancel，它属于补偿型分布式事务。TCC实现分布式事务一共有三个步骤：
Try：尝试待执行的业务：这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执
行所需的全部资源
Confifififirm：确认执行业务：确认执行业务操作，不做任何业务检查，
只使用Try阶段预留的业务资源。通常情况下，采用TCC则认为Confifififirm阶段是不会出错的。即：只要Try成功，Confifififirm
一定成功。若Confifififirm阶段真的出错了，需引入重试机制或人工处理。
Cancel：取消待执行的业务:取消Try阶段预留的业务资源。通常情况下，采用TCC则认为Cancel
阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理
TCC两阶段提交与XA两阶段提交的区别是：
XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。
TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。
TCC事务的优缺点：
优点：把数据库层的二阶段提交上提到了应用层来实现，规避了数据库层的2PC性能低下问题。
缺点：TCC的Try、Confifififirm和Cancel操作功能需业务提供，开发成本高。
10.3 Seata介绍
2019年1月，阿里巴巴中间件团队发起了开源项目Fescar（Fast & EaSy Commit AndRollback），
其愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。后来更名为Seata，意为：Simple
Extensible Autonomous Transaction Architecture，是一套分布式事务解决方案。
Seata的设计目标是对业务无侵入，因此从业务无侵入的2PC方案着手，在传统2PC的基础上演进。它把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务
Seata主要由三个重要组件组成：
TC：Transaction Coordinator事务协调器，管理全局的分支事务的状态， 用于全局性事务的提交
和回滚。
TM：Transaction Manager事务管理器， 用于开启、提交或者回滚全局事务。
RM：Resource Manager资源管理器，用于 分支事务上的资源管理，向TC注册分支事务，上报分
支事务的状态，接受TC的命令来提交或者回滚分支事务。
Seata的执行流程如下:
-
A服务的TM向TC申请开启一个全局事务，TC就会创建一个全局事务并返回一个唯一的XID
-
A服务的RM向TC注册分支事务，并及其纳入XID对应全局事务的管辖
-
A服务执行分支事务，向数据库做操作
-
A服务开始远程调用B服务，此时XID会在微服务的调用链上传播
-
B服务的RM向TC注册分支事务，并将其纳入XID对应的全局事务的管辖
-
B服务执行分支事务，向数据库做操作
7.全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚
- TC协调其管辖之下的所有分支事务， 决定是否回滚
Seata实现2PC与传统2PC的差别：
1.架构层次方面，传统2PC方案的RM实际上是在数据库层，RM本质上就是数据库自身，通过XA协
议实现，而Seata的RM是以jar包的形式作为中间件层部署在应用程序这一侧的。
2.两阶段提交方面，传统2PC无论第二阶段的决议是commit还是rollback，事务性资源的锁都要保
持到Phase2完成才释放。而Seata的做法是在Phase1就将本地事务提交，这样就可以省去Phase2
持锁的时间，整体提高效率
10.4 Seata实现分布式事务控制
本示例通过Seata中间件实现分布式事务，模拟电商中的下单和扣库存的过程
我们通过订单微服务执行下单操作，然后由订单微服务调用商品微服务扣除库存
10.4.1案例基本代码
10.4.1.1修改order微服务
controller
@RestController
@Slf4j
public classOrderController5{
@Autowired
privateOrderServiceImpl5 orderService;
//下单
@RequestMapping("/order/prod/{pid}")
publicOrder order(@PathVariable("pid")Integerpid) {
log.info("接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息",pid);
returnorderService.createOrder(pid);
}
}
OrderService
@Service
@Slf4j
public classOrderServiceImpl5{
@Autowired
privateOrderDao orderDao;
@Autowired
privateProductService productService;
@Autowired
privateRocketMQTemplate rocketMQTemplate;
@GlobalTransactional
publicOrder createOrder(Integerpid) {
//1调用商品微服务,查询商品信息
Product product=productService.findByPid(pid);
log.info("查询到{}号商品的信息,内容是:{}",pid,JSON.toJSONString(product));
//2下单(创建订单)
Order order=newOrder();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(pid);
order.setPname(product.getPname());
order.setPprice(product.getPprice());
order.setNumber(1);
orderDao.save(order);
log.info("创建订单成功,订单信息为{}",JSON.toJSONString(order));
//3扣库存
productService.reduceInventory(pid,order.getNumber());
//4向mq中投递一个下单成功的消息
rocketMQTemplate.convertAndSend("order-topic",order);
returnorder;
}
}
ProductService
@FeignClient(value="service-product")
public interfaceProductService{
//减库存
@RequestMapping("/product/reduceInventory")
void reduceInventory(@RequestParam("pid")Integerpid,
@RequestParam("num")
intnum);
}
10.4.1.2修改Product微服务
controller
//减少库存
@RequestMapping("/product/reduceInventory")
publicvoidreduceInventory(Integerpid,intnum) {
productService.reduceInventory(pid,num);
}
service
@Override
public void reduceInventory(Integerpid,intnum) {
Product product=productDao.findById(pid).get();
product.setStock(product.getStock()-num);
//减库存
productDao.save(product);
}
10.4.1.3异常模拟
在ProductServiceImpl的代码中模拟一个异常,然后调用下单接口
@Override
public void reduceInventory(Integerpid,Integernumber) {
Product product=productDao.findById(pid).get();
if(product.getStock()<number) {
throw new RuntimeException("库存不足");
}
inti=1/0;
product.setStock(product.getStock()-number);
productDao.save(product);
}
10.4.2启动Seata
10.4.2.1下载seata
10.4.2.2修改配置文件
将下载得到的压缩包进行解压，进入conf目录，调整下面的配置文件：
registry.conf
nacos-confifififig.txt
这里的语法为：service.vgroup_mapping.${your-service-gruop}=default，中间的${your-
service-gruop}为自己定义的服务组名称， 这里需要我们在程序的配置文件中配置
10.4.2.3初始化seata在nacos的配置
10.4.2.4启动seata服务
10.4.3使用Seata实现事务控制
10.4.3.1初始化数据表
在我们的数据库中加入一张undo_log表,这是Seata记录事务日志要用到的表
10.4.3.2添加配置
DataSourceProxyConfifififig
Seata是通过代理数据源实现事务分支的，所以需要配置io.seata.rm.datasource.DataSourceProxy的Bean，且是@Primary默认的数据源，否则事务不会回滚，无法实现分布式事务
@Configuration
public class DataSourceProxyConfig{
@Bean
@ConfigurationProperties(prefix="spring.datasource")
public DruidDataSource druidDataSource() {
return newDruidDataSource();
}
@Primary
@Bean
public DataSourceProxy dataSource(DruidDataSource druidDataSource) {
return newDataSourceProxy(druidDataSource);
}
}
registry.conf
在resources下添加Seata的配置文件registry.conf
bootstrap.yaml
10.4.3.3在order微服务开启全局事务
@GlobalTransactional//全局事务控制
public Order createOrder(Integerpid) {}
10.4.3.4测试
再次下单测试
10.4.4 seata运行流程分析
要点说明：
1.每个RM使用DataSourceProxy连接数据库，其目的是使用ConnectionProxy，使用数据源和数据连接代理的目的就是在第一阶段将undo_log和业务数据放在一个本地事务提交，这样就保存了只要有业务操作就一定有undo_log。
2.在第一阶段undo_log中存放了数据修改前和修改后的值，为事务回滚作好准备，所以第一阶段完
成就已经将分支事务提交，也就释放了锁资源。
- TM开启全局事务开始，将XID全局事务id放在事务上下文中，通过feign调用也将XID传入下游分支事务，每个分支事务将自己的Branch
ID分支事务ID与XID关联。
4.第二阶段全局事务提交，TC会通知各各分支参与者提交分支事务，在第一阶段就已经提交了分支
事务，这里各各参与者只需要删除undo_log即可，并且可以异步执行，第二阶段很快可以完成。
5.第二阶段全局事务回滚，TC会通知各各分支参与者回滚分支事务，通过XID和Branch ID找到相
应的回滚日志，通过回滚日志生成反向的SQL并执行，以完成分支事务回滚到之前的状态，如果
回滚失败则会重试回滚操作
seata事务模式
AT模式(Auto Transaction)
AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT
模式是一种对业务无任何侵入的分布式事务解决方案。但AT模式存在的不足就是 当操作的数据 是共享型数据，会存在脏写的问题，所以如果是
用户独有数据可以使用AT模式。
写隔离
读隔离
XA模式
XA协议包括两阶段提交（2PC）和三阶段提交（3PC）两种实现
TCC(Try、Confirm、Cancel)模式
简单点概括，SEATA的TCC模式就是手工的AT模式，它允许你自定义两阶段的处理逻辑而不依赖AT模式的undo_log。
TCC实践,总结以下注意事项:
业务模型分2阶段设计 并发控制 允许空回滚 防悬挂控制 幂等控制
用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm
一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。
SAGA模式
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
Saga 模式使用场景
Saga 模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。
事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，可以使用 Saga 模式。
Saga模式的优势与缺点
优势
-
一阶段提交本地数据库事务，无锁，高性能；
-
参与者可以采用事务驱动异步执行，高吞吐
-
补偿服务即正向服务的“反向”，易于理解，易于实现；
缺点
Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。后续会讲到对于缺乏隔离性的应对措施。
注意
与TCC实践经验相同的是，Saga 模式中，每个事务参与者的冲正、逆向操作，需要支持：
-
空补偿：逆向操作早于正向操作时；
-
防悬挂控制：空补偿后要拒绝正向操作幂等
总结
AT、TCC、Saga、XA 模式分析
四种分布式事务模式，分别在不同的时间被提出，每种模式都有它的适用场景：
-
AT 模式是无侵入的分布式事务解决方案，适用于不希望对业务进行改造的场景，几乎0学习成本。
-
TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。
-
Saga 模式是长事务解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁，长流程情况下可以保证性能，多用于渠道层、集成层业务系统。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，也可以使用 Saga 模式。
-
XA模式是分布式强一致性的解决方案，但性能低而使用较少。
