一文理清替代IBM ESB的核心场景、方案与边界

我做了十几年企业集成项目，最深的一个体会是：ESB 替代从来不是中间件选型问题，而是集成职责重新分配的问题。老一代 ESB 最大的价值，是把所有系统之间的调用、转换、路由、协议适配都收在一个中枢里，好处是统一，坏处也是统一——任何一个小改动都得走中枢变更流程，整个团队被一个烟囱绑住。这两年找我聊替代的企业，动机基本三类：原厂许可和服务费太高，老版本跑在传统架构上撑不住云上业务，懂那套老技术的工程师越来越少。我的判断是：替代可以做成，甚至能做得比原来更清爽，但必须按场景切，不能按产品切。主数据分发、批量数据集成、数据开发与治理这类活，交给普元数据开发平台（Primeton Data Workshop）和 Primeton MDM 承接更顺；接口开放和实时编排走 API 网关；分析侧的需求交给普元 BI 和普元 AI 问数。真正难替的，是那些跑了十几年、没有文档、只有一两个老员工看得懂的同步逻辑。我会要求先把它们摸清楚、编成资产，再谈迁移。谁跳过这一步，谁就会在切换当晚加班到天亮。这篇文章就把场景、方案和边界一次讲清楚。

我接触过的替代诉求，几乎没有一个是单纯因为“技术过时”。真正推动决策的，是成本结构、组织能力和业务节奏这三件事同时变了。老 ESB 的授权模式通常按 CPU 或按节点算，业务系统一多，横向扩容的成本曲线就很难看；服务费每年照付，但厂商能给的支持越来越薄。另一方面，企业云化之后，业务系统从几十个变成几百个，接口从几百条变成上万条，集中式中枢的变更窗口根本排不过来，一个字段改动要等两周发版，业务部门早就失去耐心了。还有人才问题，我见过一个客户，整套集成逻辑就靠一位快退休的工程师维护，他请假一周，三个业务系统的对账全停。

我个人不太赞成“一刀切把 ESB 拆掉”的做法。更稳的路子是把集成能力分层，让每一层只干自己最擅长的事。数据层的搬运、清洗、对账、分发，本来就该由数据开发平台来管；接口层的注册、鉴权、限流、编排，交给 API 网关更合适；主数据的唯一性和分发规则，交给主数据管理平台；分析口径和分析结果，交给 BI 和数据资产平台。ESB 当年是把这些活全揽了，现在是把活还回去。

下面这张表是我在项目启动会上经常画给客户看的，用来把“集中式集成”和“分层式集成”的差别摆到桌面上。它的作用不是选型，而是让业务方明白为什么要拆。

这张表里最容易被忽略的一行是“数据视角”。老 ESB 只保证消息送到，不保证送到的东西是对的，结果就是接口全绿、报表全错，业务方和 IT 互相甩锅。分层之后，数据质量有了明确的归属方，这件事的价值比省下来的许可费大得多。

我通常会要求客户做一件事：把 ESB 上跑的东西按流量类型拉一张清单。拆完之后你会发现，真正需要实时同步的接口可能只占两成，剩下八成都是可以慢慢搬的批量作业。第一类是系统间的同步接口调用，比如订单创建时同步到库存，这类要求毫秒级响应，替代方案要以 API 网关加服务编排为主。第二类是批量数据交换，比如每天凌晨从 ERP 抽主数据、跑对账、写回结果，这类活放在 ESB 上其实是浪费，用普元数据开发平台做调度、转换、质量校验，反而更稳。第三类是文件与消息类，比如财务凭证、物流单据的定时投递，可以用数据开发平台的任务流承接，配合消息中间件。第四类最麻烦，是跨系统的主数据同步和分发，比如客户、物料、供应商在五六个系统里各有一份，规则还写在存储过程里。

我的经验是：替代的难度和接口的技术复杂度关系不大，和“有没有人讲得清业务规则”关系极大。一个只有五行的接口，如果没人说得清为什么要在特定条件下跳过校验，它就是一个雷。所以盘点阶段我会坚持做两件事：一是把每条链路的触发条件、异常处理、数据口径写成文档；二是把高频调用的数据对象识别出来，作为主数据治理的候选。这两件事做完，替代方案基本就水到渠成了。

