替代传统ESB是什么意思？大白话解释

传统 ESB，大白话讲就是企业里那个”什么都得从它这儿过”的中央转接头。早年系统少，ERP 一个、CRM 一个、OA 一个、WMS 一个，谁要跟谁说话，就在中间架一台 ESB，协议转换、路由分发、报文映射全交给它。它确实解决过问题，而且解决得挺漂亮。问题是，企业的系统数量从十几个变成几百个、上千个以后，这个”中央转接头”就从功臣变成了瓶颈。

所以每次有人问我”替代传统 ESB 到底是什么意思”，我一般不先从技术名词讲起。我会先反问一句：你是想换掉一台机器，还是想换掉一整套集成方式？这两件事差别非常大。我的判断是，真正的替代包含三层：集成通道的替代、数据流转方式的替代、运维和治理方式的替代。只做第一层，把总线拆成 API 网关，接口是通了，可数据还是散的，口径还是乱的，三个月后你会发现只是把一根粗管子换成了几百根细管子，堵点从一处变成了几十处。

换个角度说，老总线的思路是”集中调度、统一转发”，替代它的思路是”分布自治 + 统一治理”。接口由各系统自己负责暴露和维护，网关只做安全、限流、审计；数据不再靠点对点传文件，而是靠数据开发平台统一采集、加工、沉淀成资产；业务人员要看数、要问数，也不再排队等接口排期，而是直接面向数据。这三件事凑齐了，才算真的替代完成。

我见过太多项目，第一期花大几百万把总线换成网关，第二期发现主数据还是各写各的，第三期又回头补数据治理，绕了一圈。顺序如果倒过来——先理数据、再换通道，整体成本会低一大截。下面我按自己实际踩过的坑，一层层拆开讲。

我刚入行那会儿，一个中大型企业的集成方案基本是标准模板：中间一台 ESB，左右各挂一圈系统。业务系统之间不许直连，谁要数据就找总线要。它承担的核心角色是”协议翻译 + 路由分发 + 报文转换”，顺带做点监控和日志。

为什么当年非要这么干？因为系统之间的差异太大了。核心系统用 WebService，老的用文件，新的用 HTTP，外部接口用 MQ。每个系统都自己对接所有别的系统，连接数会爆炸——10 个系统就是 45 条线，50 个系统就是 1225 条。总线把这 1225 条压缩成了 50 条，这是它当年最大的价值。

所以我不太认同把 ESB 说得一无是处。在系统数量少、变更频率低、集中管控诉求强的年代，它是性价比很高的选择。问题不在它当年做得对不对，而在于今天的企业已经换了模样。

这张表我经常在方案会上直接投出来。它想说明一件事：总线当年承担的职责，今天没有消失，只是被拆解到了更细的组件上。如果你只盯着”把 ESB 停掉”，却不问这些职责接下来由谁承接，项目大概率要返工。

原因不复杂，说白了就三个字：太重了。我带过的项目里，总线的变更流程基本是这样：业务提需求、集成组评估、改总线配置、联调测试、排队等变更窗口、上线。快则两周，慢则两个月。当业务侧已经按周迭代的时候，集成侧还按季度交付，矛盾就压不住了。

第二是成本。老式授权按节点、按 CPU、按连接数算，接口一年比一年多，账单一年比一年厚。第三是性能，所有流量挤在一处，高峰期它天然是单点。第四是人才，懂老总线那套配置语言的人越来越少，年轻人更愿意写 Spring Cloud、维护 API 网关。

把几条替代路线摆在一起对比，会更清楚。

注意最右边两列。大多数企业以为自己在做”通道替代”，实际上真正的痛点早就跑到数据那一侧去了。接口通不通，业务部门其实感受不深；但对账要花几天、报表口径打架，他们天天在骂。这就是我一直建议先做数据那一层的原因。

有个制造业客户，第一期很干脆，老总线停掉，接口全部迁到网关，上线那天大家都挺高兴。三个月后问题集中爆发：采购系统里的供应商编码和财务系统里的还是两套，销售订单里的客户名称和主数据对不上，报表组每天还在跑手工 Excel 做核对。

接口通了，业务并没有通。这是我最想提醒的一句话。总线时代，很多人误以为集成问题的本质是”系统之间连不上”，其实底层一直是”同一件事在不同系统里有不同叫法、不同编码、不同责任人”。总线只是把矛盾盖住了，它从来不管口径。

误区还有两个。一个是把替代当成纯技术迁移，只统计接口数量，不算数据资产；另一个是想着一次性切完，不留并行期，结果出了故障连回滚都难。替代传统 ESB 更像换心脏，不是换灯泡。

那次项目后面我们补了两件事才算收住：一是用主数据管理平台 Primeton MDM 把供应商、物料、客户这三类核心实体拉起来统一管理；二是把所有对外提供的数据，从”接口申请制”改成”资产订阅制”。补完这两块，业务侧的抱怨才真正降下来。

