Java微服务拆分决策：从单体到分布式的成本、边界与回退

去年年底的一次版本发布让我彻底改掉了能拆就拆的毛病。那天晚上一个跑了三年的电商单体应用要上线一个新促销规则代码评审过了、测试也过了结果打包发布时发现一个不起眼的依赖冲突整个 WAR 起不来回滚花了四十分钟——而这四十分钟里下单接口全挂。事后复盘团队里有人提了一句要是拆成微服务就好了只挂促销那一个服务。这话听着特别有道理但我们花了两周把它拆完之后问题反而更多了链路变长、日志分散、一次跨服务写操作对不上账。这段经历是我写这篇东西的直接原因。Java 微服务架构这个话题被讲得太多了多到很多人以为从单体到分布式是一条单向的、越走越正确的路。实际干下来你会发现它更像一次有明确前置条件、有明确代价、也有明确退路的搬迁工程。单体不是落后的代名词分布式也不是免费的午餐。这篇内容会把这条路拆成几个真实的决策点什么信号说明你该动了、第一刀切在哪里、骨架怎么搭、跨服务调用怎么不被拖垮、数据一致性怎么兜住、出了问题怎么在一堆服务里定位到那一行日志。适合已经有一定 Spring Boot 开发经验、正在犹豫要不要拆、或者已经拆了一半正在填坑的同学。1. 单体为什么会被卡住先分清症状再谈架构我见过太多团队拆分微服务的理由只有一句业务涨了单体撑不住。这句话在技术上几乎等于没说因为它掩盖了真正的问题。一个 Spring Boot 单体能不能撑住业务取决于并发量、代码组织度、发布频率、团队规模这四个变量而不是取决于它是不是单体。所以在动刀之前第一件事是把疼定位到具体器官上。1.1 三类真实症状只有一类必须靠拆分解决第一类是发布耦合。十几个人的团队共用一个代码仓库、一个构建产物任何人改一行代码都要走完整的回归测试一个月只能发两次版。这种情况的根因是发布单元和业务边界不匹配拆服务确实能治但先做 Maven 多模块拆分、明确模块间依赖方向往往能缓解七八成。我待过的一个团队先做了多模块治理把发布频率从月级提到周级拆分的事就往后推了半年。第二类是资源与故障隔离。一个导出报表的慢查询把整个应用的线程池占满导致主链路超时或者图片处理模块吃光了堆内存把订单服务一起带崩。这类问题的特征是局部故障全局放大是拆分收益最明确的一类。但要先排除一个更便宜的方案把重活扔到独立部署的异步 worker 里用消息队列解耦成本可能是拆服务的十分之一。第三类是组织规模。当开发人数超过二十代码的认知负担和合并冲突本身就变成瓶颈这时候需要的是每个小组拥有独立的部署单元也就是康威定律在起作用。这类情况下拆分的驱动因素不是技术而是协作效率。把症状对上号之后你会发现真正必须拆的场景比想象中少。我一般会给团队画一张对照表把决策摆到明面上讨论而不是凭感觉。症状优先尝试的低成本方案何时才升级到拆分发布频繁冲突、回归成本高多模块拆分 依赖约束 契约测试模块边界稳定但仍无法独立发布单个功能拖垮全局异步化、独立 worker 部署、线程池隔离该功能有独立的伸缩需求和 SLA数据库表被多业务乱改表归属划分 只读视图写入事务边界确实跨业务团队人数膨胀、沟通成本高代码所有权 模块负责人制小组需要独立的发布节奏和技术栈想技术升级才拆不要拆没有业务驱动就不拆1.2 拆分成本要提前算清楚别只算收益拆分的成本不是多写几个 pom而是长期的运维复杂度。我在项目里通常会先把这几笔账列出来让业务方也看见基础设施成本注册中心、配置中心、网关、链路追踪、日志聚合、监控告警这些组件至少要占掉一到两个人力的长期维护。调试成本一个请求跨五个服务本地复现一个线上问题的难度是单体的数倍。没有链路追踪的话排障时间会从十分钟变成两小时。数据一致性成本原来一个本地事务搞定的事现在要考虑消息可靠投递、消费幂等、补偿任务。这部分是微服务里最容易出线上事故的地方。测试成本端到端测试需要一套能跑起来的完整环境契约测试、消费者驱动的测试变成必需品。我个人的经验阈值是如果团队里没有人能专职负责基础设施和可观测性那么拆分到超过五个服务就会开始失控。这不是理论是踩出来的。2. 第一刀切在哪里按业务能力而不是技术层新手最容易犯的错是按照技术分层来拆controller 一个服务、service 一个服务、dao 一个服务。这种拆法在纸面上很整齐实际结果是每一次业务请求都要穿过三层网络延迟翻三倍任何一个字段改动都要三边联调。这本质上是把代码里的分层原封不动搬到了网络上是最典型的分布式单体前兆。2.1 从数据库事务边界反推服务边界找边界的实操方法我的习惯是打开数据库 ER 图把经常在同一个事务里被一起修改的表圈成一组。这一组表基本就是一个服务的天然候选。因为在微服务里一个服务应该独占自己的库跨库事务是最贵的操作所以事务内聚就是最好的边界信号。举个例子订单表、订单明细表、订单状态流水表永远在同一个事务里写那它们就该属于订单服务而库存表、库存流水表属于库存服务两个服务之间通过下单成功事件来驱动扣减而不是让订单服务直接 update 库存表。这套方法有个前置动作必须先做把现有的跨模块直接 join 全部梳理出来。我一般会写一段脚本扫一遍慢查询日志和代码里的 join 语句列出所有的跨域关联然后逐个判断——是改成服务内冗余字段还是改成接口调用还是改成事件同步。这一步做不细拆完之后就会变成每个接口都在调五个服务拼数据。2.2 服务粒度宁可粗一点也不要细碎关于粒度我的判断标准只有一条一个服务应该对应一个能独立演进、独立发布、独立扩容的业务能力。如果两个模块永远一起改、一起发、一起扩容那它们就不该拆开。反过来如果一块逻辑有独立的伸缩曲线比如秒杀校验的 QPS 是普通接口的五十倍那即使业务上不大也值得单独拎出来。实践中我会用三个问题来校验粒度是否合适这个服务能不能在不改其他服务的前提下完成一次完整的业务功能上线这个服务的数据库表是不是只被它自己写这个服务挂掉一小时业务影响面是不是可控且可描述三个都答是粒度基本合适。如果第一个答否说明切得太碎如果第三个答影响全站说明这个服务承担了过多职责还要继续拆或者做降级设计。2.3 拆分顺序先剥外围最后动核心交易大拆分最忌讳一次性重构。我见过的成功案例都是渐进式的第一步先把非核心的、只读的、旁路的模块剥出去比如消息推送、文件上传、报表统计、字典配置。这类模块的特点是失败影响小、事务简单、调用方少用它来跑通整套基础设施最合适——注册中心、配置中心、网关路由、链路追踪全部在这个阶段验证一遍出问题的代价很低。第二步剥业务关联度中等但写操作独立的模块比如用户中心、商品中心。这一步要重点处理数据迁移和双写过渡。第三步才动核心交易链路因为这部分的跨服务一致性问题最难。整个过程我建议按季度规划而不是按周因为每个阶段都需要一段并行运行期来验证。有个细节很容易被忽略拆出去的第一个服务不要选最难的也不要选最边缘到没人用的。选一个有真实流量、但故障影响可控的这样基础设施的问题能暴露出来团队也能积累信心。3. 骨架三件套注册发现、配置中心、网关服务拆开之后最先撞上的问题不是业务而是服务 A 怎么找到服务 B。硬编码 IP 在容器化环境里必然失效因为每次发布 IP 都变。这时候需要的是一套服务发现机制每个服务启动时把自己注册到注册中心调用方从注册中心拿到实时的实例列表。这一层还有第二个价值——它天然支持按实例权重做灰度、按健康状态自动摘除故障节点。3.1 注册发现客户端发现与服务端发现的取舍主流方案分两派。一派是客户端发现调用方自己拉取实例列表并在本地做负载均衡Nacos、Consul 这类注册中心配 OpenFeign 就是这种模式好处是少一跳、性能好坏处是每个服务都要引入客户端依赖并维护缓存逻辑。另一派是服务端发现由负载均衡器或网关统一转发好处是客户端无感坏处是多一跳网络。我在 Java 技术栈里的默认选择是客户端发现配置大致是这样spring: application: name: order-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: prod group: ORDER_GROUP ephemeral: true这里有几个参数值得展开说。namespace用来做环境隔离测试和生产的实例绝不能注册到同一个命名空间否则测试流量打到生产实例上的事故我见过不止一次。group用来做同环境内的业务分组隔离。ephemeral决定是临时实例还是持久实例临时实例靠心跳保活进程挂掉后会被自动摘除绝大多数业务服务都该用临时实例只有那种需要人工介入才下线的场景才用持久实例。服务端还要有健康检查的兜底。注册中心的心跳只能证明进程活着不能证明接口能用。所以我会额外暴露一个轻量健康检查接口只检查关键依赖数据库连接、缓存连接不做复杂逻辑避免健康检查本身成为性能瓶颈。3.2 配置中心把开关从代码里赶出去单体时代的配置文件放在 jar 包里改一个超时时间要重新打包发布这个痛点在小团队里不明显服务一多就变成了灾难二十个服务改一个公共参数要改二十次。配置中心解决的就是这个问题——配置外置、集中管理、支持热更新、支持按环境按集群差异化。落地时最容易出问题的是热更新的作用域。不是所有配置都能热更新比如数据库连接池的核心参数、线程池大小改了之后需要重建对象才生效直接刷新配置值是没用的。我的做法是在代码里给配置项分两类一类是纯值型超时时间、限流阈值、开关用RefreshScope支持热更新另一类是结构性配置明确标注重启生效避免运维误以为改完立刻有效。Data Component RefreshScope public class GatewaySwitchConfig { // 灰度开关支持配置中心热更新 Value(${biz.gray.enabled:false}) private boolean grayEnabled; // 调用下游的读超时单位毫秒 Value(${biz.timeout.read:800}) private int readTimeout; }另外一个必须养成的习惯配置要有默认值。配置中心挂掉或者网络抖动时服务启动不能因为拿不到配置直接崩。所有Value都写上:默认值这是最便宜的高可用手段。3.3 网关的职责边界别把它做成万能胶网关的定位应该是南北向流量的统一入口职责包括路由转发、鉴权、限流、协议转换、灰度分流。它不该承担的是业务逻辑编排、多服务聚合返回值、复杂的字段裁剪。我见过把网关写成超级 BFF的项目最后网关的代码量超过所有业务服务之和任何一个业务改动都要动网关网关成了新的单体。路由配置上有个细节值得说默认情况下网关的线程模型是异步非阻塞的但如果你在过滤器里写了阻塞调用比如同步查数据库做鉴权整个网关的吞吐会断崖式下跌。所以鉴权信息要么放缓存、要么走响应式客户端。这一点在压测时特别容易被发现单机 QPS 从两万掉到八百通常就是过滤器里藏了一个同步 IO。4. 跨服务调用超时、重试、熔断的次序不能乱服务拆开之后一次用户请求会串起三到五个服务任何一个环节变慢用户感知到的延迟就是所有环节之和。更麻烦的是某个下游变慢会占住上游的线程上游的线程被占满后又会影响它的上游这就是雪崩。我处理这类问题的顺序是固定的先把超时设对再考虑重试最后才是熔断和隔离。顺序反了效果会互相抵消。4.1 超时是底线而且必须逐层递减超时的基本原则是下游超时必须小于上游超时。假设网关超时 3000ms订单服务调用库存服务的超时是 2000ms库存服务调用计价服务是 1000ms这样任何一层出问题调用方都能在自己的超时窗口内拿到明确的失败结果而不是无限等待。如果反过来了——下游超时比上游还长——上游早就断开了下游还在傻等线程被白白占用。feign: client: config: default: connectTimeout: 300 readTimeout: 800 loggerLevel: basic连接超时设得比读超时短很多是因为连接失败通常是网络或实例已经挂了快速失败比等待更有价值读超时则要覆盖正常业务的 P99 耗时。这两个值的设定不能拍脑袋得看监控里的实际分位数。我的习惯是取 P99 的 1.5 倍作为读超时同时保证这个值小于上游超时的二分之一。4.2 重试是把双刃剑只对幂等操作开很多人把重试当成提可靠的万能药结果在大促时制造了重试风暴下游已经过载响应变慢上游还在不断重试请求量翻倍下游彻底压垮。我的规则很明确只对幂等的读接口开启重试写接口一律不重试重试次数最多一次并且必须配合退避和抖动。幂等读的重试配置可以这样写Bean public Retryer feignRetryer() { // 初始间隔 100ms最大间隔 500ms最多重试 1 次 return new Retryer.Default(100, 500, 2); }这里第三个参数是最大尝试次数设为 2 表示首次失败后重试一次。写接口如果需要最终可靠正确的做法不是重试而是本地消息表加补偿任务这个话题在第 5 节展开。4.3 一次雪崩的完整时间线复盘我把去年遇到的一次典型故障按时间线记下来因为它几乎踩全了所有坑时间点发生了什么根因T0s商品详情接口 P99 从 80ms 涨到 1200ms数据库慢查询索引失效T15s订单服务调用商品服务超时线程池开始堆积订单服务读超时设的是 5000ms太宽松T40s订单服务线程池打满下单接口全线超时没有线程隔离慢调用占满共享池T60s网关重试配置生效下单请求量翻倍对非幂等写接口开了自动重试T180s数据库连接数打满商品服务彻底不可用缺少熔断流量持续压入事后改了三件事把订单服务调用商品服务的读超时从 5000ms 降到 600ms给商品调用单独配一个线程池做舱壁隔离去掉网关层对所有接口的自动重试只保留 GET 的幂等重试。改完之后再压测商品服务人为注入 5 秒延迟下单接口的成功率仍然保持在 95% 以上只是商品区块降级成了兜底文案。熔断参数上我一般这样设统计窗口 10 秒最小请求数 20慢调用比例阈值 50%熔断时长 5 秒。最小请求数是关键设成 1 的话一个偶发慢请求就会触发熔断误伤率极高。5. 跨服务写操作分布式事务里最容易踩的坑这是微服务里事故密度最高的地方。原来在一个本地事务里搞定的下单扣库存写流水拆开之后变成了三个服务的三次写操作中间任何一步失败都会导致数据对不上。我见过最严重的一次订单创建成功但库存没扣超卖了三百多件全靠人工补单。5.1 强一致两阶段提交为什么在多数业务里不划算两阶段提交能保证强一致代价是同步阻塞和性能急剧下降。在跨服务的场景里它意味着所有参与者在一个事务期间都持有资源锁只要有任何一个服务变慢整个链路就被拖住。对电商、内容这类高并发业务来说这个代价基本不可接受。我的选型原则是只有账户余额、资金这类绝对不能错的场景才考虑 TCC 或者强一致方案其余绝大多数业务用最终一致就够了。订单扣库存、积分发放、消息通知这类场景允许几百毫秒甚至几秒的最终一致用本地消息表或事务消息实现性能和可靠性都更可控。5.2 本地消息表加幂等消费的落地写法这个方案的核心思路很朴素把业务写库和消息发送放进同一个本地事务靠数据库的原子性保证不丢消息再靠定时任务把没发出去的消息补发最后靠消费端的幂等保证不重复处理。CREATE TABLE local_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_type VARCHAR(32) NOT NULL COMMENT 业务类型, biz_id VARCHAR(64) NOT NULL COMMENT 业务主键用于幂等, payload TEXT NOT NULL COMMENT 消息体, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待发送 1已发送 2已消费, retry_count INT NOT NULL DEFAULT 0, next_retry_at DATETIME NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_biz (biz_type, biz_id) ) ENGINE InnoDB;写业务数据的同一个事务里插一条消息记录事务提交后由定时任务扫描status 0的记录投递出去。消费端收到消息后先查自己的防重表如果这个biz_id已经处理过就直接确认没处理过就在本地事务里同时写业务数据和防重记录。Transactional(rollbackFor Exception.class) public void consumeStockDeduct(StockDeductMessage msg) { // 1. 幂等校验防重表唯一索引兜底 int inserted dedupMapper.insertIgnore(msg.getBizId()); if (inserted 0) { log.info(重复消息直接忽略,bizId{}, msg.getBizId()); return; } // 2. 业务处理 int rows stockMapper.deduct(msg.getSkuId(), msg.getCount()); if (rows 0) { throw new BizException(库存不足,skuId msg.getSkuId()); } }这里有个细节必须强调幂等校验和业务写入必须在同一个本地事务里。如果先查防重表、再开另一个事务写业务中间进程挂掉就会出现防重记录有了但业务没做的情况消息被误判为重复而丢弃这是最隐蔽的数据丢失。5.3 补偿任务与监控指标怎么设计本地消息表方案一定要配套补偿任务。扫描频率我一般设成 5 秒一次只捞next_retry_at now()的记录重试次数超过 8 次就转入死信状态并触发告警由人工介入。为什么要分级因为中间某几次可能是下游临时抖动无限重试没有意义但直接丢弃又可能丢真实数据。监控上有三个指标必须盯着待发送消息的堆积量、死信消息数量、消费失败率。堆积量持续上涨说明投递链路有问题死信数量非零说明有业务逻辑异常需要人看。这三个指标不上监控的话一致性问题是静默的往往等到财务对账才发现。6. 可观测性拆完之后如何定位一行日志微服务带来的调试体验下降是实打实的。用户反馈下单卡了一下在单体时代你加个日志断点就能定位拆开之后你需要在五个服务的上千条日志里找出属于这次请求的那几条。没有链路追踪这个过程基本靠猜。6.1 TraceId 贯穿全链路的三个断点链路追踪的核心是给每个请求分配一个唯一标识并在所有跨进程调用中透传。Java 技术栈里实现的关键是抓住三个容易断链的位置HTTP 调用通过 Feign 的RequestInterceptor把 TraceId 塞进 header下游用 Filter 读出来放进 MDC。消息队列发送时放到消息头消费时取出并放回 MDC否则消费链路和上游彻底断开。线程池这是最隐蔽的断点。MDC 是基于 ThreadLocal 的任务提交到线程池后就丢了上下文必须在提交任务时手动捕获并传递。public class TraceMdcInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { String traceId MDC.get(traceId); if (traceId ! null) { template.header(X-Trace-Id, traceId); } } }线程池那一段我的做法是包装一层TaskDecorator在提交任务时把当前 MDC 快照存下来执行时再恢复执行完清理掉。这段代码很短但不写的话异步链路排查基本无解。6.2 采样率与存储成本的平衡全量采集链路数据的成本是很吓人的高 QPS 场景下存储费用能超过服务器费用。所以采样率必须调。我的策略是分层采样错误请求和慢请求 100% 采集正常请求按 1% 到 5% 采样。这样既保证了问题请求一定能看到完整链路又控制了存储量。同时给慢请求单独设阈值比如超过 500ms 就强制采集这比盲目全量采集实用得多。日志聚合同样需要治理。服务一多日志量会翻十倍我一般要求业务服务只打关键节点日志请求入口、关键分支、异常、外部调用结果中间过程用 debug 级别生产环境默认关闭。日志格式统一成 JSON把 traceId、服务名、接口名都作为字段方便检索。6.3 告警阈值怎么定才不吵告警疲劳是微服务运维最大的隐形杀手。规则一堆每天几百条通知最后没人看。我的做法是只对四类情况告警核心接口错误率超过 1%、核心接口 P99 超过阈值持续三分钟、消息堆积超过阈值、熔断器打开。其余的都做成看板人主动去看不推消息。这里有个小技巧阈值不要用绝对值用相对基线。比如错误率的告警基线设为过去七天的同时段均值加上三个标准差这样大促期间的整体水位上涨不会造成误报而真正的异常尖峰仍然能触发。这一条改完之后我们团队的无效告警下降了大概七成。7. 上线方式与团队边界服务拆完之后发布节奏会变得频繁一天发十几次是常态。这时候如果还是全量替换每次发布都是一次风险事件。灰度发布和蓝绿部署就变成了必需品。同时服务的边界最终是由团队边界塑形的这一点如果不提前想清楚架构会随着组织变动反复摇摆。7.1 灰度发布绕不开的数据库兼容灰度发布的本质是同一个服务的两个版本同时在线这就对数据库变更提出了约束任何一次表结构变更都必须保证新旧两个版本的代码都能正常工作。我总结出一套三步走的规矩。第一步是扩展阶段只加字段、加表、加索引不改不删。新字段必须允许 NULL 或者有默认值老代码不认识这个字段写入时不受影响。第二步是双写阶段新代码写新字段同时兼容读老字段老代码继续写老字段。这个阶段要跑够时间确保数据回填完成并且有监控能对比两个字段的差异。第三步才是清理阶段等所有实例都升级完、灰度完全铺开、观察期过了之后再删掉老字段。急不得我见过灰度期间直接删字段导致未升级实例全部报错的事故回滚都回不了。阶段数据库动作代码状态观察指标扩展加字段允许 NULL旧版本无感知写入延迟、锁等待双写新旧字段并存新版本双写、读新兜底读旧两字段差异率、回填进度收敛老字段置为废弃全部读新字段错误率、慢查询清理删除老字段无引用无灰度分流的维度也有讲究。按用户 ID 取模分流最稳妥同一个用户体验一致按 header 分流适合内部测试按比例随机分流最简单但体验会跳变。我在核心交易链路上一般用用户 ID 分流比例从 1% 起每十五分钟观察一次错误率和延迟没问题再加倍。7.2 团队边界决定服务边界康威定律说系统的结构会趋同于组织的沟通结构这在微服务里体现得极为直接。如果两个服务由同一个小组维护它们迟早会因为顺手而互相调用、共享数据表边界慢慢就模糊了。反过来如果两个模块分属不同小组即使技术上耦合也会被强行拆开。所以划定服务边界的时候我会先问一句这个服务未来由谁负责如果找不到明确的负责人说明要么这个服务太边缘考虑合并要么组织还没准备好考虑推迟拆分。一个服务有明确的所有者才有明确的 SLA、明确的发布节奏、明确的故障责任人架构才稳得住。配套的还有接口契约的管理。我要求所有跨服务接口必须定义独立的 API 包消费方只能依赖这个包不能直接依赖提供方的实现模块。这个约束看起来很形式化但它能在编译期就拦住大量不该有的耦合。接口变更走版本号新增字段允许删除和改语义必须升版本。8. 分布式单体的识别与回退到模块化单体这是我特别想讲的一节因为几乎所有团队都会在拆分路上经历一次拆完之后更糟的阶段。如果这个阶段处理不好就会一路加组件、加中间件最后得到一个既没有单体效率、也没有微服务弹性的四不像。8.1 分布式单体的五个典型特征判断标准很具体对上三个以上基本就能确诊服务之间同步强耦合一次请求串行调用五个以上服务任意一个慢全链路就慢没有一个是可选的。数据库混用服务 A 直接读服务 B 的表或者多个服务连同一个库。这说明边界根本没切开只是把代码分到了不同进程。发布必须成套改一个功能要同时发布三四个服务版本必须严格对齐本质还是一体发布。共享实体类所有服务依赖同一个 domain 包一个字段改动引发全量编译失败。没有独立的数据所有权说不清哪张表归谁出问题无法定位责任人。如果诊断出这些问题方向不是继续拆而是往回收敛。我经历过一次这样的收敛把五个服务合并成两个反而让发布频率和故障率都改善了。8.2 什么时候应该收手做模块化单体模块化单体是一个被严重低估的选项。它的形态是单个部署单元但内部用严格的模块划分和依赖约束模块之间只通过明确的接口通信每个模块有自己的表所有权。它的好处是把微服务的边界纪律保留下来同时避免了分布式的一切开销。在 Java 里落地模块化单体最实用的手段是 Maven 多模块加依赖检查把每个业务模块做成独立 module用构建工具限制模块间只能依赖对方暴露的 api 模块实现模块不可见。再加一层架构测试比如用 ArchUnit 写规则禁止跨模块直接访问 dao 包构建时自动检查违规就失败。ArchTest public static final ArchRule order_should_not_access_stock_internal noClasses().that().resideInAPackage(..order..) .should().accessClassesThat() .resideInAPackage(..stock.internal..);这段规则写在测试里每次构建都会跑。它带来的约束效果某种程度上比拆成两个服务更强因为它是编译期强制的不依赖人的自觉。我的判断是团队规模在十人以内、业务没有明确的独立伸缩需求、团队里没有专职的基础设施人力优先做模块化单体。等这三个条件中有两个被打破了再启动真正的服务化。这条建议我给过好几个团队回过头看采纳的那些项目在半年内的线上事故数量都明显更低。补充一个现实观察从微服务回退到模块化单体的团队往往比从单体走向微服务的团队更容易成功。因为他们已经经历过分布式的痛对边界纪律有真实的敬畏合并之后不会退化成大泥球。最后分享两个我个人的习惯。第一个是每次拆分之前先花半天时间把这次拆分要解决的三个具体问题写下来贴在项目看板上三个月后回头看如果三个问题里解决了不到两个就说明这次拆分方向有问题该停下来复盘而不是继续推进。第二个是给每个新拆出来的服务写一份故障影响说明书明确写清它挂了会影响哪些功能、有没有降级方案、降级后的用户表现是什么。这份文档在真实故障发生时的价值远超任何架构图。踩过几次坑之后我越来越确信架构决策的质量不取决于用了多少组件而取决于你是否清楚每个选择的代价并且提前为这个代价做好了准备。