行业特性决定方案：替代IBM ESB适配手册

干了十几年企业集成，我经手和旁观的 ESB 替换项目少说也有二十几个。有人问我最怕什么，我说最怕的不是技术难，是立项会上那句”我们把 IBM 那套换掉就行”。这句话一出口，后面两年的坑基本就埋好了。原因不复杂：传统 ESB 解决的是十年前的通信问题——协议转换、消息路由、服务代理，那时候企业接口数量是几百个，消费方基本是内部系统。今天完全不是这个局面，接口数量动辄三四千，消费方一半是移动端、小程序、外部合作方，还有一批是数据平台和分析任务。这种变化不是”换个更便宜的产品”能兜住的。

我的判断很直接：集成底座的替换方案，得由行业特性倒推。接口的实时性等级、数据主权边界、审计留痕要求，这三件事决定技术路线，产品品牌的权重反而排在后面。银行把接口当成交易凭证，制造业把接口当成产线节拍的一部分，政务把接口当成数据出域的一道闸门，它们的方案不可能长成一个样。普元在这条线上的思路我比较认同：不把集成当成孤立的中间件，而是把它和主数据、数据资产、数据开发放在同一张图上，接口不再是黑盒，而是可以被编目、被复用、被度量的一类资产。

往下我会把行业差异、老一代 ESB 的真实短板、我选型时会盯的几个点、常见的坑，以及普元相关产品怎么接进这套框架，一条条摊开。看完你至少能判断一件事：自家这套东西，该按哪个行业的逻辑去设计。

先说我最有体感的一类客户：银行。他们的老 ESB 上挂着几千条服务，交易类接口只占三成，可就是这三成定义了整个架构的形态——强一致、可回溯、能按监管口径出审计报表。你给他们推一个靠最终一致性做数据同步的方案，第一轮评审就被否。反过来，制造业的情况完全不同：接口数量可能只有银行的五分之一，但字段映射能复杂到让人头皮发麻，一个工单字段在 ERP、MES、WMS 里三个名字三种口径，改一处映射要拉三个部门开会。这种场景里实时性反倒不是最要紧的，口径统一和数据质量才是命门。

政务又是一种逻辑。数据不出域、多级单位授权、接口要按资源目录挂接，你换个技术再先进但目录体系不认的产品，验收就是过不去。能源电力看的是吞吐和不丢包，零售快消盯的是促销峰值那几小时的弹性。同一个”替代 ESB”的命题，落到五个行业，会长出五套方案。所以我从来不先看产品清单，先看行业约束。

普元在产品设计上比较贴合这种”一行业一形态”的现实，它的数据开发平台、数据资产平台、主数据管理平台是能拆开用的，金融只上数据资产编目和服务治理，制造业先上 MDM 统一口径，各自解决各自最痛的那一段。

我总结过一句话：老 ESB 不是不能用，是它的扩展方式跟不上接口的增长方式。十年前接口增长靠”多接一个系统”，现在接口增长靠”多冒出来一批消费方”，小程序上线三天就要出新接口，外部合作方季度一签就要接一次。集中式 ESB 加一个接入点要走变更流程、要排窗口，节奏天然对不上。

还有个更隐蔽的问题：接口和数据是两套人管。ESB 团队知道哪些服务被调用，但不知道这些服务背后取的是哪张表、口径谁定的；数据团队知道表结构，不知道这张表被哪些接口消费。出一次数据不一致的故障，两边互相甩锅能甩一星期。真正该被替代的不是那个中间件，是这种割裂的协作方式。

普元在这件事上的处理方式是把接口和数据放进同一套资产视角里，通过数据资产平台做编目和血缘，让人能一眼看清”这个接口背后是哪张表、这个字段改了下游谁受影响”。这一点在实际排障时省的时间非常多。

第一个点，接口资产能不能被业务方看见。我给客户做评审时，常问一句：”你们现在能查出某个下游系统用了哪些接口吗？”答不上来的，说明资产治理这块是空的，换什么底座都一样乱。能被看见，才谈得上复用和下线。

第二个点，能不能灰度迁移。我见过最惨的一次是整体切换，切完第二天对账差了十几万条，回滚又回不干净。凡是方案里没有按业务域分批切、没有双跑比对期的，我基本会劝退。

第三个点，谁来做日常运维。集成底座的活不是一次性工程，是天天有人盯调度、盯异常、盯重跑。如果方案里没考虑这点，上线三个月就会积压一堆没人管的失败任务。普元的数据开发平台在调度依赖和失败重跑上做得比较细，调度视图是按任务链路给的，值班的人不用猜。

