简介微服务设计模式看似纷繁复杂实则围绕服务拆分、通信集成、数据一致性、可观测性与横切治理展开。这份PPT以架构师视角系统梳理了分解、集成、数据库、可观测、交叉关注五类模式重点包括按业务能力分解、按子域分解、按事务/两阶段提交分解以及面向遗留系统改造的扼杀模式同时涵盖隔板、边车等容错扩展技巧和API网关、聚合器、代理等集成方案。其中数据库模式聚焦服务自治与数据一致性可观测模式贯穿日志、监控与追踪帮助快速定位故障。资源还总结了可伸缩性、灵活性、故障隔离、可用性、去中心化治理及DevOps持续交付等架构原则并指出2PC分布式事务的性能局限强调模式组合使用的重要性。整份材料为单个PPTX课件共1个文件2.09MB结构清晰既适合微服务初学者建立认知也可供中高级开发者作为设计选型参考。目前已有260人学习/下载。1. 微服务设计模式先看它解决什么问题再谈选型一个简单的下单请求在单体应用里就是一个事务扣库存、锁券、调支付要么全成要么全败。一旦拆成微服务这个动作会跨三个服务、三次网络调用任何一次迟到或失败都会让数据悬在半空代码里全是补偿逻辑。这时候你翻设计模式资料看到的往往还是23种GoF模式的老面孔跟微服务没多大关系。微服务设计模式是解决分布式环境下服务拆分、服务发现、数据一致性、流量治理这些反复出现的问题的方案集合价值不是让你代码更优雅而是让系统拆了之后还能立得住。适合谁看正在从单体迁移到服务化架构的开发者和架构师以及已经上了微服务、但总说不清楚问题出在哪一环的人。2. 服务拆分怎么才不算拆碎边界、数据库与事务模式2.1 聚合模式与防腐层用领域边界决定哪里不能拆拆分最怕的不是拆不动而是拆太碎。常见做法是按技术层拆把 Controller、Service、DAO 各抽成一个服务这样拆出来的不是微服务是分布式单体。判断边界的标准应看业务能力是否具备独立生命周期订单有独立的状态流转库存有独立的增减规则支付有独立的外部依赖它们天然适合分开。而订单详情页要展示用户信息这种跨服务查询不构成拆分理由那是查询问题不是边界问题。聚合模式要求在每个服务内部定义一个聚合根所有对聚合内对象的修改都走这个根保证服务内部的一致性边界。防腐层模式则是当服务需要对接外部系统或遗留系统时在中间加一层翻译和隔离防止外部模型的污染扩散进自己的领域模型。落到微服务拆分上这两个模式解决的是同一个问题先划清边界再谈通信。如果一个模块同时被三个服务依赖且每次改动都要协调三个团队发版说明边界划错了。我常用的检查方法是画一张依赖图把被依赖超过两层以上的模块圈出来逐个确认它是否应该下沉为独立服务还是应该被某个服务收编。2.2 数据库拆分模式私有数据库与Saga补偿事务服务拆分后数据库不能还共用一个。每个服务独占自己的库或 Schema是微服务设计模式里最容易理解、也最难执行的一条。它意味着不能再跨表 join跨服务的数据一致性只能靠其他机制保证。常见方案有 2PC、TCC、Saga 和事件最终一致。2PC 在跨服务场景下基本没人用了锁时间太长协调者一挂全员卡死TCC 适合强一致短期事务但侵入性强真正被大规模采用的是 Saga 和事件最终一致。Saga 把一个分布式事务拆成一组本地事务序列每步成功就推进失败就走反向补偿。补偿的顺序必须严格逆序而且每一步都要幂等。下面是一个订单创建的编排式 Saga 核心骨架用 Java 写一个简单的协调器public class OrderSagaOrchestrator { private final MapString, StepStatus sagaLog new ConcurrentHashMap(); // 每一步先执行本地事务成功后记录失败则触发补偿 public void createOrder(OrderCmd cmd) { try { if (!inventoryClient.deduct(cmd.getSku(), cmd.getQty())) { throw new SagaStepException(inventory.deduct.failed); } sagaLog.put(inventory.deduct, StepStatus.SUCCEEDED); if (!paymentClient.authorize(cmd.getAmount())) { throw new SagaStepException(payment.authorize.failed); } sagaLog.put(payment.authorize, StepStatus.SUCCEEDED); orderRepository.confirm(cmd.getOrderId()); } catch (SagaStepException e) { compensate(cmd); throw e; } } private void compensate(OrderCmd cmd) { // 逆序补偿用 orderId 步骤名做幂等键重复执行也不重复扣账 if (sagaLog.containsKey(payment.authorize)) { paymentClient.reverse(cmd.getOrderId()); } if (sagaLog.containsKey(inventory.deduct)) { inventoryClient.restore(cmd.getSku(), cmd.getQty(), cmd.getOrderId()); } } }这段代码的逻辑不复杂先扣库存再授权支付最后确认订单。任何一步抛错就进入补偿流程只补偿那些已成功的步骤。注意 compensate 里每次调用都传了 orderId这是幂等键补偿接口必须保证同一个 orderId 重复调用只在第一次生效否则消息重试会把账扣两次。Saga 分为编排式和 choreography 事件式两种。编排式由一个协调者集中控制上面代码就是这种风格优点是流程清晰、补偿顺序明确缺点是协调者本身会成为单点事件式不引入协调者每个服务监听事件并决定下一步动作适合链路长、参与方多的场景但流程被拆散在多个服务里排查问题就像在黑匣子里找线头。我一般在服务数量小于五个时用编排式再多就考虑事件式。2.3 CQRS模式读模型与写模型分离的代价CQRS 是微服务设计模式里被误用最多的一个。它的本意是当读写负载差异极大时把命令路径和查询路径分开建模各用各的数据结构和服务。典型场景订单写频率低但查询条件复杂写库做了严格的三范式约束读库则按查询维度做宽表甚至冗余物化视图。这样写模型保持领域规则读模型自由优化带宽和延迟都能改善。但 CQRS 的成本比 Saga 还高。它要求你同时维护两份模型、处理两边的同步延迟、解决读库与写库的最终一致性问题如果业务读写比例均衡或者查询只是简单的按主键取数CQRS 带来的复杂度远超收益。一个常见做法是先不加 CQRS等出现同一个查询要 join 五个服务的数据或者写库被统计查询拖垮时再针对单个查询路径引入。决定是否使用的判断标准很简单读路径是否已经开始反向影响写路径的稳定性。对比项什么时候值得上 CQRS什么时候别上读写比例读远大于写且查询维度复杂读写均衡查询简单数据一致性要求可以接受秒级延迟必须强一致团队维护能力能处理双模型同步问题团队刚接触微服务典型场景报表、搜索、聚合页CRUD 管理后台3. 服务间通信模式网关、注册中心与消息驱动的取舍3.1 服务发现客户端发现与服务端发现的选型逻辑微服务实例会扩缩容、会迁移、会宕机IP 地址是动态的服务间通信就不能写死地址。服务发现要解决三件事注册、发现、健康检查。实现方式分为客户端发现和服务端发现。客户端发现模式下服务本身从注册中心拉取实例列表再用负载均衡算法挑一个发起调用Spring Cloud 生态里的 Eureka、Consul、Nacos 走的就是这条路服务端发现模式则把寻址逻辑收敛到基础设施里Kubernetes 的 kube-proxy 和 CoreDNS 就是典型服务只需要访问一个固定的虚拟地址。注册中心选型没有标准答案得看你的运行环境。如果你的服务部署在 Kubernetes 里我一般建议优先用 K8s 内置的服务发现再配合 ingress 做外部流量接入省去维护一套独立注册中心的心智负担。如果你的服务运行在虚拟机或自建机房Nacos 或 Consul 这类独立注册中心更合适因为它们还承担配置管理和健康检查职责。画微服务架构图时注册中心一定是你最先画出的那根连接线它决定了所有服务的调用路径。服务发现有个隐蔽的坑健康检查的灵敏度。检查频率太高会把短暂抖动的实例摘掉导致流量集中打到剩余节点频率太低则会把已经挂掉的实例留在列表里调用方疯狂超时重试。常见做法是探活间隔设为 5 到 10 秒连续三次失败才摘除实例恢复后还要经过半开状态逐步放流量而不是瞬间全部导入。3.2 API网关模式路由、认证与限流的正确边界网关是微服务对外的统一入口几乎所有 springcloud 微服务开源项目里都会放一个网关服务。它承担的职责包括路由转发、TLS 终止、认证鉴权、限流、灰度发布、日志采集。这些事放在网关里是合理的因为它们横切所有服务在每个服务里各做一遍既重复又难以统一。网关最忌讳的是把业务编排写进去。我见过一个项目网关里写了完整的下单流程先调库存、再调支付、再调订单还把失败补偿也放在网关里。这个网关很快就变成了超级单体改一处要回归全部路由而且网关的连接池一满所有下游服务跟着抖。正确的边界是网关只做转发和横切关注点业务聚合交给后端服务或者专门的编排层。聚合器模式是网关身边一个容易混淆的模式。聚合器本身是个后端服务负责把多个微服务的结果拼装成一个响应返给前端。区别在于网关做聚合是技术妥协聚合器做聚合是业务需求。比如移动端首页要展示订单、优惠券、积分三块数据发起三次请求太浪费做一个聚合器服务把三次调用合并成一次这是合理的业务聚合应该放在网关后面的独立服务里。3.3 消息与事件驱动竞争消费者、事件广播与可靠投递同步 HTTP 调用不是微服务通信的唯一方式事件驱动通信在削峰、解耦、跨服务数据同步场景里更常用。常见的消息模式有两种竞争消费者模式和发布订阅模式。竞争消费者把消息只投递给一个消费者实例适合任务分发比如大批量发送通知多个消费者实例平分队列里的消息发布订阅则把事件广播给所有订阅者适合订单状态变更后库存、风控、积分、消息中心各自作出响应。事件驱动看起来比同步调用优雅但它的可靠性成本很高。消息队列只能保证消息不丢不能保证消费者不重复处理。同一个订单创建事件因为消费者宕机被重新投递如果消费者没有做幂等数据就重复落库。我在项目里见过最典型的案例库存服务订阅订单创建事件消费者在处理前查了一次库存是否已扣这个检查不是原子的两个线程同时进来就双双通过库存直接扣成负数。解决方式是在事件里带一个业务唯一键处理前先尝试写入去重表写成功才执行后续逻辑。4. 可靠性治理模式断路器、舱壁和超时重试的参数逻辑4.1 断路器模式三态转换与滑动窗口参数微服务调用链上只要有一个服务变慢依赖它的服务会跟着变慢因为调用方在等响应连接池在耗尽新请求继续堆积最终整条链路雪崩。断路器模式就是干这个的当下游错误率达到阈值断路器打开后续请求直接快速失败不再等待下游超时给下游喘息的时间。断路器有三态关闭、打开、半开。关闭状态正常放行错误率超过阈值就打开打开期间所有请求快速失败经过一段冷却时间后进入半开状态放少量试探请求如果试探成功则关闭失败则重新打开。参数设置直接决定它是救火还是帮倒忙。下面是 Resilience4j 的配置我按生产经验做了注释resilience4j.circuitbreaker: configs: default: slidingWindowType: COUNT_BASED # 按次数统计还是按时间统计 slidingWindowSize: 20 # 滑动窗口内统计最近的20次调用 minimumNumberOfCalls: 10 # 窗口内最少有10次调用才计算错误率 failureRateThreshold: 50 # 错误率达到50%就打开断路器 waitDurationInOpenState: 10s # 打开后等待10秒进入半开 permittedNumberOfCallsInHalfOpenState: 5 # 半开状态最多放5个试探请求 instances: orderService: baseConfig: default waitDurationInOpenState: 30s # 强依赖的下游恢复慢冷却时间调长注意默认配置里滑动窗口大小是 20最少调用次数是 10。这意味着如果你的服务在低流量下每分钟只有几次调用断路器要累计到至少 10 次调用才会开始统计熔断反应会滞后。高流量服务可以把 slidingWindowSize 调大低流量服务应该把 minimumNumberOfCalls 调低否则断路器形同虚设。还有两个参数容易忽略。recordExceptions 决定哪些异常计入失败率网络超时和业务校验失败应该区分对待校验失败是预期结果不该触发熔断。waitDurationInOpenState 不能照搬默认值下游是缓存服务还是数据库服务恢复时间完全不同我给强依赖一般调成 30 秒以上弱依赖用默认 10 秒。4.2 舱壁模式线程池隔离与信号量隔离的取舍舱壁模式的思路来自轮船船舱分隔成多个独立舱室一个舱进水不会沉没整条船。在微服务里就是为不同下游依赖划分独立的执行资源防止某个下游的慢请求耗尽所有线程拖垮对其他下游的调用。常见的实现有两种。线程池隔离为每个下游依赖分配独立的线程池A 服务慢导致 A 的线程池耗尽但 B 的调用还用自己的线程池完全不受影响。优点是隔离彻底支持超时控制缺点是多一层线程切换开销线程池本身还要应对高并发下的排队排队的任务也可能把内存堆满。信号量隔离不创建新线程调用者直接用当前线程执行通过信号量限制同时进入的请求数优点是无额外开销缺点是无法做异步超时。选型维度线程池隔离信号量隔离保护强度强物理隔离中只限制并发数系统开销高线程上下文切换低无额外线程可超时性支持独立超时依赖调用方超时适用场景对延迟要求高、依赖多且差异大依赖少、调用快、高吞吐场景4.3 超时、重试与指数退避的配合超时和重试是最容易实现的治理手段也最容易配错。超时配长了一个慢调用拖住多个线程积累的请求越来越多超时配短了正常慢查询会被误杀误杀后如果还有重试会给下游叠加数倍流量。我一般把网络调用分成连接超时和读取超时两个参数分别设置。连接超时控制在 1 到 2 秒读取超时根据业务接口的 TP99 来定通常取 TP99 的 1.5 到 2 倍。比如订单接口 TP99 是 300 毫秒读取超时就设 500 到 600 毫秒留出缓冲又不能放太松。重试只对幂等操作开启并且失败后要退避不要立刻重试。指数退避配合随机抖动避免多个客户端同时重试造成惊群效应。代码里常见的实现是退避时间按 2 的指数增长再加一个随机偏移量import random import time def retry_with_exponential_backoff(func, max_retries3, base_delay0.2): for attempt in range(max_retries): try: return func() except Exception as e: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 0.1) time.sleep(delay)这段代码的关键在 delay 的计算第一次失败等大约 0.2 秒第二次 0.4 秒第三次 0.8 秒随机抖动让同一时刻失败的调用不会同步重试。注意重试要配合幂等如果接口不能保证幂等重试只会放大问题。还有一点容易被忽略重试和熔断一定要配合使用。如果下游已经处于故障状态重试再多次都是浪费正确顺序是先快速失败触发熔断熔断冷却期结束后再做有限重试。5. 落地避坑微服务设计模式高频翻车的5个现场5.1 Saga 补偿不幂等重试把账扣了两次现象一个订单创建失败补偿流程触发后因为补偿接口调用的消息消息回执超时重发了一次补偿请求结果用户库存被多恢复或者支付退款被重复执行账实不符。原因大部分人设计 Saga 时只考虑了补偿的顺序没有考虑补偿的幂等。补偿接口和正常接口一样也要保证同一个事件处理且仅处理一次。没有幂等键的补偿在分布式环境下就是定时炸弹。解决给每个补偿接口加幂等键键用业务单号加步骤名组成处理前先查状态表已处理过的直接返回成功。还有一个项目里学到的教训补偿记录不能只放内存要落到独立的 saga_log 表里这样协调者重启后才能从日志继续补偿而不是把整个流程重跑一遍。5.2 断路器只熔断没有降级故障被放大了十倍现象下游服务故障断路器成功打开但所有请求全部抛异常返回前端直接报错。虽然没有继续拖垮下游但用户侧体验从慢变成了不可用故障影响面反而更大。原因断路器模式只解决了停止等待问题没解决失败后给用户什么的问题。很多系统初始接入时只关注熔断忽略了 fallback以为返回错误也算兜底。解决熔断的同时必须配置降级策略。降级可以是缓存数据、默认值、空列表也可以是用异步消息把请求记录下来稍后重放。我通常把降级分为业务降级和技术降级技术降级返回安全默认值业务降级走备选链路。判断标准是用户能得到一个明确的、合理的响应而不是一个 500。5.3 强行按技术层拆分做成分布式单体现象项目拆完变成 6 个服务用户服务、订单服务、支付服务、通知服务、文件服务、网关。看起来边界清晰实际上每个服务里还是 Controller、Service、DAO 三层结构改一个需求要同步改六个服务发布也要协调六个团队比单体还难维护。原因这是最常见的拆分错误把分层当成拆分。用户和订单明明是一段强耦合的业务逻辑因为按技术层拆一个请求要串三次服务多出两倍网络延迟和故障点。解决拆分边界只能按业务能力不是按技术分层。被一个业务用例覆盖的完整流程优先放在一个服务内部哪怕这个服务内部也有分层。这个错误一旦成型很难回头所以拆分前一定要找业务方把核心流程捋清楚画出跨模块的数据流再决定边界。5.4 所有跨服务调用都用同步 HTTP链路深度失控现象一次页面请求网关调 AA 调 BB 调 CC 又调 D整个链路四五个跳转接口耗时可分到几百毫秒一旦中间某个环节抖动用户只能看着加载转圈。原因同步调用最直观、最好调试所以大家默认都走 HTTP。但同步链路每增加一跳延迟至少增加一两个 RTT可靠性风险同步累积。设计模式大全里提供了异步消息、事件驱动这些替代方案但落地时多数人被异步难调试劝退。解决控制同步调用链路的深度。我给自己定的规则是一次用户请求的同步调用链不允许超过三级超过部分必须拆成异步事件或者做并行聚合。另一个补救方案是在关键链路引入全链路追踪把一次请求的调用树完整记录下来超过阈值的链路就能直接看到是哪个环节的耗时不正常。5.5 注册中心健康检查参数照抄故障实例迟迟不摘除现象某次线上故障一个节点已经 JVM 假死但注册中心里它还是 ACTIVE 状态调用方持续把流量打到这个节点上表现为偶发性超时重启后又恢复正常过一阵又复发。原因JVM 假死的特征是进程还在、线程池满、无法处理新请求。HTTP 健康检查如果只探测端口连通性端口在听但请求队列已满检查结果依然是健康。项目里用的是 5 秒一次探活三次失败摘除这个频率下假死节点要等配置周期才会被摘除期间已经在持续拖垮调用方。解决健康检查要做两层第一层是 Liveness 检查进程是否存活第二层是 Readiness 检查服务的请求处理能力。Readiness 的探测接口应该模拟真实业务比如查一下数据库连接池是否有空闲连接而不是简单地返回 200。摘除参数要小于调用方的超时时间使快速失败能收到真实状态而不是等了超时之后才意识到节点有问题。6. 模式组合的进阶技巧先画调用链再做故障注入验证前面讲的都是单个模式怎么用实际操作中更考人的是模式怎么组合。组合的核心原则是先保证系统不至于雪崩再考虑数据的最终一致性最后优化响应速度。所以我的组合策略一直很固定网关加注册中心做基础通信超时和断路器覆盖所有同步调用关键跨服务写操作上 Saga遇到读写比例严重失衡再加 CQRS。这套组合能覆盖绝大多数微服务项目的普遍问题既不过度设计又能兜住底。验证组合是否合理最直接的办法是画调用链。我接手一个微服务系统时第一件事不是看代码而是从网关开始把所有同步调用关系画出来。画完数三样东西同步链路最大深度、跨服务数据依赖的数量、每个服务参与的事务边界。链路深度超过三级、数据依赖超过五个、事务边界模糊这三个条件满足任何一个都说明模式组合需要调整。这一步做完再谈优化才有依据。模式组合的第二步是故障注入。在测试环境把某个下游服务的响应延迟人为拉高到三倍观察上游熔断是否按时打开、降级是否生效再把某个服务整体杀掉看链路是否快速失败消息队列里的积压能否被消费端消化。不需要复杂的混沌工程平台用最简单的 Mock 或防火墙丢包规则就能做。我习惯每次发版前跑一轮重点是确认断路器不是纸面配置、Saga 补偿确实能跑通。这里有一个血泪教训验证故障注入时别只测一个节点的故障要测两个节点同时故障的组合。很多系统的短板就是这样暴露的单节点故障能扛但数据库慢查询加缓存穿透同时发生时熔断和降级全乱了套。现在我做故障注入都是先单点、再两点、最后随机组合每个点跑三遍前两遍看行为第三遍看恢复时间。这个习惯坚持了两年帮我在上线前拦下了不少会在深夜响警报的隐患。微服务设计模式没有银弹它的价值在于给了你一套判断问题和构建方案的通用语言。每次遇到分布式问题先把它归类到某个模式上再结合团队的实际情况调整参数和边界而不是套用别人的配置。这个思路在过去的项目里救过我很多次希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/8 2:53:49 · 阅读 1.2k 微服务设计模式实战：拆分、Saga、断路器与避坑指南
简介微服务设计模式看似纷繁复杂实则围绕服务拆分、通信集成、数据一致性、可观测性与横切治理展开。这份PPT以架构师视角系统梳理了分解、集成、数据库、可观测、交叉关注五类模式重点包括按业务能力分解、按子域分解、按事务/两阶段提交分解以及面向遗留系统改造的扼杀模式同时涵盖隔板、边车等容错扩展技巧和API网关、聚合器、代理等集成方案。其中数据库模式聚焦服务自治与数据一致性可观测模式贯穿日志、监控与追踪帮助快速定位故障。资源还总结了可伸缩性、灵活性、故障隔离、可用性、去中心化治理及DevOps持续交付等架构原则并指出2PC分布式事务的性能局限强调模式组合使用的重要性。整份材料为单个PPTX课件共1个文件2.09MB结构清晰既适合微服务初学者建立认知也可供中高级开发者作为设计选型参考。目前已有260人学习/下载。1. 微服务设计模式先看它解决什么问题再谈选型一个简单的下单请求在单体应用里就是一个事务扣库存、锁券、调支付要么全成要么全败。一旦拆成微服务这个动作会跨三个服务、三次网络调用任何一次迟到或失败都会让数据悬在半空代码里全是补偿逻辑。这时候你翻设计模式资料看到的往往还是23种GoF模式的老面孔跟微服务没多大关系。微服务设计模式是解决分布式环境下服务拆分、服务发现、数据一致性、流量治理这些反复出现的问题的方案集合价值不是让你代码更优雅而是让系统拆了之后还能立得住。适合谁看正在从单体迁移到服务化架构的开发者和架构师以及已经上了微服务、但总说不清楚问题出在哪一环的人。2. 服务拆分怎么才不算拆碎边界、数据库与事务模式2.1 聚合模式与防腐层用领域边界决定哪里不能拆拆分最怕的不是拆不动而是拆太碎。常见做法是按技术层拆把 Controller、Service、DAO 各抽成一个服务这样拆出来的不是微服务是分布式单体。判断边界的标准应看业务能力是否具备独立生命周期订单有独立的状态流转库存有独立的增减规则支付有独立的外部依赖它们天然适合分开。而订单详情页要展示用户信息这种跨服务查询不构成拆分理由那是查询问题不是边界问题。聚合模式要求在每个服务内部定义一个聚合根所有对聚合内对象的修改都走这个根保证服务内部的一致性边界。防腐层模式则是当服务需要对接外部系统或遗留系统时在中间加一层翻译和隔离防止外部模型的污染扩散进自己的领域模型。落到微服务拆分上这两个模式解决的是同一个问题先划清边界再谈通信。如果一个模块同时被三个服务依赖且每次改动都要协调三个团队发版说明边界划错了。我常用的检查方法是画一张依赖图把被依赖超过两层以上的模块圈出来逐个确认它是否应该下沉为独立服务还是应该被某个服务收编。2.2 数据库拆分模式私有数据库与Saga补偿事务服务拆分后数据库不能还共用一个。每个服务独占自己的库或 Schema是微服务设计模式里最容易理解、也最难执行的一条。它意味着不能再跨表 join跨服务的数据一致性只能靠其他机制保证。常见方案有 2PC、TCC、Saga 和事件最终一致。2PC 在跨服务场景下基本没人用了锁时间太长协调者一挂全员卡死TCC 适合强一致短期事务但侵入性强真正被大规模采用的是 Saga 和事件最终一致。Saga 把一个分布式事务拆成一组本地事务序列每步成功就推进失败就走反向补偿。补偿的顺序必须严格逆序而且每一步都要幂等。下面是一个订单创建的编排式 Saga 核心骨架用 Java 写一个简单的协调器public class OrderSagaOrchestrator { private final MapString, StepStatus sagaLog new ConcurrentHashMap(); // 每一步先执行本地事务成功后记录失败则触发补偿 public void createOrder(OrderCmd cmd) { try { if (!inventoryClient.deduct(cmd.getSku(), cmd.getQty())) { throw new SagaStepException(inventory.deduct.failed); } sagaLog.put(inventory.deduct, StepStatus.SUCCEEDED); if (!paymentClient.authorize(cmd.getAmount())) { throw new SagaStepException(payment.authorize.failed); } sagaLog.put(payment.authorize, StepStatus.SUCCEEDED); orderRepository.confirm(cmd.getOrderId()); } catch (SagaStepException e) { compensate(cmd); throw e; } } private void compensate(OrderCmd cmd) { // 逆序补偿用 orderId 步骤名做幂等键重复执行也不重复扣账 if (sagaLog.containsKey(payment.authorize)) { paymentClient.reverse(cmd.getOrderId()); } if (sagaLog.containsKey(inventory.deduct)) { inventoryClient.restore(cmd.getSku(), cmd.getQty(), cmd.getOrderId()); } } }这段代码的逻辑不复杂先扣库存再授权支付最后确认订单。任何一步抛错就进入补偿流程只补偿那些已成功的步骤。注意 compensate 里每次调用都传了 orderId这是幂等键补偿接口必须保证同一个 orderId 重复调用只在第一次生效否则消息重试会把账扣两次。Saga 分为编排式和 choreography 事件式两种。编排式由一个协调者集中控制上面代码就是这种风格优点是流程清晰、补偿顺序明确缺点是协调者本身会成为单点事件式不引入协调者每个服务监听事件并决定下一步动作适合链路长、参与方多的场景但流程被拆散在多个服务里排查问题就像在黑匣子里找线头。我一般在服务数量小于五个时用编排式再多就考虑事件式。2.3 CQRS模式读模型与写模型分离的代价CQRS 是微服务设计模式里被误用最多的一个。它的本意是当读写负载差异极大时把命令路径和查询路径分开建模各用各的数据结构和服务。典型场景订单写频率低但查询条件复杂写库做了严格的三范式约束读库则按查询维度做宽表甚至冗余物化视图。这样写模型保持领域规则读模型自由优化带宽和延迟都能改善。但 CQRS 的成本比 Saga 还高。它要求你同时维护两份模型、处理两边的同步延迟、解决读库与写库的最终一致性问题如果业务读写比例均衡或者查询只是简单的按主键取数CQRS 带来的复杂度远超收益。一个常见做法是先不加 CQRS等出现同一个查询要 join 五个服务的数据或者写库被统计查询拖垮时再针对单个查询路径引入。决定是否使用的判断标准很简单读路径是否已经开始反向影响写路径的稳定性。对比项什么时候值得上 CQRS什么时候别上读写比例读远大于写且查询维度复杂读写均衡查询简单数据一致性要求可以接受秒级延迟必须强一致团队维护能力能处理双模型同步问题团队刚接触微服务典型场景报表、搜索、聚合页CRUD 管理后台3. 服务间通信模式网关、注册中心与消息驱动的取舍3.1 服务发现客户端发现与服务端发现的选型逻辑微服务实例会扩缩容、会迁移、会宕机IP 地址是动态的服务间通信就不能写死地址。服务发现要解决三件事注册、发现、健康检查。实现方式分为客户端发现和服务端发现。客户端发现模式下服务本身从注册中心拉取实例列表再用负载均衡算法挑一个发起调用Spring Cloud 生态里的 Eureka、Consul、Nacos 走的就是这条路服务端发现模式则把寻址逻辑收敛到基础设施里Kubernetes 的 kube-proxy 和 CoreDNS 就是典型服务只需要访问一个固定的虚拟地址。注册中心选型没有标准答案得看你的运行环境。如果你的服务部署在 Kubernetes 里我一般建议优先用 K8s 内置的服务发现再配合 ingress 做外部流量接入省去维护一套独立注册中心的心智负担。如果你的服务运行在虚拟机或自建机房Nacos 或 Consul 这类独立注册中心更合适因为它们还承担配置管理和健康检查职责。画微服务架构图时注册中心一定是你最先画出的那根连接线它决定了所有服务的调用路径。服务发现有个隐蔽的坑健康检查的灵敏度。检查频率太高会把短暂抖动的实例摘掉导致流量集中打到剩余节点频率太低则会把已经挂掉的实例留在列表里调用方疯狂超时重试。常见做法是探活间隔设为 5 到 10 秒连续三次失败才摘除实例恢复后还要经过半开状态逐步放流量而不是瞬间全部导入。3.2 API网关模式路由、认证与限流的正确边界网关是微服务对外的统一入口几乎所有 springcloud 微服务开源项目里都会放一个网关服务。它承担的职责包括路由转发、TLS 终止、认证鉴权、限流、灰度发布、日志采集。这些事放在网关里是合理的因为它们横切所有服务在每个服务里各做一遍既重复又难以统一。网关最忌讳的是把业务编排写进去。我见过一个项目网关里写了完整的下单流程先调库存、再调支付、再调订单还把失败补偿也放在网关里。这个网关很快就变成了超级单体改一处要回归全部路由而且网关的连接池一满所有下游服务跟着抖。正确的边界是网关只做转发和横切关注点业务聚合交给后端服务或者专门的编排层。聚合器模式是网关身边一个容易混淆的模式。聚合器本身是个后端服务负责把多个微服务的结果拼装成一个响应返给前端。区别在于网关做聚合是技术妥协聚合器做聚合是业务需求。比如移动端首页要展示订单、优惠券、积分三块数据发起三次请求太浪费做一个聚合器服务把三次调用合并成一次这是合理的业务聚合应该放在网关后面的独立服务里。3.3 消息与事件驱动竞争消费者、事件广播与可靠投递同步 HTTP 调用不是微服务通信的唯一方式事件驱动通信在削峰、解耦、跨服务数据同步场景里更常用。常见的消息模式有两种竞争消费者模式和发布订阅模式。竞争消费者把消息只投递给一个消费者实例适合任务分发比如大批量发送通知多个消费者实例平分队列里的消息发布订阅则把事件广播给所有订阅者适合订单状态变更后库存、风控、积分、消息中心各自作出响应。事件驱动看起来比同步调用优雅但它的可靠性成本很高。消息队列只能保证消息不丢不能保证消费者不重复处理。同一个订单创建事件因为消费者宕机被重新投递如果消费者没有做幂等数据就重复落库。我在项目里见过最典型的案例库存服务订阅订单创建事件消费者在处理前查了一次库存是否已扣这个检查不是原子的两个线程同时进来就双双通过库存直接扣成负数。解决方式是在事件里带一个业务唯一键处理前先尝试写入去重表写成功才执行后续逻辑。4. 可靠性治理模式断路器、舱壁和超时重试的参数逻辑4.1 断路器模式三态转换与滑动窗口参数微服务调用链上只要有一个服务变慢依赖它的服务会跟着变慢因为调用方在等响应连接池在耗尽新请求继续堆积最终整条链路雪崩。断路器模式就是干这个的当下游错误率达到阈值断路器打开后续请求直接快速失败不再等待下游超时给下游喘息的时间。断路器有三态关闭、打开、半开。关闭状态正常放行错误率超过阈值就打开打开期间所有请求快速失败经过一段冷却时间后进入半开状态放少量试探请求如果试探成功则关闭失败则重新打开。参数设置直接决定它是救火还是帮倒忙。下面是 Resilience4j 的配置我按生产经验做了注释resilience4j.circuitbreaker: configs: default: slidingWindowType: COUNT_BASED # 按次数统计还是按时间统计 slidingWindowSize: 20 # 滑动窗口内统计最近的20次调用 minimumNumberOfCalls: 10 # 窗口内最少有10次调用才计算错误率 failureRateThreshold: 50 # 错误率达到50%就打开断路器 waitDurationInOpenState: 10s # 打开后等待10秒进入半开 permittedNumberOfCallsInHalfOpenState: 5 # 半开状态最多放5个试探请求 instances: orderService: baseConfig: default waitDurationInOpenState: 30s # 强依赖的下游恢复慢冷却时间调长注意默认配置里滑动窗口大小是 20最少调用次数是 10。这意味着如果你的服务在低流量下每分钟只有几次调用断路器要累计到至少 10 次调用才会开始统计熔断反应会滞后。高流量服务可以把 slidingWindowSize 调大低流量服务应该把 minimumNumberOfCalls 调低否则断路器形同虚设。还有两个参数容易忽略。recordExceptions 决定哪些异常计入失败率网络超时和业务校验失败应该区分对待校验失败是预期结果不该触发熔断。waitDurationInOpenState 不能照搬默认值下游是缓存服务还是数据库服务恢复时间完全不同我给强依赖一般调成 30 秒以上弱依赖用默认 10 秒。4.2 舱壁模式线程池隔离与信号量隔离的取舍舱壁模式的思路来自轮船船舱分隔成多个独立舱室一个舱进水不会沉没整条船。在微服务里就是为不同下游依赖划分独立的执行资源防止某个下游的慢请求耗尽所有线程拖垮对其他下游的调用。常见的实现有两种。线程池隔离为每个下游依赖分配独立的线程池A 服务慢导致 A 的线程池耗尽但 B 的调用还用自己的线程池完全不受影响。优点是隔离彻底支持超时控制缺点是多一层线程切换开销线程池本身还要应对高并发下的排队排队的任务也可能把内存堆满。信号量隔离不创建新线程调用者直接用当前线程执行通过信号量限制同时进入的请求数优点是无额外开销缺点是无法做异步超时。选型维度线程池隔离信号量隔离保护强度强物理隔离中只限制并发数系统开销高线程上下文切换低无额外线程可超时性支持独立超时依赖调用方超时适用场景对延迟要求高、依赖多且差异大依赖少、调用快、高吞吐场景4.3 超时、重试与指数退避的配合超时和重试是最容易实现的治理手段也最容易配错。超时配长了一个慢调用拖住多个线程积累的请求越来越多超时配短了正常慢查询会被误杀误杀后如果还有重试会给下游叠加数倍流量。我一般把网络调用分成连接超时和读取超时两个参数分别设置。连接超时控制在 1 到 2 秒读取超时根据业务接口的 TP99 来定通常取 TP99 的 1.5 到 2 倍。比如订单接口 TP99 是 300 毫秒读取超时就设 500 到 600 毫秒留出缓冲又不能放太松。重试只对幂等操作开启并且失败后要退避不要立刻重试。指数退避配合随机抖动避免多个客户端同时重试造成惊群效应。代码里常见的实现是退避时间按 2 的指数增长再加一个随机偏移量import random import time def retry_with_exponential_backoff(func, max_retries3, base_delay0.2): for attempt in range(max_retries): try: return func() except Exception as e: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 0.1) time.sleep(delay)这段代码的关键在 delay 的计算第一次失败等大约 0.2 秒第二次 0.4 秒第三次 0.8 秒随机抖动让同一时刻失败的调用不会同步重试。注意重试要配合幂等如果接口不能保证幂等重试只会放大问题。还有一点容易被忽略重试和熔断一定要配合使用。如果下游已经处于故障状态重试再多次都是浪费正确顺序是先快速失败触发熔断熔断冷却期结束后再做有限重试。5. 落地避坑微服务设计模式高频翻车的5个现场5.1 Saga 补偿不幂等重试把账扣了两次现象一个订单创建失败补偿流程触发后因为补偿接口调用的消息消息回执超时重发了一次补偿请求结果用户库存被多恢复或者支付退款被重复执行账实不符。原因大部分人设计 Saga 时只考虑了补偿的顺序没有考虑补偿的幂等。补偿接口和正常接口一样也要保证同一个事件处理且仅处理一次。没有幂等键的补偿在分布式环境下就是定时炸弹。解决给每个补偿接口加幂等键键用业务单号加步骤名组成处理前先查状态表已处理过的直接返回成功。还有一个项目里学到的教训补偿记录不能只放内存要落到独立的 saga_log 表里这样协调者重启后才能从日志继续补偿而不是把整个流程重跑一遍。5.2 断路器只熔断没有降级故障被放大了十倍现象下游服务故障断路器成功打开但所有请求全部抛异常返回前端直接报错。虽然没有继续拖垮下游但用户侧体验从慢变成了不可用故障影响面反而更大。原因断路器模式只解决了停止等待问题没解决失败后给用户什么的问题。很多系统初始接入时只关注熔断忽略了 fallback以为返回错误也算兜底。解决熔断的同时必须配置降级策略。降级可以是缓存数据、默认值、空列表也可以是用异步消息把请求记录下来稍后重放。我通常把降级分为业务降级和技术降级技术降级返回安全默认值业务降级走备选链路。判断标准是用户能得到一个明确的、合理的响应而不是一个 500。5.3 强行按技术层拆分做成分布式单体现象项目拆完变成 6 个服务用户服务、订单服务、支付服务、通知服务、文件服务、网关。看起来边界清晰实际上每个服务里还是 Controller、Service、DAO 三层结构改一个需求要同步改六个服务发布也要协调六个团队比单体还难维护。原因这是最常见的拆分错误把分层当成拆分。用户和订单明明是一段强耦合的业务逻辑因为按技术层拆一个请求要串三次服务多出两倍网络延迟和故障点。解决拆分边界只能按业务能力不是按技术分层。被一个业务用例覆盖的完整流程优先放在一个服务内部哪怕这个服务内部也有分层。这个错误一旦成型很难回头所以拆分前一定要找业务方把核心流程捋清楚画出跨模块的数据流再决定边界。5.4 所有跨服务调用都用同步 HTTP链路深度失控现象一次页面请求网关调 AA 调 BB 调 CC 又调 D整个链路四五个跳转接口耗时可分到几百毫秒一旦中间某个环节抖动用户只能看着加载转圈。原因同步调用最直观、最好调试所以大家默认都走 HTTP。但同步链路每增加一跳延迟至少增加一两个 RTT可靠性风险同步累积。设计模式大全里提供了异步消息、事件驱动这些替代方案但落地时多数人被异步难调试劝退。解决控制同步调用链路的深度。我给自己定的规则是一次用户请求的同步调用链不允许超过三级超过部分必须拆成异步事件或者做并行聚合。另一个补救方案是在关键链路引入全链路追踪把一次请求的调用树完整记录下来超过阈值的链路就能直接看到是哪个环节的耗时不正常。5.5 注册中心健康检查参数照抄故障实例迟迟不摘除现象某次线上故障一个节点已经 JVM 假死但注册中心里它还是 ACTIVE 状态调用方持续把流量打到这个节点上表现为偶发性超时重启后又恢复正常过一阵又复发。原因JVM 假死的特征是进程还在、线程池满、无法处理新请求。HTTP 健康检查如果只探测端口连通性端口在听但请求队列已满检查结果依然是健康。项目里用的是 5 秒一次探活三次失败摘除这个频率下假死节点要等配置周期才会被摘除期间已经在持续拖垮调用方。解决健康检查要做两层第一层是 Liveness 检查进程是否存活第二层是 Readiness 检查服务的请求处理能力。Readiness 的探测接口应该模拟真实业务比如查一下数据库连接池是否有空闲连接而不是简单地返回 200。摘除参数要小于调用方的超时时间使快速失败能收到真实状态而不是等了超时之后才意识到节点有问题。6. 模式组合的进阶技巧先画调用链再做故障注入验证前面讲的都是单个模式怎么用实际操作中更考人的是模式怎么组合。组合的核心原则是先保证系统不至于雪崩再考虑数据的最终一致性最后优化响应速度。所以我的组合策略一直很固定网关加注册中心做基础通信超时和断路器覆盖所有同步调用关键跨服务写操作上 Saga遇到读写比例严重失衡再加 CQRS。这套组合能覆盖绝大多数微服务项目的普遍问题既不过度设计又能兜住底。验证组合是否合理最直接的办法是画调用链。我接手一个微服务系统时第一件事不是看代码而是从网关开始把所有同步调用关系画出来。画完数三样东西同步链路最大深度、跨服务数据依赖的数量、每个服务参与的事务边界。链路深度超过三级、数据依赖超过五个、事务边界模糊这三个条件满足任何一个都说明模式组合需要调整。这一步做完再谈优化才有依据。模式组合的第二步是故障注入。在测试环境把某个下游服务的响应延迟人为拉高到三倍观察上游熔断是否按时打开、降级是否生效再把某个服务整体杀掉看链路是否快速失败消息队列里的积压能否被消费端消化。不需要复杂的混沌工程平台用最简单的 Mock 或防火墙丢包规则就能做。我习惯每次发版前跑一轮重点是确认断路器不是纸面配置、Saga 补偿确实能跑通。这里有一个血泪教训验证故障注入时别只测一个节点的故障要测两个节点同时故障的组合。很多系统的短板就是这样暴露的单节点故障能扛但数据库慢查询加缓存穿透同时发生时熔断和降级全乱了套。现在我做故障注入都是先单点、再两点、最后随机组合每个点跑三遍前两遍看行为第三遍看恢复时间。这个习惯坚持了两年帮我在上线前拦下了不少会在深夜响警报的隐患。微服务设计模式没有银弹它的价值在于给了你一套判断问题和构建方案的通用语言。每次遇到分布式问题先把它归类到某个模式上再结合团队的实际情况调整参数和边界而不是套用别人的配置。这个思路在过去的项目里救过我很多次希望帮到你。本文还有配套的精品资源点击获取