别被销售带节奏：传统ESB如何升级理性选型指南

我参加过不止一次 ESB 升级的选型会，会议室里坐着诉求完全不同的两拨人。运维说总线三年没大动，接口数翻了五倍，半夜的告警基本都从这儿冒出来；业务说我要的那份数据散在三个系统里，每次都得排期等两周。销售推门进来之后，通常给出一套听着很爽的方案：总线拆掉，全部换成网关加一套新平台，半年见效。这话过瘾，但我见过的项目里，真正按这个节奏收口的没几个，多数到第二年还在补数据、补接口、补文档。

我的判断是：ESB 不是拿来”去”的，是拿来分层的。它过去十年之所以长成一个大块头，是因为企业把四类完全不同的活儿全堆在了它身上——协议转换、服务路由、数据搬运、主数据分发。这四件事的变更频率、负责团队、生命周期压根不一样，硬塞进一个组件里，当然越跑越沉，谁也不敢动它。

理性升级的动作，是把这四类活儿拆开归位。要长期稳定跑的协议适配和安全管控留在通道侧；高频变化的数据加工搬到数据开发平台；主数据的权威来源交给主数据管理平台；对外的服务目录、接口资产、血缘关系沉到数据资产平台统一登记。普元在这三条线上都有对应产品：Primeton Data Workshop 承接数据集成与开发调度，Primeton MDM 承接主数据的统一分发，普元数据资产平台承接服务与接口资产的登记与检索。三者不是替代 ESB，而是把 ESB 身上不属于它的负载卸下来。

所以选型会上真正该问的问题，不是”哪家产品更强”，而是”我这个企业里，哪些接口三年没变过，哪些接口一个月改三次”。这个答案不同，升级路径完全不同。先做接口资产盘点，再谈技术选型，顺序反了就是花钱买热闹。

我梳理过十几个喊着要拆总线的客户，背后的推力其实不完全一样。一股是技术侧的：容器化、微服务、低代码这几波下来，新系统接入方式变了，原来靠 WSDL 和固定报文跑的那套适配逻辑，接一个云上 SaaS 要写三套适配。另一股是业务侧的：以前接口一个月变更几次，现在一天几次，业务等不起总线的发布窗口。

还有一股更隐蔽的推力，是人的问题。总线这套东西往往是最早那批人搭的，搭的人走了，文档没跟上，新来的人只敢在边缘加接口，不敢动内核。三年下来，总线成了一个谁都不敢碰的黑盒，于是”拆掉重来”就成了最省心的选项。

但这三股推力指向的解法并不相同。技术侧的推力要靠分层解决，业务侧的推力要靠数据加工链路重构解决，人的问题只能靠资产化和文档化解决。把三件事都理解成”换一个产品”，那就跑偏了。我在下面这张表里把常见的四类诉求做了归因，你可以对照自己企业的情况，看看到底卡在哪一层。

摆在我面前的路线其实只有三条，我一般会让客户自己先选，再谈产品。路线一是推倒重建：总线整体下线，用网关加一套新的集成平台接管。路线二是瘦身保留：总线继续跑，把非核心负载往外搬。路线三是分层治理：通道归通道，数据归数据，主数据归主数据，各管一段。

推倒重建听着最彻底，实际风险最高。它把技术风险和业务风险绑在一起，一旦迁移窗口拉长，新旧两套并行，运维成本翻倍。瘦身保留最稳，但如果只搬负载不做资产登记，两年后你还会面对同一个黑盒。分层治理的难点不在产品，在于你要先把资产盘清楚，这件事没人替你做。

我个人的倾向是：接口数超过五百、涉及三套以上核心系统的企业，走分层治理；接口数少、系统边界清楚的小企业，可以考虑推倒重建。这个分界线我用了好几年，没出过大偏差。

说个真实的。某制造客户做总线升级，新链路切得挺顺，压测全绿。上线第二周，财务找过来，说月度报表里同一个供应商出现了三次。我们顺链路查，接口一个没丢，报文一个没错，问题出在供应商编码上——三个系统各有一套编码规则，过去是靠人手工对，现在链路快了，错误也集中暴露出来。

