🛡️ SpringCloud微服务保护与分布式事务知识点总结

一、微服务保护

1.1 雪崩问题及解决方案

❄️ 雪崩问题定义：微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况，形成级联失败。

🛠️ 常见解决方案：

• 🚧 舱壁模式/线程隔离：限定每个业务能使用的线程数，避免耗尽整个Tomcat资源

• ⚡ 熔断降级/断路器：统计业务执行的异常比例，超出阈值则熔断该服务

• 📊 请求限流：限制业务访问的QPS，避免服务因流量激增而故障

1.2 Sentinel框架

🚀 Sentinel简介：阿里巴巴开源的一款微服务流量控制组件，具有以下特征：

• 丰富的应用场景，承接了阿里巴巴近10年的双十一大促流量
• 广泛的开源生态，与Spring Cloud、Dubbo等框架整合
• 完善的SPI扩展点

📊 核心功能对比：

功能	Sentinel	Hystrix
隔离策略	信号量隔离	线程池隔离/信号量隔离
熔断降级策略	基于慢调用比例或异常比例	基于失败比率
流量整形	支持慢启动、匀速排队	不支持
系统自适应保护	支持	不支持
控制台	开箱即用	不完善

1.3 流量控制

🌊 流控模式：

• 📱 直接模式：对当前资源直接进行流量控制
• 🔗 关联模式：当关联资源达到阈值时，限制当前资源
• 🔗 链路模式：只针对某条链路进行管控

⚡ 流控效果：

• 🚫 快速失败：超过阈值直接拒绝请求
• 🔥 Warm Up：预热模式，允许流量阈值逐渐上涨
• ⏳ 匀速排队：严格控制请求通过的间隔时间

1.4 熔断降级

⚡ 熔断策略：

• 🐌 慢调用比例：统计慢调用比例，超过阈值触发熔断
• ❌ 异常比例：统计异常请求比例，超过阈值触发熔断
• 📊 异常数：统计异常请求数量，超过阈值触发熔断

🔄 熔断器状态转换：

• 🟢 关闭状态：正常调用
• 🔴 打开状态：触发熔断，直接返回降级结果
• 🟡 半开状态：尝试放行少量请求进行探测

二、分布式事务

2.1 分布式事务理论基础

📚 CAP定理：分布式系统有三个指标，但只能同时满足两个：

• ✅ 一致性(Consistency)：所有节点数据一致
• ✅ 可用性(Availability)：每个请求都能得到响应
• ✅ 分区容错性(Partition Tolerance)：网络分区时系统仍能工作

🔄 BASE理论：对CAP的补充，包含三个思想：

• 🟢 基本可用(Basically Available)：允许损失部分可用性
• 🟡 软状态(Soft State)：允许出现中间状态
• ✅ 最终一致性(Eventually Consistent)：最终达到数据一致

2.2 Seata框架

🚀 Seata简介：阿里巴巴开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。

👥 三大核心角色：

• 📊 TC(Transaction Coordinator)：事务协调者，维护全局事务状态

• 👨‍💼 TM(Transaction Manager)：事务管理器，定义全局事务范围

• 🔧 RM(Resource Manager)：资源管理器，管理分支事务

2.3 Seata事务模式

2.3.1 XA模式

✨ 核心原理：XA模式基于X/Open组织制定的分布式事务处理（DTP）标准，该模式利用数据库自身对XA协议的支持，通过两阶段提交（2PC）协议来保证分布式事务的强一致性。

• 第一阶段 - 准备阶段：事务协调者（TC）通知所有参与者（RM）执行分支事务（执行SQL），但不进行提交。各参与者将事务状态报告给TC。

• 第二阶段 - 提交/回滚阶段：TC根据所有参与者的反馈决定全局事务的最终结果。如果所有参与者都准备成功，则通知所有参与者提交事务；如果任何一个参与者准备失败，则通知所有参与者回滚事务。

🔄 执行流程：

1. 执行阶段：RM向TC注册分支事务，执行业务SQL但不提交，并将执行状态报告给TC。
2. 完成阶段：TC检查所有分支事务状态。若全部成功，通知所有RM提交事务；若有任一失败，通知所有RM回滚事务。

2.3.2 AT模式（自动补偿）

✨ 特点：

• 无侵入式，对业务代码零改造

• 基于支持本地ACID事务的关系型数据库

• 一阶段提交业务数据和回滚日志

• 二阶段异步提交或回滚
  

🔄 执行流程：

1. 一阶段：执行业务SQL，生成before image和after image，提交本地事务
2. 二阶段提交：删除回滚日志
3. 二阶段回滚：根据回滚日志进行反向补偿

2.3.3⚖️ XA模式 vs AT模式：核心差异总结

特性维度	XA模式	AT模式
一致性级别	强一致	最终一致
性能表现	较低（一阶段锁定资源）	较高（一阶段提交释放锁）
业务侵入性	无侵入	无侵入
实现机制	基于数据库XA协议，两阶段提交	基于SQL解析，生成反向补偿日志
回滚方式	依赖数据库事务回滚机制	依赖数据快照（undo_log）进行反向补偿
资源锁定期	长（从一阶段开始到二阶段结束）	短（仅一阶段本地事务期间）
适用场景	金融转账、对一致性要求极高的场景	电商、互联网应用等大部分业务场景

2.4 Seata部署与集成

🚀 部署步骤：

1. 下载Seata Server
2. 创建所需数据库表（global_table、branch_table、lock_table、undo_log）
3. 修改配置文件（registry.conf、file.conf）
4. 启动Seata Server

🔧 项目集成：

1. 添加Seata依赖
2. 配置数据源代理
3. 添加Seata配置项
4. 使用@GlobalTransactional注解开启分布式事务

三、实践应用

3.1 服务保护实践

🔧 Sentinel整合步骤：

1. 引入Sentinel依赖
2. 配置控制台地址
3. 在簇点链路中配置流控规则
4. 编写降级逻辑

3.2 分布式事务实践

🛒 电商下单场景：

• 订单服务：创建订单
• 库存服务：扣减库存
• 账户服务：扣减余额
• 使用Seata AT模式保证事务一致性

⚙️ 配置要点：

• 确保所有微服务使用相同的事务分组
• 配置正确的Seata Server地址
• 数据库需要创建undo_log表
• 使用@GlobalTransactional注解标注事务入口

四、总结

微服务保护和分布式事务是微服务架构中的核心问题。**通过Sentinel实现服务保护，可以有效防止雪崩效应；通过Seata实现分布式事务，可以保证跨服务的数据一致性。**在实际项目中，需要根据业务场景选择合适的保护策略和事务模式，在系统稳定性和性能之间找到最佳平衡点。