SpringCloud Alibaba

---

SpringCloud Alibaba能干吗？

• 服务限流降级：默认支持 Servlet、Feign、RestTemplate、Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
• 服务注册与发现：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持。
• 分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。
• 消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
• 阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。
• 分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。

alibaba/spring-cloud-alibaba

SpringCloud Alibaba Nacos服务注册和配置中心

Nacaos简介

Nacos Service的启动：

• Linux下单机模式：sh startup.sh -m standalone
• Windows下单机模式：startup.cmd -m standalone

Nacos是什么？

• Nacos: Dynamic Naming and Configuration Service
• 一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
• Nacos就是注册中心 + 配置中心的组合。等价于Nacos = Eureka+Config +Bus

home

Nacos能干吗？

• 替代Eureka做服务注册中心
• 替代Config做服务配置中心

Nacos的AP和CP模式切换：

C是所有节点在同一时间看到的数据是一致的；而A的定义是所有的请求都会收到响应。

何时选择使用何种模式？

• 一般来说，如果不需要存储服务级别的信息且服务实例是通过nacos-client注册，并能够保持心跳上报，那么就可以选择AP模式。当前主流的服务如 Spring cloud 和 Dubbo 服务，都适用于AP模式，AP模式为了服务的可能性而减弱了一致性，因此AP模式下只支持注册临时实例。
• 如果需要在服务级别编辑或者存储配置信息，那么 CP 是必须，K8S服务和DNS服务则适用于CP模式。CP模式下则支持注册持久化实例，此时则是以 Raft 协议为集群运行模式，该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误。
• 模式切换：curl -X PUT '$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

Nacos同springcloud-config一样，在项目初始化时，要保证先从配置中心进行配置拉取，拉取配置之后，才能保证项目的正常启动。

Nacos用于服务配置中心

Nacos中的匹配规则:

• $-$.$

回滚：

历史记录默认保存30天

配置问题：

配置文件后缀名一定要添加！否则读取不到配置文件

Nacos作为配置中心-分类配置

命名空间、组、DataId的关系：

• 默认情况：Namespace=public，Group=DEFAULT_GROUP, 默认Cluster是DEFAULT
• Nacos默认的命名空间是public，Namespace主要用来实现隔离。比方说我们现在有三个环境：开发、测试、生产环境，我们就可以创建三个Namespace，不同的Namespace之间是隔离的。
• Group默认是DEFAULT_GROUP，Group可以把不同的微服务划分到同一个分组里面去
• Service就是微服务；一个Service可以包含多个Cluster（集群），Nacos默认Cluster是DEFAULT，Cluster是对指定微服务的一个虚拟划分。
  比方说为了容灾，将Service微服务分别部署在了杭州机房和广州机房，这时就可以给杭州机房的Service微服务起一个集群名称（HZ），
  给广州机房的Service微服务起一个集群名称（GZ），还可以尽量让同一个机房的微服务互相调用，以提升性能。
• 最后是Instance，就是微服务的实例。

SpringCloud Alibaba Sentinel(分布式系统的流量防卫兵)

---

介绍：

Sentinel采用的懒加载说明

Sentinel是什么？

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

官方文档：

alibaba/Sentinel

home

Sentinel的主要特性：

Sentinel 分为两个部分:

• 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
• 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

资源：

• 资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

规则

• 围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

官方文档：

alibaba/Sentinel

Sentinel 功能和设计理念

流量控制：

• 流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。然而，从系统稳定性角度考虑，在处理请求的速度上，也有非常多的讲究。任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状，如下图所示：

流量控制有以下几个角度:

• 资源的调用关系：例如资源的调用链路，资源和资源之间的关系；
• 运行指标：例如 QPS、线程池、系统负载等；
• 控制的效果：例如直接限流、冷启动、排队等。

流控规则

流控模式：

默认：快速失败(默认的流控处理)

关联：当关联的资源达到阈值时，就限流自己，例如当与A关联的资源B达到阀值后，就限流A自己

链路：多个请求调用了同一个微服务

流控效果

预热：

• 简介：当流量突然增大的时候，我们常常会希望系统从空闲状态到繁忙状态的切换的时间长一些。即如果系统在此之前长期处于空闲的状态，我们希望处理请求的数量是缓步的增多，经过预期的时间以后，到达系统处理请求个数的最大值。Warm Up（冷启动，预热）模式就是为了实现这个目的的。
• 公式：阈值除以coldFactor(默认值为3),经过预热时长后才会达到阈值，即刚开始为设定阈值/3，等预热时间到了恢复设定的阈值。
• 应用场景：秒杀系统在开启的瞬间，会有很多流量上来，很有可能把系统打死，预热方式就是把为了保护系统，可慢慢的把流量放进来，慢慢的把阀值增长到设置的阀值。

排队等待：

• 匀速排队，让请求以均匀的速度通过，阀值类型必须设成QPS，否则无效。排队时间超过设定的超时时间就不再处理请求。

