CQRS作为单体到微服务的零停机迁移方案

单体遗留系统整体迁移到微服务时，最痛苦的环节往往不是写业务逻辑，而是历史数据迁移和新老系统切换那一刻的不确定性——数据模型要对齐、切换窗口要停机、一旦出问题很难回退。借用CQRS（命令查询职责分离）这种读写分离思路，可以完全绕开这个痛点：新微服务只管写，只负责处理业务逻辑和产生自己的新增/变更数据，不需要兼容老单体的历史数据模型；另外单独建一个CQRS查询库，专职提供读服务，这个查询库汇总了老单体的全部历史数据，以及新微服务产生的新增或变更数据。新微服务完成本地写操作后，通过领域事件驱动机制把数据异步复制一份到查询库；如果涉及修改历史数据，则先从查询库读出历史明细，在微服务内完成变更，再把结果异步写回查询库。这样，老单体和新微服务可以并行独立地各自完成写操作、互不干扰，同时两者共享同一个查询库，保证读到的数据始终是新老两边合并后的一致视图。这个设计的关键收益是彻底取消了传统迁移里最危险的”历史数据一次性搬迁”和”新老应用一刀切切换”两个动作：新微服务出问题时，老单体完全不受影响，可以继续正常受理业务；等新微服务稳定运行后，老单体才悄悄退役下线，整个过程用户和查询侧几乎无感知。集成过程中如果新老系统间还存在业务逻辑或服务不兼容，可以引入防腐层，把跟老系统交互相关、又不属于新领域模型职责的适配逻辑单独放进防腐层，避免这些兼容代码污染新构建的领域模型；等新老过渡完成后，防腐层代码本身也可以被直接丢弃。

结构图：

flowchart TB
  A["老单体应用<br/>（继续独立处理写操作）"] -->|历史数据 + 后续变更<br/>领域事件异步同步| Q["CQRS查询库<br/>（汇总新老全量数据，专职读服务）"]
  B["新微服务<br/>（独立处理新业务写操作）"] -->|新增/变更数据<br/>领域事件异步同步| Q
  Q --> R["统一查询服务<br/>（读到的始终是新老合并后的一致视图）"]
  A -.通过防腐层适配旧系统交互，避免污染新领域模型.-> B
  A -.新微服务稳定后，老单体无感下线.-> X["下线"]