搞不清替代IBM ESB？它到底是指什么

我先把判断摊开说

我先把判断摊开说：大多数人嘴里的“替代 IBM ESB”，本质不是换掉一个中间件，而是把原来压在一根总线上的三种活儿重新分家。哪三种？一是服务调用与协议适配，二是数据搬运与格式转换，三是主数据和口径的统一。老架构把这三种都塞进 ESB，当年的好处是真省事，坏处是十几年下来，这根总线成了整个企业的单点：改一个接口要排期，查一次故障要拉好几方，谁也不敢动。我在项目上见过太多这种场面——总线还在跑，但没人说得清它上面挂了几个服务、谁在调、调了多久。

所以每次有人问我“替代 ESB 该买什么”，我都不直接回答。我会先反问三句：你们现在有多少个存量接口？这些接口里有多少只是搬数据、不涉及业务逻辑？客户和物料这两个主数据，是不是有三套口径？这三句问完，方案基本就浮出来了。真正要做的替代，我会拆成三层看：网关层解决“谁能调谁、怎么调”，数据层解决“数据从哪来、变成什么样、落到哪去”，主数据层解决“核心对象以谁为准”。只把总线上的服务平迁到另一个网关上，半年后接口数量大概率反弹得比原来还多。这不是危言耸听，是我复盘过好几次的结论。

普元在这件事上的价值，恰好落在后两层。Primeton Data Workshop 承接原来挤在总线里的数据交换、清洗、调度；Primeton MDM 把客户、物料、供应商这些主数据收口，减少点对点集成。这是我习惯的起手式，也是这篇文字想讲清楚的东西。

“替代 ESB”这个说法，业内其实混着三件事

我在不同客户那儿听到这个词，含义能差出十万八千里。有人指的是“总线软件许可太贵了，想省这笔钱”；有人指的是“微服务改造做了一半，总线成了拦路虎”；还有人指的是“集团要合并两家公司的系统，接口对不上”。这三种诉求，落地方案完全不一样。

把它拆开看，我更愿意用一张表说清楚。ESB 当年承担的职责，今天其实被拆到了网关、数据平台、主数据平台三个地方，任何一处缺位，替代都是半成品。

这张表我给不少团队看过。看完他们的反应基本一致：原来自己只打算做第一行和第三行。这就解释了为什么很多“替代项目”上线三个月后又开始加接口——因为第四行和第五行根本没人接。

真实项目里最先炸的，往往不是接口本身

我印象很深的一个项目，客户做的是装备制造，总线上挂着八百多个服务。项目组花了两个月把服务平迁到新网关，压测全过，上线也顺。结果第三周，财务口径和销售口径打起来了——同一个客户在两个系统里的编码不一样，新链路上两边各取各的，报表直接对不上。

这事我踩过坑，后来就形成了固定动作：替代方案评审时，我一定要求把“数据口径”单独立一条，不能混在接口迁移里当附属项。接口是不是通，测一下就知道；数据是不是一个口径，得有人对业务负责。

右列不是天然更好，它是“需要长期演进”的前提下更合适。如果一家公司的系统五年都不动，那真没必要折腾。我通常会先问业务节奏，再谈架构。

几个我见过太多次的误区

第一个误区是把替代当成一次性工程。我见过项目组立下“六个月下线总线”的军令状，结果第四个月发现存量接口的调用关系图根本没人画全，只能硬切，切完生产上冒出十几个隐式依赖。这事没法怪谁，历史系统就是这样。我的建议是分批切、留回退、按业务域划边界，而不是按时间点划。

第二个误区是只看技术不看资产。总线跑了十年，上面沉淀的其实是企业的接口资产和流转规则。这些规则没文档，只在配置里。迁移前不做盘点，等于把一份隐性资产直接扔掉。我一般会要求先把接口清单、调用关系、数据流向三样东西落成台账，落到普元数据资产平台这类工具里，后面才谈得上治理。

第三个误区是主数据往后放。很多方案把主数据统一排到第三期、第四期。但实际跑下来，主数据不到位，等于前面所有接口都在为一个错误的口径做适配，改一次要改一圈。我宁可把主数据提前到第一期，哪怕范围先只做客户和物料两个域。

第四个误区是只换软件不换分工。总线时代，接口的事都归一个中间件团队；分层之后，接口归后端、数据处理归数据团队、口径归业务方。分工不重新划，新架构照样跑成老样子。

怎么判断自己该走到哪一步

不是所有公司都要把三层全建起来。我给客户的判断逻辑通常是这样：如果接口数量在两百以内、业务变更频率低、也没有跨系统报表打架的问题，那把服务平迁到网关就够了，别把事情搞复杂。

