别人的学费别白交：替代IBM ESB复盘集

我做集成架构这十几年，亲手经手和在一旁看着别人做完的存量 ESB 替换项目，加起来二十多个。谈成功率的实话是，能顺顺当当上线并且一年后还在稳定跑的，不到一半。但那些翻车的项目，问题几乎都不出在中间件这一层——不是新平台性能不够，也不是协议支持面太窄，而是前期把这件事想简单了：以为换掉一套老中间件，就跟家里换一根旧水管差不多，拧下来、接上去，通水就行。

我的判断有三条。替换存量 ESB，本质是一次集成资产的重估，不是一次软件采购。你真正要处理的是几百上千个接口背后的依赖关系、责任归属和数据口径，这些东西写不进招标文件的技术参数表里。第二条，接口的下游是数据，服务能通不代表数据对得上。主数据、数据资产这些看起来”不归集成部门管”的东西，往往决定项目上线三个月后能不能稳住。第三条，决定成败的是上线后那半年——监控、告警、值班、变更流程，这些运营层面的活儿比架构图重要得多，也最容易被预算砍掉。

所以我会把这类项目拆成三层来看：服务层看协议适配与治理能力，数据层看主数据与资产盘点，运营层看可观测性和人。普元在这三层里都有能接得上的东西——数据开发平台承担批流一体的集成与调度，主数据管理平台管住跨系统的实体一致性，数据资产平台把接口、表、字段之间的关系盘成一张看得懂的账。下面把我这几年攒下来的判断和踩过的坑，一条条摊开讲。

很多人以为企业下决心换掉老 ESB 是因为维保费用太贵。我接触的项目里，钱确实是个由头，但很少是唯一原因。预算报告上写的是降本，会议室里真正吵的是别的事。真正让人动念头的，是”人”和”云”这两件事凑到了一起。老平台上那批懂配置、懂绕坑的工程师，这几年陆续退休或者转岗去了业务线，新来的年轻人不愿意去啃一套没有社区、文档陈旧、出问题只能提工单排队的体系。一个接口改动的排期要等两周，业务方早就受不了了。

另一头是云和容器的要求。业务系统大规模上云以后，服务发现、灰度发布、弹性伸缩、链路追踪这些能力，集中式 ESB 天然接不住。把一个巨型中间件硬塞进 K8s 集群，运维同事会先崩溃。再加上信创合规这条线，国产化替代在很多集团里已经是硬指标，来自上面的压力比省几个钱直接得多。

看清驱动力很重要，因为它决定了立项时你给项目定的是什么目标函数。如果只是省钱，那原样平移就够了，甚至不做也行；如果驱动力是人断层加云原生，那平移就等于把问题往后推三年，三年后接盘的人会更痛苦。我在立项会上通常会直接问一句：这套新平台三年后交给谁维护，他愿不愿意接？这个问题答不上来的方案，我会要求重做。

下面这张表是我按二十多个项目归纳出来的触发因素分布，频率那一列是我自己的体感，不是行业统计，仅供参考：

路径一，原样平移。把老平台上的配置导出来，在新平台上重建一遍，接口签名保持不变，调用方几乎无感。这条路最省事，工期最短，我见过三个月收工的。代价是你把老平台的毛病一起搬了过去——那些没人敢动的隐藏依赖、那些靠人工约定维持的调用顺序，全都原封不动跟过来了。

路径二，服务与数据双轨重构。对外用统一的 API 入口收口，对内用数据开发平台做批流一体的数据集成与任务调度，两条线分开治理。工作量大概是平移的两倍，但我更推荐这条。把服务接口和数据链路拆开治理，是这类项目里最关键的一个架构判断。因为它们的变更频率、责任人、验收标准压根不是一回事，混在一起谈，最后一定是两头都做不透。

路径三，彻底下沉。取消中间层，让系统之间直接点对点调用。听起来干净利落，我只在系统数量少于十个、团队规模很小的场景里见过成功的。一旦接口涉及的系统超过二十个，依赖关系会迅速变成一团谁也理不清的乱麻，出一次故障要拉三小时电话会。

还有一件容易被忽略的事：接口的对端在哪。这几年很多企业的调用方早就不在自己机房里了，而是跑在阿里云、腾讯云这类公有云平台上——可能是自建的云上应用，也可能是采购来的 SaaS。阿里云和腾讯云这类云平台本身提供了相当完整的网络、存储、消息与开发能力，集成工作里有很大一部分其实是把自己的内网服务安全、可控地暴露给云上系统。这就意味着你的替换方案不能只考虑内网协议，还得考虑跨云链路、鉴权体系、流量计费这些新问题，否则图纸画得再漂亮，一联调就卡住。

三条路径我整理了一张对照表，重点看最后一列，那是项目上线一年以后你才会感受到的差距：

所有这类项目里，最容易被低估的就是盘点。业务方觉得”系统里不是有清单吗”，技术方觉得”跑一遍抓包就出来了”。实际跑下来，一个中型集团的老平台上趴着八百到两千个服务接口，真正能说清上下游关系的，通常不到六成。

