Spring Cloud Alibaba 三件套，加上分布式锁与事务。

一、组件

Spring Cloud Alibaba

Spring Cloud Alibaba 在 Spring Cloud 之上对接 Nacos、Sentinel、RocketMQ 和 Seata，让 Java 微服务用同一套注解完成注册发现、限流降级和分布式事务。它降低了国内云上中间件的接入成本。

版本矩阵必须和 Spring Boot 对齐，混用社区 Netflix 组件时尤其容易踩兼容坑。配置中心的命名空间和环境隔离要先于代码仓库拆分，避免测试配置冲进生产。

治理上把限流规则当代码一样评审。只靠默认值会上线后才发现热点接口被打穿。可观测性要同时看 JVM、Sentinel 实时指标和调用链。

Sentinel

什么是雪崩问题？

雪崩问题是微服务之间的调用链，其中一个服务结点故障，导致的整条调用链的崩溃问题。

雪崩问题的处理

  • 超时机制

  • 舱壁模式（线程池隔离、信号量隔离）：限制每个业务能够请求的线程数。

  • 熔断降级

  • 流量控制：限制QPS

Sentinel和Hystrix对比

流量控制-流控模式

  • 直接模式

  • 关联模式

  • 链路模式

流控效果

  • 快速失败

  • warm up（预热模式、冷启动模式）

  • 排队等待

热点参数限流

隔离

  • 线程池隔离

  • 信号量隔离（Sentinel默认）

降级

熔断策略

  • 慢调用比例

  • 异常比例

网关授权

自定义异常结果

规则持久化

  • 规则管理三种模式

  • 实现push模式持久化

Seata

Seata 为微服务提供分布式事务协调，常见 AT、TCC、SAGA 和 XA。AT 靠反向 SQL 自动回滚，侵入小但要求本地事务和 undo 日志；TCC 要业务提供 try/confirm/cancel，适合资金类强一致。

事务协调器是单点风险，生产要高可用并监控全局锁超时。长事务会拖垮资源，分支要短、重试要幂等。和 Spring Cloud 集成时注意数据源代理是否生效，未代理等于没保护。

选型先问能不能拆成最终一致。能用本地消息表就不要上全局事务。压测要覆盖回滚路径，而不是只测提交成功的快乐路径。

二、架构与一致性

互联网应用架构

互联网应用架构通常从接入层、应用层、数据层向外延展：CDN 与网关挡流量，无状态服务水平扩展，会话外置，数据按读写比拆分。缓存、消息队列和搜索是常见的外围依赖。

演进顺序应匹配规模：先单体模块化，再拆独立扩展的热点服务，最后才是全微服务。观测（日志、指标、追踪）必须先于拆分，否则出了问题找不到调用链。降级和限流是架构的一部分，不是运维临时脚本。存储选型看一致性需求，别把所有状态都塞进同一套 MySQL。安全从网关统一鉴权，内部服务默认不暴露公网。

分布式锁解决方案

分布式锁用来互斥跨进程的临界区，常见实现有 Redis、ZooKeeper 和数据库唯一约束。正确性要求互斥、可重入策略明确、持有者崩溃能释放。性能上要避免锁粒度过粗把吞吐锁死。

Redis 方案简单快，要处理过期与续期；ZK 临时节点适合需要严格通知的场景，延迟更高。能用数据库约束或队列串行化的，不必上锁。锁内只做最短必要操作。

测试要覆盖时钟回拨、主从切换和网络分区。没有 fencing token 时，过期后旧持有者回来仍可能写脏数据。日志打上 lockKey 和持有线程，方便事后对账。

分布式事务

CAP理论

BASE理论

分布式事务实现方案

  • 2PC

  • XA 方案：基于数据库XA实现2PC

  • Seata框架方案

  • 3PC

  • TCC 方案

  • SAGA 方案

  • 本地消息表

  • 可靠消息最终一致性方案

  • 最大努力通知方案

参考

深入浅出分布式事务处理-CSDN博客