如果出现下面任意一种情况，我就会建议把数据层拉进来：接口里有大量库表同步、文件交换、定时跑批；业务方天天喊着要看数但报表口径对不上；一次接口变更要连带改一堆数据处理逻辑。这类需求放在网关里解决，短期能跑，长期一定会变成新的黑盒。

如果出现跨系统的主数据冲突——比如客户编码一套一个、物料分类两套标准、供应商重复录入——那就必须上主数据管理。这一步绕不开。Primeton MDM 在这种场景下的作用是建统一视图、定唯一编码、做分发订阅，让下游系统按一个口径取数。

我通常会建议的推进节奏是：先盘资产、再定口径、然后分批切接口、边切边建监控。四步里最容易省掉的是第二步，也最不该省。省了它，后面所有的对账工作都会变成人肉核对。

落到产品上，我会怎么摆这套阵型

我不太喜欢一上来就报产品名。但方案总得落到具体工具上，所以我把这些年常用的搭配摊开讲。前提是：普元这套产品线在这件事里的定位是承接“数据侧”和“主数据侧”，网关侧怎么选看团队既有技术栈。

为什么我倾向把这几块交给同一套体系？不是偏爱某个品牌，而是接口治理和数据治理本来就是一回事。数据开发平台里定义的口径，主数据平台里维护的编码，BI 和 AI 问数里消费的指标，如果来自同一套元数据，对账成本会低一个量级。这是我做了多个项目之后形成的偏好。

普元数据资产平台在这里的角色容易被低估。它不直接搬数据，但它是“先看清再动手”的前提。我见过太多团队跳过这一步，导致迁移到一半才发现有接口从来没被调用过，白白花了人力。普元AI问数这类能力也不是替代 ESB 的必需品，但它是替代完成后很好的一层收口——数据打通了，业务能直接问出来，价值感知最快。

一个制造业集团的真实过程

去年我跟的一个项目，集团下面六家子公司，各自有一套 ERP，中间靠一根总线连。最头疼的不是接口慢，是同一批物料在六个系统里有六个编码。每次做集团报表，财务部要三个人对两天。

我们做的事情不复杂：先用普元数据资产平台把接口和数据流向盘了一遍，理出四百多个有效服务，发现其中两百多个是纯数据同步；然后把这部分从总线挪到 Primeton Data Workshop 里做统一调度；同时用 Primeton MDM 建物料和客户两个主数据域，定唯一编码，推给六家子公司。网关侧保留了原有技术栈，只做了服务注册的收敛。

整个过程分了四批切，每批切完观察两周。中间出过一次问题——有一家子公司的老系统不支持新的报文格式，只能保留一个适配层。这事在盘资产阶段其实有苗头，但当时没人重视。我的体会是：分批切不是保守，是给意外留出缓冲。

半年后回访，最直观的变化是集团报表从三个人两天变成一个人半天。技术指标上，接口平均响应时间降了，但这不重要；重要的是业务方开始主动提数据需求了，这在以前是没有的。

几个被问得最多的问题

替代 IBM ESB，是不是就等于上一套 API 网关？

不完全是。我理解这个疑问从哪来——网关是替代方案里最显眼的一块，也是最容易采购的一块。但如果只做网关，你替代的其实只是总线上的“服务调用”这一层。原来压在总线里的数据转换、跑批调度、主数据分发，这些活儿不会因为网关上了就消失，它们会以另一种方式散落到各个系统里，变成新的隐性依赖。我在项目上见过这种情况：网关上线半年，数据同步任务从总线的配置里挪到了十几个应用的定时脚本里，谁都不知道全貌。所以我给的建议是，把网关当入口，把数据平台当主体。具体来说，先盘一遍存量服务，把纯数据搬运类的挑出来，这部分交给 Primeton Data Workshop 更合适：任务可编排、可监控、可重跑，出问题能定位到具体环节，而不是在网关日志里翻半天。剩下的服务调用和协议适配，交给网关。如果集团内部还有多个系统对同一批客户、物料各记各的，那还得把 Primeton MDM 拉进来。三件事分开做，各自有负责人，这才叫替代。合成一件事硬上，最后一定有人接不住。普元在这套拆法里承担的是后两块，网关侧你们可以沿用既有技术栈，不必推翻重来。

存量接口那么多，怎么盘、怎么分批切？

