服务拆分

把单体拆成微服务，真正的成本不在拆本身，而在每条跨服务链路上新增的一致性开销：延迟、可用性、可观测性三笔账。本文从本地事务如何退化为跨服务协调讲起，对比强一致两阶段、可靠消息最终一致、Saga 补偿三种偿还方式的代价，再补上最容易被低估的幂等与顺序问题、缓存与读模型的第二笔税，最后给出分阶段落地建议与一份拆分前检查清单。

很多团队在单体变慢时第一反应是拆服务，拆完却发现发布更慢、排障更难、故障更容易扩散。本文不讨论要不要微服务，而是给出可验证的拆分信号、拆分顺序、数据一致性的三种取舍，以及一套能落地的检查清单。

微服务拆分常被当成架构升级，但工具链成熟只降低了“拆”这个动作的成本，没有降低分布式系统的失败成本。本文给出一个判断框架：组织边界、变更频率、独立伸缩需求三者至少两个成立才值得拆；拆分前先用架构测试守住模块边界、用 traceId 补齐可观测性、用契约稳定接口。附三种做法的取舍对比与可执行检查清单。

很多团队的微服务拆分失败，不是因为框架选错，而是把“业务名词”和“数据表”当成了服务边界。本文从一致性成本出发，解释跨服务写操作如何引出分布式事务、幂等与可观测性负担，对比本地事务+事件、Seata AT/TCC、Saga 等方案的取舍，并给出一套可执行的拆分检查清单。

微服务拆分的成本大头不是网络调用，而是故障半径被放大。本文拆解重试、超时倒挂、共享资源池三个放大器，给出按故障域而非业务名词划边界的判断方法，以及网关、可观测性、限流降级、幂等事务四类必须统一收口的能力，并附一条分阶段落地路径与它的适用边界。

拆完服务就补齐治理全家桶，往往让故障更难定位。本文以故障成本（发生概率、定位时长、影响面）作为排序标准，讨论可观测、隔离、协调三类组件的上线顺序，比较按技术分层拆分与按数据边界拆分的取舍，并给出六个阶段、带验收标准的最小闭环。

很多团队把拆分微服务当成架构升级的仪式，却忽略了它本质是一笔交易：用组织自治和独立伸缩，换取分布式一致性、可观测性与运维的长期成本。本文讨论拆分动机如何失真、代码耦合与数据耦合的拆分成本为何差异巨大、一致性方案如何从业务容忍度倒推，并给出一条从模块化到服务化的可执行路径。