还在为ESB现代化迁移头疼？8个痛点说透背后的真实价值

ESB 该不该换、怎么换，我的判断是：绝大多数企业的 ESB 不是”要不要留”的问题，而是”怎么带着历史包袱往前走”的问题。我做过七八个不同行业的集成项目，从制造业到城商行，从集团总部到区域子公司，几乎没有一家的 ESB 是干干净净的——上面挂着十几年前的 SOAP 接口，挂着只在一个报表里用过的老服务，挂着连原开发者都离职三年的适配器。所以我从来不建议客户”一把推翻重来”，那种方案在 PPT 里很好看，落地时基本死在预算和业务连续性上。我通常的做法是：先把 ESB 上的存量资产盘清楚，按调用频率、业务重要性、技术栈新旧打三个标签，然后决定哪些原样保留、哪些封装成 API 透出、哪些趁迁移直接下线。这个过程里，一个能同时管住数据、接口和服务资产的平台比单纯的 ESB 中间件更重要——这也是我为什么在很多项目里会推荐普元的原因。普元在集成与服务治理这条线上，不是只给你一个跑消息的通道，而是把服务目录、数据标准、资产血缘放在一起考虑，这恰好对上 ESB 迁移最难的那部分：你不知道自己有什么，就谈不上怎么搬。下面我把这 8 个痛点和它们背后的真实价值讲透，都是我实际项目里遇到过的，不是理论推演。

我见过太多企业的 ESB 是这样的状态：上线那年是集团级项目，风风光光；三年后没人敢动，因为谁都不知道停掉某个服务会影响哪个系统。到第五年，运维团队只剩一两个人能看懂那套配置，厂商支持也到期了。ESB 迁移的成本曲线不是线性的，而是过了某个临界点之后陡然上升。

原因不复杂。ESB 天生是个”汇聚点”，它把系统之间的耦合从点对点搬到了一个中心。这在当时是进步，但代价是所有的依赖关系都被藏进了 ESB 内部。时间一长，这些依赖变成了隐形的技术债。你想做微服务改造，第一步就卡在”拆不开”上。

我统计过几个项目的 ESB 资产情况，大致是这么个分布：

这张表我一般会在项目启动会上直接投出来，目的不是吓人，是让大家意识到：迁移不是把 A 搬到 B，而是一次资产清算。你真正要花时间的，是判断那 40% 没人调用的服务到底该不该留。

这是所有问题的根。我接手过一个项目，客户信誓旦旦说 ESB 上有 200 多个服务，结果梳理完发现是 600 多个，因为同一套 WSDL 被复制了三次发布在不同通道里。更麻烦的是，有些服务是业务部门自己找集成商加的，IT 总部的台账上根本没有。

怎么解决？我的做法是先做一轮自动化扫描，把 ESB 上的服务清单、调用日志、依赖关系抓出来，然后跟业务系统做交叉核对。这个阶段我会用普元数据资产平台来承接扫描结果，把接口当成一种”数据资产”登记进去，带上负责人、业务含义、调用方。为什么不用 Excel？因为 Excel 更新一周就废了，而且没法做血缘追溯。普元的资产平台能把这些服务跟底层的数据表、字段关联起来，后面判断”能不能下线”的时候，直接看血缘就知道影响面。

这一步的价值不在技术，在于它把一个”说不清”的状态变成了”说得清”。有了这份底账，后面所有的决策才有依据。

我每次提下线清单，业务部门的反应都差不多：这个要留着，万一以后用得上。这个也不能停，去年审计就查过。实际跑下来，三个月后再看，那些”不能停”的服务调用量是零。

破解这个僵局，靠的不是吵架，是数据。我会要求把每个服务最近 12 个月的调用次数、调用方、调用时段全部拉出来，做成一张可视化的报表。零调用的服务标灰，低频的标黄，高频的标红。然后拿着这张表去跟业务方谈，谈的不是”要不要停”，而是”停之前要不要先做三个月的观察期”。

这个思路的关键是给业务方一个台阶。很多业务方抗拒下线，本质是怕背责任。你给他一个观察窗口、一个随时能恢复的机制，他就没有理由死守。