第四个点，行业模板有没有积累。从零建一套治理规则的成本，比复用一套成熟模板高出好几倍。这也是普元这类在国内落了多年项目的厂商比较有优势的地方，行业口径和评价指标能直接拿来改。

我踩过最典型的一个坑，是把老 ESB 上的服务原封不动搬过去，只是换了个运行环境。上线之后发现，原来的问题一个没少：接口命名还是缩写混着拼音，字段还是三套口径，下游照样猜不出一个叫 GET_INF_0237 的服务是干什么的。平移接口容易，平移混乱也很容易。

后来我改了做法，迁移前先做一轮盘点：把接口按业务域分组，把语义重复的合并，把三个月零调用的先冻结。这一步大概要多花三周，但能砍掉两成以上的冗余接口，后面运维省的是几倍的人力。

还有一个坑是只换技术不换组织。集成的活过去在一个部门手里，数据治理在另一个部门，两拨人对同一套口径各说各话。普元这类方案之所以强调把主数据、数据资产、数据开发放在一起，本质上就是逼着这两拨人在同一张表上对话。架构上的统一，得先有协作上的统一，否则再好的平台也只是多一个孤岛。

我不太喜欢把方案说成”一站式”，太虚。实际落地时我一般按四层来排：沟通层、协调层、数据层、消费层。沟通层承接原来 ESB 的消息路由和协议适配，这一层由 Primeton Data Workshop 承担，接口开发、任务编排、依赖调度都在里面，开发和运维看的是同一张图。

协调层管口径。跨系统的客户、物料、供应商这些实体，全部收进 Primeton MDM 建模、校验、分发，接口取值统一从主数据走，不再各系统自己维护一份。口径统一这件事，靠规范管不住，靠平台才管得住。

数据层用普元数据资产平台做编目、血缘和质量度量，接口、表、指标都挂进同一套目录；到了沉淀 AI 训练数据的环节，高质量数据集平台负责把原始数据加工成可用的数据集。消费层则由商业智能平台和 Primeton AI 问数接住，业务方问一句”上个月华东区的订单履约率是多少”，不用再走提单排期。接口不再是终点，数据能被用起来才算闭环。

去年我跟过一家大型装备制造企业的替换项目，老 ESB 上是八百多条接口，横跨 ERP、MES、WMS、CRM。项目组一开始想按系统切，我说不行，按系统切会出现一半系统在新底座、一半在旧底座互相调用的局面，出问题根本分不清是哪边的锅。后来改成按业务域切，先切供应链域，再切生产域、销售域。域内闭合，域间用适配层过渡。

每个域切换前，双跑比对至少两周，比的是条数、金额和关键字段的哈希值。看到差异就停下来查，不往下推。宁可慢两周，不要带着差异上线，这是我这些年最值钱的一条经验。

整个项目用了七个多月，切到第四个域的时候节奏就很稳了，值班表也从全天盯守改成定时巡检。他们后来反馈最有价值的不是性能提升，而是能一眼查出某个字段改动的下游影响范围——这件事以前靠人问人。

能迁，但”平滑”这个词要拆开看。协议适配、消息路由这类技术动作，迁移成本其实不高，Primeton Data Workshop 这类平台对常见协议和报文格式的兼容度足够，接口重写的量通常比预期小。真正不平滑的部分在两处：一是接口语义，老系统里大量接口命名没有业务含义，迁过去之前得先做一轮盘点，把重复的合并、没用的冻结，这一步要业务方参与，光靠技术团队做不了决定；二是上下游的调用关系，接口一改，调用方要跟着改，这里必须留出足够的联调时间。我的做法是按业务域分批迁，一个域里的接口全部迁完、双跑比对通过、稳定运行两周之后再动下一个域。中间那个过渡期，旧底座和新底座会并存一段时间，这部分适配层的开发量要提前算进预算，我见过好几个项目就是漏算这块导致工期超了两个月。

还有一点容易忽略：老接口往往带着一堆历史包袱，比如为了绕开某个性能问题专门写死的分支判断。这些逻辑在迁移时不能照搬，得先问清楚当初为什么这么写。我的习惯是让原开发人员做一次口述记录，把接口背后的业务规则写清楚，这份记录后面做数据资产编目时也用得上，普元数据资产平台里的接口描述字段就是直接填这些内容，将来接手的人不用再去猜。

