【反向重构】聊聊最近组里把微服务并回大单体时，数据迁移和安抚老客户的真实血泪史

一亩三分地傻福吗 发个代码也要积分 赚钱想疯了？

我们也做过反向重构，但是基于K8S，改动主要都在Life Cycle Management，重写Fleet和Local Operator对于Provisioning的Reconciliation为主。主要区别就是多个微服务image的部署变成了单个。相应的Stateful Work Node的Reconciliation Loop重写就好。
我在思考和楼主系统的区别是因为K8S帮我们的系统简化了你提到的一些流量迁移，脑裂和同步的问题吗？

klotics 发表于 2026-6-18 22:17
我们也做过反向重构，但是基于K8S，改动主要都在Life Cycle Management，重写Fleet和Local Operator对于Pro ...

我觉得你的主要场景是部署是分布式还是单体，但是业务逻辑还是相对独立。如果是计算层合并，那么只要把多个微服务的镜像（Images）打包合并成了一个镜像部署，甚至底层可能依然在共享或者访问各自原有的异构数据库。这种重构主要在 K8S 运维层（Operator/LCM），解决的是机器成本和部署碎片化的问题。因为没有动底层数据库，所以不涉及复杂的数据迁移。

如果是存储层合并，你们是把原本分散在不同微服务物理库（比如不同的 MySQL 实例）里的异构数据，合并到了同一个大单体的物理库中。一旦动了数据库，就必然会产生“不停机追历史数据”、“双写防脑裂”和“跨系统对账”的硬核业务问题。

或者你是情况包括了两种，但是业务相对独立，所以只要重新写Reconciliation Loop就好？

秀眉丽眼的木耳 发表于 2026-06-18 22:25:06
我觉得你的主要场景是部署是分布式还是单体，但是业务逻辑还是相对独立。如果是计算层合并，那么只要把多个微服务的镜像（Images）打包合并成了一个镜像部署，甚至底

问到关键点了。我的部署场景是分布式也是multi-tenant的架构，但是我们只涉及多个非业务关键Agent的整合，而我们业务本身就是给To B用户提供智能数据库的解决方案。我们解决方案自己的Storage layer包括支持的数据库本身都没有变化。所以也没有真正需要同步复制或者异步数据库迁移的需求，而这个需求更像是我们的客户需要面对的问题就比如楼主提到的应用场景。这样解释了为什么业务问题的复杂性有差异了，从我们Infra的角度这种整合貌似更简单更像运维管理的整合和升级。不知道我这样的理解是不是正确的。

klotics 发表于 2026-6-18 23:34
问到关键点了。我的部署场景是分布式也是multi-tenant的架构，但是我们只涉及多个非业务关键Agent的整合， ...

这个理解是对的。非常感谢你的反馈。我开始很担心这个场景会不会适用的人很少。但是只要能够引起一些思考就非常好。其实并非业务整合都会这么复杂，在业务量没有到一定量级的时候，双写/双读完全可以。