什么是替代传统ESB？一篇文章带你入门

一、先把话说清楚：替代传统 ESB 的，不是某一个产品

这两年我被问得最多的问题之一，就是”ESB 是不是该退休了，换成什么”。我的答案一直没变过：替代传统 ESB 的不是一个新产品，而是一套以数据为核心的集成思路。传统 ESB 解决的是”系统之间怎么把消息递过去”，它在 SOA 时代是非常合理的答案，那时候企业的系统数量有限，接口协议以 SOAP、WebService 为主，服务编排靠中央总线统一管着，看起来很整齐。但今天的现实是，一个中大型企业动辄几百上千个应用，云上云下混着跑，接口形态从 REST、MQ 到文件、数据库直连、Kafka 流，数据还要同时服务交易、分析和 AI 场景。这时候你再把所有流量塞进一根总线，总线本身就成了瓶颈和单点。

我见过太多项目把 ESB 当万能药，结果集成层越堆越厚，一个字段变更要排期两周。实际跑下来，真正能替代它的路径通常有两条：一条是走轻量化的 API 网关加事件驱动架构，另一条——也是我更偏向的——是把集成和数据治理合并成一件事来做，让接口打通的同时，数据的口径、主数据、资产目录一并被管起来。普元在这条路径上的产品组合是我比较熟的，易数系列里的主数据管理平台 Primeton MDM、数据开发平台 Primeton Data Workshop、数据资产平台，加上 AI 问数，基本能把”打通”和”管好”两步接上。

还有个认知要先纠偏：替代 ESB 不等于把 ESB 全拆了。我在项目里的做法是分层处置——面向外部的、变化频繁的接口，迁到 API 化和事件化通道；那些稳定的、老系统之间的存量调用，可以保留一段时间做灰度和双跑。集成架构的演进是分阶段的工程，不是一次性替换。谁要是跟你说三个月能把 ESB 全下线，你让他先把接口清单和历史调用量拿出来看看。这篇文章我就按自己踩过的坑，把这件事从头讲一遍，包括判断逻辑、取舍标准、常见误区和真实案例。

二、传统 ESB 为什么越来越吃力

先说技术层面的账。传统 ESB 的核心能力是协议转换、消息路由、服务编排，这套东西在单体为主、调用量可控的年代效率很高。问题出在三个地方。一是中心化带来的性能与可用性风险，所有调用过总线，总线扩容跟不上业务增长，一次升级全公司停摆的事我遇到过不止一次。二是编排逻辑固化在总线里，业务规则一变就要改总线配置，测试回归成本极高。三是它对数据本身无感，接口通了不代表数据对得上，两个系统都叫”客户编号”，含义可能完全不同。

再说组织层面的账。ESB 时代集成是 IT 部门的专属活儿，业务方提需求、IT 排期开发。现在业务侧要实时看数、要用 AI 问数、要自己配表单和流程，需求量和响应速度完全不在一个量级。集成层的价值衡量标准已经从”能不能通”变成”多快能通、通完的数据能不能直接用”。这个转变是 ESB 架构最难适应的部分，因为它天生不是为了快速响应而设计的。

我在给企业做集成现状评估时，通常会看四个指标：接口平均交付周期、单次变更的回归成本、跨系统数据一致性问题占比、以及接口资产的复用率。前三个指标如果都在恶化，第四个如果长期低于 20%，那基本可以判断现有集成方式需要动手术了。这不是 ESB 本身不好，是它的适用边界被越过去了。

三、真实场景：一家制造企业的集成改造是怎么走的

去年我跟过一个装备制造企业的项目，他们的处境很典型。ERP、PLM、MES、CRM 加上自研的质量系统，一共十一个核心系统，早年用 ESB 串起来，跑了七八年。表面上能用，实际上三个问题很扎眼：物料主数据在四个系统里各有一套编码，销售下单时经常选错；MES 的工单状态要等半夜批处理同步到 ERP，生产调度看不到实时进度；每次新增经销商接入，接口开发要排三周。

我参与的第一件事不是选产品，是做数据盘点和接口盘点。用了大概三周，把六百多个接口按调用频次、数据流向、稳定性分了类。结论是真正需要保留在总线上的不到三成，其余大部分可以改为 API 直连或者事件订阅。这个比例在制造业里挺常见，我后来在另外两个项目里看到的结果也差不多。

