微服务边界应该如何持续演进？
简化版
服务边界不是一次设计完成的，应根据业务不变量、变化频率、团队责任和运行数据持续调整。演进采用兼容接口、Strangler、双写校验或事件回填逐步拆分/合并，避免停机式大爆炸改造。
详细版
边界信号包括频繁跨服务事务、共同发布、聊天式调用、数据所有权冲突，以及独立伸缩和故障隔离收益。先明确目标边界与数据 owner，建立旧新适配层；迁移流量和数据时保留可回滚开关，完成对账后才撤旧。
拆分并非唯一方向：过细服务导致大量协调时应合并。验收看变更前置时间、跨团队依赖、调用延迟、事故半径和数据差异，而不是服务数量变化。
完整版教学
一、为什么边界会变化
早期业务认知有限，订单与履约可能放在一起；规模扩大后，两者规则、团队和伸缩特征分离。反过来，曾预想独立的两个概念也可能始终共同变化，继续拆开只增加协调。
记忆钩子：边界是假设，运行与组织数据负责验证它。
二、拆分和合并信号
| 信号 | 可能动作 | 先排除 |
|---|---|---|
| 总是共同发布 | 合并 | 流水线不成熟 |
| 独立高负载 | 拆分 | 单纯慢 SQL |
| 跨服务强事务 | 调整边界 | 流程设计问题 |
| 高频细粒度 RPC | 合并/粗粒度 API | 客户端错误用法 |
一个指标不能直接决定架构，要联合业务语义判断。
三、先明确目标状态
画出现有数据、调用和 owner，再定义新边界的不变量、接口、事件与 SLO。没有目标数据所有权就先拆代码，会留下两边都能写同一事实的危险状态。
目标还要说明哪些历史数据迁移、哪些只读归档，以及回滚时谁仍是权威写入者。
四、Strangler 迁移流程
入口路由 -> 旧实现
-> 新实现（影子/小流量）
回填数据 -> 双读比对 -> 切主写 -> 撤旧先把新请求按租户或比例路由到新实现，影子结果只比较不生效。逐步切换时每一阶段都要能回到明确的旧路径。
五、数据迁移的难点
存量回填和增量变更会并发。常见做法是记录快照水位，再回填存量并通过 CDC 追增量；切换前确认 lag 为零或在业务允许范围内。
例如 5000 万行按 5000/s 回填，理论需 10000 秒约 2.78 小时，还要计线上写入和重试。对账应比较数量、字段校验和与关键业务总额。
六、兼容与撤旧
旧消费者存在时，新接口与事件要向前兼容。双写不能永久存在：它会增加差异来源，应设截止日期、差异告警和明确 owner。
撤旧前检查流量为零、数据对账、告警迁移、权限回收和回滚窗口。代码删除只是最后一步。
迁移期间的适配层应标记 owner 和删除日期，否则临时双模型会固化成新的长期耦合。
合并服务时同样要迁移调用方与数据，并保留旧接口代理窗口，不能只把两个仓库复制到一起。
七、常见误区与追问
- 误区：微服务只能越拆越细。 合并也是消除错误边界的重要手段。
- 误区：双写成功返回就代表一致。 两边可能部分成功，需要差异扫描。
- 误区：完成流量切换即可删旧库。 还要覆盖回滚和历史任务窗口。
- 误区：以代码包边界代替数据边界。 双方共享写表仍未真正拆分。
- 追问：怎样选择灰度单位？ 选能保持业务完整性的租户、区域或 key。
- 追问：回填期间新写怎么办？ 快照水位配合 CDC，并用版本防旧值覆盖。
- 追问：如何证明演进成功？ 交付、可靠性、性能和数据差异共同达标。
八、加强记忆
边界演进按“证据识别—目标建模—兼容入口—存量回填—增量追平—灰度切换—对账撤旧”推进。拆与合都服务于不变量和团队自治；任何阶段只保留一个权威写入者，并用可回滚路由和业务对账控制迁移风险。