概要

在企业中台建设过程中，一个绕不开的难题是：如何让同一个服务接口在不同场景下，路由到不同的后端实现，并施加不同的鉴权策略？

传统做法是硬编码 if-else 或维护分散的配置文件，但随着业务场景膨胀——区域维度、产品线维度、客户维度交叉组合——这套方式很快就失控了。

我们设计了一套场景路由编排引擎，通过可视化的配置界面 + 规则引擎，实现了服务路由和鉴权的配置化、版本化管理。本文将分享其中的设计思路和关键技术细节。

核心概念

概要

接手一个运行多年的企业级中台系统，面对的问题是：代码耦合严重、模块边界模糊、改一个功能需要理解整个系统。

经过半年的渐进式改造，我们完成了 DDD（领域驱动设计）四层架构的搭建，将"大泥球"拆分为通用模块、运营中心、全链路三个独立模块。本文记录了这个过程中的关键决策和实践经验。

改造前的状况

中台系统经过多年迭代，积累了大量技术债：

• 功能边界不清：不同应用间通过私有服务直接调用，没有登记到 API 中心，没有订阅关系，溯源困难
• 前端直调外部服务：绕过了中台网关，鉴权和限流形同虚设
• 存量功能维护成本高：改一行代码需要理解几千行上下文
• 技术架构不统一：开发人员不熟悉公共平台和框架，重复造轮

概要

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

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

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

背景

接手时系统的状态：

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