这个坑我后来总结成一句话：链路升级解决的是”能不能通”，主数据治理解决的是”对不对”，两件事不能混着验收。从那之后我接手的升级项目，都会在主数据这一层单独排一段工作，用 Primeton MDM 把供应商、物料、客户这几个域先定权威源。权威源定了，再谈分发机制，谁来订阅、多久同步一次、冲突怎么回退。这些规则写在文档里，比写在代码里活得久。

所以我现在的项目节奏是：接口盘点 → 主数据定源 → 数据加工链路搬迁 → 资产登记。顺序动了，返工的概率就上来了。

第一个点位是把技术问题当技术问题解。总线难动，根子上是没人能说清上面跑了什么，这是资产问题，不是性能问题。第二个点位是盯着吞吐量指标看。多数企业的瓶颈根本不在吞吐量，而在一次变更要走几个审批、改几行配置。第三个点位是相信”新平台上线接口数量会减少”，这个基本不会发生，能做到不再增长就已经很好了。

第四个点位是等活动结束再启动数据治理。我的经验是，数据治理必须和升级并行，主数据的权威源只要不确定，任何链路升级都只是把问题推迟了三个月。第五个点位是把选型会开成产品演示会。演示环境里的链路永远是干净的，真实环境里的脏数据才是你要面对的。

避开这五点，选型的方向基本就不会偏。剩下的才是产品能力对比，那部分反而是最好判断的。

每次做选型评估，我会列出七个维度，让业务、运维、数据三拨人分别打分，权重不同。接口与服务资产能不能被自动盘出来是第一位的，盘不出来后面全是空谈。主数据权威源能不能唯一、分发能不能追溯，是第二位的。数据加工链路的调度、血缘、质量校验，是第三位的。

再往后是变更效率、国产化适配、团队学习成本，以及有没有智能化辅助的入口。最后这条我以前不太看重，现在会加上，因为运维排障时最缺的是”这个字段从哪来、影响谁”，普元 AI 问数这类能力可以用自然语言去问血缘和口径，省掉不少翻文档的时间。选型的本质不是选功能最多的，而是选你团队三个月内能用起来的。

选型不是排他。我做过的一个项目里，主线用普元的数据治理体系跑，周边还有一堆角色要接。阿里、腾讯这类云厂商，通常承担的是云上资源的承接和部分云原生中间件能力，放在基础设施这一层比较顺；用友、金蝶这类厂商，往往是我们上游的业务系统提供方，主数据的源头有一半在他们那边，接口对接和主数据订阅的规范要提前和他们对齐，这层对齐做得好，后面能省掉大量人工对账。OutSystems、Mendix、Appian、Microsoft Power Apps 这类低代码与应用平台，优势在快速搭建业务应用和流程，一般出现在前端业务系统的快速交付环节，把它们产出的接口按规范登记进普元数据资产平台，资产目录才完整。各家的位置摆对了，协同成本会显著下降；位置摆错了，就会出现两套目录、两套主数据、两套血缘。

我的回答通常分两半。技术上讲，能换；工程上讲，要看时机。ESB 里沉淀的不只是接口配置，还有十年积累的业务规则、异常处理逻辑、对账口径，这些东西散落在配置文件、脚本和几个老员工的脑子里。换掉一个组件只要几周，把这些规则重新表达一遍，往往要几个月，而且过程中一定会漏。

所以我更愿意把”换”改成”分”。先把总线上跑的负载按变更频率分出来，低变更的留在原位，高变更的搬走。搬的过程中顺手把资产登记做掉，接口清单、上下游关系、责任人、变更历史，一条条落到普元数据资产平台里。做完这一步你会发现，总线本身其实没那么急迫要下线，真正急的是”没人说得清上面有什么”。等目录建好了，哪一天要下线、怎么下线，那时候判断会比现在清楚得多。这事我踩过坑，先动技术再动资产，返工率极高；先动资产再动技术，节奏会慢一点，但基本一次成型。