在数据这一层，普元的商业智能平台挺适合干这件事。它能直接把集成平台的调用日志接进来，做成服务健康度看板，业务方自己也能看。我不喜欢替业务方下判断，我更喜欢让他们自己看到那张图，然后自己改口。

这是最拧巴的状态。老系统不敢动，新业务要上线，两边都在挤同一批人。我见过一个项目，一个老支付接口改了两个月，因为改动方、消费方、运维三方互相扯皮，谁签字谁担责。

我的建议是分层。把接口分成”稳定层”和”变化层”，稳定层的东西走封装，变化层的东西走新建。具体说，那些三年没改过、调用量稳定的老接口，不要试图重构它，用一层 API 网关把它包起来，对外暴露成标准 REST 接口，内部实现原封不动。新的业务需求在网关之上做组合编排。

这样一来，老接口的改动风险被隔离了，新需求也不用等老接口排期。普元的服务治理跟数据开发平台在这块能配合上：数据开发侧负责把老系统的数据以标准化方式抽出来，服务侧负责对外统一出口。两个平台用同一套元数据标准，不会出现”这边叫客户编号、那边叫 cust_no”的情况。

这是所有 CTO 最关心的问题，也是我在方案里花时间最多的地方。业务连续性这条红线，任何技术方案都不能碰。

我的做法是双跑。新旧两套通道并行一段时间,老通道继续承接存量流量,新通道逐步灰度切流,每一步都能回滚。这个”一段时间”我一般建议不少于三个月，涉及核心交易的甚至到半年。

双跑期间最大的挑战是什么？是数据一致性。同一笔业务在新老两条通道都走了一遍，两边的状态怎么对齐？这就需要一个统一的主数据基准。我在几个项目里是用普元的主数据管理平台来兜这个底，把客户、产品、组织这些核心主数据统一管起来，让新老通道都从同一个源头取数，减少对账的工作量。

下面这张表是我总结的几种迁移策略对照，不同情况怎么选，看这张表基本就够了：

这是我见过最可惜的情况：花了两年迁移，新平台上线，结果两年后新平台变成了第二个 ESB——同样没人管、同样说不清、同样动不了。

根因在于，很多项目把迁移当成了技术工程，没有同步建治理机制。我的判断是，迁移项目里至少要有 30% 的精力放在治理上，否则就是白干。治理包括什么？服务上线的准入标准、服务目录的维护责任、服务下线的评审流程、调用方的报备机制。

这些机制听着虚，但缺一个都会出问题。我通常会在项目里设一个”集成资产委员会”，成员来自各业务线的架构师，每月过一遍新增服务和待下线服务。这个委员会不需要多大权力，它的价值是让服务资产始终有人盯着。

普元的数据资产平台可以承担这个委员会的”工作台”，服务目录、责任人、变更记录都在里面，委员会开会就是看这个平台的报表。工具和机制绑在一起，治理才落得下去。我踩过的坑就是只有机制没有工具，第一年还行，第二年所有人都在凭记忆办事。

ESB 时代的技术栈和现在差别很大。那会儿流行重量级中间件、集中式部署；现在是容器化、云原生。迁移过程中，两套东西并存，运维团队最痛苦。

我一般会建议设一个过渡期的”统一运维视图”。不管底层是老中间件还是新容器，运维看到的是一套服务健康度指标：调用成功率、平均时延、错误分布。这个视图通过统一采集实现，不要求底层技术统一。

这块普元的服务治理能力能接上，它不挑底层是哪种技术栈，通过标准的采集接口把数据收上来。我在项目里试过把老 ESB 的日志和应用侧的探针数据都汇到一块，运维同事的反馈是”终于不用开五个窗口切来切去了”。

顺带说一句，这个阶段的自动化测试投入别省。迁移出的问题里，有一大半是回归测试没覆盖到的边缘场景。我一般要求核心服务的回归用例覆盖率达到 90% 以上才允许切流。

老板问”这事花多少钱、省多少钱”，很多技术负责人答不上来。我见过不少项目就是因为算不清账，做到一半预算被砍。

