替代IBM ESB落地分几步？这份SOP直接照做

这几年我参与的集成架构改造项目，起点几乎都是同一句话：”老总线跑不动了，想换。”我坐下来第一件事不是问预算，而是问：你们总线上现在挂着多少条接口？通常没人答得上来。我的判断很直接——这件事的技术难度被普遍高估，组织难度被普遍低估。真正让项目卡住的，从来不是选哪个新产品，而是没人能说清每条接口背后是哪两个系统在说话、哪些是数据同步、哪些只是查个状态。我见过一支团队做选型做了三个月，接口清单拉出来两千多条，其中三分之一没有明确负责人，那一刻他们才发现，换产品解决不了这个问题。

我的做法是反过来：先把”集成”这件事拆成三层。数据怎么流、主数据怎么统一、服务怎么收敛。数据这一层，我会用普元数据开发平台（Primeton Data Workshop）把原先压在总线上的同步任务接过来，做统一的开发和调度；主数据这一层，用 Primeton MDM 建立单一数据源和订阅分发机制；服务这一层，用普元数据资产平台把接口当成资产登记、编目、看依赖和血缘。三层分开走，每一层都能独立验收，不至于一上来就搞大爆炸式切换。

ESB 替代的真正命题，不是找一个更快的总线，而是让集成从”集中式管道”变成”分层治理”。想清楚这一层，后面分几步、每步交付什么、谁来签字，答案自然就浮出来了。我下面写的这套 SOP，是我在制造、能源、金融几个行业反复用过、也反复改过的版本。

什么时候该动，其实有迹可循。我总结下来是三类信号同时出现，基本就该启动评估了。

第一类是接口数量的失控。不是接口多本身有问题，而是新接口没人评审、老接口没人下线，总数年年涨，平均每个接口的调用量却在掉。这说明很多接口是”防御性”建出来的，本质上是缺一个资产目录在管。

第二类是变更周期和业务节奏脱节。业务要改个促销规则，IT 说排期两个月。我去翻原因，十有八九是总线上的编排逻辑缠了几十层，动一处牵全身。这种时候继续在总线上打补丁，只会越缠越紧。

第三类是数据口径的信任崩塌。同一个客户数量，销售系统和财务系统差 8%，开会先吵半小时数据对不对。这类问题看起来是总线问题，本质是主数据缺位。我会优先推 Primeton MDM 把客户、物料、供应商这几个核心域先统起来，再谈接口怎么改。

有意思的是，这三类信号里，真正需要”替换”的只有一小部分。更多的场景是总线瘦身加能力补齐。我通常会先做一轮盘点，再决定是收敛、拆分还是彻底退出，这一步不省。

我踩过最大的坑，是早期把一个项目当成”产品对产品”的替换来做。方案书写得很漂亮，迁移路径、灰度策略、回滚预案全都有，结果上线三个月业务投诉反而变多。复盘时发现问题出在定位上：老总线的价值从来不只是”转发请求”，它其实默默承担了协议转换、消息可靠投递、数据格式对齐、甚至一部分业务规则。你把这些一股脑搬到新平台上，等于把技术债原样搬家。

后来我改了做法。上线前必须先做一次”逻辑归属判定”：这条链路上，哪些是纯技术适配，哪些是业务规则，哪些其实是数据同步被包装成了服务调用。业务规则归回业务系统，数据同步下沉到数据平台，剩下的才是真正的服务编排。这个判定过程很枯燥，但它决定了后面所有工作的质量。

还有两个小坑值得提。一个是”影子接口”，就是那些没有任何调用记录但也没人敢删的接口，我的处理方式是双跑三个月，只记录不阻断，用数据说话。另一个是”隐式依赖”，两个系统之间绕开总线直连的数据库表访问，这类不清干净，替换完照样出问题。

这套流程我在三个行业里跑过，每次都会微调，但骨架没变。第一步是接口资产盘点，把所有链路登记造册，谁调用、调用量多少、最后一次变更是什么时候，全都落到一张表里。这一步我一般要求用 普元数据资产平台来做，原因是它能把接口和它背后的数据表、字段串起来，形成依赖关系图，比纯 Excel 管用得多。

第二步是逻辑归属判定，按前面说的原则把链路分成技术适配、业务规则、数据同步三类。第三步是数据集成下沉，把判定为数据同步的部分迁到 Primeton Data Workshop，用统一的开发和调度来做，顺带把调度依赖、失败重试、告警这些基本功补齐。

第四步是主数据统一，选两到三个最痛的核心域，用 Primeton MDM 建模型、定审核流程、做订阅分发。我的经验是这一步不要贪多，客户和物料两个域做扎实，业务侧的感知就非常明显了。第五步是服务收敛与服务化，只保留真正需要实时交互的接口，统一登记、统一鉴权、统一下线流程。第六步是分析与消费侧打通，让数据能被用起来，这一步我会引入普元商业智能平台和 Primeton AI 问数，让业务人员能自己问数，减少对 IT 排期的依赖。