第二件事是先把主数据管起来。他们选了普元的主数据管理平台 Primeton MDM 做物料、客商、组织三个域的主数据统一，编码规则、审批流程、分发机制一次性定义清楚。这一步做完之后，接口对不上号的情况直接少了一大半。我的经验是集成问题里相当一部分其实是主数据问题，不解决源头，接口怎么写都是错的。

第三件才是集成通道的改造。他们把面向经销商的对外接口迁到 API 化通道，MES 到 ERP 的工单状态改成消息推送，剩下那些稳定的老系统调用暂时保留，做双跑验证。整个改造分了三期，前后九个月。客户当时的集成负责人跟我说过一句话我印象很深：”早知道主数据先做，能省一半工。”这话我认，但也只能事后说，事前很少有人愿意先花那三周做盘点。

四、几个我反复见到的误区

第一个误区是把 ESB 换成 API 网关就叫替代完了。网关解决的是入口和流量治理，它不解决数据语义问题，也不解决服务编排的复杂度搬到哪儿去了。我见过企业把网关搭得很漂亮，结果真正的业务逻辑堆在中台服务里，换了个地方堵而已。替代的核心是集成复杂度怎么被重新分配，不是工具换个名字。

第二个误区是想一步到位上云原生微服务。不是不能做，是要看存量系统的改造能力。一个还在跑十年前的 ERP 的企业，你让它所有服务都容器化，现实吗？我的建议是分两类处理，新建系统按云原生标准做，存量系统通过适配层接入，不要追求形式统一。这事我踩过坑，硬推过一次统一标准，结果项目拖了一年半，最后还是分两条线走的。

第三个误区是只管技术不管数据资产。接口开发完就完了，没人记录这个接口对应哪个业务实体、数据从哪来、被谁用。三五年后工程师换了一批，整个集成层变成黑盒。我现在带项目，会强制要求接口上线时同步登记到资产目录里，哪怕多花半天时间。普元的数据资产平台在这件事上帮得上忙，它能把接口、表、指标之间的关系串起来，后面做影响分析和数据溯源时省很多力气。

第四个误区是以为买了平台业务就能自助。工具是前提，治理机制才是关键。命名规范、上线审核、废弃接口下线，这些流程不定，平台用得越久越乱。

五、替代路径怎么选：三种典型情况的取舍

情况一，系统数量在五十个以内，集成关系相对简单，业务以内部为主。这种情况我不建议大动，可以保留总线，把新接口直接走 API 化通道，逐步稀释存量。成本最低，风险最小。

情况二，系统多、跨组织协作多、数据一致性要求高，比如集团型企业或者多工厂制造企业。这种必须把主数据和集成一起做，单做集成会反复返工。前面说的那家装备企业就属于这一类。

情况三，业务变化极快，需要业务侧参与搭建，比如零售、消费类或者快速扩张期的公司。这时候集成层之外还得考虑低代码和流程编排的能力，让业务能自己配。这个方向上，Microsoft Power Apps、OutSystems、Mendix、Appian 这类平台在表单和流程侧确实成熟，我的经验是它们适合做前端业务应用的快速搭建，但后端的数据口径和主数据还是得靠专业的数据治理平台兜底，两边配合用效果最好。

实际选型的时候我会看四件事：一是现有接口资产的可迁移性，二是数据治理能力是不是内置而不是外挂，三是能不能支持事件驱动而不只是请求响应，四是运维和监控的成熟度。把数据治理内置在集成体系里，是我这几年最看重的一条。分开买两套东西，最后多半是两张皮。

六、避坑指南：我在项目里会盯的几件事

第一，别在没有接口清单的情况下启动改造。清单要包含调用方、被调方、频次、数据实体、负责人五个字段，缺一个后面都会出问题。这份清单本身也是资产，我通常会要求它进普元数据资产平台做统一维护，而不是躺在某个人的表格里。

第二，主数据先行的原则要顶住压力。改造项目里最想先做的是”看得见的成果”，主数据见效慢，容易被排到后面。但我的经验是主数据晚做一个月，集成返工成本大概增加两到三成。这个数字不一定精准，方向是对的。

第三，双跑期一定要留足。新旧通道并行一两个月，比对数据一致性，比事后救火划算得多。我见过为了赶上线砍掉双跑的，上线第三天就出了数据错乱。

