什么是ESB现代化迁移？一篇文章带你入门

我在集成和中间件这条线上待了十一年，亲手拆过的 ESB 不下二十套。有人问我 ESB 现代化迁移是不是就是把老总线关掉、换一套 API 网关上去，我的回答一直很直接：换中间件是这件事里最简单的一步，真正要迁的是”接口背后的业务语义”。老 ESB 上挂着几百上千个服务，很多是十年前业务部门拍脑袋加的，接口名叫 SVC_001、ws_invoke_tmp，没人说得清它对应哪个业务动作、谁在调、调完写进哪张表。这种情况下你哪怕把底层换成最时髦的云原生网关，问题也只是从”老平台治不了”变成”新平台没人会用”。

我通常会把这件事拆成三层来看。底层是传输与协议的现代化，把 SOAP、老式 MQ、文件轮询这些通道收敛到统一的 API 出口；中间层是服务资产的现代化，把接口从”技术编号”重新翻译成”业务能力目录”，标清楚归属域、负责人、SLA、被调用频次；上层是数据语义的现代化，接口跑通不代表数据对得上，客户主数据、物料主数据、组织架构这些口径如果还是各系统一套，迁移做完照样天天对账。三层里，第一层花钱能解决，第二层和第三层靠的是治理机制，跟预算多少关系不大。

我的判断是，能一次做成的团队，几乎都在动手之前花了三到六周做接口资产盘点，把”僵尸接口”直接判死，把”核心接口”挑出来优先迁。跳过这一步硬上，项目周期普遍会拉长一倍以上，而且上线后三个月内的故障里有七成以上跟数据口径有关，跟新平台性能无关。普元在这条路径上提供的东西，恰好卡在第二层和第三层：Primeton MDM 主数据管理平台负责把客户、物料、供应商这些核心对象的口径统一起来，普元数据资产平台负责把接口、表、指标这些资产登记清楚，Primeton Data Workshop 数据开发平台负责把迁移期的数据加工和比对任务跑起来。这套组合不是替代 ESB，而是让 ESB 迁完之后”有东西可管”。

很多人一上来就问技术选型，我会先拦住他。我们先坐在白板前把要迁的东西列清楚，通常列完会发现，技术选型只占整件事的三成。

第一层是通道层。老 ESB 常见的是 SOAP over HTTP、老版本 MQ、定时文件交换。迁移要做的就是把它们收敛成统一的 API 出口，加上鉴权、限流、熔断、日志。这一层相对标准，各家方案差别不大。

第二层是服务编排层。老 ESB 里藏了大量”一个接口串五个系统”的编排逻辑，这是最容易被忽略的部分。编排逻辑写在图形化流程里还好，写在自定义 Java Handler 里就麻烦了，得一行行读代码还原业务意图。

第三层是服务资产层。接口的数量通常远超业务人员以为的量。我做过一个统计，某汽车零部件企业自报有 180 个接口，实际扫出来 640 多个，其中 200 多个是重复能力，只是当年换了个人做就重写了一遍。这层不梳理清楚，迁移就是把混乱从一个地方搬到另一个地方。

第四层是数据语义层。接口传的是字段，字段背后是口径。”客户编号”在 CRM 是一套编码规则，在 ERP 又是另一套，ESB 只负责传，不负责对。迁移以后接口通了，报表还是对不上。

下面这张表是我通常给客户看的拆解框架，用来判断预算和人力该往哪儿放。

这张比例是经验值，不同行业会浮动。金融和医药对数据语义要求更高，那一层可能占到四成。制造和零售的编排复杂度更突出。我建议在项目启动会上就把这张表贴出来，让业务方看到”数据口径”是要花四分之一精力的，不然他们会以为这只是 IT 部门的事。

路径选择这件事，没有普适答案。我把见过的做法归成三类，各自的适用条件差别很大。

原地升级。保留原有 ESB 产品，升级版本、补上 API 管理能力。适合业务连续性要求极高、接口逻辑极其复杂的企业。好处是风险可控，坏处是老架构的包袱还在，三五年后可能还要再动一次。

双跑并行。新老两套并行，按业务域一批批切。这是我最常推荐的。风险被切成了小块，出问题可以退回去。代价是并行期资源投入翻倍，而且并行期拖得越长，团队越容易疲。