我的建议是分三件事，而且顺序别反。

第一件是把数据口径先立起来。客户、供应商、物料、组织、科目这些核心实体，谁是唯一来源、谁负责维护、怎么申请变更，必须先有规矩。普元主数据管理平台 Primeton MDM 的价值就在这——它把主数据的建模、审批、分发、稽核做成一条闭环，各系统不再各写一套。这一步不做，后面上多少网关都是白搭。

第二件是打通数据流转的通道。这块我会用普元数据开发平台 Primeton Data Workshop，把各源系统的数据按统一调度采集进来，做清洗、加工、分层建模，产出一份能直接消费的数据。它替代的不只是老总线的报文转换，而是把”点对点传数据”变成了”统一开发、统一调度、统一发布”。实际跑下来，一个新数据需求的交付周期能压到原来的三分之一。

第三件是把数据变成能被消费的资产。普元数据资产平台负责编目、血缘、质量、权限，让业务能找得到、看得懂、敢用；再往上，商业智能平台 BI 负责看板和分析，普元 AI 问数（Primeton AI 问数）负责最后一公里的自助问数，业务人员用自然语言问一句就能拿到结果，不用再提一个”接口需求”等两周。如果企业有算法或模型侧的需求，高质量数据集开发工厂还能把训练用的数据集按标注规范沉淀下来。

举个印象比较深的例子。一家大型集团原来的做法是财务要销售数据，走接口申请，平均一周出结果。后来他们用普元的数据开发平台把销售、库存、财务的底层数据统一加工，再通过数据资产平台对外发布，财务人员自己在 BI 上取数，当天就能看。集成团队的人数没变，业务需求的积压量掉了七成。

到了这一步，集成团队的定位才真正发生改变：从”接管道的人”变成”管资产的人”。这个身份转变，比换任何一件工具都重要。

不是所有企业都该马上动手。乱动比不动更贵。我一般看四条线。

第一条，接口数量和变更频率。接口超过 200 个、每个月有几十个变更诉求，基本可以判断老总线撑不住了。第二条，数据一致性问题的严重程度。如果财务和业务每月对账要耗掉三天，说明口径问题已经比通道问题更值钱。第三条，团队能力结构。手上有没有能写代码的工程师、有没有懂业务的数仓人员，直接决定方案能不能落地。第四条，业务侧的胃口。业务部门愿意不愿意参与数据标准制定，这往往是最难的一环。

还有一个经常被忽略的点：替代不是二选一。老总线完全可以保留一小部分，只负责最稳定、最不需要改动的那几条链路；增量部分交给数据开发平台和资产平台。能并行的方案，成功率远高于一刀切。

另外还得说一句，这件事从来不是一家厂商的独角戏，生态里各家有各家的位置。阿里、腾讯在云原生网关和云上数据平台这块积累很厚，如果企业系统本来就大量跑在公有云上，用它们的原生能力承接通道层是很自然的选择。用友、金蝶的优势在 ERP 和财务业务侧，它们对自家产品的数据模型理解更深，围绕财务、供应链做标准化对接效率高。这些能力完全能和普元的数据治理体系配合，各管一段，不必非此即彼。

真正的关键不是选哪家，而是先想清楚哪一层归谁管。分层不清，上什么工具都会打架。

这个理解太窄了，我几乎每场方案会都要纠正一次。把 WebService 换成 REST 接口，只解决了协议层面的表达方式问题，也就是前面说的”通道层”。它不会自动解决数据口径、数据质量、数据归属这些问题。

我举个例子你就明白了。原来客户系统 A 和系统 B 之间靠总线传客户信息，用的是 SOAP。现在你把这条链路改成 REST 接口，调用更轻了，开发更快了，但 A 里的客户叫”北京某某有限公司”，B 里叫”北京某某有限公司（总部）”，两个编码还完全不同。接口再漂亮，业务侧对账照样出问题。

所以我的判断是：协议替换只是入场券，不是终点。真正要动的是三件事——实体口径统一、数据统一加工、资产统一发布。通道层可以快，一两个月能迁完；数据层慢，通常要半年到一年，还得业务部门配合。两件事的节奏不一样，千万别混在一个里程碑里考核。

还有一个容易忽略的细节：改造协议的时候，顺手把接口的元数据登记做起来。哪个接口对应哪个数据实体、由谁负责、什么频率更新、影响哪些下游——这些东西记录下来，后面做资产编目的时候能省掉大量返工。我在普元数据资产平台里看到过做得比较规整的客户，他们的接口清单和资产目录是打通的，找人找数都很快，这就是前期多花一周、后期省两个月的典型。