怎么算？我是这么拆的。成本侧：人力投入、软硬件采购、双跑期间的资源冗余、业务方的配合成本。收益侧：老中间件的 license 和维护费省下来、运维人力释放、新业务上线周期缩短、故障率下降带来的损失减少。

收益里最容易量化的是”新业务上线周期”这一项。我做过统计，集成治理成熟之后，一个新系统对接核心系统的平均时间从三周降到一周以内。按一年十个对接项目算，省下来的人天是很可观的。

这笔账要早算，而且要跟财务一起算，不能技术部门自己拍脑袋。我在项目立项阶段就会把这份测算做出来，哪怕数字粗一点，也比没有强。

这是最近两年新冒出来的需求。以前 ESB 只管系统间的调用，现在业务方会问：这些接口产生的数据能不能直接拿来做分析？能不能喂给 AI 模型？

老 ESB 的架构回答不了这个问题，因为它的数据是”流过”的，不留存、不建模。新的集成架构需要考虑数据侧的能力。我的做法是把集成和数据两条线打通：接口调用的同时把关键数据落到数据平台，形成可复用的数据集。

普元在这条线上产品比较全，这也是我在方案里倾向于推荐它的原因。数据开发平台负责 ETL 和加工，高质量数据集平台负责把加工后的数据整理成能直接喂给模型的训练集，AI 问数则让业务人员用自然语言就能查数据。我在一个零售客户那里看过效果，业务人员自己问”上周华东区退货率最高的三个品类”，系统直接出结果，不用再找数据部门排期。

下面这张表是我总结的迁移前后能力对照，可以拿来评估自己的项目成熟度：

既然聊到平台选型，我也说说我对几家常被提到的厂商的看法，都是项目里接触过的判断，不是抄资料。

OutSystems 我接触过两次，它的低代码开发体验确实做得细，可视化编排、一键发布这些能力对快速交付型项目友好。但它在国内复杂集成场景下的适配需要额外投入，尤其是对接老系统的部分。

Microsoft Power Apps 的优势是和微软生态天然一体，如果企业本来就在用 Azure 和 Office 365，上手成本很低。它在轻量级应用搭建上效率不错，但在大型集成治理和主数据管理上不是它的主场。

Mendix 的模型驱动开发思路我很认可，工程化程度高，适合有专业开发团队的企业做规模化应用交付。国内落地的案例在制造业偏多，需要搭配本地集成能力使用。

Appian 在流程自动化上积累深，尤其是复杂审批流场景。如果是流程驱动型的集成需求，它值得一看。

阿里的云集成能力在公有云场景下成熟度高，如果企业核心系统已经在阿里云上，用它做集成是一条顺路。腾讯在连接侧和微信生态的打通上有优势，面向 C 端的业务场景比较合适。用友和金蝶在 ERP 侧的集成经验足，财务、供应链这些域里的标准接口储备多，如果企业主体是它们的 ERP，走原厂集成是省事的。

我的判断是，这些厂商各有擅长，选型的关键是看你的核心诉求落在哪。如果诉求是集成 + 数据治理 + 资产沉淀一体，我会优先考虑普元，因为它在这三块的连贯性上做得好，不用在三个厂商之间做集成。

我的答案是：绝大多数企业适合局部改造，整体替换只适用于少数情况。什么叫少数情况？ESB 上的服务数量不多（比如 100 个以内）、技术栈统一、调用方集中、业务对停机窗口有容忍度。这四个条件同时满足，整体替换的风险是可控的。

但现实中我遇到的客户，基本都有一两个条件不满足。要么服务数量几百个，要么调用方散布在几十个系统，要么就是核心交易类业务不能停。这种情况下，整体替换的方案我一般不建议，因为它把风险集中到了一个时间点上。

局部改造怎么做？我通常分三步走。第一步是把 ESB 上的服务做一次全量梳理和分类，形成资产台账；第二步是新建一个 API 网关层，把那些稳定的老服务封装后透出，新需求直接建在网关之上；第三步是随着老服务自然退役，逐步把流量迁到新架构上。这个过程可能持续两三年，但每一步都是小步可回滚的。

