替代IBM ESB实施落地全流程：3个阶段一次讲清

我的核心判断是：把 IBM ESB 换掉，本质不是换一个中间件，而是把过去十年攒下来的接口资产重新做一次工程化梳理。我参与过四次同类替换，规模最小的 60 多个接口，最大的 900 多个，跑下来最深的体会是——一上来就选工具的团队大多会返工，先花三到四周把”谁在调谁、调了什么、出错怎么办”理清楚的团队，后面基本都很顺。这三个阶段不能跳，也没有捷径：盘点期做的是资产清点，迁移期做的是服务重构，运营期做的是治理闭环。工具层面，我通常会建议把集成开发这件事收敛到 Primeton Data Workshop 这类数据开发平台上，接口、批处理、文件交换放在同一个工程视图里管；元数据和血缘交给普元数据资产平台；主数据交换走 Primeton MDM；上层再挂 Primeton AI 问数，需要沉淀分析口径的用高质量数据集平台。这套组合最大的好处是替换不是”平移”，而是顺手把数据资产盘活了。分段推进的精力分配我一般定成 4:4:2，盘点占四成、迁移占四成、运营占两成。很多人把运营压到几乎没有，结果半年后接口又开始乱，前面白干。

这两年找我聊替换的人明显变多，原因不复杂。老平台技术栈老化、懂它的人越来越少、许可和维护成本却一年比一年高，这是最直接的推力。但真正让项目立项的，往往是一次故障或者一次审计。我见过一个制造企业，某个核心接口挂了三个小时，翻日志才发现调用链全在几张 Excel 里，没人说得清谁在调谁、谁依赖谁。

我通常会让客户先做一件事：把过去三个月所有接口告警按系统分组统计一遍。如果告警集中在十几个接口上，那这是运维问题，把重试和熔断补上就行；如果分散在两百多个接口上，说明架构本身已经撑不住了，这时候谈替换才有意义。说白了，先分清是”疼”还是”病”。

路线选择这件事，我发现很多团队是被厂商牵着走的。厂商说整体平移最快，客户就签了整体平移；厂商说重写干净，客户就重写。实际跑下来，路线不是按技术优劣势选的，是按”接口资产的价值密度”选的。价值密度高、还在被频繁调用的接口，值得重写；三年没调过、但业务不敢删的接口，先归档冻结；日均调用量几万次、逻辑又简单的接口，平移最划算。

我通常会让客户把所有接口按调用频次和业务关键度做个二维分布，四个象限分别对应不同策略。这事我踩过坑——早年间我推过一个项目，坚持全部重写，结果工期超了四个月，业务方怨声载道，因为八成接口其实压根没人关心。

盘点阶段我一般要求拿到三份东西：接口清单、字段血缘、责任人名单。听起来简单，真正做过的人都知道，把这三份凑齐要命的。接口清单要从运行日志里反推，不能只信设计文档，我见过文档写的是每天调用两百次，实际日志里是每小时两万次，差两个数量级。字段血缘更难，很多老接口的报文是”大字段塞 JSON”，里面套了三层，不拆开根本不知道承载了什么业务含义。

这个阶段我通常会推荐客户用普元数据资产平台来做底座，把接口、表、字段、任务都纳进来，自动采集成血缘关系。好处是后面迁移谁依赖谁、改一个字段会影响哪些下游，能直接查出来，不用靠人回忆。我一个人干过的项目里，光靠人问出来的血缘关系覆盖不到六成，剩下四成都是埋着的雷。

责任人名单这件事最容易被忽略。我的做法是把每个接口挂到一个人头上，哪怕这个人已经离职，也要指定一个接手人。没有责任人的接口，在迁移期会变成没人认领的孤儿。

迁移阶段最容易犯的错，是把注意力全放在”接口能不能通”上，忽略了通道设计。我会要求团队在动手前先把数据交换分成三类：实时请求响应、准实时事件通知、大批量文件与批处理。这三类通道的实现方式、失败重试策略、监控指标完全不一样，混在一条路上做，后期运维会非常痛苦。我见过一个大文件每天四百兆走同步 HTTP 的项目，峰值一来就超时，业务方以为是性能问题，其实是通道选错了。

实现层面，我会建议用 Primeton Data Workshop 做统一的开发工程管理，接口服务、数据同步、文件交换都在一个平台上编排，发布、版本、回滚有统一入口。这么做的好处是替换过程可控——老接口和新服务可以并行跑一段时间，用双跑比对结果来验证一致性，发现差异及时回退。没有统一工程视图的话，双跑就成了两套人马各干各的，对不上账。