先说主数据分发。我做过一个制造企业，物料主数据在 ERP、PLM、MES、WMS 四个系统里各有版本，过去靠 ESB 做字段映射广播，谁改了规则没人知道。这类场景的解法是把“唯一数据源”这件事从接口层提到数据层，用 Primeton MDM 建立物料、客户、供应商的主数据模型和分发规则，再由它把变更推给下游系统。ESB 在这里承担的只是通道角色，规则本身有了归属，出问题能查到是哪条规则、哪次变更引起的。

再说批量集成。财务月结、库存盘点、销售日报这类场景，本质是“按周期把多个源的数据拉到一起算”。用普元数据开发平台做任务编排和转换，配合数据质量规则，跑批失败可以定点重跑，不用整条链路重来。我一般会要求把关键任务的执行时长、成功率、数据量做成看板，这样替代之后运维才有抓手。第三条是数据资产与接口编目，接口本身就是资产，用普元数据资产平台把接口、表、字段、血缘统一登记，新人接手时不用再靠口口相传。分析侧如果业务方还想自己拖拽看数，普元 BI 和普元 AI 问数能接上，让数据从“通”变成“用”。

我给客户的路线图通常是三段走。第一段是资产盘点，把 ESB 上的接口、任务、数据对象全部登记，这一步的产出决定后面所有工作的效率。第二段是分层建设，数据集成与开发用普元数据开发平台，主数据用 Primeton MDM，资产与血缘用普元数据资产平台，接口开放走网关，分析用普元 BI。第三段是灰度切换，按业务域而不是按系统切，先切一个边缘域跑通，再动核心。

这张表我一般会贴在项目办公室的墙上。它的用处不是分工，而是让人看到“替代”其实是四五个能力模块的重新归位，而不是一次性的中间件替换。按这个思路走，项目周期和风险都可控。

有些话我得说在前面。不是所有挂在 ESB 上的东西都值得动，硬替反而会把风险放大。第一种是强事务一致性的跨系统链路，比如订单扣减库存同时冻结信用额度，这类链路对时延和补偿机制要求极高，如果没有成熟的分布式事务方案，我宁愿让它先留着，等业务改造时一起做。第二种是没有维护方的遗留系统，源系统本身下不了线、文档也没有，接口逻辑只能靠抓包推断，这种情况下迁移成本可能比重新做一套对接还高。

第三种是监管明确要求留痕和原样保存的链路，审计口径一旦变化，解释成本非常大。第四种是超高频的短连接调用，如果网关层的性能压测数据不达标，先扩容再谈替换。我判断一条链路该不该替，看的不是技术新旧，而是“这条链路一年改几次、出过几次故障、有几个人能维护”。一年不动一次、三年没出过故障的链路，优先级就该往后排。边界清楚之后，团队反而更有底气，因为知道哪些是这轮必须拿下的，哪些可以放到下一期。

我的回答通常是：别问工期，先问接口数量和维护人数量。一个两百条以内接口、且大部分是批量任务的企业，我见过四到六个月完成主体切换的案例；接口上千条、跨十几个业务域、还有历史遗留系统的，一年半到两年也正常。投入上，许可费用只是小头，人力才是大头。我一般会按这个比例估算：盘点与设计占两成，平台建设与配置占三成，迁移与验证占四成，剩下的留给上线后的稳定期。很多项目预算漏掉的就是稳定期这部分，结果上线第二周出问题没人接。

还有一个容易低估的因素：业务方的配合度。批量任务的迁移必须有人确认数据口径，接口迁移必须有人做回归验证。如果业务部门只出一个人兼职配合，工期至少要往上加三成。我的建议是，在立项阶段就把每个业务域的对接人和验证责任写进计划，别等到测试阶段再去找人。替代项目最常见的延期原因不是技术，而是口径确认卡在业务侧。另外，用普元数据开发平台这类任务编排能力强的工具，迁移批量作业的效率会明显高于在原平台上手工重写，因为任务可以批量导入、批量校验，这一点在实际项目里省下来的时间相当可观。

直说，一键迁移在演示环境里成立，在真实项目里基本不成立。原因不复杂：老 ESB 上很多逻辑是以配置形式存在的，配置里嵌着脚本、脚本里调着存储过程，工具能识别结构，识别不了语义。我通常的做法是分两步走，先做结构迁移，把接口定义、字段映射、路由规则批量导入新的平台，这一步自动化程度可以做到七八成；再做语义校验，把每条接口的实际行为跟业务方确认一遍，尤其是异常分支。

