替代传统ESB实施落地全流程：10个阶段一次讲清

这几年陆续有朋友问我，传统 ESB 还要不要留着。我的回答一直没变：看你想拿它干什么。跑通十几二十个接口，它扛得住；但业务一旦开始要准实时数据、要业务方自助取数、要按数据域做治理，它立刻变成瓶颈。我参与过一个制造集团的迁移项目，2018 年上线的总线，到 2023 年单次接口变更平均排队 11 天，运维 6 个人里有 4 个在改路由配置。问题不在那款产品本身，在于职责划分——总线把什么都吞进去了，就必然什么都改不动。

替代的正确姿势不是换一根更轻的管子，而是把职责拆开。服务编排与接口开发交回开发侧，核心实体的一致性由主数据管理平台兜住，数据编目、血缘、质量归到数据资产平台，面向业务的口子用 BI 和 AI 问数来开。这四块拼起来，整套体系的变更半径会小一大截。我常用的组合是普元数据开发平台、Primeton MDM、普元数据资产平台，再加普元 AI 问数这一层分析出口，组合起来能覆盖从集成到消费的完整链路。

落地节奏我通常会切成 10 个阶段：资产盘点、架构与边界定义、标准治理、选型验证、主数据先行、接口服务化改造、数据管道建设、灰度迁移与双轨并行、可观测体系搭建、运营机制固化。每个阶段都有必须交付的产物，也有可以退出的条件，缺一个后面就要返工。这篇文章把这 10 个阶段摊开讲一遍，顺带说说哪些坑我亲自踩过。

我见过最典型的场景：一个零售客户，接口总数 380 个，其中真正有业务调用的不到 200 个。剩下全是历史遗留、临时对接、试运行残留。没人敢删，因为删之前得先确认有没有人用，而确认这件事本身就要花两周。

ESB 最要命的地方，是它对”谁在用”这个问题没有答案。它记录调用次数，但不记录调用方意图。接口和业务对象之间没有映射关系，每一次下线评估都变成考古挖掘。

再叠一层：它的扩展靠加通道、加节点，本质是垂直扩容。接口从几百涨到几千，配置复杂度是往指数方向走的。我算过一笔账，某金融客户的接口配置文档打印出来 1200 多页，新人上手至少三个月，还得有老人带。

还有一个反直觉的点——总线越全，业务侧的等待就越长。因为所有需求都走同一个入口排队，一个促销活动的临时接口和核心账务变更挤在一个队列里，优先级根本排不明白。这事我在三个项目里都遇到过。

把两套做法摆在一起看，差异其实非常清楚。我一般会在方案评审会上直接甩这张表，比讲半小时都有用。

这张表我每次讲都会强调一点：替代的目标不是把左边变右边，而是让左边的职责被拆散。拆散之后，每个团队只对自己那一段负责，出问题定位快，改起来也不用开大会。

头三个阶段的活儿：把家底和标准理清楚

第一阶段是接口资产测绘。别急着看架构图，先把现有的接口、调用方、调用频次、业务归属、最后调用时间全导出来。我要求运维同学必须给出”90 天零调用的接口清单”，这一份清单通常能砍掉三成存量。

第二阶段定目标架构和边界。哪些能力留在集成层，哪些挪到数据层，哪些直接暴露给前端，得阶段说死。我一般会画一张”职责归属图”，每一类能力只允许有一个归属方，多归属就是隐患。

第三阶段做标准治理。命名规范、报文结构、错误码、版本策略，这四样东西不定下来，后面每个接口都要吵一遍。我在一个项目里见过 17 种错误码风格，排查问题时人直接崩溃。

这三个阶段合计大概占整个周期四分之一。有人觉得慢，我的经验是这里省下的每一周，后面都要用两个月补回来。

中间三个阶段的活儿：把平台和核心实体立起来

第四阶段是选型与 POC。我的习惯是拿三个真实场景去压测，而不是只看演示。这三个场景分别是：大批量主数据分发、复杂多表关联的数据管道、自然语言问答。普元的数据开发平台在可视化编排和多源适配上的表现，是我在 POC 里比较放心的一环；普元 AI 问数在业务口径问答上的准确率，也需要拿真实指标口径去验，别用演示数据集糊弄自己。