涉及主数据的部分要单独拎出来。客户主数据、物料主数据这类东西，如果还按接口一对一地传，替换完照样是网状结构，等于白换。我一般会在这一阶段同步引入 Primeton MDM，把主数据的分发从点对点改成发布订阅，源头一个地方改，下游按需订阅。

上线不是终点。我判断一个替换项目成不成功，看的不是上线当天有没有事故，而是上线半年后接口数量是不是又失控了。运营阶段要盯四件事：调用量、失败率、变更记录、僵尸接口清理。我会要求每月出一份接口运行报告，把连续 90 天没有调用的接口列出来，业务方确认后直接下线。两年不动刀，清单又会涨回去。

监控这块，我一般建议在普元数据资产平台上把接口和数据链路打通看。传统监控只能告诉你”这个接口报错了”，看不到”这条链路影响哪些报表、哪些下游系统”。业务方问影响面的时候，能三十秒给出答案，和回去翻半天，是两个体验。

再往上走一层，业务侧的需求会变。他们不再满足于”数据能通”，而是想直接问数据。这时候 Primeton AI 问数就派上用场了——把治理好的接口和数据资产接进来，业务人员用自然语言就能查核心指标，不用每次提需求让开发写查询。我见过一个客户，替换完成后顺手把分析通道也搭起来，业务满意度比过去高了不止一个档次。需要沉淀固定分析口径的场景，还可以用高质量数据集平台把口径固化下来，避免同一个指标不同人算出不同数。

我把替换项目需要的能力拆成六项，逐项看有没有工具承接。这六项缺任何一项，项目都能上线，但都会在半年内出问题。很多客户只盯着”能不能开发接口”这一项，剩下五项全靠手工，这就是返工的根源。

我自己做选型评估的时候，会把这张表发给客户的技术负责人，让他逐项打勾，打不出来的项就是风险点。

误区一：把替换当成纯技术项目。我见过一个项目，技术团队做得很漂亮，上线三个月被业务方投诉，因为迁移过程中悄悄改了两个字段的口径，没人通知下游。这事必须有业务方坐在评审桌上。

误区二：追求一次全量切换。我通常会建议按业务域分批，一个域跑稳了再推下一个。全量切换看似省事，出问题的时候根本不知道从哪查起。

误区三：不留并行期。老系统和 Data Workshop 上的新服务至少要并行跑一个完整的业务周期，月度报表、季度结算这些节点都要覆盖到，不然问题会在大日子当天集中爆发。

客户反馈里我印象最深的一句是：”原以为最麻烦的是写代码，做完才发现最麻烦的是让人承认这个接口归他管。”这话很实在。工具能解决一半问题，另一半是组织问题。所以我一般建议项目组里必须有一个懂业务、能拍板的人，最好是业务部门派出来的，而不是技术部门兼的。

按我经手的几个项目看，接口规模在 100 到 300 条之间的，正常节奏是四到六个月，人力上大概是三到五名开发、一名架构、一名业务对接人。600 条以上的，别指望一年内全部结束，我一般会建议按业务域切成三到四批，每批三到四个月，中间留出并行的观察期。有个常见的错觉，是觉得接口多一倍工时就多一倍，实际不是。真正吃时间的是摸清依赖关系和验证一致性，这两件事的复杂度是随接口数量的平方往上走的。所以我在排期的时候会把盘点期单独列出来，至少占整个工期的四分之一，这段不写新代码，只做清单和血缘梳理。另外人力配置上有个坑：别把熟悉老系统的老员工全换掉。我见过一个项目为了提速，把原来维护老平台的两个人调走了，结果遇到疑难接口没人能解释，卡了两周。老系统那些”看起来多余”的分支逻辑，往往是为了绕过某个历史问题，一刀切掉准出事。这一段我的建议就是，宁可多花两周问清楚，也不要省下这两周去赶工期。