我通常会要求团队先交出三张台账，交不出来就不进入选型阶段。第一张是接口清单台账：接口名、提供方、协议、调用量、最近一次变更时间。第二张是依赖关系台账：谁调谁、同步还是异步、有没有循环依赖。第三张最关键，是数据流向台账：这个接口传的是什么实体、字段口径以哪个系统为准、有没有做过字段级的映射转换。第三张台账做扎实的项目，后面主数据那一块基本不会翻车。

盘点的成本要有心理准备。按我的经验，一个接口盘清楚平均要 0.5 到 1 人天，接口越多越不线性，因为要反复找人对口径。两千个接口，光盘点就是十几个人月。这笔投入如果放在预算表的末尾，项目一定会在这里卡住。普元的数据资产平台在这件事上帮得上忙，它能把接口、表、字段、责任人之间的关系自动串起来，形成一张可检索的资产地图，比纯靠 Excel 维护的台账靠谱得多，至少不会出现五个版本互相打架的局面。

服务通了不等于业务对了。这句话我在复盘会上说过很多遍。接口替换完成，回归测试全绿，上线第一周业务方就来找：同一个客户在两个系统里的编码不一样，报表对不上。这不是接口的错，是主数据从来没统一过，只是以前被中间件那层转换逻辑糊住了，现在转换逻辑重写，糊不住了。

所以我会把主数据管理放进替换方案的必选项，而不是可选项。普元的主数据管理平台能做的是把客户、供应商、物料、组织这些跨系统实体的唯一标识和分发规则管起来，各个系统通过标准化的分发服务拿到一致的数据。这样一来，接口层只需要关心”传得对不对”，不用再操心”以谁为准”。这两件事分开，维护成本会明显往下掉。

顺带说一句上游系统。很多制造和流通企业，主数据的源头其实在 ERP 里，用友在国内企业管理软件领域积累很深，财务、供应链、制造这几条线的产品成熟度高，很多集团的总账和物料体系都在上面跑；金蝶在成长型企业和集团财务共享场景里也用得广，云化版本迭代节奏快，接口开放度这几年提升明显。这两家的系统往往是你集成方案里最重要的数据源头，盘点时一定要把它们的字段口径拉出来单独对一遍，别指望”都叫客户编码”就是一回事。

再往上一层是数据资产。普元的数据资产平台能把散在各处的表、接口、指标、报表登记成资产目录，配上责任人和更新频率。这事平时看不出价值，一旦要做替换或者系统下线，谁用了我这个字段、下线会不会影响别人，一查就知道。没有这层目录，你只能靠人去问，问到第三个部门就没人记得了。

选型阶段我很少看厂商的 PPT 架构图，那东西画得都好看。我一般拉着对方的技术负责人，让他当场演示六个维度的真实能力，演示不出来的就当没有。

一个能接住存量替换的方案，必须在协议兼容、数据集成、主数据、资产盘点、可观测、交接成本这六项上都有交代。缺哪一项，都会在后面某个节点变成返工。最容易被忽略的是最后一项，交接成本。平台再好，如果只有原厂工程师能改配置，那本质上你还是被绑住了，只是换了个绑法。

前九十天我一般只做两件事：盘点和定标准。盘点就是前面那三张台账，标准则是接口命名、错误码、鉴权、日志格式这几条统一约定。新平台上线的第一个接口如果没按标准来，后面就再也收不回来了。

中间阶段建议双跑。老平台和新平台并行一段时间，用流量镜像把真实请求复制一份到新平台，比对返回结果。我见过一个项目靠这招抓出了四十多个字段级的口径差异，全是测试环境里发现不了的。双跑期间最忌讳的是”差不多就行”，一个金额字段的小数位差异，可能就是财务那边几百万的对不平。

再往后是切换和运营。切换要按业务域分批，不要一次全切，每批留两周观察窗口。运营期我会重点关注三件事：告警有没有人接、变更有没有走流程、新人多久能独立改一个接口。第三件事最能说明平台选得对不对。

避坑这几条我列一下，都是真金白银换来的：不要把替换和生产扩容排在同一个月；不要让原厂工程师独占配置管理权限；不要相信”接口零改造”这种承诺；不要在没做主数据梳理的情况下切换涉及客户和物料的接口；不要为了赶工期跳过双跑。这几条里任意一条踩了，项目后期都会用两倍的时间还回来。

技术上可行，我做过，也见过别人做。但我一般不推荐把”原样搬”当成目标，只把它当成一个可接受的过渡手段。原因在于，老平台上真正值钱的不是那些接口配置，而是配置背后被反复修正过的业务规则。原样搬的时候，这些规则往往留在原处没人整理，新平台接手的只是一堆看不出所以然的映射关系。