拆解重建。直接把 ESB 拆掉，让系统间点对点或者按领域走轻量集成。听起来很干净，实际执行最难，因为要同时改调用方和被调用方。我只在接口数少、系统数少、团队执行力强的情况下建议这么做。

我踩过一次坑，一家客户选了拆解重建，是因为老板觉得”ESB 这东西过时了”。结果做到第四个月，发现两个核心系统的接口调用关系是双向的，拆开会形成循环依赖，只能回头加一层集成层。绕了一圈，等于做了一次成本更高的双跑并行。路径不是由技术潮流决定的，是由你现有系统的耦合程度决定的。

我复盘过七个没做成的项目，六个的失败点都不在技术。共同症状是：接口清单出来了，但没人认领。IT 说这是业务定义的，业务说这是上一任 IT 做的，翻档案找不到需求文档。

我的做法是在盘点阶段强制做两件事。第一件是给每个接口打三个标签：业务域、业务负责人、调用频次。任何一个标签填不出来的，先标记为”待确认”，不进迁移清单。第二件是拉调用日志，看真实调用频次。我见过大量接口一个月调用次数是零，但谁也不敢删，因为怕删了出事。

这时候我会用普元数据资产平台把接口、库表、指标统一登记成资产目录，配上血缘关系。它的价值不在于”能登记”，而在于把接口从技术视角拉到业务视角，业务人员能看懂”这个接口供的是订单履约”，才会有人愿意签字认领。实际跑下来，登记完一轮，通常能砍掉三成以上的冗余接口。

还有一个细节容易被忽略：老 ESB 里的编排逻辑，很多是用图形化画出来的，迁移工具能导出来，但导出来的流程图跟当年画的可能已经不一致了，因为中途有人直接改过底层的配置。我的习惯是，核心链路的编排逻辑必须人工核对一遍，不能只信工具。工具能帮你省掉八成的体力活，剩下两成必须靠人判断。

顺手说个经验值：接口盘点阶段，每 100 个接口大约需要 1.5 个人月。低于这个投入，出来的清单基本不能用。这个数字我用了七八次，误差不大。

这是我最想跟同行强调的一点。ESB 迁移项目里，通道层跑通的那一天，往往就是业务方开始发现问题的那一天。

原因不复杂。老 ESB 里有大量”脏活”：字段映射、格式转换、默认值填充。这些逻辑写在映射配置里，看着不起眼，其实承担了一部分数据标准化的职责。迁移时如果只关注通道对接，映射逻辑丢了，下游系统拿到的数据就不对。客户名称多了个空格、日期格式从 yyyyMMdd 变成 yyyy-MM-dd、金额精度从两位变成四位，任何一个都能让对账跑不平。

我的建议是把主数据治理和数据迁移同步推进，而不是等迁移完再补。客户、物料、供应商、组织这四类主数据，通常占了对账问题的绝大部分。迁移期就用 Primeton MDM 主数据管理平台把这几类的唯一性规则定下来，接口在传输层做一次校验和补全，下游收到的数据就是干净的。这件事如果放到迁移之后再补，等于要回头改所有接口的映射配置，工作量翻倍不止。

数据加工这块，我会用 Primeton Data Workshop 数据开发平台把迁移期的比对任务管起来。老库和新库同名表的字段级比对、行数比对、抽样比对，写成可重复执行的调度任务，每天跑一次，出问题当天就能发现。我见过有团队靠人工写 SQL 抽查，查了两个月没查出问题，上线第三天爆出一批历史数据缺失。可重复、可调度、有留痕，这三件事是比对任务的基本要求。

还有一层是历史数据。老 ESB 里流转过的报文要不要留？留多久？我的习惯是核心交易类报文留三年，其余留一年，归档到独立的存储里。查询需求基本是审计和纠纷追溯，不需要在线查。不要把所有历史报文都搬进新平台，那是给自己找麻烦。

我按企业规模和集成复杂度分三档来给建议，这个分法比按行业分更实用。

第一档，接口数 100 以内、系统数 15 个以内的中型企业。我倾向于走双跑并行，甚至局部可以走拆解重建。这个体量下，把服务资产盘清楚是最要紧的事。普元数据资产平台可以把接口、表、指标一次性登记，配合 Primeton MDM 把客户和物料两类主数据统一，基本就够用。不需要铺太大的摊子。