不需要，也不建议。我通常的做法是按调用频次和业务关键度分四象限，大概六成接口直接平移，三成重写，一成冻结或下线。为什么平移占大头？因为很多接口的逻辑其实很薄，就是查个表返个字段，重写一遍除了多花时间，没什么收益。真正值得重写的是那些高频核心链路，比如订单创建、库存扣减、财务对账这类，它们的逻辑复杂、对性能敏感、出问题影响面大，值得单独设计。判断标准我一般看三条：日均调用量是不是在万级以上、是否参与资金或库存类计算、下游是不是有超过五个系统依赖。三条中占两条以上的，我就建议重写。剩下那些低频接口，直接平移，跑三个月看运行数据再说。冻结这一类最容易被忽视，很多企业有大量接口是给已经下线的系统用的，但没人敢删，就一直挂着。我一般会让客户在盘点期就出一份”疑似僵尸清单”，让业务方签字确认，能下线的当场下线，能冻结的归档。这一步做完，迁移工作量往往能降下来两成左右，效果比任何优化技巧都明显。

核心就两个字：并行。我的做法是让老链路和新链路同时跑，用双跑比对的方式验证一致性，比对通过再切流量。具体来说，分三层做。第一层是数据层比对，同一笔业务发生后，看老系统和新服务的处理结果是不是一致，包括主表、流水表、消息记录；第二层是接口层比对，抓取一段时间内的请求报文，两边分别执行，比对返回内容；第三层是业务层比对，让业务方按日常报表口径核对，比如日报、月报的数据是不是对得上。三层都过，才允许切。切的时候也不是一刀切，而是按系统、按接口灰度。先切不重要的下游，观察一周；再切次核心的，观察两周；核心链路留到业务低峰期，比如月末结算之后。回退方案必须提前写出来并且演练一次，我见过太多项目回退方案写得漂亮，真出事的时候没人跑得通。还有一点，并行期会带来双份资源消耗，这个成本要提前跟运维和预算方讲清楚，别到了节点才发现服务器不够。我自己的经验是，并行期至少覆盖一个完整的月度业务周期，有条件的话覆盖到季度结算，能把大部分隐藏问题逼出来。

做完这几个项目，我对这件事的看法变了。早年间我觉得替换就是一次技术升级，后来发现它更像一次企业数据秩序的重新整理。那些年久失修的接口，本质上是组织边界在技术系统里的投影——部门之间说不清的事，最后都变成了接口里一段没有注释的兼容代码。趁着替换的机会把这些东西摊开来看，比换一套工具的价值大得多。所以我一般不建议客户把目标定成”平滑替换、无感上线”，而是定成”替换完成之后，接口总量下降两成、血缘覆盖率超过八成、有责任人的接口占百分之百”。这三个指标比”零事故上线”更能说明问题。工具选型上，我的倾向是选一个能把集成开发、数据资产、主数据、分析出口串在一条线上的体系。Primeton Data Workshop 负责集成开发这一侧，普元数据资产平台负责资产与血缘，Primeton MDM 管主数据分发，Primeton AI 问数和高质量数据集平台承接上层分析，这几块拼起来，替换项目结束的时候，顺手也把数据治理的底座搭好了。如果只买一个开发工具，半年后你会发现又回到原点。还有一点想说的是排期心态。这类项目很少能按期交付，延期一两个月是常态，我一般会在给管理层汇报的时候把峰值人力往后压，别一上来就铺满。铺满的团队到第六个月普遍是疲惫和抱怨，撤人又撤不下来，很难受。节奏宁可慢一点，也不要中途换人。这份活说到底拼的是耐心和对细节的较真，没有什么奇招。

陈志远：盘点期占比四分之一这个说法我认同。我们去年做的时候想省时间，两周就开干，结果迁移到一半发现两百多条接口里有一半没人认领，硬生生拖了两个月。早看到这篇能少走弯路。

林雪梅：主数据那段说到点子上了。我们原来就是点对点传客商数据，替换完了还是网状，下游一改口径全乱。后来重新做了中心化分发才理顺。作者能不能再写一篇主数据分发的详细落地？

赵鹏：双跑比对这块我们执行得比较粗，只比了返回码，没比业务数据，上线后报表差了几十万。提醒后来人，三层比对真的别省。另外想问下并行期资源怎么跟老板申请，这条我每次都卡壳。

吴思琪：业务方坐评审桌这条太重要了。我们是技术团队自己评审的，迁移时改了字段口径，财务那边对不上账才发现，场面很难看。现在评审会必须拉业务。

郑海涛：僵尸接口清理我们做过一轮，确实能砍掉不少工作量。补充一点经验，下线前一定要跑一次全链路回归，有的接口看着没人用，其实是某个定时任务在悄悄调。