SpringCloud微服务保护与分布式事务知识点总结
🛡️ 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根据所有参与者的反馈决定全局事务的最终结果。如果所有参与者都准备成功，则通知所有参与者提交事务；如果任何一个参与者准备失败，则通知所有参与者回滚事务。
🔄 执行流程：
- 执行阶段：RM向TC注册分支事务，执行业务SQL但不提交，并将执行状态报告给TC。
- 完成阶段：TC检查所有分支事务状态。若全部成功，通知所有RM提交事务；若有任一失败，通知所有RM回滚事务。
2.3.2 AT模式（自动补偿）
✨ 特点：
-
无侵入式，对业务代码零改造
-
基于支持本地ACID事务的关系型数据库
-
一阶段提交业务数据和回滚日志
-
二阶段异步提交或回滚
🔄 执行流程：
- 一阶段：执行业务SQL，生成before image和after image，提交本地事务
- 二阶段提交：删除回滚日志
- 二阶段回滚：根据回滚日志进行反向补偿
2.3.3⚖️ XA模式 vs AT模式：核心差异总结
| 特性维度 | XA模式 | AT模式 |
|---|---|---|
| 一致性级别 | 强一致 | 最终一致 |
| 性能表现 | 较低（一阶段锁定资源） | 较高（一阶段提交释放锁） |
| 业务侵入性 | 无侵入 | 无侵入 |
| 实现机制 | 基于数据库XA协议，两阶段提交 | 基于SQL解析，生成反向补偿日志 |
| 回滚方式 | 依赖数据库事务回滚机制 | 依赖数据快照（undo_log）进行反向补偿 |
| 资源锁定期 | 长（从一阶段开始到二阶段结束） | 短（仅一阶段本地事务期间） |
| 适用场景 | 金融转账、对一致性要求极高的场景 | 电商、互联网应用等大部分业务场景 |
2.4 Seata部署与集成
🚀 部署步骤：
- 下载Seata Server
- 创建所需数据库表（global_table、branch_table、lock_table、undo_log）
- 修改配置文件（registry.conf、file.conf）
- 启动Seata Server
🔧 项目集成：
- 添加Seata依赖
- 配置数据源代理
- 添加Seata配置项
- 使用@GlobalTransactional注解开启分布式事务
三、实践应用
3.1 服务保护实践
🔧 Sentinel整合步骤：
- 引入Sentinel依赖
- 配置控制台地址
- 在簇点链路中配置流控规则
- 编写降级逻辑
3.2 分布式事务实践
🛒 电商下单场景：
- 订单服务：创建订单
- 库存服务：扣减库存
- 账户服务：扣减余额
- 使用Seata AT模式保证事务一致性
⚙️ 配置要点：
- 确保所有微服务使用相同的事务分组
- 配置正确的Seata Server地址
- 数据库需要创建undo_log表
- 使用@GlobalTransactional注解标注事务入口
四、总结
微服务保护和分布式事务是微服务架构中的核心问题。**通过Sentinel实现服务保护，可以有效防止雪崩效应；通过Seata实现分布式事务，可以保证跨服务的数据一致性。**在实际项目中，需要根据业务场景选择合适的保护策略和事务模式，在系统稳定性和性能之间找到最佳平衡点。