服务拆分方法论：边界、数据与依赖治理
微服务化的核心动作是“拆分”，但拆错了比不拆更糟：拆出几十个服务互相调用、一个需求改五个仓库，团队反而更慢。本章讲拆分的方法论：怎么划边界、数据怎么分、依赖怎么治理。
什么时候才该拆
拆分的收益是独立部署、独立扩容、故障隔离、团队自治；代价是网络开销、分布式事务、运维复杂度。以下信号出现时才考虑拆：
- 单应用发布频率互相拖累（改一行要全量回归）；
- 某模块资源需求与整体差异大（一个吃 CPU、一个吃内存）；
- 团队规模超过“一个应用一条主线”的协作上限；
- 故障爆炸半径过大：局部问题拖垮整个进程。
如果团队只有三五个人、业务刚起步，单体 + 良好模块化可能是更优解。
边界：怎么划才不后悔
- 按业务域而非技术层拆分。
user-service、order-service是按域；controller-service、util-service是按技术层，后者必失败。 - 参考领域模型的限界上下文：订单、库存、支付各自是独立业务语言与规则集合，接口边界清晰，才值得拆（详见 DDD 章节）。
- 边界要能“独立演进”：两个模块每次需求都要同时改、一起发，说明边界划错了。
- 控制服务粒度：初期从 3~5 个大服务开始，比一上来拆 30 个稳妥；粒度随业务理解加深再细化。
数据：微服务最难的一步
服务拆了，数据库还是共享一张大表，等于没拆。数据拆分原则：
- 数据随服务走：每个服务拥有自己数据库/表的写入权，其他服务只能通过接口访问。
- 禁止跨库 JOIN：原单库 JOIN 拆开后要么冗余字段、要么多次调用组装、要么用最终一致的数据副本。
- 事务边界重新划定：跨服务强事务尽量收敛为单服务本地事务；实在跨服务则用“本地消息表/事务消息”做最终一致（见幂等与消息可靠章节）。
- 数据迁移先行：拆分上线前把数据按归属迁好，用双写+对账过渡，避免“代码拆了数据没拆”。
依赖治理
服务拆分后最大的坑是依赖混乱：循环依赖、调用链过深、随意点对点直连。
- 禁止循环依赖：A 调 B、B 调 A 必须重构（把公共逻辑下沉或改事件通知）。
- 调用方向单向化：上层（聚合/编排）调下层（基础域），禁止反向。
- 控制调用深度：一条请求链路超过 3~4 跳，超时与失败概率指数上升，考虑用网关聚合或 BFF 收口。
- 契约先于实现：服务间先定接口契约（DTO、错误码、版本），OpenFeign 接口与 DTO 可放独立契约模块统一管理。
- 事件解耦：下单成功后“发短信/加积分/更新报表”这类下游，用 MQ 异步消费，而不是同步调用链。
- 依赖可视化：用注册中心/调用链平台定期检查服务依赖图，识别“蜘蛛网”式依赖并及时清理。
演进式拆分：绞杀者模式
不要把“大爆炸式重写”作为默认选项。推荐绞杀者模式（Strangler）：在旧单体旁先搭好新服务与网关，把功能逐个从单体“绞杀”出来——新请求走新服务，旧功能留在单体，灰度验证一个迁一个，直到单体只剩空壳再下线。每步可回滚、可发布、可验证，风险远低于一次性重构。
小结
拆分的本质是“管理复杂度”：先想清边界（业务域）、再分数据（归属与一致性）、最后治理依赖（无环、浅链、契约化）。成熟团队的做法是持续地小步演进，而不是一次性“微服务化”运动。