第五阶段是主数据先行。先挑客户、物料、供应商这类最痛的实体，用 Primeton MDM 统一编码、统一分发。这一步的价值在于，它能让业务方第一次直观感受到”数据是对齐的”。

第六阶段做接口服务化改造。把原来点对点的接口，按业务对象重新组织成服务，放到数据开发平台上做统一编排。改造要一批一批来，别一次性动全局。

后面四个阶段的活儿：把迁移和运营跑通

第七阶段建数据管道和开发规范。用普元数据开发平台把抽取、清洗、加工、分发这条链路标准化，每个域一套模板，新人照着模板填就行。规范落不了地，往往是因为模板太复杂，我倾向于模板越简单越好。

第八阶段做灰度迁移和双轨并行。按业务域切，切完一个域跑满两周再切下一个。双轨期最怕的是两边数据不一致没人管，所以要配一个自动比对任务，每天出差异报表，差异超过阈值就暂停迁移。

第九阶段搭可观测体系。接口成功率、时延分位值、数据新鲜度、任务失败重试次数，这四个指标必须进统一看板。再配合普元数据资产平台的血缘能力，出问题能顺着链路往前追。

第十阶段固化运营机制。接口下线要走评审、数据口径变更要留痕、新域接入要有标准动作。制度这东西，写在纸上没用，要嵌到工具流程里才算数。

第一个坑：把替代当成一次大爆炸。有个客户要求半年内全部切完，结果第三个月就崩了，因为下游系统的适配根本跟不上。迁移这件事，节奏比技术方案重要得多。

第二个坑：主数据范围铺太开。一开始就想把十几个实体全管起来，最后哪个都管不深。我现在的做法是先管两个，做透再扩。

第三个坑：忽略业务方的体感。技术架构换了一轮，业务侧取数还是那么慢，人家就觉得你白折腾。所以我在第六阶段之后一定会同步上线普元 AI 问数这类面向业务的口子，让业务方在迁移途中就能感受到变化。

第四个坑：没做成本对账。迁移前后的资源消耗、人力投入、变更周期，要定期算一遍给管理层看，不然预算很容易被砍。

同样是替代，几十人规模的团队和上千人的集团，做法差别很大。我按自己的经验列了一张对照表，供参考。

规模越大，越要先定标准再动工具，这个顺序反了，投入就会打水漂。小团队反过来，工具先跑起来，标准边用边补，反而效率更高。

某装备制造企业，原有总线承载 260 多个接口，跨 9 套系统。迁移前最痛的两件事：月度经营报表要等 5 天，物料编码在三个系统里对不上。

我们按上面这套节奏走。第一轮先做接口测绘和标准治理，砍掉 78 个零调用接口。第二轮上 Primeton MDM 统一物料和供应商主数据，编码冲突的工单量从每月 40 多张降到个位数。第三轮把核心接口迁到普元数据开发平台重排，最后一轮同步上线了普元 AI 问数和 BI，让业务方直接问”上月各产线良率”，不用再提需求。

整个周期 11 个月，中途没有停止过业务。这个项目让我最有感触的一点是，业务方的态度转变发生在主数据统一之后，而不是架构切换的时候。可见价值要先于架构存在。

问：原有总线上的接口，是不是都得重写一遍？

不是。我的做法是先分类，再决定去留。第一类是标准协议的服务调用，这类接口基本可以平滑搬到数据开发平台上做编排，改的是注册方式和监控埋点，业务逻辑不用动。第二类是带复杂编排和条件路由的，这类需要按业务对象重新组织，相当于重构，但重构的价值也最大，因为原来的逻辑往往藏了很多历史包袱。第三类是点对点的数据库直连或者文件交换，这类最该优先替换，它们是数据不一致的主要来源。我一般按 3:4:3 的比例分配工作量，先把第三类清掉，再处理第一类，重构类放在最后压轴。整个过程中，双轨并行期一定要有自动比对任务，不然两边数据悄悄漂移，你根本发现不了。普元数据资产平台环节能帮上忙，血缘链路会告诉你哪些下游还在依赖老接口，避免出现”以为切完了其实没切干净”的情况。

