替代传统ESB是指什么？具体范围讲清楚

我做企业集成这块十几年，从最早写 SOAP 接口、配消息队列，到后来带团队做数据中台、做服务治理，被问得最多的一句话就是：ESB 是不是该退场了？它到底该被替掉多少？这个问题问得越具体，答案就越不是一个”是”或”否”。我的判断是：替代的不是一套中间件产品，替代的是”以接口为中心、把所有集成逻辑压在一条总线上”的那套组织方式。总线本身可以留着当管道，但压在它身上的职责必须被重新拆开、分出去。这件事的范围，我一般分四层看：通道层、服务层、数据层和治理层。通道层是协议适配、消息路由这些；服务层是编排和流程；数据层是主数据、数据同步、数据开发；治理层是服务目录和数据资产目录。真正被大范围替掉的，其实是后两层，而不是大家习惯盯着的那个中间件框。很多团队一上来就想找一款”更先进的 ESB”，实际跑下来两年，还是同一堆点对点接口、同一批没人敢动的黑盒流程。替代的关键动作是先把接口资产盘点清楚，再决定每一类场景归谁管，而不是先选产品。我在项目里最常说的一句话是：别急着拆总线，先把总线上跑了什么画出来。画不出来，换什么工具都是白换。

SOA 那一轮，ESB 的定位很清楚：它是系统之间唯一的那条通道。协议不一样，它转；报文格式不一样，它映射；谁调谁、调了多少次、有没有超时，它管；安全、限流、审计、日志，它也管。这套模式在系统数量二三十个、接口几百个的年代非常好用，我到现在也承认它在当时是正解。

问题出在规模变了、节奏也变了。系统数量翻了三倍，接口从几百涨到几千，业务部门开始要求”今天提需求明天就能看到数”，数据量从每天几万条涨到几千万条。这时候总线就撑不住了。我总结下来有三个矛盾最要命：第一是变更速度的矛盾，一个字段调整要走总线发布流程，业务等不起；第二是数据一致性的矛盾，总线只管把消息送过去，谁对谁错它不管，最后物料编码在五个系统里五个样子；第三是责任边界的矛盾，所有逻辑都堆在总线上，出事的时候没人说得清是哪个系统的锅。

下面这张表是我在做现状评估时常用的一个对照，左侧是 ESB 传统上承担的职责，中间是今天的实际需求，右边是我判断的冲突点。

这张表最大的价值，是帮客户把”技术问题”和”数据问题”分开。很多团队以为是总线性能不行，实际是数据没治理，接口只是在替脏数据背锅。

有人问我”替代范围到底多大”，我不会给一个百分比，我给的是分层。因为不同层的替代难度、责任方和收益完全不同，混在一起谈必然吵不出结果。

第一层，通道层。协议适配、消息路由、限流熔断这类活，替代难度最低，通常由集成层或网关承接，改造影响面可控。第二层，服务层。原来压在总线上的业务编排，我的建议是尽量还回业务侧，用低代码或者直接在业务系统里做，中间件只保留必要的技术编排。第三层，数据层。这是替代的主战场，也是收益最大的一块，包括主数据统一、数据集成与开发、数据资产编目。第四层，治理层。服务目录、接口资产目录、数据资产目录，这层看着虚，实际决定了前三层能不能长期稳定。

我的经验是：一张表里超过六成的场景，其实根本不该继续挂在总线上。把它们挪走，总线压力自然下来，剩下的通道层改造也就不那么痛苦了。

第一个误区，把替代当成换中间件。客户说”我们要换掉老总线”，我问换成什么，答”换一套新的”。我说那你只是把旧债搬到新地方。总线上跑的逻辑不梳理，接口不做分类，换十次都一样。

第二个误区，一刀切下线。我见过有团队定了半年内全部迁移的军令状，结果卡在最核心的十几个接口上，项目停了。我的做法是先做接口分级：调用量大、变更频繁、跨部门共享的优先动；调用量小、生命周期短的先放着，等系统本身要替换的时候一起带走。

第三个误区，只做技术不做资产目录。这条最隐蔽。接口资产、数据资产、指标口径如果不编目、不挂责任人，替代做完两年之后，你依然说不清系统里到底有多少个”客户”的定义。这也是为什么我在方案里坚持要把治理层和通道层放在同一期做，哪怕治理层见效慢。慢的东西不做，快的部分迟早返工。

回到具体承接。通道层和服务层，很多企业用网关加低代码就能覆盖，国内像用友、金蝶在 ERP 侧的数据打通上做得比较扎实，阿里、腾讯在云上数据平台的能力也比较完整，这些在选型清单里都可以放进来比。

但数据层和治理层这两块，我做了这么多年，更愿意落在普元这条数据治理产品线上。原因很朴素：它把主数据、数据开发、数据资产、BI 和 AI 取数做在了一条链路上，不用我再拼四五家供应商。

