【自我总结】分布式微服务框架springcloud相关技术总结（下）

续:

3.3 服务熔断/降级

分布式系统面对的挑战：
复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时刻将不可避免的失败
服务雪崩：
多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.
对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
所以，当发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩
问题：禁止服务雪崩故障
解决：
有问题的节点，就别接受流量了，快速熔断（快速返回失败处理或者返回默认的兜底数据【服务降级】）
“断路器"本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应(fallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
出故障了“保险丝”跳闸，别把整个家给烧了
解决：服务熔断（就是保险丝），服务降级（不让客户端等待并立刻返回一个友好提示，fallback），服务限流（秒杀高并发等操作，严禁一窝蜂的过来拥挤，排队，一秒钟N个，有序进行），服务限时（就开启5秒倒计时），服务预热（最开始3个，后来再5个，逐步上去），接近实时的监控，兜底的处理动作
一句话：熔断就是跳闸，降级就是兜底的方案

大致的使用步骤：

1）Resilience4j

核心模块：
resilience4j-Circuitbreaker:断路
resilience4j-ratelimiter:速率限制
resilience4j-bulkhead: 舱壁
几个关键的参数：
1、failure-rate-threshold
以百分比配置失败率峰值
2、sliding-window-type|
断路器的滑动窗口期类型（推荐按照次数进行熔断）
可以基于“次数(COUNT_BASED）或者“时间”(TIME_BASED)进行熔断，默认是COUNT_B
3、sliding-window-size
若COUNT_BASED，则10次调用中有50%失败（即5次）打开熔断断路器;
若为TIME_BASED则，此时还有额外的两个设置属性，含义为。在N秒内(sliding-window-size)100% (slow-call-rate-threshold）的请求超过N秒(slow-call-duration-threshold）打开断路器。
4、slowCallRate Threshold
以百分比的方式配置，断路器把调用时间大于slowCallDurationThreshold的调用视为慢谓用，当慢调用比例大于等于峰值时，断路器开启,并进入服务降级。
5、slowCallDuration Threshold
配置调用时间的峰值，高于该峰值的视为慢调用。
6、permitted-number-of-calls-in-half-open-state
运行断路器在HALF_OPEN状态下时进行N次谓用，如果故障或慢速调用仍然高于阈值，断路器再次进入打开状态。
7、minimum-number-of-calls
在每个滑动窗口期样本数。配置断路器计算错误率或者慢调用率的最小调用数。比如设置为5意味着，在计算故障率之前，必须至少调用5次。刘果只记录了4次，即使4次都失败了，断路器也不会进入到打开状态。
8、wait-duration-in-open-state
从OPEN到HALF_OPEN状态需要等待的时间

2)sentinel

概述：面向分布式、多语言异构化服务架构的流量治理组件
       随着微服务的流行，服务和服务之间的稳定性变得越来越重要。。Sentinel是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
主要功能：限流 降级 熔断
思想：rule = target+strategy+fallbackAction
sentinel分为两个部分：后台+前台
核心库(Java 客户端)
·不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo/Spring Cloud 等框架也有 较好的支持。
控制台(Dashboard)
·基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

流量控制的方式：

1）阈值类型 QPS（每秒查询率），并发线程数
2）流控模式
·直接 超过阈值则提示流量超过阈值
·关联 当关联的资源达到阈值时，就限流自己 b惹事a挂了
·链路 来自不同的链路请求对同一个目标访问时，实施针对性的不同限流措施（比如c请求来就限流，d请求来访问就OK）
3）流控效果
·快速失败 流量过大的时候 直接访问失败
·warm up 限流 冷启动 当流量突然增大的时候，我们常常会希望系统从空闲状态到繁忙状态的切换的时间长一些。这个场景主要用于启动需要额外开销的场景，例如建立数据库连接等
·排队等待 主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求.
4）熔断规则
·慢调用比例(SLON_REQUEST_RATI0 ):选择以慢调用比例作为阈值，需要设置允许的慢调用 RT(即最大的响应时间)，请求的响应时间大于该值则统计为慢调用。当单位统计时长(statInterva1ns)内请求数目大于设置的最小请求数目（最少的样本数，不能一个慢调用就直接熔断），并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。
·异常比例(ERRORRATI0):当单位统计时长(statInterva1ms)内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。
·异常数(ERROR_COUNT ):当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢 复状态(HALF-OPEN 状态)，若接下来的一个请求成功完成(没有错误)则结束熔断，否则会再次被熔断。
5）@SentinelResource注解
6）热点规则
热点即经常访问的数据，很多时候我们希望统计或者限制某个热点数据中访问频次最高的ToPN数据，并对其访问进行限流或者其它操作
·商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
·用户 ID 为参数，针对一段时间内频繁访问的用户ID 进行限制
7）授权规则
       在某些场景下，需要根据调用接口的来源判断是否允许执行本次请求。此时就可以使用Sentinel提供的授权规则来实现，Sentinel的授权规则能够根据请求的来源判断是否允许本次请求通过。
       在Sentinel的授权规则中，提供了白名单与黑名单 两种授权类型。白放行、黑禁止
        调用方信息通过 Contextuti1.enter(resourceName，origin)方法中的origin参数传入。
8）规则持久化
        服务宕机，断电，重启以后，之前配置的业务规则突然就失效了，一旦我们重启微服务应用，sentinel规则将消失生产环境需要将配置规则进行持久化，将限流配置规则持久化进Nacos保存，只要刷新8401某个rest地址，sentinel控制台的流控规则就能看到，只要Nacos里面的配置不删除，针对8401上sentinel上的流控规则持续有效

使用jason格式将这个sentinel配置持久化到nacos中
-resource:资源名称;
-limitApp:来源应用;
-grade:阈值类型，0表示线程数，1表示QPS:
-count:单机阈值;
-strategy:流控模式，0表示直接，1表示关联，2表示链路;

3.4 分布式链路追踪

分布式链路追踪不可或缺，否则今后对项目的监控，优化，升级会比较麻烦
sleuth（侦探）进入维护模式
替代者：micrometer Tracing
-概述：在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。
-需求：需要在链路的任意一环最好有一种监控管理，甚至是图形化的形式展现告诉我们整个链路的调用情况是怎样
随着问题的复杂化，微服务的增多，调用链条的变长
       写代码不难，难的是改代码，改代码之前首先要读懂老代码屎山代码
       要解决如下问题：
·在大规模分布式与微服务集群下，如何实时观测系统的整体调用链路情况。
·在大规模分布式与微服务集群下，如何快速发现并定位到问题。
·在大规模分布式与微服务集群下，如何尽可能精确的判断故障对系统的影响范围与影响程度。
·在大规模分布式与微服务集群下，如何尽可能精确的梳理出服务之间的依赖关系，并判断出服务之间的依赖关系是否合理。
·在大规模分布式与微服务集群下，如何尽可能精确的分析整个系统调用链路的性能与瓶颈点。
·在大规模分布式与微服务集群下，如何尽可能精确的分析系统的存储瓶颈与容量规划。
       分布式链路追踪技术要解决的问题，分布式链路追踪(DistibutedTracing)，就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的 请求状态等等。
-zipkin用于对这些数据进行展示
-总结：将一次分布式调用请求还原成调用链路，进行日志记录和性能监控，并将一次分布式请求的调用情况用zipkin进行集中web展示

大致使用步骤：

1. 在父工程中引入相关依赖
   2）给每个微服务的yml文件中添加配置（方便对每个微服务的配置进行监控）
   

3.5 网关

Gateway是在Spring生态系统之上构建的API网关服务，基于Spring6，Spring Boot 3和Proiect Reactor等技术。它旨在为微服务架构提供一种简单有效的统一的 API路由管理方式，并为它们提供跨领域的关注点，例如:安全性、监控!度量和恢复能力。
和feign配套使用（feign对外提供接口，gateway用于管理接口）
gateway三大核心：
-route 路由 是构建网关的基本模块，由ID，目标URL，一系列的断言和过滤器组成，如果断言为true则匹配该路由
-predicate 断言 （布尔值）可以匹配HTTP请求中的所有内容（请求头或请求参数），如果请求与断言相匹配则进行路由
-filter过滤 使用过滤器可以在请求被路由前或者之后对请求进行修改（AOP）

大致使用步骤：
1、创建一个gateway微服务
2、配置yml文件使其入驻进consul或nacos

3、在gateway中配置route

4、改进，uri不能写死，应该加入负载均衡，使用服务名调用微服务

5、使用断言，进行路由匹配
常用的断言如下：
5.1 The After Route Predicate Factory 某个时间点之后才可以访问
5.2 before 某时间之前
5.3 between 某时间中间
5.4 Cookie Route Predicate
5.5 Header
5.6 Host 访问主机
5.7 path 访问路径
5.8 Query 查询参数
5.9 remoteAddr route predicate 远程地址
5.10 method 请求方法
6、使用过滤器

断言只进行判断，过滤器可以增删改 相应的参数
·断言用于匹配请求，过滤器主要是对请求和响应做处理（比如统计接口调用时间）
·断言通常用于路由规则的定义，用于确定哪些路由规则适用于当前请求。而请求鉴权功能则是针对具体的请求进行验证和授权。
·请求鉴权功能通常更加复杂和具体，需要在过滤器中实现，而断言功能则主要用于路由规则的定义。

例：
修改前缀：


这样就是访问的人不知道真实的地址 过滤器会自动加上一个前缀 加上前缀的地址才是真实的地址

设置路径：


这样就是修改了真实的访问地址
重定向：

在微服务框架中使用过滤器修改真实的服务地址的主要目的是实现服务的动态路由和负载均衡。这种做法通常被称为服务网关模式。
       服务网关作为微服务架构中的一个关键组件，充当了客户端和后端微服务之间的入口，并提供了一系列功能，包括路由、负载均衡、安全认证、监控等。通过服务网关，客户端可以通过一个统一的入口访问多个微服务，而无需直接调用每个微服务的地址。
在服务网关中使用过滤器修改真实的服务地址的主要用意包括：
       -动态路由：通过过滤器拦截请求，并根据一定的路由规则将请求转发到不同的服务实例上，实现动态的服务路由。这样可以根据业务需求实现灵活的路由策略，如根据请求头、请求参数、用户权限等条件进行路由。
       -负载均衡：通过过滤器拦截请求，并根据一定的负载均衡算法选择目标服务实例，实现负载均衡。这样可以将请求均衡地分发到多个服务实例上，提高系统的性能和可靠性。
       -服务发现与注册：通过过滤器从服务注册中心获取服务实例列表，并动态更新路由表。这样可以实现服务发现与注册的功能，确保服务网关能够动态地感知服务实例的变化，并及时更新路由信息。
       -服务降级：通过过滤器监控服务实例的健康状态，并根据一定的策略实现服务的降级和熔断。这样可以在服务出现故障或异常时，及时切换到备用服务或提供友好的错误提示，保障系统的稳定性和可用性。
       综上所述，使用过滤器修改真实的服务地址是为了在服务网关中实现动态路由、负载均衡、服务发现与注册、服务降级等功能，提高系统的灵活性、可靠性和性能。

3.6 分布式事务

分布式事务是指在分布式系统中跨多个微服务进行的事务操作。由于微服务架构的特点，一个业务操作可能涉及到多个微服务的数据更新，因此需要保证这些操作的一致性和原子性，即要么全部成功提交，要么全部失败回滚。
分布式事务解决的主要痛点包括：
1、数据一致性：在分布式系统中，数据的更新可能分散在不同的微服务中，如果不加控制地进行更新操作，可能会导致数据不一致的问题。
2、原子性：要保证跨微服务操作的原子性，即要么所有操作都成功提交，要么所有操作都失败回滚，以避免数据的不完整性。
3、隔离性：在并发场景下，要保证不同事务之间的隔离性，防止因并发操作导致的数据错乱或脏读问题。
4、持久性：保证事务的持久性，即事务提交后所做的更改能够被持久化到数据库中，不会因系统故障或异常而丢失。

补充：TC-TM-RM分别是什么意思？

TC,TM只有一个 RM有多个
-TC Transactional Coordinator 事务协调器 就是Seata，负责维护全局事务和分支事务的状态，驱动全局事务提交或回滚
-TM Transactional Manager事务管理器 标注全局@GlobalTransactional启动入口动作的微服务模块（比如订单模块），它是事务的发起者，负责定义全局事务的范围，并根据TC维护的全局事务和分支事务状态，做出开始事务，提交事务，回滚事务的决议
-RM Resource Manager资源管理器 就是mysql数据库本身，可以是多个RM，负责管理分支事务上的资源，向TC注册分布式事务，汇报分支事务状态，驱动分支事务的提交和回滚
一般TM同时也是RM
三个组件相互协作，TC以Seata服务器（server）形式独立部署，TM和RM则是以seata client 的形式集成在微服务中运行
分别可以类比为班主任 班长 同学

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

案例实战：
业务需求：
下订单，减库存，扣余额，修改订单状态

1、创建seata专属库 专属表
2、修改application.yml
3、创建业务mysql （业务数据库（订单80-库存2001-账户2002） ，回滚日志表，业务表）
4、增加两个微服务（库存+账户）
5、在common公共微服务中添加两个微服务对外暴露的接口，创建两个FeignAPI

订单微服务 通过 feignapi调用 库存微服务 账户微服务
异常情况：
1）超时异常 没添加@GlobalTransactional注解
前台报超时的错 但是数据没有回退 库存和账户金额扣减后，订货单状态并没有设置为已完成，没有从0改为1
2）除数为0异常 前台也会报错 但是数据错误不会回滚
异常情况解决：
添加注解 @GlobalTransactional

总结

客户端
-ngnix
-gateway 路由 断言 过滤器
-openfeign 通过这个找到微服务
-Consul/nacos 服务注册发现/配置中心

配套周边体系
Resilience4j/ 容错限流 服务熔断/降级/限流/舱壁（隔离）
sentinel 流控 限流 热点规则
micrometer 分布式链路追踪
seata 分布式事务

参考资料：bilibili《尚硅谷2024最新SpringCloud教程，springcloud从入门到大牛》