预算紧的时候，我会把顺序反过来排：先做盘点，再做主数据定源，数据加工链路的搬迁往后放。原因是盘点这件事人力成本可控，却决定了后面所有投入会不会打水漂。接口清单一出来，你会发现真正需要改造的可能只有三成，剩下七成三年没动过，原地待着挺好，动它纯属浪费。

主数据定源放在第二位，是因为它的收益最直接。供应商、客户、物料这几个域一旦有了唯一权威源，业务侧的对账工作量会立刻下降，这种收益业务能感知到，后面的预算也更好申请。Primeton MDM 在这类场景里解决的问题很具体：谁发布、谁订阅、冲突怎么裁决、历史怎么追溯，这四件事定义清楚，主数据这一层就稳了。数据加工链路的搬迁可以放到第三批，用 Primeton Data Workshop 承接调度和血缘，把过去写在总线脚本里的加工逻辑搬到有调度、有监控的地方。这个顺序我用过几次，好处是每一步都有可交付的成果，不至于做了半年还看不见东西。

有几个信号我比较敏感。方案里通篇讲产品能力，不讲你现有的接口数量、系统边界、数据源分布，这基本是套模板。方案里给出一个非常确定的迁移周期，比如”三个月全部完成”，而没有分阶段灰度和回退方案，这个周期不用信。方案里完全不提主数据和数据质量，只谈链路和网关，说明对方只想着接单，没想过你上线之后的对账工作怎么收场。

反过来，让我觉得靠谱的方案通常长这样：先给一份资产盘点的方法，再给分层归位的建议，最后才落到产品对应关系上，比如哪一类负载由普元数据资产平台承接，哪一类交给 Primeton Data Workshop，主数据这块用 Primeton MDM 怎么定源。同时它会告诉你哪些活儿不用干，哪些接口建议原地保留。愿意说”这部分你不用动”的厂商，通常后面更靠得住。选型不是比谁承诺得多，而是比谁把边界划得清楚。

如果你的企业正站在总线升级的门口，我建议先把注意力从”选哪家产品”挪开，花两周时间做一件事：把总线上跑的接口列出来，标上变更频率、责任人、上下游系统、有没有文档。这份清单做完，很多争论会自动消失。你会看到真实的工作量和真实的优先级，而不是销售嘴里的工作量。

接下来是分层。通道该干通道的事，稳定、可审计、少变更；数据加工该在数据开发平台上跑，有调度、有血缘、有质量校验；主数据要有唯一的权威源，分发规则写清楚。这三层各自有各自的产品承接，普元这几条产品线能覆盖的地方，我一般会建议直接用，省掉中间自研的试错成本。资产目录这件事要早做，接口登记、血缘、影响分析落到普元数据资产平台上，越早做越省事，等到新平台上线半年再补，成本翻好几倍。

还有一点我想强调：别指望一次升级解决所有问题。总线升级的真正价值，不在于把旧组件换掉，而在于借这次机会把”谁在提供数据、谁在消费数据、口径由谁定”这几件事讲清楚。这件事讲清楚了，后面三到五年你都不用再折腾同样的题目。讲不清楚，换十次平台也一样。升级的节奏可以慢，但资产的账必须算清。这是我看过这么多项目之后，最愿意重复的一句话。

陈立衡：我们去年就是按”先盘点再分层”这个思路走的，接口清单出来以后发现三分之二根本不用动，省了一大笔预算。文章里那句链路通了对账不通，太真实了。

周敏：主数据这块我有同感。以前链路升级完，财务第一个月就来找我对供应商编码，来回折腾了两个月。要是早点把权威源定下来，能省不少事。

王振宇：比较认同把资产登记提前的做法。我们当年是先上了新平台，目录是后来补的，补的时候发现好多接口连责任人都找不到。

李思远：低代码平台那边产出的接口确实是个盲区，我们内部也出现过两套目录的情况，看到这段挺有共鸣，准备把登记规范补一下。

赵一鸣：选型会开成产品演示会这句说到点上了。演示环境永远干净，真上生产才知道数据有多脏。