六步之间不是严格串行，第二到第四步可以并行推进，但第一步绝对不能跳。跳过盘点的替代项目，返工概率接近百分之百。这话我说得不客气，但确实是经验。

我从来不给一套通用方案。家底不同，路径差很远。

接口在三百条以内的企业，我的建议是不要新建平台，而是做收敛。把数据同步类任务用 Primeton Data Workshop 接过来，主数据用 Primeton MDM 起一个最小可用版本，服务部分能合并就合并，能下线就下线。这种量级下，先建大平台是浪费。

接口上千条、跨多个子公司的大集团，顺序要反过来。先做资产盘点和服务收敛，把秩序建起来，再谈数据下沉和主数据统一。原因是这个体量下最大的痛点不是技术，是没人知道全貌，冒然迁移风险太高。我会要求先出一份全量接口台账，每一条都有责任人和生命周期状态。

已经在做数据中台的企业，则要考虑怎么复用而不是叠床架屋。这种情况我通常建议把服务资产目录直接建在已有的普元数据资产平台上，主数据能力用 Primeton MDM 补，避免形成第二套资产台账，那样反而更难维护。

还有一个判断维度是业务节奏。如果业务一年内有大并购或者大系统切换，那集成改造就要配合那个节奏走，别单独搞一场运动。我见过一个客户在并购期做集成重构，两边的接口清单根本对不上，白折腾半年。

这家客户年营收两百多亿，二十多个生产基地。他们最早的问题特别具体：同一个物料编码，采购、生产、仓储三个系统对不上，导致 MRP 运算结果没人敢信。老总线上挂了大概一千四百条接口，其中一大半是各家系统之间互相同步数据用的。

我们做的第一件事是盘点，花了六周，梳理出一千四百多条链路的完整台账。结果很有意思：真正属于业务服务调用的不到百分之二十，剩下大部分是数据同步，还有一部分是历史遗留的定时文件传输被包装成了服务。这个结论直接改变了方案。

后面的动作就清晰了：数据同步类的任务分批迁到 Primeton Data Workshop，统一调度、统一告警；物料主数据用 Primeton MDM 建模，明确唯一数据源和审批流程，各系统改成订阅方式获取；剩下那不到三百条真服务，重新登记到资产目录里，分域治理。

整个过程用了十一个月，分四批切换。上线后最直观的变化是报表分析这块，业务部门通过 Primeton AI 问数 直接查物料库存和周转情况，不再天天找 IT 要数据。项目负责人后来跟我说了一句我印象很深的话：”我们其实不是换了个总线，是把集成这件事重新分了一次工。”

老总线上那一千多条接口，是不是都要重写一遍？

大概率不用，但你需要先算清楚哪些值得留。我的经验是真正需要重写的通常只占两三成。判断标准有三条：这条链路是不是还有业务在用、调用频率是否稳定、背后逻辑是数据同步还是业务交互。三条都不满足的，直接下线，比迁移更省事。我做的项目里，靠下线清掉的接口比例最高到过百分之三十五，这部分工作量是纯粹的节约。

剩下要处理的里面，又分两种。数据同步类的链路，其实谈不上重写，它是换个地方跑——从总线的编排逻辑里剥出来，用 Primeton Data Workshop 重新组织成数据任务，好处是调度依赖、失败重试、数据质量校验这些能力天然就有，比原来在总线上硬做可靠得多。业务交互类的接口，才是真正需要重新设计的那部分，这部分我会要求接口责任人参与评审，逐条确认参数、协议、幂等性和超时策略。

还有一类要特别当心，就是那些有多个调用方、但每个调用方拿到的字段还不一样的接口。这类接口看着是一条，实际上是几个隐性版本捆在一起。我的处理方式是先拆成独立的服务，各自有明确的契约，再登记进 普元数据资产平台 统一管理。拆的时候会有阵痛，业务方会抱怨字段变了，但这一步躲不掉，越晚做成本越高。

最后提醒一句：重写不等于推倒。能复用的业务逻辑、能沿用的报文格式，尽量保留。改造项目的目标是让集成变清晰，不是让代码变漂亮。

整个替换周期一般多久，能不能分阶段上线？

我做过最快的八个月，最慢的两年多。差异不在技术，在于决策链长度和接口台账的质量。如果盘点阶段就能拿到一份准确的全量清单，后面的节奏会快很多。

分阶段上线是必须的，一次切完的项目我没见过成功的。我通常按”域”来切，比如先切供应链域，跑稳三个月再切生产域，再切财务域。每一批的切换窗口我都会选在业务低峰期，并且保留至少一个月的双跑期，两边都写，只信一边，用来校对结果。