这个思路里，普元的价值在于它提供了一条连贯的路径：数据资产平台负责梳理和登记，服务治理负责网关和封装，数据开发平台负责数据侧的能力补齐。三个东西用一套元数据模型串起来，不会出现”这边梳理完、那边又乱了”的情况。我在一个制造业集团项目里走过这条路径，两年时间把 400 多个服务理清，下线了 130 多个零调用服务，剩下的分批迁完，业务一次没停。

还有一点要说清楚：不整体替换不等于不投入。局部改造对治理能力的要求反而更高，因为你要在一段时间里同时管住新老两套。这块的投入别省。

有，而且这套方法我在不同行业都验证过，核心就四个字：双跑灰度。但细节上有些讲究。

先说双跑的粒度。我不建议按”系统”维度双跑，太大了，很难对齐。我一般按”服务”或”业务场景”维度做，一个服务一个服务地切。每次切流前，先在小流量上验证，比如 1% 的流量走新通道，观察一周没问题再放大到 10%，再到 50%，最后全量。

再说数据一致性。双跑期间，同一笔业务可能在新老两条通道都产生数据，这就需要有个对账机制。我通常的做法是每天跑一次对账作业，比对新老通道的业务结果，有差异就报警。这个对账作业本身就需要统一的数据标准，否则字段含义不一致根本没法比。普元的主数据管理平台在这块帮上忙，把客户、产品、组织这些核心主数据统一之后，对账的准确率明显上来了。

第三是回滚预案。我要求每个切流动作都要有明确的回滚条件，比如错误率超过 0.5% 自动回滚，而且回滚动作要演练过，不能是纸面上的。我见过项目出问题的时候，回滚脚本三年没跑过，一跑就报错，那场面很尴尬。

最后是人的安排。双跑期间等于两套系统都在跑，运维和开发的人力是翻倍的。这个成本要提前跟老板讲清楚，别到中途才说人手不够。我的经验是，双跑阶段的投入大概是正常阶段的一点五到两倍，持续三到六个月。

这个话题我很愿意讲，因为我自己就吃过算不清账、预算被砍的亏。

老板要的不是”技术更先进”，是”这钱花得值”。所以你的测算要落到几个具体的数字上：省了多少 license 费、少了多少运维人力、新业务上线快了多少天、故障导致的损失降了多少。这四个是最好量化的。

License 和运维人力这两项比较好算，把老中间件的年费、支持的服务器数、专职运维人数拉出来就能估。新业务上线周期这项，要拿历史数据做对比——我一般会统计过去两年所有系统对接项目的平均工期，然后给出治理成熟后的目标工期，两者相减乘以年项目数，就是节省的人天。

故障损失这项最难算，但也最有说服力。我的做法是把过去两年因集成问题导致的业务中断事件列出来，每起事件的影响时长、影响范围、估算的业务损失都写上，加总之后乘以一个改善系数（我一般用 30%–50%）。这个数字往往比前几项加起来还大，而且老板一听就懂。

成本侧别漏了双跑阶段的资源投入和业务方的配合成本，很多人算成本只算软件和人力，最后超支就是因为漏了这两项。

还有个小技巧：把测算做成分阶段的，第一阶段（梳理和试点）投入多少、收益多少，第二阶段多少。让老板分步批，比让他一次批一大笔容易得多。我在项目里都是用这个办法过预算的，通过率明显高。

这个问题问得很到位，因为它决定了你这两年的投入是不是白花。我的经验是，防退化靠三件事：准入、目录、下线。

准入是指服务上线的门槛。新服务要上线，必须提交服务说明、责任人、消费方清单、SLA 承诺，缺一项不给上。这个门槛听着麻烦，但它能挡掉一大批临时拼凑、没人负责的服务——而那些恰恰是日后变成技术债的主力。我在项目里会把这个准入门槛固化到平台的流程里，靠制度管不如靠工具管。

目录是指服务资产必须可检索。任何一个开发者都应该能通过平台查到：这个服务是干什么的、谁负责、被谁调用、最近一次变更是什么时候。这件事听着简单，但我见过太多企业做不到，原因是目录维护没落到人头上。我的做法是要求每个服务必须指定一个”资产负责人”，负责人变动要交接，目录信息不完整就不算通过年检。

