概要

老系统不好维护时，团队很容易形成两个极端观点：

• “这个系统已经没救了，必须全部重写”；
• “现在还能跑，千万不要动”。

两种判断都可能有道理，也都可能把项目带入困境。

我参与过大型中台的服务聚合、接口治理、异构平台迁移和领域模型建设。实践中，决定是否重构的关键并不是代码“看起来有多旧”，而是业务价值、风险边界、经济账和演进路径能否同时成立。

在启动重构前，我通常先看以下四项。

一、业务价值：系统问题是否真的阻碍了业务

技术团队常见的不满包括代码重复、框架老旧、分层不标准、测试不足。这些是技术债，但不一定足以支持一场大规模重构。

概要

中台建起来了，但更难的还在后面——如何治理一个已经运行多年、服务数量上百、接口调用关系错综复杂的中台系统？

服务只会越加越多、越改越乱。如果没有一套系统的治理方法，中台最终会从"赋能业务"变成"拖累业务"。

本文分享我在企业级中台治理中的实践经验：服务下线、接口清理、架构整改、跨团队协作——四个维度的实战心得。

背景

接手时系统的状态：

• 两套旧框架并存：云杉（Cloundscape）和 ASP，各自有几十个在役服务
• 接口数量庞大：Java 中台仅一个业务域就有数十个接口，其中不乏"无人认领"的历史遗留
• 调用关系不透明：前端直调外部服务、私有服务绕过 API 中心、订阅关系缺失
• 架构腐化：功能边界模糊，改一个模块要理解整个系统