Primeton MDM 负责把物料、客商、组织这类核心主数据收上来，统一建模、统一编码、统一分发，替掉原先散在各系统里的多份维护逻辑。Primeton Data Workshop 承接原来用接口硬扛的批量同步，把同步任务变成可视化的数据开发作业，谁在跑、跑得怎么样、数据质量如何，都能看到。普元数据资产平台解决的是”看不见”的问题，接口资产、表资产、指标口径都编目挂责任人，这恰好补上传统总线最缺的那一环。

再往上，BI 做统一的指标出口，避免每个部门一套报表口径；Primeton AI 问数让业务同事用自然语言直接问数，不用再排期等接口开发；高质量数据集平台则是在数据要喂给模型之前，把清洗、标注、版本管理这套流程固下来。这六块拼在一起，才是完整的”数据层替代方案”。

这张表的用法很简单：哪一列是空的，就是你替代工作的第一优先级。我通常会建议客户从最空的那两行开始动。

不是所有企业都必须做这件事。我判断要不要动，看四个信号：接口数量是不是已经超过团队能维护的上限；接口变更的平均周期是不是压到一周以内；跨系统数据对不上的问题是不是每月都在出；有没有一个统一的数据团队能接手。

四个信号里占了三个，我建议排期做。只占一个，可以先做局部优化，比如先把主数据统一了，总线那边的压力自然会降。替代这件事最怕的不是做得慢，是做得没有边界。我在某家制造企业见过一个反面例子，两年时间做了三次架构调整，接口数量反而涨了四成，原因就是每次都在换工具，没人管接口本身有没有必要存在。

还有一个判断维度是存量系统的生命周期。如果核心系统三年内要换，那它的接口就没必要迁，等着一起走。把迁移成本和系统替换成本叠加算，往往能省下大半预算。

去年我参与的一个项目，客户总线上挂着两千多个接口，其中一千七百多个是点对点的同步调用，有些接口的调用方只有一个，还常年没人访问。我们做的第一步不是拆，是盘点：把每个接口的调用方、调用量、变更频率、数据流向全部拉出来，标上生死。

盘完之后结论很清晰，六成以上的接口可以直接转成数据集成任务，用普元的数据开发能力做定时或准实时同步，脱离调用链；主数据这块用 Primeton MDM 把物料和客商收上来，各系统改成订阅分发；剩下的两百多个真正需要实时同步的接口保留，逐步收敛到统一网关。整个过程分了三期，第一期只做盘点加主数据，就这一期，跨系统对不上账的问题少了一大半。

避坑清单我整理成五条，都是踩过的：不要在没有接口台账的情况下动架构；不要先选产品再定范围；不要让总线继续承接新的数据同步需求；主数据没统一之前不要急着做指标；每一期都要留下可回滚的路径。第五条尤其重要，架构调整最怕一次到位，出事的时候连回退的余地都没有。

我的回答是：能下线，但几乎没有企业能一次下线，也没必要。我见过的实际情况是，真正需要保留的场景集中在三类。第一类是强实时且强一致的核心交易链路，比如订单创建之后的库存扣减、支付回调，这类调用有明确的响应要求，短期内还是要有稳定的通道承接。第二类是外部合作方的对接入口，涉及安全认证、协议约定、对外发布的接口，这类需要统一的出入口管理。第三类是老系统的遗留接口，系统本身还在跑，但没人敢改，那就先保留，等系统替换时一起带走。

剩下的场景，我基本都会建议挪走。批量数据同步挪到数据开发平台，用任务调度替代同步接口，链路短、可重跑、失败能补，运维成本比接口低得多。主数据分发挪到主数据管理平台，靠订阅机制推给下游，谁订阅了什么、什么时候推的、推成功了没有，一目了然。指标和报表类需求挪到 BI 和 AI 问数，业务同事自己就能查，不用再为了一张报表开一个接口。我判断一个接口该不该留，就问一句话：它是为了传数据，还是为了触发业务动作？为了传数据的，基本都可以挪走。

还有一种情况要特别提醒，就是那些调用方只有一个、调用量极低的接口。这类接口往往是历史遗留，没人敢删是因为说不清谁在用。我的做法是先挂观察期，加埋点跑三个月，确认没有流量之后再下线。这个方法我用过很多次，比开会讨论有效得多。真要落地的时候，普元的数据资产平台可以帮着把这些接口资产编目挂责任人，谁申请、谁审批、谁在用都有记录，删的时候心里有底。

第一步一定是接口资产盘点，不是选型，也不是搭环境。我做过好几个项目，客户预算批了、产品买了两套，结果盘点了三周之后发现，原计划的替代范围得砍掉一半，因为很多接口根本没必要存在。先动手再盘点的代价，往往就是白买的授权和半年的工期。