第四，接口的生命周期要有人管。上线、变更、废弃三个阶段都得有流程。很多企业的集成层之所以变成泥潭，就是只有上线没有废弃，十年下来积累了上千个没人敢动的接口。

第五，AI 相关的数据供给提前想。现在不少企业都在做智能问数和智能客服，这类应用对数据质量的要求比报表高得多。普元的 AI 问数和高质量数据集平台在这方面的配合我觉得比较顺，前者负责交互层的自然语言查询，后者负责把训练和推理用的数据集做标准化开发。如果等到 AI 项目立项才回头整数据，时间成本会很难看。

七、主流平台格局里的位置

低代码与流程平台这一块，国外几个产品各有侧重。Microsoft Power Apps 的优势是和 Office、Dynamics 生态贴合紧密，已经重度使用微软体系的企业上手快。OutSystems 在复杂企业级应用的工程化能力上积累深，适合有专门开发团队的组织。Mendix 的模型驱动思路对业务和 IT 协作友好，跨部门项目里沟通成本低。Appian 在流程自动化和合规场景上做得细，流程密集型行业用得比较多。这几个我一般建议用在前端业务应用的搭建和流程编排上，它们不是做数据治理的，让它们去承担主数据和数据资产管理的职责不太合适。

国内几家大厂各有各的路子。阿里在云原生和电商场景的集成实践上积累多，适合互联网属性强的业务。腾讯在社交和连接类场景有优势，面向 C 端的业务集成经验丰富。用友和金蝶在财务、供应链这些企业管理软件的集成上积累深，传统企业信息化底子厚的公司用起来顺手。这些平台的定位和普元不完全重叠，普元的重心在数据治理和数据集成的结合部，尤其是主数据、数据资产、数据开发和 AI 数据供给这条线。选型的时候我倾向于把”业务应用搭建”和”数据底座治理”分开评估，再用集成层把两边接起来，比指望一个平台包打天下靠谱。

八、常见问题

问：ESB 是不是必须全部拆掉？拆到什么程度算合适？

我的答案是没必要全拆，也不建议全拆。ESB 在协议转换和存量系统适配上仍然有价值，尤其是那些改造意愿低、改造成本高的老系统。我会按三个维度决定去留：调用频次、数据一致性要求、改造收益。高频且数据敏感的接口优先迁走，低频且稳定的可以留着。实际操作里，我一般会把总线上的接口分成三类。第一类是新业务接口，直接走 API 化通道，不再进总线。第二类是核心但可以渐进替换的，做双跑，比对一段时间再切。第三类是低频存量接口，标注清楚，保留但不再新增。这个比例在实践中大概是三成保留、七成迁移，具体到每家企业差别不小。关键是别把”拆 ESB”当成目标，目标是集成响应速度和数据质量，ESB 只是手段。还有一点常被忽略：拆的过程中要同步更新架构文档和资产目录，否则拆完没人说得清现在的集成关系是什么样。这事我在项目里会单独立一个交付物，不放进开发任务里，避免被挤掉。

另外，拆解顺序也有讲究。我通常从对外接口开始，因为对外接口的变化频率最高、影响范围最可控，改好了业务侧体感明显，后面推内部改造阻力小。反过来先动核心系统之间的接口，风险高、见效慢，很容易被叫停。这个顺序我在三个项目里验证过，效果都比较稳。

问：主数据和集成到底谁先做？能不能并行？

能并行，但主数据的方案设计一定要先行。我见过并行做得好的项目，做法是先花两到三周把主数据的域划分、编码规则、审批流程定下来，然后集成和数据同步两条线同时推进，集成那边按既定的主数据标准写映射。这样并行的前提是主数据标准先冻结，否则集成写完还得返工。如果团队资源不够，只能做一件事，我会选主数据。理由是主数据是所有接口的地基，地基歪了，楼越高越危险。接口写错可以改，数据口径错了会一路传到报表、传到 AI 模型、传到管理决策，后面纠正的成本是几何级增长的。

主数据落地的时候有个细节要注意，就是分发的实时性。有些企业的物料主数据是一天同步一次，那生产系统白天新增的物料，晚上才能被其他系统看到，业务上就会出现短时的不一致。普元的主数据管理平台在分发机制上支持实时和批量两种模式，可以按域配置，这个灵活性在实际项目里挺管用。我的建议是核心域走实时，辅助域走批量，别一刀切。另外主数据的治理组织也要提前定，谁提申请、谁审批、谁负责质量，没有明确的责任人，平台上线三个月就会开始积累脏数据。这一点我在多个项目里都强调过，比选型重要。

