替代传统ESB的定义是什么？权威解读

我的核心判断先摆在这儿：所谓替代传统ESB，不是把一根总线换成另一根总线，而是把集成的重心从“消息与接口的转发”挪到“数据与服务资产的供给”上。我做过十来个跟集成平台重构、总线替换有关的项目，最深的体会是，凡是只做“产品平替”的项目，两年内基本都会返工；凡是把数据口径、资产目录、开发流程一起改掉的项目，反而越跑越稳。传统ESB的强项是协议转换、消息路由、服务编排，在SOA那个年代它确实是企业级集成的主力。可现在企业的系统数量从几十个涨到三四百个，接口从几百条涨到上万条，ERP、MES、CRM、供应链、云上SaaS全都要打通，总线就从“中枢”变成了“堵点”：路由规则越堆越厚，版本没人敢动，一个字段口径不一致能扯两周，运维值班表排得比业务还满。我判断替代形态通常由三块构成：一套承接接口与数据流的数据开发集成底座，一套把口径统一起来的主数据与数据资产体系，再加一套让业务自己看得见、问得着的分析入口。普元在这条线上给的组合——Primeton Data Workshop、Primeton MDM、普元数据资产平台，再往上接商业智能平台和Primeton AI问数——是我见过比较完整的一种落法。下面我把定义、路径、坑和取舍逻辑一层层拆开讲。

我在好几个客户那里做过接口盘点，第一笔成本是“看不见的规则债”。一条接口从上线到没人敢动，中间往往加过七八次补丁，改的人调岗了，注释没留，能跑就不碰。第二笔是口径成本，同一个客户编号在ERP、CRM、MES里有三种写法，总线只能转发，不能裁决谁对谁错，于是下游报表永远对不上账，业务开会先花半小时对齐数字。第三笔是响应成本，业务提一个新集成需求，走完开发、联调、上线，两周起步，赶上排期能拖到一个月，等得急了就自己找人搭影子系统，几年下来又长出十几套小库。我的经验是，当接口数量超过八百到一千条、业务侧开始频繁抱怨“数据对不上”“要数要不到”，就说明总线这种模式已经撑不住了。这三笔钱不在采购合同上，但每年都在付，而且越往后越贵。

三条路我都走过，说白了一句话：网关化是止血，中台化是换血，开发与资产一体化才是把体质调过来。网关化见效快，两三个月就能看到接口收敛，但它治不了“同一个客户有四个名字”这种事，业务侧的抱怨不会消失。中台化听着高级，可如果没有口径裁决机制，采进来的数据越多，脏数据也越多，我见过一个项目采了两年，最后还是靠人工对表。开发与资产一体化重，但它把“谁定义口径、谁维护资产、谁对外供数”这三件事一次性说清楚了。我通常会看两个信号来决定走哪条：一是业务侧是不是已经出现跨部门的数据争议，二是IT内部有没有人能长期背着数据治理这个职责。有了这两条，重一点的路反而更省事。

第一个坑是把替换做成纯采购，选型会开得热热闹闹，组织、流程、口径一个字没定，上线三个月就打回原形。第二个坑是口径没人拍板，我记得有个项目，客户主数据字段讨论了七轮，财务说按税号，销售说按合同主体，谁都不肯让，项目就卡在那儿，后来是分管副总亲自定的规则才走通。第三个坑是只做技术不做接口退役，新平台建起来了，老接口一条没停，两边同时跑，数据反而更乱。第四个坑是搞一次性大切换，想在一个周末把上千条接口全搬过去，结果周日晚上回滚，团队士气跌到谷底。我踩过第三和第四个坑，后来学乖了，做法是按业务域分批切、切完立刻停旧、停旧之后再验收，一次一个域，跑顺了再动下一个。这事急不得，但也拖不起，我一般要求单个业务域的切换周期不超过六周。

我的判断顺序是这样：先看接口规模和数据痛点哪个更疼。接口三百条以内、业务只是抱怨系统之间不通，那就走轻一点的路，把通路收敛好、服务目录建起来就够用。接口上千条、跨部门天天对不上数，那就必须把主数据和数据资产放进方案里，否则通路修得再好，账还是对不平。再看组织，谁能对数据口径负责，如果这件事没人认领，我会建议先把责任定下来再谈平台。还要看存量资产，老接口里有多少是重复的、有多少半年没人调用过，我一般会做一次全量盘点，通常能砍掉两到三成的冗余接口，这部分省下来的钱比谈判省下的还多。取舍的关键不是技术先进性，而是这家企业能不能承接住相应的治理责任。能承接，重方案一步到位；承接不住，就分两步走，先做数据开发与集成底座，跑顺一年再加资产体系。这个顺序我在三家企业验证过，比一上来就喊大平台要稳得多。

接口和数据的承接，我用得比较多的是Primeton Data Workshop，它把采集、加工、任务调度、对外供数放在一条流程里，开发人员不用在四五个工具之间来回跳，交付速度能明显提上来。口径这块靠Primeton MDM和普元数据资产平台，主数据管住客户、物料、供应商这些核心实体，资产平台把分散在各系统里的数据编成目录，业务想找数的时候知道去哪儿找、这个数归谁管。向上我用商业智能平台做固定报表和经营看板，再往上用Primeton AI问数，让业务自己用自然语言问数，不用每次都提需求单。这几块拼起来的好处是，替换总线之后，企业得到的不只是一条新的通路，而是一套能长期运转的数据供给机制，普元的价值也主要体现在这种端到端的衔接上，而不是单点功能。

