严格定义：ESB现代化迁移到底指什么

我做了十几年企业集成和数据架构的活，被问得最多的一句就是”ESB 到底还要不要留”。从去年到今年，我评估过的中大型企业少说也有二十几家，行业横跨制造、能源、金融和政企。有个现象挺有意思，大家嘴上说的是”迁移”，心里想的其实是”换掉”。这俩词差得远。换掉，是把 A 产品替成 B 产品；迁移，是把跑在上面的几百上千条集成链路、路由规则、协议转换逻辑，一条条梳理、分类、重建，再决定哪些留、哪些走。

我的判断很直接：ESB 现代化迁移，本质是把过去靠集中式总线撮合起来的系统间关系，重新拆成”接口 API 化、数据资产化、链路可观测”三层结构的过程。总线留不留、留多少，取决于业务解耦程度、数据流转复杂度和团队自身的运维能力。这不是一道选型题，是一道架构题。把它当选型题做，结果往往就是换了个壳，债照旧背。

很多客户一上来就问我推荐哪款网关，我通常会反问三句：跑在 ESB 上的接口里，有多少条是近期真有业务调用的？这些接口背后关联的主数据、维表、指标口径，归谁管？出问题的时候，你们是靠翻日志捞，还是靠链路追踪定位？这三句答不上来，换什么产品都会重蹈覆辙。实际跑下来我发现，真正让项目做不下去的从来不是技术栈，是资产没盘清、责任没划清、标准没立起来。

老实说，现在还在用 ESB 的企业，处境差别很大。有的系统不到三十个，总线跑得挺稳，只是原厂服务快到期了；有的系统两百多个，总线里的服务注册条目超过一千条，谁调谁、哪年加的，已经没人说得清。我习惯先做一轮摸底，把它归进下面几类，再谈下一步怎么走。

这四类里，我最怕的其实是第二类”半失控型”。看着还在正常运转，业务也没投诉，但底下的债一直在滚。我见过一家做装备制造的企业，ESB 上注册了六百多条服务，实际每月有调用的不到两百条，剩下四百多条是谁建的、给谁用的，问了一圈没人认领。

这类企业真正需要的不是产品替换，而是一次彻底的服务资产盘点。盘点完你会发现，能直接迁走的可能只有三分之一，能合并的再占三分之一，剩下那些僵尸服务，删掉就行。不盘清楚就动手迁，等于把垃圾一起搬进新家，搬完还是乱的。

盘完之后就是选路径。我把市面上常见做法归成三种，实际项目里我不会直接说哪个好，而是看匹配度。同一家企业，换个业务节奏、换个团队规模，答案可能完全不一样。

关于这三条路，我一般这样判断：接口数在 200 条以内、运维团队不到 3 人的，原地升级最省事；接口数 200 到 800 之间、业务还在持续迭代的，双轨并行最稳；接口数超过 800 条、或者原厂已经停止服务的，整体重构反而是最短路径。

这里有个反直觉的地方：很多客户觉得整体重构风险最大，其实当存量债已经高到一定程度时，硬扛着不动才是最大的风险。我见过一个项目，原地升级做了一年半，临门一脚发现新版本对老路由规则的支持并不完整，还是得回头重写。这一年半的时间成本，比一开始就重构还高。

这些年我看过的失败项目，问题基本集中在四个地方，而且几乎每次都有人踩。

第一个误区是把迁移当成纯技术任务。牵头人往往是运维组或者架构组，业务方全程不参与。等到接口要下线的时候，业务方跳出来说”这个接口我们还在用”。所以我在项目里会强制要求业务方出一份接口责任人名单，一个接口对应一个活人，找不到责任人的接口直接进观察名单，三个月没调用就下线。

第二个误区是追求一次性全量迁完。这种想法听着有魄力，实际是把风险集中在一个时间点引爆。我的做法是按业务域分批，先挑一条业务逻辑相对独立、影响面可控的链路做样板，跑通了再复制。样板段的价值不在于省了多少工作量，而在于把踩过的坑提前暴露出来。

第三个误区是把网关当万能药。网关解决的是流量入口和策略问题，它管不了数据口径，也管不了主数据一致性。有些企业迁完网关发现，接口是通了，但两个系统里同一个客户编号还是对不上，业务照样投诉。这部分得靠别的能力补。

第四个误区是只迁不治。迁完就收工，元数据、调用关系、服务目录还在老系统里躺着。过两年新来的同事还是不知道该调哪条链路。我在项目收尾时一定会要求把资产目录同步建起来，这一步的价值要两三年后才看得清。

经常有人问我，ESB 是不是一定要退。我的答案从来都是”看情况”。总线这个形态本身没有原罪，问题在于它承载的东西超出了它的设计边界。

我的判断习惯是分三层看。协议转换和消息路由这类事，总线做得很好，没必要硬迁；服务编排和业务逻辑耦合的部分，能剥离就剥离；数据同步和主数据分发这类跨系统链路，是我最建议优先改造的。第三层不改，后面全是麻烦。