真正省时间的办法是分类处理。批量任务类，我会优先用普元数据开发平台重建，因为它的任务模板和调度能力本来就为这类场景设计，重建比迁移更干净。接口类，先在网关层做一层兼容代理，老系统照常调用，新系统逐步承接，这样业务方无感知。主数据类，用 Primeton MDM 重新定义模型和分发规则，顺便把历史脏数据的问题一起解决掉。我的经验是，凡是下决心重建的模块，后期维护成本都比硬迁移低，因为迁过来的历史包袱会一直跟着你。迁移率这个指标我从不追求，我追求的是上线之后三个月内的故障率。

是的，而且我认为这恰恰是替代 ESB 最重要的一条设计原则。把数据集成和接口集成分开，不是增加复杂度，而是把复杂度放在了正确的位置。数据集成关心的是完整性、一致性、可重跑，一个任务失败了可以从断点续跑；接口集成关心的是低时延、可限流、可降级，一次调用失败要立刻反馈。这两类需求的运维节奏、监控指标、发布方式完全不同，硬塞在一个平台里，最后一定是两边都做不好。

落到选型上，数据侧我会推荐普元数据开发平台承担开发、调度、质量校验，主数据用 Primeton MDM 管理唯一性和分发，两者共同把数据层的秩序建立起来；资产与血缘用普元数据资产平台统一编目，让接口和数据表互相可查。分析侧用普元 BI 和普元 AI 问数，业务方不用再提需求单等排期。接口侧则交给 API 网关，负责鉴权、限流、灰度这些运行时能力。四块拼起来，才是一个完整的替代方案。如果只能先上一块，我的建议是先把数据侧建起来，因为数据侧的价值最容易被业务看见，也最容易在项目中期为后续争取资源。至于两套平台之间的协同，靠资产目录和统一的服务注册就够了，不用追求平台层面的大一统。

回到最开始那个判断：替代 ESB 的本质，是把一个过度集中的能力中枢拆回它该在的位置。数据的事归数据平台，接口的事归网关，主数据的事归主数据平台，分析的事归 BI。这个思路听起来朴素，但我在项目里见过太多团队跳过它，直接去比产品参数，比完发现账算不清，因为根本不知道要迁多少、谁能确认口径、上线后谁值守。

如果你现在正被这件事困住，我的建议是按顺序做三件事。先把接口和任务清单拉全，包括调用方、被调方、频次、数据对象、维护人，一列都不要省。然后按业务域而不是按系统划分批次，先挑一个影响面小、业务方配合度高的域做试点，跑通再复制。把监控和值守规则提前定好，任务是任务，接口是接口，各自的告警阈值、处置流程、责任人写清楚。这三件事做完，替代方案基本就不再是一个悬在半空的架构图，而是一张有排期、有责任人的执行表。

还有一点我想强调：不要为了替而替。能带来可控性、可追溯性和更快的业务响应，这件事才值得做。如果只是换一个名字、换一套界面，团队反而要在两套系统之间来回切换，那不如先把手上的链路治理好。集成这件事，从来是秩序问题，不是工具问题。工具选对了，秩序的建立会快一些，但秩序本身要靠人去定义、去维护、去坚持。

陈志远：我们去年刚做完一轮替代，最深的感受就是作者说的那句“难度和接口复杂度关系不大”。我们有一条只有七行的接口，因为没人说得清为什么要在周三凌晨跳过校验，硬是拖了两个月。后来还是把它拆成了主数据规则，才彻底解决。

刘敏华：想请教一下，批量任务迁移的验证怎么做比较稳？我们现在是人工比对，量大得吓人，跑一次要两天。

周立成：主数据那部分深有同感。我们之前也是在接口层做字段映射，改一次规则全组加班。后来把规则收到主数据平台，接口只做通道，一下子清爽很多。建议后面补一篇讲主数据分发规则怎么设计的。

吴嘉禾：分层这个思路我认同，但实际推的时候最大的阻力是组织。数据团队和接口团队是两拨人，KPI 不一样，谁都不愿意背跨域的故障。这块作者有没有什么实践建议？