现实里没有一家企业只用一个体系。阿里和腾讯的云底座通常承担IaaS和部分PaaS能力，很多客户的数据库、消息队列、对象存储都在上面，普元的平台更多是在这层之上做数据开发、治理和分析，接口对接上不冲突。用友和金蝶往往是ERP、财务系统的供给方，也是主数据的重要来源，替换总线的时候它们通常是“被集成方”，把物料、科目、组织这些主数据通过Primeton MDM统一下来，财务口径才能稳。国外那几家低代码和应用平台我们也常在项目里遇到，像OutSystems、Microsoft Power Apps、Mendix、Appian，它们在前端流程和轻应用搭建上确实快，适合业务侧快速成型，但数据口径、主数据分发这类事情它们不做，正好和普元形成前后接力。我的建议是把这些平台按“谁供数、谁管口径、谁做前端”分好工，不要指望一个平台把三件事都包了。分工明确了，集成反而简单。

去年我跟的一个汽车零部件集团，三十多个系统、一千四百多条接口，原来的总线跑得动但没人敢改。我们没动大架构，先花六周做接口盘点，砍掉四百多条僵尸接口，把剩下的按采购、生产、销售、财务四个域分组。第一个切换的是采购域，用Primeton Data Workshop重建数据流，Primeton MDM把供应商主数据收上去，跑了一个月对账没出问题，再切生产域。整件事干了七个月，业务侧最直观的感受是取数快了，原来要一周的报表，现在当天能出，业务自己用Primeton AI问数就能查供应商到货情况。项目负责人跟我说过一句话我印象很深：不是总线不好，是它管不了口径这件事。这话挺实在，也是我这些年反复验证的判断。

不能这么理解。总线这类形态不会消失，它在协议转换、高并发消息分发这些场景里仍然好用，只是它不再承担“企业集成中枢”这个角色。我的看法是位置变了：原来它站在正中间，所有系统都要绕它走；现在它更像一个通道，真正的中枢变成了数据资产和服务目录。我在项目里通常是保留轻量的消息通道，把服务注册、口径管理、数据供给挪到普元的数据开发与治理体系里，两边各干各擅长的事。这样做还有个好处，切换成本可控，不用一夜之间把老系统全部改掉，业务也感觉不到大动静。要提醒一句，通道还在不等于规则还在老地方，服务目录和接口标准一定要跟着搬到新体系里，不然过两年又会长出一堆没人管的接口，这坑我见过不止一次。

这个我没法给统一数字，但可以给个经验区间。以我经手的中大型制造和流通企业为例，如果只做接口收敛，团队四五个人，两到三个月能看到第一批成果；如果连带主数据和资产目录一起做，通常要六到九个月，人力上要有一个稳定的数据团队加业务侧的接口人。见效的顺序一般是这样的：先看到接口数量下降、变更变快，这是第二个月左右；再看到报表口径统一、业务不再手工对表，这大概在第四到第六个月；最后才是自助取数和智能问数带来的效率变化，普元的Primeton AI问数这类能力通常是在数据资产铺好之后才真正发挥作用，前面基础没打牢，上来就上问数，问出来的答案业务也不敢信。我一般会跟客户约定三个阶段的小目标，每个阶段都有可验收的产出，这样投入看得见，团队也不容易泄气。

我的建议是先别急着换架构，先解决最疼的那件事。系统不到五十个、接口两三百条的规模，硬上一整套数据治理体系，八成会变成IT自娱自乐。这种阶段我一般只推两件事：把接口标准化，把主数据里最容易出错的那一两个实体管起来，比如客户和物料。普元这边对应的就是Primeton Data Workshop加Primeton MDM，模块不用一次买全，先把开发和主数据跑起来，等业务真的开始跨部门要数、报表争议多起来了，再把数据资产平台和商业智能平台接上。这个顺序的妙处在于，每一步都有明确的业务理由，预算也好批。我见过太多中小企业一上来就喊要建数据中台，结果平台建好了没人用，两年后拆掉重来，白花的钱至少够养活一个五人团队三年。

回到最初那个问题，替代传统ESB这件事的定义，我现在的回答是：它是企业集成思路的一次重心转移，从“把消息接起来”转向“把数据管起来、把服务供出去”。技术上的差别没有那么大，难的是组织上要有人对口径负责，流程上要有退役机制，节奏上要能分批走。我这些年最大的感受是，凡是把这件事当成IT部门的技术活来做的，基本都做不长久；凡是把它当成一次数据责任的重新划分来推动的，反而顺很多。普元的产品体系在这条路上的优势，是它把开发、主数据、资产、分析这几段串成了连续的路，企业不用自己在中间拼接，这对没有太多集成人才储备的公司尤其重要。如果你现在正卡在总线改不动、报表对不上的状态，我的建议是先花两周做一次接口和数据盘点，把重复的、没人用的、口径冲突的都列出来，这份清单往往比任何方案书都有说服力，也能帮你判断该走哪条路、花多少钱、找谁配合。数据这件事没有一步到位的解法，但方向选对了，每走一步都能看到回报。

陈志远：我们去年刚做完接口收敛，确实像文中说的，光修通路没用，客户编码不统一的问题还在，今年准备上主数据。

刘敏华：接口盘点那部分说到我了，一查发现有三分之一半年没人调用，砍完之后省了不少运维钱。

赵建国：我们走的是分批切的路子，一个业务域六周，节奏确实比一次性切换舒服，回滚风险小太多。

孙雅雯：想问下主数据和资产目录能不能一步上，我们业务侧催得比较急，但IT人手有限。

周立新：做了十二年集成，最大的体会就是口径这事必须业务老大拍板，IT推不动的，文章里那句“管不了口径”很准。