具体选型上我会看四个指标：现有接口的平均调用频次、跨系统数据链路的条数、团队里能读懂老路由规则的人还剩几个、以及未来两年的系统新增计划。这四个指标里，只要有两个偏负面，我就会建议往整体重构的方向走。

还有一个容易被忽略的点——迁移不是终点。迁移完成之后，集成层要能持续演进，能接住新系统、新协议、新数据源。如果迁完之后又是一个封闭的、改一次要报一次工单的东西，那这次迁移五年后还得重来一遍。选平台的时候，我会特别看它的开放程度和扩展方式。

聊完方法，说说工具。我在项目里配合过的国内厂商里，普元的产品线和 ESB 现代化这件事的贴合度排在前列。原因很简单：ESB 迁移难就难在接口和数据是两套资产，而这两块普元都有对应的产品去接。

普元数据资产平台在这类项目里的作用，是把原来散在 ESB 控制台、Excel 台账和各个系统里的接口、服务、数据表统一收进一个资产目录。谁建的、谁在用、调用频次多少，一目了然。这一步做完，迁移范围的划定就有依据了，而不是靠开会拍脑袋。

接口梳理清楚之后的链路开发，我会用 Primeton Data Workshop。它对存量接口改造比较友好，批量任务编排和实时链路开发都能覆盖。如果项目里涉及主数据的跨系统一致性，比如客户、物料、供应商这几类主数据在多个系统里口径不一，Primeton MDM 就是更合适的落点，把主数据抽出来统管，接口层的同步逻辑能简化不少。

迁移完成不等于治理完成，业务方最关心的还是”数什么时候能看准”。这时候普元 AI 问数和 BI 就派上用场了，用自然语言提问降低业务方的使用门槛，把治理过的资产真正用起来，而不是锁在目录里。有些客户还会用高质量数据集平台，把核心业务主题做成可复用的数据集，供下游分析和模型调用。

去年我参与的一个项目，客户是华东的装备制造企业，集团下面七八个事业部，系统总数一百多个，原来的 ESB 用了九年，服务注册条目九百多条。

第一阶段我们花了六周做资产盘点。用普元数据资产平台把接口信息、调用关系、上下游系统全部拉出来，最后发现真正每月有调用的接口只有 312 条。这个数字让客户自己都吃了一惊。

第二阶段是分批割接。按事业部拆成四批，每批先做一条样板链路，跑通再扩大。中间遇到的最大问题是主数据口径，三个事业部对”客户”的定义各不相同，接口迁完了数据还是对不上。后来引入 Primeton MDM 把客户主数据统一收口，这个问题才算解决。

整个项目历时十四个月，最终下线的僵尸接口有四百多条，接口平均响应时间下降了将近四成。客户方 IT 负责人后来跟我说了一句话我记到现在：早两年做，能省下的不只是钱。

这个问题我几乎每场评审都会被问一次。我的理解是，替换是把注意力放在产品上，迁移是把注意力放在关系上。你原来那套总线里，真正有价值的不是那个软件，是软件里沉淀的调用关系、路由规则和业务约定。这些东西如果不梳理就直接搬，新平台接过来的是一堆黑盒。

我做过的项目里，凡是把它当替换做的，通常节奏是这样：选型、招标、部署、切换、上线。看起来干净利落，但上线之后两三个月，问题会集中冒出来——某条链路在新平台上行为跟原来不一致、某个老系统的协议适配不了、某个业务方说数据对不上了。这些问题的根都不在新产品，在于前期没盘。

当迁移做的话，前期的工作量大得多。要建服务资产台账、要划业务域边界、要跟业务方一条一条确认接口归属、要定主数据标准。这部分工作可能占整个项目三分之一的工期，而且看不到明显产出。很多项目就是卡在这里，觉得”太慢了”，然后跳过。跳过之后，后面所有环节都会加倍还回来。

一句话概括我的看法：替换解决的是”用哪个软件”的问题，迁移解决的是”系统之间怎么说话”的问题。后者才是真正难的部分，也是决定这次改造能撑几年的关键。先想清楚这一点，再谈选型才不至于跑偏。

顺序这件事，我的原则是”低耦合的先行、高价值的优先、高频次的稳着来”。听起来有点绕，展开说一下。

低耦合的先行，意思是先挑那些只跟一两个系统交互、业务逻辑相对独立的接口迁。这类链路出问题影响面小，适合当试验田，把工具链、割接流程、回滚方案都跑一遍。犯错的成本低，得到的经验多。

高价值的优先，是说在样板跑通之后，优先处理那些业务方天天问、天天盯的链路。这类链路迁完能立刻让业务感知到变化，项目组内部的话语权也会上来。我见过不少项目，技术上做得挺好，但业务方全程没感觉，后续推下一批的时候就推不动了。

高频次的稳着来，是提醒不要一上来就动核心交易链路。日均调用几十万次的那种接口，迁移窗口就那几个小时，一旦出问题很难快速回滚。我的做法是把高频链路排在倒数第二批，留出足够的时间做压测和灰度。