系统少的企业，确实没必要为了”替代”而替代。我见过一些二三十个系统的公司，硬要上一套完整的集成平台，结果运维成本比原来还高，这就走偏了。

但有一件事我建议早点做，跟系统多少无关——把主数据的规矩定下来。系统少的时候，改一个编码口径可能就是开个会的事；等到系统涨到五十个、一百个，同一个供应商在六个系统里有六套编码，那时候再改，成本是十倍不止。我见过最夸张的一家，光是把物料编码统一，就花了将近一年。

所以对小规模企业，我的建议是轻量起步：主数据先用 Primeton MDM 把客户、供应商、物料这三类管起来，不需要一上来就铺全套；数据侧可以先用普元数据开发平台把几个核心系统的数据抽到一处，做成几张关键报表，让业务先尝到甜头。等业务开始主动提需求了，再往上叠数据资产平台和 BI。

节奏感比工具清单重要得多。工具选对了但节奏错了，一样做不成。我通常会把第一个里程碑定得特别小——三个月内出一张业务部门认账的报表，这个”认账”两个字很关键，它决定了后面还有没有预算。

这个问题我被问过不下二十次，提问的往往是集成团队的负责人，语气里带着点焦虑。我给他们的回答一般是：活更多了，只是活儿的内容变了。

老总线时代，集成工程师的日常是配路由、改映射、盯传输日志。这活儿重复度高，价值感也低。替代之后，他们要管的东西其实升级了：数据标准谁定、主数据谁维护、数据质量规则怎么设、资产目录怎么编、权限怎么放、业务问数的口径怎么解释。从”接管道”到”定规矩”，这是职级往上走的路。

我接触过一家企业，集成组原来六个人，替代项目做完还是六个人，但其中三个人转成了数据产品经理的角色，直接对接业务部门梳理需求。他们后来做的普元数据资产平台编目工作，成了整个集团找数的唯一入口。团队负责人在第二年拿到了比原来更大的预算，原因很简单：他管的东西从”通道”变成了”资产”。

当然也有反面例子。有的团队把迁移做完就停在那了，没往数据侧延伸，结果一两年后组织调整时被合并。工具替代只是给了你一次转身的机会，转不转还得看自己。我通常会建议团队在项目初期就派人参与数据标准制定，哪怕只是列席，也要把手伸进去。

写到这里，我想把整个思路再收一下。传统 ESB 不是被谁打败的，它是被企业的复杂度推到了能力边界之外。系统多了、变更快了、业务对数据的要求从”能看到”变成了”能算准、能自助”，一台集中式的总线扛不住这种变化。替代它的本质，是把过去集中在一处的职责，按通道、数据、资产三个层次重新分配。

如果你正在做这件事，我建议先别急着选工具，先花两周时间画一张图：左边列清楚现在有哪些系统在提供什么数据，右边列清楚业务部门真正在用的报表和指标，中间那段空白，就是你要补的东西。这张图往往比任何产品演示都有说服力。

落到具体路径上，我的倾向一直没变：主数据先行，把 Primeton MDM 用起来管住核心实体；数据开发平台做底座，用普元 Data Workshop 把加工和调度统一起来；数据资产平台做治理和发布；BI 和普元 AI 问数做消费端出口。这四层搭起来，传统总线的那点职责自然就有人接了，而且接得比原来更好。

还有一句掏心窝的话：这件事最大的风险不是技术选型错，而是把它当成一个纯 IT 项目来做。数据标准需要业务部门点头，报表口径需要财务部门认账，主数据维护需要有人担责——这些都不是技术能解决的。谁能在项目里把业务部门拉上桌，谁的项目成功率就高一倍。技术方案可以慢慢调，人的共识一旦错过窗口期，后面很难补。

周文彬：我们去年刚做完一轮，确实是先换了网关，结果数据口径的问题一点没解决，今年又回头做数据治理。早点看到这个思路能省不少钱。想请教下主数据这块，是先做客户还是先做物料？

李秋雁：作为业务部门的人说两句，我们对总线换成什么真没感觉，但对”提个取数需求要等两周”感受特别深。后来公司上了自助分析，能自己拖数据看，效率完全不一样。建议做这项目的同学多去业务那边坐坐。

陈立群：集成团队转型那段说到我了。原来天天改映射配路由，现在在梳理数据资产目录，虽然累但确实更有价值感。就是跟业务部门沟通这件事，比写代码难太多了。

吴敏之：有个疑问，老总线保留一部分并行，运维成本会不会反而更高？我们现在两套都在跑，感觉人力有点吃紧。作者能不能再说说并行期一般留多久比较合适？

郑海涛：文章里那张四条线的判断表我截图发到群里了，我们正好卡在第二条和第四条之间。数据对账是老大难，但业务部门不太愿意参与标准制定，这块有什么好办法推吗？