啦啦啦的博客

Distro协议是Nacos社区字眼的一种AP分布式协议，是面向临时实例设计的一种分布式协议，其保证在某些Nacos节点宕机后，整个临时实例处理系统依旧可以正常工作。作为一种有状态的中间件应用内嵌协议，Distro保证了各个Nacos节点对于还亮注册请求的统一协调和储存。Distro协议的主要设计思想如下：Nacos 在开源支持就定下了⼀个目标，尽可能的减少用户部署以及运维成本，做到用户只需要⼀个程序包，就可以快速以单机模式启动 Nacos 或者以集群模式启动 Nacos。而Nacos 是⼀个需要存储数据的

所谓动态监听，简单理解就是指Nacos会自动找到那些服务已经注册，而对比来说静态监听，就是指需要有指定配置指定的服务。其实在这里我们就要说一下客户端和服务端的交互方式，无非就是推和拉核心：Nacos动态刷新机制，采用推和拉的优点，避免缺点。Nacos做配置中心的时候，配置数据的交互模式是有服务端push推送的，还是客户端pull拉取的？Nacos客户端发送一个请求连接到服务端，然后服务端中会有一个29.5+0.5s的一个hold期，然后服务端会将此次请求放入到allSubs队列中等待，触发服务端返回结果的情

Nacos不仅仅可以作为注册中心来使用，同时它支持作为配置中心首先我们还是新建Model：cloudalibaba-config-3377​ 这里我们主要要引入的是此依赖，这个依赖依据在官网上可以找到:https://spring-cloud-alibaba-group.github.io/github-pages/greenwich/spring-cloud-alibaba.html#_an_example_of_using_nacos_discovery_for_service_registration

在微服务系统中，网关提供了微服务系统的统一入口，所以我们在做限流的时候，肯定是要在网关层面做一个流量的控制，Sentinel 支持对 Spring Cloud Gateway、Zuul 等主流的 API Gateway 进行限流。Sentinel 1.6.0 引入了 Sentinel API Gateway Adapter Common 模块，此模块中包含网关限流的规则和自定义 API 的实体和管理逻辑：其中网关限流规则 GatewayFlowRule的字段解释如下：resource：资源名称，可以是网关中

Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务（执行处理时候出错了，给一个修复的机会）都由业务开发实现。Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。之前我们学习的Seata分布式三种操作模型中所使用的的微服务全部可以根据开发者的需求进行修改，但是在一些特殊环境下，比如老系统，封闭的系统（无法修改，同时没有任何分

首先我们先来了解常规的TCC模式。TCC 是分布式事务中的二阶段提交协议，它的全称为 Try-Confirm-Cancel，即资源预留（Try）、确认操作（Confirm）、取消操作（Cancel），他们的具体含义如下：TCC 是一种侵入式的分布式事务解决方案，以上三个操作都需要业务系统自行实现，对业务系统有着非常大的入侵性，设计相对复杂，但优点是 TCC 完全不依赖数据库，能够实现跨数据库、跨应用资源管理，对这些不同数据访问通过侵入式的编码方式实现一个原子操作，更好地解决了在各种复杂业务场景下的分布式事务

Seata 1.2.0 版本重磅发布新的事务模式：XA 模式，实现对 XA 协议的支持。我们从三个方面来深入分析：首先我们需要先了解一下什么是XA？XA 规范早在上世纪 90 年代初就被提出，用以解决分布式事务处理这个领域的问题。注意：不存在某一种分布式事务机制可以完美适应所有场景，满足所有需求。现在，无论 AT 模式、TCC 模式还是 Saga 模式，这些模式的提出，本质上都源自 XA 规范对某些场景需求的无法满足。XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed T

概念：AT模式是一种无侵入的分布式事务解决方案，在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。两阶段提交协议的演变：在一阶段中，Seata会拦截“业务SQL“，首先解析SQL语义，找到要更新的业务数据，在数据被更新前，保存下来"undo"，然后执行”业务SQL“更新数据，更新之后再次保存数据”redo“，最后生成行锁，这些操作都在本地数据库事务内完成，这样保证了一阶段的原子性。相对一阶段，二阶段比较简单，负责

Seata支持注册服务到Nacos，以及支持Seata所有配置放到Nacos配置中心，在Nacos中统一维护；高可用模式下就需要配合Nacos来完成Seata-server端配置注册中心，在registry.conf中加入配置注册中心nacos注意：确保client与server的注册处于同一个namespace和group，不然会找不到服务。配置中心Seata-Server配置配置中心，在registry.conf中加入配置使用nacos作为配置中心我们需要把Seata的一些配置上传到Na