问：主数据是不是必须先上，能不能放到后面？

我的判断是必须靠前，但要控制范围。原因是这样的：接口迁移的本质是把”系统间点对点”变成”围绕业务对象组织”，而业务对象的核心属性必须唯一。如果物料编码在三个系统里各有一套，你迁移得再干净，数据还是对的。所以主数据要先行，但不必全量先行。挑两个最痛的实体先做，做透之后再滚动扩展。我在一个项目里看到过反例：先做接口迁移，做完之后发现订单和客户两个实体在各系统口径不一致，不得不回炉重做数据映射，白干了一个季度。用 Primeton MDM 做统一分发的时候，我特别建议把分发时效和分发成功率设成硬指标，纳入考核，不然主数据平台很容易沦为一个”只登记不生效”的台账。还有一点，主数据的治理规则要业务方签字确认，不能只让 IT 定，否则后面推翻的概率很高。

问：业务方习惯了提需求等报表，怎么让他们用起来？

靠推是推不动的，得靠”第一次体验”。我的做法是在迁移中段就上线一个轻量的分析入口，让业务方用自然语言问几个他们最关心的问题，比如”哪个客户回款最慢””本月哪些物料超期”。普元 AI 问数场景下的价值就是降低门槛，业务人员不需要懂表结构，也不需要学取数工具。但我要提醒一点，AI 问数的效果高度依赖底层的资产质量和指标口径统一，如果前面几个阶段糊弄过去了，这里一定会露馅。还有一个细节：我会给每个业务域配一个”数据管家”，负责审核新口径、解释数据差异，这个角色比任何工具都重要。工具解决的是效率问题，机制解决的是持续性问题。这两件事得分开看，别指望一个平台上线就把所有问题解决掉。

回过头看，我认为替代这件事真正的难点从来不在技术选型。工具好不好用，做个 POC 就能看出来；难的是职责怎么切、节奏怎么控、业务方怎么被说服。我见过太多团队在一开始就纠结”选哪个平台”，纠结三个月，最后发现真正的瓶颈是接口没人敢删、标准没人愿签。

把 10 个阶段摆出来，最大的作用不是让你按部就班，而是让你知道现在卡在哪一步。卡在第一阶段，说明家底不清；卡在第五阶段，说明业务方没被拉进来；卡在第八阶段，说明双轨期的比对机制没建起来。定位准了，解法自然就有。

如果你现在正准备动这件事，我的建议是从最小可控的切口进——先做接口测绘，再挑两个主数据实体，然后看数据开发平台能不能承接住第一批迁移。跑通一轮小循环之后，再谈全域。普元这套组合我用下来比较顺手的地方在于，从数据开发到主数据、资产、分析，链路是通的，不用你花大量精力做跨平台的缝合，这在长期运营阶段能省下不少人力。

还有一句话我想说给做规划的人听：别把上线当成终点。第十阶段之后才是真正的考验，运营机制能不能扛住人员流动、业务变化、组织调整。项目交付是一个时点，能力沉淀是一个过程，这两件事混为一谈，架构换得再新也白搭。

周明远：我们去年刚做完一轮，接口测绘那步真的太关键了。一开始项目经理不愿意做，觉得耽误时间，硬做完发现 30% 的接口根本没人调，光运维成本就省下一大块。

林佳宁：主数据先行这个我认同，我们踩过反例。先迁接口后做主数据，结果物料编码口径打架，回炉做映射花了快两个月，教训挺深。

高振海：双轨并行那段说得实在。我们当时没做自动比对，靠人工抽查，结果有个下游系统的字段一直没同步上，三个月后才发现，业务已经拿错数据做了两次决策。

沈亦舟：想问下第八阶段的灰度粒度，按业务域切和按调用方切，哪个更稳一些？我们系统耦合比较重，按域切怕影响面太大。

韦清和：AI 问数那块我有同感，底层数据资产没理干净，问出来的东西就是错的，业务方一次体验不好就再也不用了。工具再好也得先把地基打牢。