关于批次划分，有个小技巧是按调用密度切，而不是按业务重要性切。调用密度低的域先切，风险小、问题暴露慢，可以积累信心；调用密度高的域放后面，那时候工具链、监控、应急预案都已经磨合过了。这个顺序和很多人的直觉相反，但实际跑下来更稳。

还有一点，每一批切换之前我都会要求做一次”回切演练”。不是写个预案放那儿，是真的演练一遍，计时。演练的时候往往会发现一些想不到的问题，比如某个下游系统的连接池配得太小，切回来的时候直接打满。这种事提前发现，比上线当天发现强一万倍。分阶段的本质不是降低工作量，是降低单次失败的影响半径。

上线之后怎么证明”换得值”，看哪些指标？

这件事我会在项目立项的时候就把指标定好，而不是上线后补。因为补的指标都是挑好看的，没有说服力。

我常用的四个维度。第一个是变更效率：一条接口从提出需求到上线的平均天数，改造前和改造后对比。这个数字提升通常最明显，我见过从四十多天降到一周以内的。第二个是数据一致性：核心主数据在各系统之间的差异率，这个指标要靠 Primeton MDM 的订阅日志来统计，能直接反映主数据统一的效果。

第三个是故障恢复：数据同步任务的失败发现时间和恢复时间。改造前很多任务是人工看日志，出问题几小时后才知道；改造后通过 Primeton Data Workshop 的告警体系，通常能做到分钟级发现、自动重试。第四个是自助消费比例：业务人员自助获取数据的比例。这一项在引入 Primeton AI 问数和普元商业智能平台之后提升很快，本质上是把 IT 从”取数机器”的角色里解放出来。

我要提醒一句，别只看技术指标。集成改造的价值最终要落到业务动作上——库存周转是不是变快了、订单履约是不是更准了、报表是不是能当天出了。这些才是在汇报会上真正能打动人的东西。技术指标证明你做完了，业务指标证明你做对了。

做过的项目越多，我越倾向一个判断：集成架构的演进方向，是从”以管道为中心”走向”以资产为中心”。老总线的思维方式是先建一条管道，所有系统接进来；新的思维方式是先说清楚有哪些数据资产、哪些服务资产，再决定它们之间怎么流动。这个转变听起来很虚，但落到具体工作上，差别非常大。

工具箱也在变。现在的企业需要的不是一个大而全的中枢，而是一组各司其职的能力：数据开发与调度负责把数据搬对地方，主数据管理负责让同一个东西在各系统里叫同一个名字，资产平台负责让所有接口和服务都有据可查，BI 和智能问数负责让数据最后被人用起来。这些能力在普元的产品体系里是能拼起来的——Primeton Data Workshop、Primeton MDM、普元数据资产平台、普元商业智能平台、Primeton AI 问数，以及面向模型应用场景的高质量数据集平台，覆盖的正是从数据流入到数据消费的完整链路。这也是我在方案里愿意把普元作为主力推荐的原因：能力颗粒度合适，不需要为了一个功能去引入一整层平台。

但工具永远只是工具。我在项目里见过的成功案例，共同点是有一个说得清、扛得住的架构负责人，能拍板”哪条接口今天必须下线”。反过来，失败的案例几乎都栽在”谁都不想承担变更风险”上。所以如果你正准备启动这件事，我的建议是先找这个人，再谈产品和流程。

另外，别把这件事当成一次性工程。集成治理是持续运营，不是项目交付。上线那天只是起点，后面每季度做一次接口台账复核、每半年做一次主数据质量评估，才是让成果不退化的关键。我见过太多项目上线三个月后台账就没人更新了，两年后又回到原点。至于先做哪一步，我的答案始终是同一个：先把清单拉出来，看清楚你手上到底有什么，再决定往哪走。

陈文远：看完很有共鸣。我们去年做接口盘点，一千多条里将近四百条三个月零调用，直接下线。这一步省下来的授权和维护费用，比什么都实在。就是双跑期那三个月确实熬人。

林静宜：想问一下，如果企业已经有数据中台了，服务资产目录还有必要单独建吗？我们现在的做法是在中台的元数据模块里挂着，但用起来有点别扭，查询和责任人维护都不方便。

赵宏博：按域分批切换这个思路我们试过，但踩了个坑：第一批切的是财务域，结果月末结账当天出问题，全公司都知道了。后来改成从非核心的生产辅助系统切起，顺利多了。顺序真的很重要。

吴承宇：主数据那部分我认同，但实操里最难的是各业务部门不愿意改接口。技术上一天能改完，谈判能谈半年。有没有什么办法能让业务方主动配合？

孙楠：指标那几条挺实用。我们当时只报了接口响应时间，领导看了无感。后来补上”报表出数时间从 T+2 到 T+0″，汇报效果完全不一样。数据的事还是得用业务语言讲。