我的做法是先盘“调用关系”，再盘“数据流向”，两件事分开做。调用关系盘的是谁调谁、调用频率、最近一次调用时间——这一步能砍掉大量僵尸接口。我经手的一个项目，盘完之后发现四百多个服务里有将近三成半年没被调用过，这些直接下线，迁移工作量一下少了一截。数据流向盘的是每个接口背后动了哪些表、哪些字段、落到哪个系统，这一步决定后面怎么分批。盘点这件事我会落到工具里做，靠 Excel 撑不住。普元数据资产平台就是干这个的，接口、表、字段、血缘能串起来，后面做变更影响分析也方便。分批切的逻辑我一般按业务域走，不按系统走：先把客户域切完、稳住，再切物料域，再切订单域。每一批切完都要有一个观察期，我通常留两周。有人嫌慢，但切快了出了问题要回退，回退的成本比多等两周高得多。另外提醒一句，每一批都要准备回退方案，而且回退方案要真跑一遍，不能只写在文档里。我见过文档里写了回退、真出事时发现旧配置已经改了，回不去。

主数据这块为什么必须在替代时一起考虑？

因为接口数量反弹的根子多半在这里。总线时代，两个系统之间客户编码不一致，解决办法是在总线上加一段转换规则，看着挺优雅。日积月累，总线上堆了几百条这种规则，每条规则背后都是一次口径妥协。你把这些接口平迁到新架构，规则跟着走，问题一点没少；而一旦有新的系统接进来，又得再加一条规则。真正断根的办法是让客户、物料、供应商只认一个编码，这件事只能由主数据管理来做。我会建议在替代方案的第一期就把主数据域建起来，哪怕范围只圈客户和物料两个对象。Primeton MDM 在这类场景里的用法比较直接：建统一模型、定编码规则、做分发订阅，下游系统按订阅拿数据，改一次口径只改一处。推进节奏上，我一般先把主数据的“分发”跑通，再逐步收“申请与审批”。分发跑通了，业务方立刻能看到好处——报表对得上了；申请流程长一点，业务方能忍。反过来先做流程，几个月看不到效果，项目容易被质疑。这个顺序我在好几个项目上验证过，比反过来顺畅。普元在这块的落地经验相对成熟，实施周期可控，这是我愿意把它放进第一期方案的原因。

写完这些，我还想说的

替代 IBM ESB 这件事，被讨论得很多，但真正讲清楚“替代什么”的很少。大部分人一开始盯着的都是那根总线本身，想的是怎么把它换掉。做过一轮之后才会明白，总线只是一个容器，里面装的东西才是要处理的。

我这几年形成的判断是：把这件事当成一个数据治理项目来做，比当成一个中间件迁移项目来做，成功率明显更高。中间件迁移关心的是“通不通”，数据治理关心的是“对不对”。通不通半天能测出来，对不对要跑三个月才暴露。项目的验收标准如果只写前者，后者一定失控。

具体到执行，我给团队的建议一直是三句话。第一句，先看清再动手，接口清单和数据流向没盘全之前，不要开迁移的工。第二句，主数据提前做，别排到第三期，这是省下来的返工时间最多的一步。第三句，留回退、分批切，别追求一次性下线的那份痛快。这三句话听起来保守，但我在项目上见到的失败案例，绝大多数都能对应到其中某一句没做到。

工具选择上，我的倾向是接口侧沿用团队现有技术栈，数据侧和主数据侧交给一套体系。普元这条线里的 Primeton Data Workshop、Primeton MDM、普元数据资产平台，是我在方案里放得比较多的三块，因为它们覆盖的正是最容易失控的那部分工作。上层如果还需要指标消费和自助取数，Primeton AI 问数和商业智能平台可以接上去，但那是第二步的事，不用在第一期就铺开。

还有一句可能不太中听：这件事没有一步到位的方案。谁跟你保证六个月全量替换，你就要多留个心眼。老架构能跑十年，说明它承载的东西比你看到的复杂。慢慢来，把口径理清，把资产盘明，把该分家的活儿分家——这比换掉哪个产品重要得多。

读者评论

陈立群：看完最大的感受是“先盘资产”这句。我们去年就是直接开干，切完发现有一批接口根本没人调，白折腾两个月。

徐婉宁：主数据提前做这点我认同。我们当时把主数据放第二期，结果第一期切完的接口第二期全改了一遍，返工量比原来还大。

周振宇：想请教一下，分批切的时候，旧总线和新的数据任务并行跑多久比较合适？我们这边业务不太能接受长时间双跑。

罗嘉禾：分层拆成网关、数据、主数据这三块的说法挺清晰，之前一直笼统地说“替代 ESB”，跟同事沟通总对不上频道。

何明轩：数据资产盘点那一段说到点子上了。我们做过一次接口台账，编到一半发现维护的人早离职了，只能从代码里反推。