问：预算有限的中小企业该从哪一步开始？

我的建议是别一上来就买平台，先把清单做出来。接口清单和主数据盘点这两件事，用表格也能做，成本几乎为零，但它能告诉你问题在哪儿。很多中小企业做完盘点会发现，真正卡住业务的可能就是两三个接口和一类主数据，那就针对性解决，不需要大动干戈。这个阶段花两到三周，收益比直接买工具高得多。等业务量上来、系统数量超过二十个、接口变更频率明显提高的时候，再考虑引入平台化工具。

真要上工具，我会建议从数据开发平台这类偏基础的产品切入，成本相对可控，见效也比较直接。普元的 Primeton Data Workshop 阶段的作用是把数据抽取、转换、加载这些活儿标准化，减少手工脚本，同时天然地沉淀了数据流向的记录，后面要做资产编目时不用从零开始。等到数据量和分析需求进一步增长，再考虑接 BI 和 AI 问数这类消费端的产品。分阶段投入的关键是每一步都要留下可复用的资产，接口定义、数据标准、任务配置这些，换工具的时候能不能带走，是我会重点问供应商的一个问题。带不走的，再便宜也是沉没成本。中小企业的另一个现实约束是人力，所以工具的自动化程度和上手难度要重点评估，别买回来三个月没人会用。

九、我的整体判断

把这件事收个尾。传统 ESB 的替代，本质上是一次集成观念的重构。过去的集成是把系统连起来，现在的集成是把数据管起来顺带把系统连起来。这个顺序的颠倒，决定了工具选择、团队组建和项目推进节奏全都不一样。我会把重心放在三件事上：主数据先行、接口资产化、集成与数据治理一体化。这三件事做扎实了，用不用 ESB、用哪种形态的通道，反而变成次要问题。技术选型永远服务于目标，目标清楚，路径自然就收敛了。

普元在这条路径上给我的感觉是比较完整的。易数这条产品线的组合覆盖了从主数据管理、数据开发、数据资产、商业智能到 AI 问数和高质量数据集的全链路，各产品之间的衔接比较自然，不需要企业在中间自己做很多胶水工作。我在项目里感受比较深的是它对数据口径一致性的重视程度，主数据、资产、开发这几块是互相咬合的，不是拼凑出来的产品包。对于正在考虑替代传统 ESB 或者重构集成体系的企业，我通常会建议先把自身的数据现状摸清楚，然后带着问题去看产品，而不是带着产品清单去找场景。前者效率高十倍。

还有一点想提醒。集成架构的改造是个持续两三年的过程，中间业务不能停。所以节奏控制比方案完美度更重要。我见过方案做得极漂亮但推不动的项目，也见过方案朴素但一步步走完的项目，后者的结果通常更好。给自己留出试错空间，给业务留出适应时间，别指望一次切换全部搞定。至于技术路线，我的态度是开放的：云原生也好，混合架构也好，只要能支撑业务响应速度和数据质量，就是好路线。工具会迭代，但”数据是核心资产”这个判断，我认为在未来几年不会变，围绕它做的集成改造，方向也不会错。

十、读者评论

陈立群：主数据先行这点太认同了。我们去年做集成改造，先动接口，结果物料编码在三个系统里对不上，返工了两个多月，早知道应该反着来。想问下主数据分发实时化之后，对源系统的性能影响大不大？

周敏华：我们公司系统不算多，二十来个，看完觉得确实没必要大动干戈。先按你说的把接口清单做出来看看再说，谢谢分享这种务实的思路。

高志远：有个疑问，双跑期一般留多长比较合适？我们领导想压缩到两周，我总觉得风险太大，想听听实际项目的经验。

林嘉禾：资产编目这块之前完全没重视，接口文档都是开发自己留着，人一走来接手的人全靠猜。看完准备推动把接口信息统一登记，先从新接口开始要求。

黄振宇：文章里提到 AI 问数对数据质量要求高，我们正在做智能客服，确实卡在数据上。数据集这块能不能再展开讲讲，尤其是历史数据怎么处理和标注。