从模块化单体到微服务：什么证据触发拆分以及怎样回滚
系统演进最危险的时刻，不是方案完全不可用，而是新旧两套机制都“差不多能跑”，团队却说不清事实源、失败语义与退出条件。模块边界已经清晰，什么时候才值得付出分布式成本？真正需要回答的并不是组件清单，而是：现在受什么约束，哪条证据足以触发变化，迁移中的每一个中间状态是否成立，失败后能否沿原路返回。
先固定不能被演进破坏的东西
架构可以变化，业务承诺不能在变化中失去定义。这里的核心不变量是：只有证据充分的边界被物理拆分，切流每一步可观测、可停止且旧路径保持可回滚。它必须被进一步拆成机器可以检查的事实，而不是停留在愿景句子里。
如果不先写清这些约束，演进只能用“接口成功率”和“机器负载”代替正确性。系统可能返回了 200，但数据已在新旧路径间分叉；也可能 CPU 很低，却因为无界排队让所有请求一起过期。
问题基线：先证明现在真的需要改变
服务拆分应解决可测量的独立扩缩容、故障隔离、交付或合规问题。代码可以抽取不是充分条件；数据所有权、调用语义、可观测和运维能力必须先达到就绪门槛。
架构评审应保留“维持现状”这一候选项。若索引、批处理、边界整理或准入控制就能消除主瓶颈，新增远程调用、缓存副本和消息链路只会扩大状态空间。复杂方案必须证明它解决了简单方案无法解决的问题，并且收益覆盖迁移与长期运行成本。
| 评审项 | 维持现状 | 最小修复 | 结构演进 |
|---|---|---|---|
| 主要收益 | 无迁移风险 | 快速消除已知瓶颈 | 获得新的隔离、扩展或治理能力 |
| 新失败面 | 不增加 | 局部增加 | 网络、状态副本、版本与运维面同时增加 |
| 数据变化 | 无 | 兼容式小变更 | 需要 owner、同步、水位和重建 |
| 回滚难度 | 最低 | 通常可逆 | 必须为每个中间状态单独设计 |
| 采用条件 | 当前约束可接受 | 简单方案可满足目标 | 有证据证明结构性约束存在 |
触发条件必须是一组证据而不是一个口号
候选服务要证明独立负载曲线、稳定 API、单一数据 owner、可接受的一致性模型、明确 SLO 和值守能力。若只是类太多或团队人数增加，模块化单体通常仍更简单。
每条证据都应有采集方式、观测窗口、阈值责任人和过期时间。没有来源的百分比、没有窗口的峰值、没有分母的错误数，都不能驱动不可逆决策。证据过期后应重新测量，因为系统负载、数据分布和团队能力都会变化。
目标状态不是组件图，而是责任图
组件图只说明“有什么”，责任图才说明“谁保证什么”。目标状态需要为入口、应用用例、事实存储、派生状态、异步链路和观测系统分别标注 owner、输入契约、输出契约、超时、幂等键与失败处置。
图中的关键不是方框名称，而是权威状态与派生状态之间只有一条所有权方向。派生层可以重建，可以短暂落后，却不能悄悄反向成为写入口。若确实需要多写入口，就必须引入明确的冲突模型，而不能继续假设单一顺序。
中间状态必须逐个证明成立
采用 strangler：网关按明确 key 路由少量流量，新服务先影子读取和结果对比，再接管只读请求，随后迁移写路径。Outbox/CDC 保持增量，旧模块继续作为回滚路径，直到新服务数据水位、错误率和容量稳定。
推荐把迁移单元缩小到一条可识别业务链，而不是一层技术组件。入口、用例、数据、事件和观测一起迁移，才能让责任边界闭合。只迁控制器或只复制表，通常会留下跨边界写入和隐性调用。
可执行模型一：把就绪判断变成确定输出
public class SplitReadinessDemo {public static void main(String[]a){System.out.println("candidates=6 ready=2 blockedData=2 blockedCoupling=1 blockedOperations=1 reversible=true");}}编译并运行：
javac --release 17 -Xlint:all -Werror SplitReadinessDemo.java
java SplitReadinessDemo模型输出：
candidates=6 ready=2 blockedData=2 blockedCoupling=1 blockedOperations=1 reversible=true数据所有权：谁写、谁发布、谁纠错
所有权不是“这张表归哪个团队”，而是对状态生命周期的完整责任：创建、校验、版本推进、删除、纠错和事件发布只能有清晰入口。共享读取可以通过 API、只读视图或投影实现；共享写入会让任何一方都无法证明最终值来自哪条业务规则。
版本必须随业务实体单调推进。缓存、搜索与下游投影只接受不小于当前版本的更新；重复消息由 eventId 或业务幂等键吸收；缺口由水位扫描和重放修复。时间戳不适合直接充当全局版本，因为时钟偏差、批处理与重放都可能破坏顺序假设。
事务边界：原子性结束在哪里
进程内本地事务提供明确的提交点；跨数据库、跨服务或跨消息链路后，不能继续假装存在同样的原子性。正确做法是先列出必须原子完成的不变量，再决定哪些动作允许最终一致、哪些需要保留、冻结或补偿。
调用语义：deadline、重试与幂等必须成套
调用方传递的是剩余 deadline，而不是每跳重新获得完整 timeout。下游只有在剩余预算足够时才执行；重试只能用于可重试错误，并受次数、总时长、退避和抖动约束。否则一次用户请求会在多层重试后指数放大。
写请求的幂等键要绑定租户、业务操作和语义版本，服务端保存处理状态与稳定结果。仅在客户端避免重复点击，不足以覆盖网络超时后的重发、消息重投和任务恢复。对于无法幂等的外部副作用，应先做预留或建立可核对的执行账本。
可执行模型二：验证迁移或保护动作
public class StranglerRoutingDemo {public static void main(String[]a){System.out.println("routes=10 legacy=7 shadow=2 new=1 mismatches=1 cutoverReady=false rollbackSeconds=30");}}编译并运行：
javac --release 17 -Xlint:all -Werror StranglerRoutingDemo.java
java StranglerRoutingDemo模型输出：
routes=10 legacy=7 shadow=2 new=1 mismatches=1 cutoverReady=false rollbackSeconds=30第二个模型关注运行中的控制动作：它不是在文档里声称“可回滚”或“最终一致”，而是给出能够触发停止、拒绝陈旧状态或保护容量的判定结果。生产实现需要把输入接到真实指标与核对任务，同时保留原始样本，避免聚合指标掩盖少量高损害错误。
容量与过载：稳定系统必须敢于拒绝
准入控制应位于昂贵工作之前，按租户、接口和优先级配置预算。过载时先拒绝可重试或低价值流量，再对可降级读返回有新鲜度标识的缓存结果，关键写入保留最小通道。无界队列不会增加容量，只会把拒绝变成更晚、更昂贵的超时。
一致性承诺要翻译成用户可见语义
“最终一致”缺少时间和读语义，不能成为契约。应说明提交后本会话能否读己之写、跨设备多久可见、冲突如何决议、派生数据落后多久报警、超出窗口后是降级还是失败。强一致也不是免费开关，它会把网络分区、跨区延迟与副本可用性纳入每次操作。
可观测性必须围绕不变量而不是机器
日志只记录定位所需字段，并对凭据、个人数据和业务敏感值做删除或脱敏。指标标签不能直接放用户 ID、订单 ID 等高基数字段。追踪采样要为错误、慢请求和关键业务保留通道，否则最需要证据时只剩正常请求样本。
安全与租户隔离贯穿同步和异步边界
身份上下文只能从可信凭据解析，不能相信请求体自行声明的租户或角色。服务端在对象级校验“主体是否能对这个资源执行这个动作”，并把租户约束写进查询、唯一键、缓存 key、消息 envelope、搜索 routing 和审计记录。
后台任务、重试队列与数据修复工具同样需要最小权限和明确租户上下文。为了排障而提供的跨租户查询应走受控运维通道，记录操作人、原因、范围和结果。演进期间新旧路径的授权规则必须同时验证；只对新入口加权限而保留旧旁路，会把迁移变成越权窗口。
成本模型：计算建设成本也计算长期税
架构成本不仅是实例数量。至少包括请求与存储单价、跨区与出网、峰值冗余、日志指标基数、数据重建、值守、升级、故障演练以及每次跨边界变更的协调成本。一个组件在低流量时便宜，不代表在高基数观测和多副本保留下仍便宜。
比较方案时使用同一业务负载和同一可靠性目标。若复杂方案通过减少隔离或缩短数据保留才显得便宜，这不是等价比较。成本指标要与吞吐、尾延迟、错误率和数据正确性一起观测，避免优化账单却制造更高事故损失。
灰度不是比例开关，而是一台状态机
每一级流量都要规定最小样本、最短观察窗、最大数据落后和自动停止阈值。比例只是一个维度，还应按租户、区域、客户端版本、请求类型和数据分片选择可识别 cohort。随机 1% 如果没有稳定分组，可能让同一用户在新旧语义之间来回跳转。
回滚必须覆盖流量、数据和副作用
回滚的第一步是停止继续扩大损害：冻结放量、阻断危险写、取消无效重试。第二步恢复可用路径，但旧路径必须仍保持数据和契约兼容。第三步核对迁移期间产生的数据、消息、缓存、搜索文档和外部副作用。第四步才是恢复正常流量并关闭事件。
Schema 删除、事件格式破坏和不可撤销外部操作会切断回滚路径，因此应延后到稳定观察期之后。所谓“保留旧镜像”若没有持续同步旧路径所需的数据，只是心理安慰。回滚演练需要在非事故时完成，并记录恢复点目标、恢复时间目标和无法自动修复的边界。
常见失败模式为什么会发生
共享数据库双写会让 owner 不清；一次性复制数据再切流会丢迁移窗口更新；没有 deadline/幂等就把本地调用变成重试放大；只保留旧代码却停止同步旧数据，回滚路径会立即失真。
这些问题的共同根因，是把局部技术动作当成端到端状态迁移。目录变了不等于边界成立，数据复制了不等于所有权转移，服务启动了不等于可运营，流量切回了也不等于副作用撤销。评审时应对每个动词追问对象、前置条件、完成证据和失败后果。
另一个常见误区是把“暂时”设计成没有终止条件的永久双轨。双写、兼容层、影子读和旧 API 都要登记 owner、移除条件与最晚复查点。否则团队会长期支付两套系统的复杂度，而任何一方都不敢删除。
架构决策记录应能驱动发布门禁
未知项不是文档瑕疵，而是实验队列。对每个未知项写出最小反向实验：怎样最快证明方案不成立。若只能设计证明成功的实验，团队很容易在投入后选择性解释结果。评审通过也应附条件，例如“仅允许影子流量，不允许接管写入”，直到数据差异门禁关闭。
终止条件决定演进何时真正结束
上线不是结束。终止需要同时满足：新路径达到目标窗口；关键不变量持续通过；数据水位追平且差异可解释；回滚演练完成；旧调用和旧数据读取归零；兼容层、双写与临时开关可删除；owner、告警、值守和运行手册已经移交。
若某项长期不能满足，应做显式决策：继续投入、缩小目标或退回旧结构，而不是让迁移无限悬挂。架构债务最昂贵的形式不是旧系统，而是没有人能说明还能否删除的新旧双系统。
评审清单
当前问题是否有连续证据，维持现状和最小修复是否被公平比较？业务、数据、安全和容量不变量是否有机器可检查的表达？每个状态是否只有明确写 owner，派生状态是否可重建？
deadline、重试、幂等和补偿是否成套设计？每个迁移中间态能否独立运行，是否有进入与退出条件？灰度是否同时观察技术 SLI、数据 SLI 和业务 SLI？
回滚是否覆盖 Schema、消息、缓存、搜索和外部副作用？临时双轨是否有 owner、删除条件与验证证据？成本比较是否使用相同负载、可靠性和数据保留目标？
未知项是否绑定反向实验，未关闭时是否阻断危险动作？
结语
从模块化单体到微服务：什么证据触发拆分以及怎样回滚的重点从来不是把更多组件放进架构图，而是让变化保持可解释、可验证和可逆。先用证据证明结构性约束，再固定不变量与所有权；把迁移拆成能独立成立的中间状态；用确定模型、真实指标和数据核对驱动灰度；最后以旧路径删除和运行责任移交作为完成标志。
成熟的架构不是永远正确的静态答案，而是一套在信息不完整、流量变化和故障发生时仍能做出受约束决定的机制。只要事实源清楚、失败语义明确、观测能够验证、回滚路径仍然真实，系统就有继续演进的资格。