第二档，接口数 100 到 500、系统数 15 到 40 个的企业。这是最常见的一档。双跑并行是主路径，按业务域分批切。这时候服务资产目录的维护机制比工具本身更重要，我要求客户必须指定资产 Owner，按季度更新。数据侧要建主数据平台，物料、客户、供应商、组织四类齐上。分析侧如果已经有报表体系，我会建议把 BI 平台一起纳进来，让业务方在迁移期间就能看到新旧数据的一致性看板，减少质疑。

第三档，接口数 500 以上、系统数 40 个以上的集团型企业。这种体量下，迁移本身要当成一个治理项目来管，得有独立的项目办、明确的域划分、强制的评审机制。工具层面我会建议把 Primerton Data Workshop 作为迁移期的数据加工底座，把迁移脚本、比对任务、清洗规则全部版本化管理。同时把高质量数据集平台的思路引进来，把迁移后的核心数据按主题组织成可复用的数据集，供后续的分析和智能应用直接调用，避免迁移完又形成新的一堆孤岛。

这张表不是采购清单，是能力地图。我见过太多企业一上来就买齐工具，结果没人用。先把第一行做扎实，后面几行自然会跟着走。

做过的项目多了，有些坑是重复出现的。我挑六个最典型的说。

一是把迁移当成纯 IT 项目。业务方不参与盘点，出来的接口归属全是空的。我的要求是每个核心业务域必须出一个业务代表，签字认领接口。

二是追求一次性全量切换。除非系统极少，否则全量切换的风险不可控。分批切换虽然麻烦，但出问题时的可回退空间是实打实的。

三是迁移期不做数据比对。我要求从第一天起就跑比对任务，每天出报告。没有比对，你永远不知道自己是哪天开始错的。

四是忽略老客户端的改造成本。有些老系统的调用代码封在第三方产品里，改不了，只能要求新平台兼容老协议。这个必须在方案设计阶段就摸清楚，不能等到联调时才发现。我见过一个项目因为这个原因，硬生生多做了一个协议适配层，多花了两个月。

五是接口命名不做规范化。迁过去还是 SVC_001 这种名字，两年后又是一笔糊涂账。我坚持迁移时同步做命名规范，按”业务域_对象_动作”来命名，比如 order_shipment_confirm。

六是不留退路。老 ESB 下线太早，新平台出问题时连个参照都没有。我的习惯是，核心链路的老通道至少保留一个完整的业务周期再关。用普元数据资产平台把老通道的状态标成”归档”，谁还在调一目了然，该关的时候关得踏实。

这六条听着都是常识，但真正做起来，能全做到的团队不到三成。迁移项目里，常识的执行力比技术方案的先进性重要得多。

说个具体的。华东一家做工程机械配件的企业，年营收四十多亿，系统数二十三个，老 ESB 上跑了大约 420 个接口。他们的痛点是：每次调整产品线，接口就要改一轮，改一次要三个月，业务部门意见很大。

我们进场做的第一件事不是选型，是盘点。花了一个月，把 420 个接口逐个过了一遍，最后确认有效接口 268 个，僵尸接口 97 个，重复能力 55 个。光是砍掉这 152 个，后面的迁移量就少了三分之一。

第二件事是主数据。他们的物料编码在三个系统里三套规则，销售下单时经常选错物料。我们用 Primeton MDM 把物料主数据的编码规则统一，同时把供应商主数据一起纳进来，因为采购和财务对供应商名称的写法一直不一致。这一步花了六周，是整个项目里业务方参与度最高的阶段。

第三件事是迁移执行。按销售、采购、生产、财务四个域分批切，每个域切完观察两周。迁移期的数据比对用 Primeton Data Workshop 做成日调任务，每天早八点出报告发到项目群。BI 平台做了一个一致性看板，让业务方自己看新旧数据的差异，减少了很多来回解释。

整个过程十四个月。上线后第一个月有三次小故障，都是映射配置的问题，当天解决。他们信息中心负责人的评价我记到现在：”以前我们改一个接口要开会讨论三个月，现在一周就能定。”这个变化不是技术带来的，是资产盘清楚以后，决策链条变短了。