熔断降级

Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，
让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为是抛出 DegradeException）。

Sentinel的断路器是没有半开状态的。

熔断降级官网介绍：

alibaba/Sentinel

熔断策略：

注意：Sentinel默认的统计RT上限是4900ms，超过此阈值的都算作4900ms。

平均响应时间（DEGRADE_GRADE_RT ):当1s内持续进入5个请求，对应时刻的平均响应时间（秒级）均超过阈值（ count ，以ms为单位)，那么在接下的时间窗口( DegradeRule中的timewindow，以s为单位)之内，对这个方法的调用都会自动地熔断(抛出DegradeException )。注意Sentinel默认统计的RT上限是4900 ms，超出此阈值的都会算作4900 ms，若需要变更此上限可以通过启动配置项-Dcsp.sentinel.statistic.max.rt=xxx来配置。

异常比例( DEGRADE_GRADE_EXCEPTION_RATIo ):当资源的每秒请求量>=5，并且每秒异常总数占通过量的比值超过阈值（ DegradeRule中的 count ）之后，资源进入降级状态，即在接下的时间窗口( DegradeRule中的timewindow，以s为单位)之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是[0.0，1.0]，代表0% - 100%。

**异常数(DEGRADE_GRADE_EXCEPTION_COUNT )：**当资源近1分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 timeWindow小于60s，则结束熔断状态后仍可能再进入熔断状态。时间窗口一定要大于等于60秒。

• RT（平均响应时间，秒级）：平均响应时间 超出阈值 且 在时间窗口内通过的请求>=5，两个条件同时满足后触发降级窗口期过后关闭断路器RT最大4900（更大的需要通过-Dcsp.sentinel.statistic.max.rt=XXXX才能生效）
• 异常比列（秒级）：QPS >= 5 且异常比例（秒级统计）超过阈值时，触发降级；时间窗口结束后，关闭降级

• 异常数（分钟级）：异常数（分钟统计）超过阈值时，触发降级；时间窗口结束后，关闭降级

热点Key限流：

热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

@SentinelResource注解说明：

@SentinelResource注解不支持private方法

• @SentinelResource处理的是Sentinel控制台配置的违规情况，有blockHandler方法配置的兜底处理；
• RuntimeException：int age = 10/0,这个是java运行时报出的运行时异常RunTimeException，@SentinelResource不管

总结：@SentinelResource主管配置出错，运行出错该走异常走异常

系统自适应限流：

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

系统保护的目的：

• 保证系统不被拖垮
• 在系统稳定的前提下，保持系统的吞吐量

系统保护规则：

• 系统保护规则是从应用级别的入口流量进行控制，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

服务熔断功能

sentinel整合ribbon+openFeign+fallback

若 blockHandler 和 fallback 都进行了配置，则被限流降级而抛出 BlockException 时只会进入 blockHandler 处理逻辑。

规则持久化

一旦重启应用，sentinel规则将消失，生产环境需要将配置规则进行持久化。将限流配置规则持久化进Nacos保存，只要刷新8401某个rest地址，sentinel控制台的流控规则就能看到，只要Nacos里面的配置不删除，针对8401上sentinel上的流控规则持续有效。

1. 持久化需要引入的pom

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

2. 在yml中配置数据源

sentinel:
      transport:
        #配置Sentinel dashboard地址
        #这是ikart.top的域名
        dashboard: localhost:8080
        #默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口
        port: 8719
      **datasource:
        ds1:
          nacos:
            server-addr: localhost:8848
            dataId: cloudalibaba-sentinel-service
            groupId: DEFAULT_GROUP
            data-type: json
            rule-type: flow**

SpringCloud Alibaba Seata处理分布式事务

---

简介：

产生背景：

一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题。单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用，分别使用三个独立的数据源，业务操作需要调用三个服务来完成。此时每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性问题没法保证。

官方文档：

Seata 是什么

Seata术语：

• **TC (Transaction Coordinator) - 事务协调者：**维护全局和分支事务的状态，驱动全局事务提交或回滚。
• **TM (Transaction Manager) - 事务管理器：**定义全局事务的范围：开始全局事务、提交或回滚全局事务。
• **RM (Resource Manager) - 资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
• Transaction ID XID：全局唯一的事务ID

处理过程：

Seata分布式事务处理工程

1. TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID；
2. XID 在微服务调用链路的上下文中传播；
3. RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖；
4. TM 向 TC 发起针对 XID 的全局提交或回滚决议；
5. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

如何使用？

• 本地@Transactional
• 全局@GlobalTransactional

配置Stata：

注意：启动顺序为先启动nacos然后在启动seata

连接Seata需要初始化数据库

关于Script目录介绍参考：

Seata脚本说明

1. 修改conf目录下的file.conf文件，将store{mode=“ ”}设为db
2. 修改conf目录下的register.conf文件,将registry{type=“ ”}设为nacos

Q.E.D.