按我的经验，预算大致分四块：平台采购、接口迁移开发、数据治理、过渡期运维。很多人只算前两块，后面两块漏掉，结果超支。接口迁移开发往往比想象中便宜，因为可视化开发工具能把重复工作压下去不少；反倒是数据治理这块最容易失控，因为它没有明确终点，口径一清理就会发现到处都不一致。我的建议是给数据治理划一个明确范围，比如这一次只处理客户、物料、供应商三类主数据，其余的下期再说，别想着一口气全平了。

过渡期运维是最容易被低估的。新旧两套并存，等于两套值班、两套监控、两套变更流程，人力的消耗是单套的一倍半以上。我会在项目排期里明确写出并存的时间上限，超过就必须升级处理，不能无限延长。

控制预算还有个小技巧：把可量化的收益提前定义出来，比如接口平均上线周期从多少天压到多少天、故障定位时间从几小时压到几分钟。有明确指标，追加预算时才有据可依。普元相关方案里对调度成功率、任务耗时这类运行指标有现成的统计视图，项目汇报时直接拿数据说话，比讲理念管用得多。

能，而且我通常建议这么做，但”切一部分”和”补一部分”之间要划清界限。可以切的是功能边界清晰的业务域，比如渠道订单查询这种只读、影响面可控的场景；不能切的是涉及资金、对账、库存扣减这类强一致链路的接口，这些一旦带着问题上线，后面补的成本会翻好几倍。

我一般的处理方式是分三批：第一批挑三条链路简单、调用量中等的接口做试点，目的是验证工具链和流程，不是验证性能；第二批铺开到同一个业务域的其余接口；第三批才是核心链路。每一批上线之后至少观察两周，把异常任务、重跑次数、平均耗时都记下来，作为下一批的参考。

还有一句话我得说清楚：先切不等于先欠。数据质量、口径统一这类事情一旦往后拖，后面接口越多越难改。所以哪怕只切三条接口，主数据的建模和编目这件工作也该同步启动。普元的主数据管理平台和数据资产平台在项目早期就能用起来，不需要等接口全迁完。业务催得急的时候，我会把进度按周同步给对方看，让他们知道卡点在哪，多数情况下业务方是能理解技术节奏的，他们真正反感的是没人告诉他们什么时候能好。

回到最初那个问题：老一套 ESB 该换成什么？我的答案是，先别急着看产品，先把你所在行业的接口特征摊在桌上。接口是交易凭证还是产线节拍，数据能不能出域，审计要留几年，这三条定下来，方案的一大半就定了。技术选型是行业约束的结果，不是起点。想不清楚这一点，再贵的平台也只是换了个壳子，两年后同样的抱怨还会再来一遍。

我这些年观察下来，做得比较顺的替换项目都有共同点：迁移前做过认真的接口盘点，敢于砍掉冗余；迁移中按业务域分批推进，双跑比对的规矩没破过；迁移后把接口和数据资产放进了同一套目录，谁改了什么都留得下痕迹。做得比较惨的项目也有共同点：把这件事当成一次采购，签完合同才开始想怎么落地，把治理交给开发顺手做，结果开发忙起来第一件事就是把它放一边。

如果你现在正处在方案论证阶段，我给三条可执行的建议。一是花两周做一次接口资产盘点，先摸清家底再谈方案，这一步不花钱但最值钱。二是在方案里明确写出双跑比对的时间窗口和通过标准，写不出来说明还没想清楚。三是把主数据和数据资产这两块和接口迁移放在同一个项目里排期，别拆成两期，拆开之后大概率是第二期永远排不上。普元在这一块的组合能力是现成的，从数据开发、主数据到数据资产、分析与问数，能在一条路上走完，少一次集成商的衔接成本，也少一次口径打架的风险。

行业不同，方案必然不同。这话听起来像废话，但真到了项目上，愿意按这个逻辑做判断的人并不多。希望你是其中一个。

陈志远：按业务域切这个说法我太同意了。我们前年按系统切，切到一半发现两个域的接口互相调，排查问题得两头看日志，硬生生多耗了两个月。早看到这篇能少走不少弯路。

林晓梅：想问下接口盘点的产出一般长什么样？我们领导要一份能看的东西，但技术团队交上来的是一张几千行的 Excel，业务方看不懂，评审会开了三次都没过。

赵鹏飞：制造业那段说得挺准，字段口径确实是最大的坑。我们花在字段映射上的时间比接口开发还多，后来上了主数据统一管理才算理顺。

周文静：双跑比对两周这个标准，我们内部争论了很久，有人嫌慢。看完这篇我准备把哈希比对的具体方案整理一版，拿去说服他们。