Server端存储模式（store.mode）支持三种：找到以下对应的db配置，要修改其中的jdbc连接，以及要注意其中涉及到了三个表，分别是global_table，branch_table，lock_table分别是全局事务会话表，分支事务会话表，锁数据表；重启Seata即可生效。anch_id`)) ENGINE = InnoDBDEFAULT CHARSET = utf8;...

官方下载地址：https://github.com/seata/seata/releases下载完成之后需要解压接着我们需要修改Seata的存储模式，修改file.conf文件，把Seata的默认存储模式修改为数据库"DB"，同时需要配置JDBC启动启动步骤为，先启动nacos然后在启动Seata-Server启动Seata-Server的方式非常简单，直接双击此文件即可:seata-server-1.4.2\bin\seata-server.bat启动完成效果然后在nacos控制台上就可

2PC即两阶段提交协议，是将整个事务流程分为两个阶段，P是指准备阶段，C是指提交阶段。举例：比如说相亲对象两个人去吃饭，店老板要求，先付钱在吃饭，这是男女双方提出了AA，也就是说只有男女双方都付钱，才能落座吃饭，但是只要两个人中有一个不统一付款就不能落座吃饭。其实此例子就形成了一个事务，如果男女双方有一个人拒绝付款，那么老板就不会出餐，并且会把已收取的钱原路退回。真个事务过程是由事务管理器和参与者组成的，店老板就是事务管管理器，男女双发就是参与者，事务管理器决策整个分布式事务在计算机中关系数据库支持的两阶段

基础概念：事务ACID通过以上的图中我们可以看出，其实只要涉及到操作多个数据源，就可能会产生事务问题，当然在实际开发中我们要尽量避免这种问题的出现，当然如果避免不了，我们就需要进行解决，在我们的微服务系统架构中，目前比较好，比较常用的解决方案就是Seata。随着互联化的蔓延，各种项目都逐渐向分布式服务做转换。如今微服务已经普遍存在，本地事务已经无法满足分布式的要求，由此分布式事务问题诞生。 分布式事务被称为世界性的难题，目前分布式事务存在两大理论依据：CAP定律 BASE理论。这个定理的内容是指的是在一个分

路由过滤器允许以某种方式修改传入的 HTTP 请求或传出的 HTTP 响应。路由过滤器的范围是特定的路由。Spring Cloud Gateway 包含许多内置的 GatewayFilter 工厂。GateWay内置的Filter生命周期为两种：pre（业务逻辑之前）、post（业务逻辑之后）GateWay本身自带的Filter分为两种： GateWayFilter（单一）、GlobalFilter（全局）单一的有32种，全局的有9种官方网址：https://docs.spring.io/spring-cl

这节课我们来研究一下GateWay的Predicate（断言）每一个Predicate的使用，可以理解为：当满足条件后才会进行转发，如果十多个，那就是满足所有条件才会转发以上这么多的断言，我们不可能一一的去演示，我们挑出一些比较常用的来给大家做演示，这些具体的演示在官网上都有提供，具体地址为：https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gateway-request-predicates-factories

在之前的学习中，我们已经掌握了GateWay的一些基本配置，包括两种配置方法，但是其中有很多的配置细节，我们没有细讲，包括我们现在的配置是写死的具体端口号，那么这节课，我们要实现通过GateWay实现负载均衡的两种方式首先我们看一下我们之前的网关服务9999的yml配置，这里的配置信息，其实有一些，咱们目前是不清楚的，比如：所以这个位置我们可以把当前的配置优化为以下情况，它是一样可以启动的，我们可以进行测试启动9001和网关9999，通过网关来访问"localhost:9999/msb/**"GateW

经过上节课的讲解，我们现在知道了GateWay的基本配置路由的方式，通过YML来完成，但是实际上GateWay还提供了另外一种配置方式其实这种配置方式就是通过代码的方式进行配置，也就是通过@Bean注入一个RouteLocator那我们直接来操作一下首先我们在新建一个GateWayConfig，其实这里的配置对应的就是我们之前在YML中配置的对应内容我们在9001的DemoController中添加一个控制器这个时候我们就可以测试了，启动9999网关服务和9001微服务，然后访问地址：http://lo

核心流程图如下：核心概念：客户端向 Spring Cloud Gateway 发出请求。如果Gateway Handler Mapping确定请求与路由匹配，则将其发送到Gateway Web Handler 处理程序。此处理程序通过特定于请求的Fliter链运行请求。Fliter被虚线分隔的原因是Fliter可以在发送代理请求之前（pre）和之后（post）运行逻辑。执行所有pre过滤器逻辑。然后进行代理请求。发出代理请求后，将运行“post”过滤器逻辑。过滤器作用：在GateWay的内部有三个核心点，

在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调用。这样的话会产生很多问题，例如：为解决上面的问题所以引入了网关的概念：所谓的API网关，就是指系统的统一入口，提供内部服务的路由中转，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、路由转发等。Zuul 1.xNetflix开源的网关，基于Servlet框架构建，功能丰富，使用JAVA开发，易于二次开

我们首先需要知道：在Sentinel Dashboard中配置规则之后重启应用就会丢失，所以实际生产环境中需要配置规则的持久化实现，Sentinel提供多种不同的数据源来持久化规则配置，包括file，redis、nacos、zk。将限流规则持久化进Nacos保存，只要刷新8401某个接口地址，Sentinel控制台的流控规则就能感应到，同时只要Nacos里面的配置不删除，针对8401上Sentinel的流控规则就持续有效。其实就是实现Sentinel Dashboard与Nacos之间的相互通信通过Naco

根据之前的学习，我们已经学习过了包括Sentinel整合Ribbon，包括对OpenFegin的基本学习，那么这节课，我们就需要通过Sentinel来进行整合OpenFegin我们需要在当前的8084项目中引入对应的依赖激活Sentinel对OpenFeign的支持，所以配置yml主启动类要添加@EnableFeignClients注解OpenFegin接口编写这里我们的接口写法和之前保持一致，但是要注意，我们这里要多增加一个FeignClient的属性：实现类必须添加@Component注解，否

Feign 提供了日志打印功能，我们可以通过配置来调整日志级别，从而了解 Feign 中 Http 请求的细节。简单理解，就是对Feign接口的调用情况进行监控和输出日志级别：NONE：默认的，不显示任何日志；BASIC：仅记录请求方法、URL、响应状态码及执行时间；HEADERS：除了 BASIC 中定义的信息之外，还有请求和响应的头信息；FULL：除了 HEADERS 中定义的信息之外，还有请求和响应的正文及元数据。需要在启动类中通过@Bean注解注入OpenFeign的日志功能在yml中配置中配置

OpenFeign 客户端默认等待1秒钟，但是如果服务端业务超过1秒，则会报错。为了避免这样的情况，我们需要设置feign客户端的超时控制。由于OpenFeign 底层是ribbon 。所以超时控制由ribbon来控制。在yml文件中配置首先演示超时效果，我们现在9003/9004上设置一个延迟3秒执行的方法，来模仿长业务线调用。客户端8888通过OpenFeign来进行调用测试结果客户端报错：首先我们需要在8888消费者端的yml文件中配置超时时间，因为OpenFeign本身整合了Ribbon所以

OpenFeign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用OpenFeign，可以做到使用HTTP请求访问远程服务，就像调用本地方法一样的，开发者完全感知不到这是在调用远程方法，更感知不到在访问HTTP请求，用法其实就是编写一个接口，在接口上添加注解即可。可以简单理解它是借鉴Ribbon的基础之上，封装的一套服务接口+注解的方式的远程调用器。它的宗旨是在编写Java Http客户端接口的时候变得更加容易，其底层整合了Ribbon，所以也支持负载均衡。之前我们使用Ribbon的时

概念： fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了 里面排除掉的异常类型）进行处理。fallback 函数签名和位置要求：其实通过官网上提供的概念，我们不难看出这个属性类似于blockHandler，但是各位一定要注意他们有本质的不同。注意： fallback属性和blockHandler属性的本质不同在于他们作用的异常不同：上节课我们已经完成环境的搭建，那我们就直接在8084项目的DemoControll

服务熔断：应对微服务雪崩效应的一种链路保护机制，类似保险丝。需要完成Sentinel整合Ribbon+openFeign，所以我们先要搭建环境，那么先从整合Ribbon开始为了演示操作，所以在这里我们需要利用Ribbon进行负载均衡的调用，所以我们需要创建一个服务消费者cloudalibaba-consumer8084和两个服务提供者cloudalibaba-provider9003和cloudalibaba-provider9004，以下是结构图其实我们之前就搭建过这种结构，比较简单，所以我们快速搭建在建

​ Sentinel 提供了@SentinelResource注解用于定义资源,并提供了AspectJ的扩展用于自定义资源,处理BlockException等。之前我们用过这个注解，同时了解了它的两个属性：我们之前利用这个注解完成了热点规则的学习，同时做了一个案例，我们简单复习一下，这个案例的核心思想就是我们传递一个指定参数，然后通过注解@SentinelResource注解标注资源进行限流，当出现限流以后，通过blockHandler属性设置限流以后的解决方法。其实这个注解不仅仅可以用到热点规则上，还可

​ Sentinel 系统自适应限流从整体维度对应用入口流量进行控制，结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标，通过自适应的流控策略，让系统的入口流量和系统的负载达到一个平衡，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。​ 系统保护规则是从应用级别的入口流量进行控制，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。​ 系统保护规则是

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效官网：https://sentinelguard.io/zh-cn/docs/parameter-flow-control.html​ 其实参数例外项就是可以达到更加细粒度的控制，比如我们当前的例子中，目前ho

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效官网：https://sentinelguard.io/zh-cn/docs/parameter-flow-control.html这里还有相对应的高级选项，我们这里先了解基本规则。其实这个热点限流其实就是更加细

​ 概念：异常数 ()：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。​ 注意：异常降级仅针对业务异常，对 Sentinel 限流降级本身的异常（）不生效。简单理解：编写接口设置异常数策略，当1秒钟内请求超过5并且异常数大约5个的时候触发熔断通过JMeter来测试1秒钟发送10个请求此时就会触发熔断...

​ 概念：异常比例 ()：当单位统计时长（）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 ，代表 0% - 100%。​ 注意：异常降级仅针对业务异常，对 Sentinel 限流降级本身的异常（）不生效。简单理解：编写测试接口设置熔断策略异常比例我们通过JMeter来测试，设定HTTP请求地址1秒钟发

​ 概念：选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。​ 简单理解：举例：首先我们先添加一个控制器方法：设置熔断策略，1QPS>5 并且这些请求的RT>3

​ 除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块，可能是另外的一个远程服务、数据库，或者第三方 API 等。例如，支付的时候，可能需要远程调用银联提供的 API；查询某个商品的价格，可能需要进行数据库查询。然而，这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况，请求的响应时间变长，那么调用服务的方法的响应时间也会变长，线程会产生堆积，最终可能耗尽业务自身的线程池，服务本身也变得不可用。​ 现代微服务架构都是分布式的，由非常

QPS直接失败案例添加有两种方式，可以直接在流控规则选项中添加，也可以在簇点链路中添加，一般会采取第二种方式现在我们给"/testA"添加流控。线程数直接失败案例这个时候我们重启项目，然后重新通过访问testA接口，通过两个网页（线程）来快速访问，这个时候我们来看效果，这里要注意，要重新添加流控规则。注意：这个时候虽然效果一致，但是是两种完全不同的规则，一种是QPS，一种是并发线程，这点大家一定要分清！......

​ 我们现在通过一个案例来让大家了解Sentinel的初始化演示，现在我们需要做几件事：配置yaml文件，目的是让当前8401注册进Nacos，然后被Sentinel8080进行监控编写FlowLimitController测试当以上的这些配置配置好以后，我们就可以进行测试了，那我们的测试方式就是，首先保证Nacos和Sentinel都是启动状态，然后再来启动项目，按照我们的理解这个时候，就应该在Sentinel的dashboard上能体现出它监控的服务，但是此时并没有，原因是因为Se

分布式系统的流量防卫兵：随着微服务的普及，服务调用的稳定性变得越来越重要。Sentinel以“流量”为切入点，在流量控制、断路、负载保护等多个领域开展工作，保障服务可靠性。特点：1.2. +丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。3. 完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 50

​ 我们现在知道，想要启动Naocs只需要启动startup.sh命令即可，但是如果启动3个Nacos那？所以如果我们需要启动多个Nacos，就需要自行修改startup命令。这里的修改和我们之间的在win上的修改是完全一样的，所以我们只要打开这个文件，加上对应的内容即可Linux服务器上Nacos的集群配置cluter.conf这里开始正式配置集群，首先我们要更改cluter.conf这个配置文件，当然我们也需要备份，但是这里它的原始名称为：cluster.conf.example，我们

​ 在之前的课程中我们已经给大家讲解过了Nacos生产环境下需要搭建集群配置，那么这里我们预计需要：1个Nginx+3个Nacos注册中心+1个MySql

​ Nacos默认自带嵌入式数据库derby，所以我们每次创建一个Nacos实例就会有一个derby，当有多个Nacos节点的时候，就会出现一致性问题，所以Nacos支持了外部数据库统一数据管理MySql。具体配置方式可以参考官网：https://nacos.io/zh-cn/docs/deployment.html我们需要找到Nacos安装目录下的conf目录中的Sql脚本，然后在数据库中进行执行注意：需要我们先创建好数据库并且使用：​ 这里表示更改Nacos数据库为本机MySql数据库注意：这里