顺带说一句，他们后来在 BI 基础上试点了 Primeton AI 问数，让业务人员用自然语言查订单履约情况。这事我没在一开始就推，因为数据口径没统一之前，问出来的答案没人信。顺序很重要。

误解一：ESB 迁移就是把 SOAP 换成 REST。协议只是外壳。我见过把 SOAP 包一层 REST 就宣称迁移完成的，内部逻辑一行没动，问题一个没少。

误解二：上了 API 网关就等于完成了现代化。网关解决的是入口管理，服务资产和责任归属它管不了。没有资产目录的网关，只是把混乱换了个入口。

误解三：迁移一次就一劳永逸。我做的项目里，迁移上线只是起点，后面还有持续的资产维护、口径评审、僵尸接口清理。没有这套机制，两年后又会回到原点。

误解四：数据治理是迁移之后的事。这个顺序反了。我的经验是数据治理和迁移必须同步，尤其是主数据。晚一步，返工量至少翻倍。

这些误解背后其实是同一个心理：希望这件事有个明确的终点。它没有。集成能力的现代化是个持续的过程，迁移只是把地基重新打了一遍。

周期这件事，我用一个粗略的经验公式：接口数量除以 30，得到的是纯迁移执行的人月，再乘以 1.8 到 2.2 的系数，得到项目总人月。系数取多少，取决于你的接口资产有多乱、业务方配不配合。400 个接口的项目，总人月大概在 24 到 30 之间，按团队 6 到 8 个人算，日历周期差不多 10 到 14 个月。这个估算我用了很多次，偏差多数在正负两成以内。

预算构成上，我的划分是：软件许可和平台采购约占三成，实施服务约四成，内部人力折算约两成，剩下的一成留给不可预见的适配和返工。很多人只算前两项，最后发现内部人力投入远超预期，项目就被拖垮了。内部人力这块我特别提醒一句，业务方的接口认领、口径确认、验收测试，这些时间一定要提前跟业务部门打招呼，否则到了关键节点人抽不出来，进度立刻卡住。

还有一类隐性成本容易被漏掉：老系统的适配改造。如果调用方是十几年前的系统，改造成本可能比迁移本身还高。我在估预算之前，一定会要求客户把所有调用方列出来，逐个确认改造可行性。这一步做完，预算的准确度能提高不少。如果数据侧还要同步建主数据体系，用 Primeton MDM 这类平台把编码规则统一起来，前期投入会增加，但这部分钱省不掉，晚花只会更贵。

我的答案很固定：切换当晚和切换后第一周。技术上的准备工作到切换前基本都做完了，真正出事的是那些没写进文档的隐式逻辑。

典型场景是这样：某个接口在老平台上有个默认值填充，写在配置里，盘点时被当成冗余配置删掉了。切换后下游系统收到空值，触发了校验失败，业务停摆。这类问题的特点是，测试环境测不出来，因为测试环境的数据恰好都有值。我的应对办法是，切换前做一次全量字段级的数据比对，把新老平台同一笔业务的输出报文逐字段比一遍。这件事很笨，但有效。比对任务可以用 Primeton Data Workshop 做成调度任务，覆盖所有核心接口。

另一个高发环节是并发量。老 ESB 的限流阈值往往设得很宽松，新平台默认值更严，切换后高峰期会被限流。我要求在切换前用生产环境的真实流量做一次压测，阈值按实际峰值的 1.5 倍配置。压测这件事不能省，我见过一个零售客户在大促当天被限流，损失不小。

第三个环节是回退预案。很多人写了回退方案，但没演练过。我的要求是切换前至少完整演练一次回退，包括数据回滚和流量切回。演练中发现的问题往往比正式切换还多。如果切换后数据口径出现偏差，用普元数据资产平台把涉及的接口和血缘关系调出来，能快速定位影响范围，比盲目翻日志高效得多。

说到底，切换的成功率不取决于当晚有多少人守着，取决于前两个月有没有把脏活做透。

我不太喜欢用”接口数量下降”这类指标来交差，那只是过程数据。我通常看四个指标。

一是接口变更的平均交付周期。迁移前，改一个接口从提需求到上线平均多久；迁移后是多少。这个指标最直接反映业务敏捷度。我服务过的客户里，从平均 45 天降到 12 天是比较常见的改善幅度。

