从单体架构迁移到微服务，我是怎么设计的

架构演进从来不是”重写”，而是一场有节奏、可回滚、能持续交付的工程。本文复盘我在一个传统单体系统上做微服务化改造的完整设计思路。

为什么不直接重写

接手时，系统是一个运行多年的单体应用，业务逻辑高度耦合，编译一次要十几分钟，任何小改动都要整体发版。团队第一反应是”推倒重写”。

但重写意味着：在很长一段时间内没有新功能产出，且新旧系统切换期的数据一致性几乎无法保证。最终我们选择了绞杀者模式（Strangler Fig Pattern）——在保留老系统运转的前提下，逐步把能力”绞杀”出来。

拆分原则：先按业务域，再按变更频率

拆分粒度是最容易踩坑的地方。拆太细，分布式事务和运维成本爆炸；拆太粗，等于没拆。

我们的经验是两轮拆分：

1. 第一轮按业务域：把系统切成若干个自治的领域边界（用户、订单、设备、GIS 等），每个域对应一个团队、一个独立的交付单元。
2. 第二轮按变更频率：把”频繁变更”和”稳定不变”的模块再次分离，让高频模块能独立发布，不用拖着稳定模块一起回归。

判断边界是否合理的标准很简单：这个服务能不能独立演进、独立部署、独立扩容？ 如果三个”独立”都做不到，说明边界划错了。

基础设施先行

微服务改造最大的成本不在业务代码，而在基础设施。没有配套的注册中心、网关、配置中心，微服务就是”分布式单体”。

我们按这个顺序落地基础设施：

注册中心（Nacos）→ 网关（Gateway）→ 配置中心 → 链路追踪 → 监控告警

注册中心与配置中心一定要先于业务服务上线，否则每个服务的 IP、配置都会变成散落的硬编码，后期治理成本极高。

数据拆分：最难啃的骨头

数据拆分比代码拆分难一个数量级。我们的策略是：

• 先拆服务，共享数据库（过渡态）：先把读写逻辑拆到独立服务，数据库暂不拆。
• 再拆数据库：按领域拆库，跨库的强一致事务用最终一致性（MQ 消息）替代。
• 主数据单独治理：像用户、组织这类被几十个系统引用的数据，单独建设主数据服务，统一同步。

一个关键教训：跨服务的 JOIN 必须禁止。一旦允许一个服务直接查另一个服务的表，服务边界立刻名存实亡。

迁移节奏：小步快跑，随时可回滚

我们按”能力”而不是”模块”来迁移。每个迁移单元都满足：

• 有灰度开关，能按租户/用户逐步放量
• 新旧逻辑双跑一段时间，对比结果
• 出问题能一键切回老逻辑

这样每一周都能有可验证的进展，而不是憋三个月后一次性切换。

小结

微服务改造的本质是组织与边界的问题，技术只是手段。真正决定成败的是：边界划得清不清楚、基础设施到不到位、迁移能不能随时回滚。这三件事想清楚了，迁移就成功了一大半。