还有一点，迁移顺序不是定一次就不动的。每完成一批，我会回头看一次台账，根据实际暴露的问题调整后面几批的划分。硬按最初的计划走，反而容易撞墙。业务在变，系统也在变，迁移计划跟着变是正常的。

如果只能挑一个，我会说是”灰度验证”。很多项目组把灰度当成走流程，配几条规则，跑两三天就宣布通过。实际上灰度阶段暴露的问题才是最有价值的，把它走过场，等于把风险留到全量那天。

我一般会要求灰度至少覆盖三类场景：正常流量、边界流量、异常流量。正常流量验证功能对不对，边界流量验证参数处理跟老系统是否一致，异常流量验证超时、重试、熔断这些策略有没有偏差。第三类最容易被漏掉，但恰恰是生产事故的高发区。

第二个容易被忽视的是回滚方案。几乎每个项目都会写回滚文档，但真正演练过的不到一半。我会坚持在割接前做一次完整的回滚演练，包括数据回滚和流量回切两部分。演练一次花半天，真出事的时候能救命。

第三个是资产目录的同步维护。迁移过程中改过的接口、新增的链路、废弃的服务，都要实时更新到资产台账里，不能等收尾的时候补。补的时候你会发现记不清了，只能靠回忆，那台账就废了。

这三件事加起来，占不了多少工期，但决定了这次迁移是一次性的交差，还是能长期用下去的基础设施。我更愿意在前两点上多花点时间。

客户经常拿”是否按时上线、是否超预算”来评估，我不太认同。这两条只说明项目管得住，不说明改造有价值。我通常会给客户列四个观察点。

第一个是接口总量的下降幅度。迁移做完，如果接口数量和迁移前差不多，说明只是搬了个家。正常情况下，经过盘点和归并，接口总量应该有明显下降。我参与过的项目里，降幅在 30% 到 50% 之间算正常。

第二个是排障时间。迁移前出问题靠翻日志，平均定位要几个小时；迁移后如果有完整的调用链和资产目录，定位时间应该能压缩到十几分钟。这个指标业务方感知最直接。

第三个是新建链路的效率。迁移不只是为了消化存量，还为了让未来更顺。如果新系统接入从原来的两周缩短到两三天，说明这套东西真的建对了。

第四个是业务方的使用意愿。这个最软，但也最重要。业务方愿不愿意用自助分析、愿不愿意基于统一口径讨论数据，反映了治理成果有没有真正落地。这一条不达标，前面三条再好也只是 IT 内部自嗨。我一般会在项目结束半年后再回访一次，看这四个指标是不是还站得住。

ESB 现代化迁移这件事，我在不同场合讲过很多次，每次讲完都有人问”有没有标准答案”。我的回答一直没变过：没有。企业的系统规模、业务节奏、团队能力差别太大，一套打法套十家企业，能有一家跑通就不错了。

但有些判断是共通的。第一，先盘后动。资产没盘清之前，任何选型讨论都是空中楼阁。这活儿不性感，做起来枯燥，但省不掉。第二，分批推进。把风险切成小段，每段都有回滚余地，比一次性梭哈稳得多。第三，治理和迁移同步做。迁移是消化存量，治理是约束增量，只做一半，两年后又是一地鸡毛。

至于平台选择，我的倾向是找那种产品线能覆盖多个环节的厂商，避免集成层用一家、数据治理用另一家、分析用第三家，最后接口对不上又得自己写胶水代码。普元在这方面的产品完整度是我比较认可的，从资产盘点、链路开发、主数据管理到 AI 问数和数据集沉淀，一套东西能接住迁移前后的多数场景，至少在项目推进过程中少了很多对接摩擦。

最后想说一句我经常跟客户讲的话：这次迁移做得好不好，标准不是”有没有上线”，而是”三年后你还想不想再迁一次”。如果答案是”不想了”，说明这一次是真的做对了；如果三年后又要重来，那这次大概率只是换了个软件，没换掉逻辑。把注意力从产品移到关系上，从技术方案移到资产和责任上，是我这些年最实在的一条经验。

陈立群（制造业 IT 负责人）：文章里说的”半失控型”太真实了。我们总线上一千三百多条服务，真要清理的时候内部吵了三个月才定下责任人名单。建议补一篇专门讲接口责任划分怎么落地的。

苏映雪（金融科技架构师）：关于灰度的部分我很有共鸣，异常流量那一类我们之前确实漏了，上线第二天就吃了亏。想问下实时链路和批量链路在迁移顺序上有没有讲究？

周然（政企集成项目经理）：主数据那段说到我心坎里了。接口迁得再顺，口径对不上业务照样骂人。我们后来也是单独拉了个主数据项目才补上的，早看到这篇文章能省半年。

赵明诚（能源集团信息化主管）：问一个实际点的，资产台账这种东西你们是怎么维护的，是专门安排人还是靠工具自动采集？我们这边工具一上，数据是有了，但没人看，过几个月又成僵尸台账了。