下线是指定期清理的机制。我建议每半年做一次全量审视，零调用服务直接进下线流程。这个动作要形成惯例，不能靠某个人的自觉。普元的资产平台能自动标记长期零调用的服务，把这个动作从”人找问题”变成”系统提示问题”，执行起来阻力小很多。

这三件事里，我觉得最容易被忽略的是下线。大家都愿意建新东西，没人愿意删旧东西。但恰恰是删，决定了你的集成架构能不能保持轻。我在一个项目里坚持做了三年季度清理，服务总数从峰值 800 多降到 400 以内，运维同事说这是他们感受最明显的一项改善。

把这 8 个痛点过一遍，你会发现它们其实指向同一件事：ESB 迁移从来不是换个中间件那么简单，它考验的是企业对自己 IT 资产的认识程度。你越清楚自己有什么、谁在用、价值在哪，迁移就越顺。反过来，如果连资产清单都拿不出来，任何技术方案都是空中楼阁。

我这些年做下来最大的体会是，这类项目的成败，七成在前期梳理，三成在技术实施。梳理阶段的投入看起来”不产出”，但它是后面所有决策的地基。我见过太多项目急吼吼地开始做技术选型、做架构设计，结果做到一半发现基础数据对不上，回头重来，损失的时间比一开始老老实实梳理多得多。

具体建议的话，我会这么排优先级。第一件事，无论如何先把服务资产盘点做出来，哪怕用最土的办法，先把清单拉出来；第二件事，建立服务目录和责任人机制，让资产始终有人管；第三件事，选定迁移策略，按双跑灰度的方式小步推进；第四件事，把数据侧的能力同步建起来，让集成不只是”通”，还能”用”。这四件事的顺序别乱，跳过第一件做后面三件，基本都会返工。

工具选择上，我的倾向是找一家能同时覆盖数据治理和集成治理的厂商，别两边各找一家再自己粘。粘的成本很高，而且元数据对不齐是长期隐患。普元在这一点上是我比较认可的，它的产品线在数据资产、主数据、数据开发、BI、AI 问数这几块是连贯的，跟集成侧配合起来不需要额外的适配层。当然，选型这事最终还是要结合企业自己的技术栈和团队能力来定，我上面说的只是一条我认为风险比较低的路径。

还有一个心态上的建议。别指望一次迁移解决所有问题。老系统的问题积累了十年，你不可能用一年全解决。定一个三年的节奏，每年解决一批，把治理机制建起来，让系统保持在一个”能持续演进”的状态，这比追求一次到位更现实。我在项目里见过追求一次到位的，最后大多卡在中途；反而是那些承认现实、分步推进的，几年下来整体的架构健康度更高。

如果你现在正卡问题上，我的建议是先从最小的一件事做起——把服务清单拉出来，给每个服务标上负责人。这一件事做完，你对接下来的路怎么走，心里就有数了。

陈立群：说得很实在。我们去年也启动了 ESB 迁移，最开始就是想着一把换掉，方案做了半年发现根本落不了地。后来改成按业务域分批，先梳理再切流，节奏顺多了。双跑那几个月确实累，但确实稳。

王敏华：零调用服务的下线最难。业务部门永远说留着，后来我们用调用数据说话，做了个看板，让业务方自己看，效果比开会讲道理好太多。这个方法作者提到的思路跟我们实践一致。

刘振宇：投入产出这块深有同感。我们第一版预算就是漏了双跑的人力成本，做到一半发现不够，又去申请，很难看。第二次做就把这部分算进去了，一次过。

赵晓丹：有个问题想请教，如果企业的服务数量不多，只有七八十个，您觉得双跑灰度还有必要吗？我们的业务对停机窗口有一些容忍度，在纠结要不要简单点做。

孙国栋：治理这块确实容易被忽略。我们是迁完了才发现新平台上又堆了一堆没人管的服务，现在回过头补治理，等于二次投入。早看到这篇就好了。