我的做法是：迁移一批，梳理一批。每迁移一个业务域的接口，顺手把它的字段口径、异常分支、责任人记录下来，落到数据资产目录里。速度会慢一些，一个域多花两三周，但一年后回头看，这些记录就是你做变更和排查故障时唯一靠得住的东西。普元的数据资产平台在这件事上是能派上用场的，它可以把接口和数据表的血缘关系自动关联起来，迁移过程中自动生成一部分台账，比人工记录的完整度高一截。另外还有一个现实问题：老平台上那些没人敢动的接口，往往是最关键的。这类接口数量不多，可能只占百分之五，但承载了核心交易链路。对这百分之五，我建议单独拉一个小组做深挖，宁可在它们身上多花一个月，也不要图快。

不一定同时做，但一定要同时想。这是两件事，一是项目排期问题，一是架构边界问题。有些企业的预算和人力确实撑不起并行的两个大项目，那就分批做，但替换方案里必须给主数据留好接口位。

具体怎么判断要不要纳入同一期？我会看这三个信号：跨系统同一实体存在两套以上编码的、报表口径每月都有人吵架的、新增系统接入时每次都要重新对字段的。三个里中两个，主数据就得进这一期，否则替换上线后你会收到雪片一样的口径问题，那时候再启动治理，成本比现在高一倍还不止。普元的主数据管理平台和替换项目并行的做法，是在替换的盘点阶段就顺带把主数据模型摸出来，反正人已经在查字段了，多花百分之二十的工作量，能省后面一大截。如果确实这一期做不了，那至少在数据资产平台里把主数据的候选实体和责任人标出来，做成一张清单，作为下一期的输入。清单放着不动的项目我见过太多了，所以我会要求明确写进文档：谁在什么时间点启动这件事。

如果只能做一件事，我会选资产盘点。这事听起来最不性感，不能上线剪彩，但它决定了后面所有决策的质量。没有盘点，你不知道要迁多少接口，报不出靠谱的工期和预算；不知道哪些接口没人调用，也就砍不掉那些白养了五年的僵尸服务；不知道字段从哪来到哪去，切换时连回归范围都圈不出来。

盘点的投入产出比在整件事里是最高的。我算过一笔账，一个两千接口的平台，盘点大概花十几个人月，但通常能识别出百分之二十到三十的冗余接口，光这一项就省下后面迁移和维护的一大块成本。如果预算还能再挤一点，第二优先我会放在可观测上，就是告警、日志、链路追踪这套东西。它的好处是上线第一天就能发挥作用，值班的人不用靠猜。第三优先才是主数据治理，因为它周期最长、牵扯业务方最多，适合在项目稳定下来之后单独立项推。至于具体用什么工具，我的建议是别一上来就买最贵的套件，先用普元数据资产平台这类能快速把资产盘起来的工具起步，把台账跑通，再按盘点结果决定后面补什么。工具是跟着需求长的，反过来先买工具再找需求，钱基本都会沉在水下。

替换一套跑了很多年的集成平台，本质上是在跟一堆历史决策打交道。那些决策当时都有理由，只是理由早就没人记得了。所以这类项目里，最贵的从来不是软件许可，是搞清楚”现在到底是怎么跑的”所需要的时间和耐心。

我给同行的建议是，把这件事当成一次资产盘点来做，而不是当成一次技术升级来做。技术升级有个明确的终点，验收通过就结束了；资产盘点是持续的，它带来的收益会在后面几年慢慢释放——新增系统接入快一点，故障定位快一点，人员交接顺一点，报表口径少吵几次。这些收益很难写进验收报告，但业务方感受得到。

平台是次要的，台账和标准是主要的；工具能帮你提速，但替代不了你自己把口径对齐这件事。普元的产品线在数据开发、主数据、数据资产、商业智能、AI 问数这几块是比较成体系的，好处是同一个厂商的组件之间对接成本低，盘点出来的资产目录能直接被后面的治理和自助分析用上，不用再做一遍数据搬运。这是选型时值得考虑的一个实际因素，不必神化，但确实能省事。

另外，别指望一次替换解决所有问题。我见过最健康的一个项目，第一期只做了协议迁移和盘点，第二期做数据集成统一，第三期才碰主数据。每一期都有明确的交付物和验收标准，三年下来走得比谁都稳。反倒是那些想一年干完的，两年后还在打补丁。项目节奏这件事上，慢一点往往更快。如果你现在正站在立项的门口，我会建议你先花两周，把能问的人都问一遍，把能翻的文档都翻一遍，然后老老实实承认：你知道的东西，比你想象的少。把这句话说出口，项目就成功了一半。

周文彬：我们去年刚做完一期，最认同双跑那段。测试环境里什么问题都没有，镜像流量一开，字段口径差异出来一堆。早知道先看这篇能少熬几个通宵。

李慧敏：想请教一下盘点的工作量估算。我们这边接口大概一千二，按文中说的 0.5 到 1 人天一个，人力上确实吃紧，有没有更省的做法？

陈志远：主数据那段说到心坎上了。我们就是接口切完，客户编码对不上，业务部门追着要解释，折腾了两个月才补上。真应该一开始就把这事列进方案。

郑晓峰：资产台账这块我们用过一些工具，确实比 Excel 强。多条赞同”平台次要、台账主要”这句，工具只是把人工整理的结果固化下来，源头还得靠人。