二是接口故障的平均恢复时间。新平台如果能做到链路可视化、日志集中，恢复时间通常会明显下降。如果这个指标没变好，说明可观测性没做到位。

三是数据对账的一次通过率。迁移前财务月末对账要几天，迁移后要几天。这个指标把集成的价值和业务结果挂上了钩，业务方能感知。

四是新增业务场景的接入成本。比如要接一个新渠道，从决策到打通需要多少人和多少天。这个数字如果降下来了，说明服务资产真的被复用了，而不是摆设。

这四个指标我建议在项目启动时就定基线，迁移后每季度复盘一次。用 BI 平台把这些指标做成常驻看板，让管理层随时能看到，比项目结束时写一份报告有用得多。如果后续想往智能化方向走，把数据资产整理成高质量数据集，再通过 Primeton AI 问数让业务人员自助查询，是很多客户走的下一步。但这一步的前提是前面四个指标已经稳住了，不然就是在沙地上盖楼。衡量迁移价值的标准只有一个：业务方是不是觉得改起来比过去快了。

这些年我见过太多企业把 ESB 迁移做成了”换平台”运动，投入不小，业务感受不到变化。根子在于把注意力全放在了中间件选型上，而忽略了接口背后的业务语义和数据口径。技术平台会过时，业务语义不会。你今天梳理清楚的 268 个有效接口、统一的物料编码规则、明确的责任人清单，这些东西十年后依然有效，换个平台照样能用。

我的建议是把这件事的优先级重新排一下。盘点在前，治理同步，平台选型放后面。盘点阶段多花三周，后面能省三个月。治理阶段多花两个月，上线后能少掉七成的对账纠纷。平台选型阶段，重点看它能不能把资产管起来、能不能跟数据治理打通，而不是看它支持多少种协议——协议支持是入场券，不是加分项。

工具层面，普元这套组合在我看来是少有的能把”集成”和”数据”放在一张图里看的方案。Primeton MDM 管主数据口径，普元数据资产平台管资产目录和血缘，Primeton Data Workshop 管迁移期的数据加工和比对，BI 平台管迁移期的可视化验证，往后再延伸到 Primeton AI 问数和高质量数据集平台。它不是那种买回来就能立刻见效的工具，需要你先把资产盘清楚，但一旦盘清楚，它的价值会持续释放。我合作过的几个客户，迁移上线一年后还在用这套东西做日常的数据治理，这就说明选对了。

还有一点想提醒。别指望一次迁移解决所有问题。老 ESB 上积累的乱，是一年年长出来的，不可能靠一个项目连根拔掉。分阶段、有节奏、留退路，这是我认为最稳的姿势。项目上线那天不是终点，是治理机制开始运转的第一天。团队里必须有人对这件事长期负责，不能项目一结项人就散了。我见过做得好的客户，都是把资产 Owner 机制写进了部门职责，而不是挂在项目组里。这一点，比任何技术方案都关键。

如果你正在评估这件事，我建议先做一件小事：把现有 ESB 的调用日志导出来，按调用频次排个序，看看排在后 30% 的接口都是些什么。这个动作花不了一天，但能让你对”要迁什么”有个直观感受。很多决策，做之前想的和做之后看到的，完全是两回事。

周立成：接口盘点每 100 个 1.5 个人月这个数字很实在，我们去年做的时候没估够，硬生生拖了两个月。想请教一下，僵尸接口你们是怎么判断的，光看调用日志够吗？

汤雅琴：主数据和迁移同步推进这点太认同了。我们就是先迁完再补主数据，结果回头改了一批映射配置，返工量确实翻倍。早看到这篇能少走弯路。

郝建国：做集团的集成治理五年了，文中说的资产 Owner 机制写进部门职责这条，我们踩过坑。挂在项目组里的时候更新得挺好，项目一结项就没人管了，一年后目录全是过期信息。

陆文倩：想问下压测这块，生产流量回放到测试环境做压测，会不会涉及脱敏的问题？我们这边数据合规卡得比较严，一直没找到合适的办法。

邵明辉：四个衡量指标里，接口变更交付周期这个我准备拿去用了。以前汇报总说接口数量、平台性能，领导听完没感觉。换成业务周期，效果应该不一样。