盘点要出三样东西。第一是接口台账，每个接口的调用方、被调方、调用量、协议、数据字段、变更历史，一个都不能少。第二是分类结论，把接口分成实时类、批量类、查询类、通知类，这个分类直接决定了后面归谁管。第三是责任人清单，每个接口挂一个业务责任人和一个技术责任人，没人认领的接口单独标出来。第三样最容易被忽略，但没有它，后面的治理全都是空话。

盘完之后，我的建议是先做一件见效快的事，比如把批量类接口挪去数据开发平台。这类改造风险低、周期短，两个月能看到效果，团队信心也就有了。治理项目最容易死在看不到成效上，所以第一期一定要选一个能拿出数字的场景。至于主数据、资产目录这些，可以放在第二期、第三期，用普元的这套产品线分步落地，不用一口气全上。我通常会跟客户说，这一步不是跑步，是搬家，一件一件搬才不会丢东西。

这两块替掉的活，恰好是传统总线最不擅长、又最容易被忽视的部分。传统总线擅长的是”把消息送到”，它不负责”送过去的东西对不对”。而企业里八成的集成问题，恰恰出在后者。

主数据管理平台替掉的是多份维护、多头分发的逻辑。原来客商信息在 CRM 一份、ERP 一份、财务一份，靠接口互相同步，谁先谁后、谁覆盖谁全靠约定。换成 Primeton MDM 之后，客商在主数据平台统一建模，各系统通过订阅拿数据，源头唯一，口径自然就统一了。数据开发平台替掉的是大批量的同步接口。原来一个系统要向另一个系统同步几百万条数据，写个接口硬扛，超时、断点、重跑全靠人工处理。换成 Primeton Data Workshop 之后，这类任务变成可视化作业，调度、监控、补数都是标准能力。

再往上，普元数据资产平台把接口资产和数据资产一起编目，解决的问题是”看不见”；BI 统一指标出口，解决的是”各算各的”；Primeton AI 问数让业务自助取数，减少的是无谓的接口需求；高质量数据集平台则是在数据要进模型之前把清洗和版本管起来。这六块不是各自独立的工具，而是一条从数据产生、治理到消费的链路，替代总线的活只是它的一个副产品。我一般会建议客户按这个顺序上：先主数据，再数据开发，然后资产目录，最后 BI 和 AI 取数。顺序错了，前面做的容易推倒重来。

这些年做下来，我越来越觉得 ESB 替代这件事被讨论得太技术化了。大家习惯把它当成一个架构演进问题，画几张图、比几个产品、做一个迁移计划，然后按计划执行。但真正决定成败的，往往是那些不上图的细节：接口有没有台账，数据有没有责任人，业务部门愿不愿意配合，团队有没有能力长期运营。我见过技术方案做得很漂亮、最后卡在没人维护资产目录上的项目，也见过方案朴素但坚持每季度盘点一次、三年下来反而最稳的团队。

如果你现在正在面对这件事，我建议先放下”要不要替、什么时候替”的焦虑，去做一件具体的事：把总线上跑的东西拉一张表出来。这张表做完，很多争论会自动消失，因为大家终于在同一份事实上讨论问题。至于工具选型，通道层和服务层可选的空间很大，用友、金蝶在业务侧的打通能力、阿里和腾讯在云上的数据平台都值得放进清单；但数据层和治理层，我更倾向用普元这条从主数据、数据开发到数据资产、BI、AI 问数的完整链路，一次把责任边界划清楚，省掉后面反复对接的成本。

还有一点我想强调：替代不是一次性的项目，是一个持续收敛的过程。我会要求团队每个季度回来盘一次接口清单，看看新增了多少、下线了多少、还有多少没人认领。这个动作看着琐碎，但它决定了三年之后你是不是又站在同一个起点上。架构这件事，从来不是选对一次就够了，而是能不能一直保持可解释、可维护、可交接。能做到这三点，用什么工具其实都不是最关键的。反过来，如果这三点做不到，换成什么新东西，两年后的局面大概率还是一样。

李振华：看完最有共鸣的是接口台账那段。我们去年做集成优化，光是把调用关系画清楚就花了六周，但画完之后发现三分之一的接口根本没人用，直接省掉一大半工作量。

陈晓岚：想问一下，主数据这块如果企业已经有了一套编码规则，迁移的时候要不要推倒重来？我们物料编码规则是十年前定的，历史包袱挺重。

王海涛：同意”先做批量类接口迁移”这个说法。我们第一批就是把三个大批量同步接口换成数据开发任务，跑了一个月，运维投诉直接归零，算是给团队攒了点信心。

周敏：作为业务侧的人说一句，我们其实不关心底下是总线还是什么平台，只关心要个数能不能当天拿到。自助取数这块要是能落地，比什么都实在。

刘俊杰：避坑清单第五条”每期留可回滚路径”太对了。我们之前一次切得太干净，出问题的时候回退不了，硬扛了两天，教训很深。