ESB现代化迁移的8个认知误区，很多人第一个就错了

我在集成这条线上待了十多年，SOA 治理那波跟过，这两年的云原生改造也趟过几轮。八个误区里，第一个就把大半项目拦在门外——把迁移理解成”换一个中间件”。选型会开好几轮，POC 也做得挺热闹，可接口清单没人认真过一遍，业务语义没人当面确认，等到切换那天才发现一堆接口连当年为什么这么写都查不到了。我自己的判断是：ESB 迁移真正要迁的不是中间件，是接口背后承载的业务语义和数据口径。中间件只是载体，载体随时能换；语义一旦丢了，就只能靠线上事故一点一点往回找，那个代价比整个迁移工程量还高。我通常会在项目启动前问三个问题：接口资产盘清了吗？关键字段的口径对齐了吗？业务方愿不愿意签字认账？这三个答案含糊，产品选得再新也是白搭。说白了，迁移这件事的成败，在动手写第一行配置之前就定了七成。这篇文章我把八个误区逐个拆开讲——它一般出现在哪个阶段、踩了会有什么后果、我当时是怎么绕过去的、事后回头看哪一步最值得补。

很多团队一上来就讨论技术栈，我会先按住他们，把现状数字拉出来。数字不清，后面的方案全是猜。我见过最多的翻车方式，是拿接口总数当工作量，而真正要干的活藏在文档覆盖率和活跃调用比例里。举个常见的比例，一个跑了八年的 ESB，接口总数可能上千，但真正每天都在走流量的往往不到三成，剩下的要么是年度跑一批的批处理，要么是当年上线后就没再被调用过的”僵尸接口”。这两类东西的处理方式完全不同，混在一起排期，工期必然失控。

这几组数字出来之后，方案基本就有轮廓了。我的做法是把接口分成三类：高频核心、低频batch、长期无人调用。高频核心走重点保障，低频批处理可以合并或延后，长期无人调用的先冻结再走下线流程，别急着搬。这一步做完，你会发现真实工作量往往比最初估的少三成，但难度集中在少数几十个接口上，那才是真正要投入资深人力去啃的地方。

下面这张表是我自己常用来给团队对齐认知的，左边是大家嘴上的说法，右边是实际跑下来的样子。差距在哪，风险就在哪。

这个误区排第一不是随便排的。产品替换解决的是”跑在哪”，迁移要解决的是”跑什么”和”为什么这么跑”。我参与过一个项目，新平台两周就搭好了，接口一个没迁过来，因为没人说得清原来的路由规则为什么那样配。后来我们花了两个月做接口清单和语义登记，把每个接口的输入输出、字段含义、调用方、上下游依赖一条条补上，补完之后才发现有三十多个接口的入参字段名相同但含义完全不同。这种事你没盘出来，新平台上照样埋雷。

大爆炸式切换听起来干脆，实际是最容易出事的做法。我会要求至少保留两个窗口的灰度期，按调用方而不是按接口来做分批。理由很简单：接口的复杂度是技术问题，调用方的复杂度是协同问题，协同问题更难压。有一回我们按接口切，切到一半发现某个老系统只会走老地址，而这个系统归另一个部门管，临时协调花了十天。后来改成按调用方切，先把内部系统的调用方切干净，再动外部合作方，节奏一下子就顺了。灰度不是为了稳妥而稳妥，是为了让问题以小代价暴露。

工作量跟接口个数关系不大，跟流量的集中度关系很大。我通常会让团队先跑一个月的调用统计，按调用量排序，再决定哪批先动。排在前面的那些接口，往往是核心交易链路，改动需要业务、开发、测试三方同时在场；排在后面的，很多可以直接合并甚至下线。用 Primeton Data Workshop 这类数据开发平台把调用日志先做一次加工和归集，形成一张清晰的调用热度图，比开十次会都管用。数据摆在那儿，谁该先动一目了然。

通道迁完就收工，是我见过最普遍也最可惜的浪费。一个跑了八年的集成层，攒下来的接口本身就是一笔资产，迁完不留档，下次还得重新摸一遍。我的习惯是迁移过程中同步建资产台账：每个接口登记业务含义、责任部门、数据流向、变更历史。普元数据资产平台在这件事上帮过我不少忙，它的编目能力可以把接口、数据表、字段这几层关系串起来，迁移完顺便就得到一张能查、能追溯的资产地图。以后再来一次改造，起点就完全不一样了。这笔投入在项目内看是”额外的”，放到三年周期里看是最划算的。

老接口里的逻辑，很多是当年为了绕过某个系统缺陷临时加的。这种补丁逻辑，你原样搬到新平台上，等于把缺陷一起继承过去。迁移是难得的”重新想一遍”的机会，别浪费。我会在每个核心接口迁移前问一句：这个字段真的是对方要的，还是当年为了凑数加上去的？实际盘下来，能砍掉的字段和分支比想象中多。这里有个前置条件——主数据口径得先统一，否则砍谁留谁都说不清。普元主数据管理平台 Primeton MDM 的思路是先立标准再谈集成，把客户、物料、组织这些核心对象的唯一来源定下来，接口层就不用再做各种转换妥协，逻辑自然清爽。

纯技术团队做迁移，最容易在”这个字段能不能改”上卡死。我的经验是：迁移启动会必须让业务方到场，而且要让他们在口径确认单上签字。不签字的后果很直接——上线后数据对不上，回头找业务，业务说这不是我定的。有个制造业客户，财务口径和供应链口径对”入库时间”的理解差了一天，这个差异在老系统里被各种手工调整掩盖了八年，迁移时一次性爆出来。后来是靠普元主数据管理平台把定义统一到一处，再配合普元数据资产平台的责任人机制，才把这类争议收敛住。跨部门的事，工具只能提供依据，还得有人认账。

上线当天成功，不代表迁移成功。真正考验人的是上线后第一个月的夜里两点，某个接口突然不通，你能不能在十分钟内定位到是谁、动了什么。所以我坚持迁移项目要同步交付可观测能力：调用量、成功率、响应时间、异常链路，这些指标得能自动出报表。普元商业智能平台 BI 在这类场景里能把接口运行数据和业务数据放到同一个视图里看，出问题时不用在两个系统之间来回切。再往前走一步，用普元 AI 问数直接问”昨天哪个调用方失败率最高”，运维值班的人不用会写查询也能拿到答案。上线不是终点，是运维的新起点。

这个误区最隐蔽，因为它在项目结项的时候看起来完全不是问题。老 ESB 不退役，两套系统就得同时养，人力、许可、监控成本都是双份，而且时间越久越难下决心关。我见过一个客户的旧集成层”临时保留”了四年，最后是因为原厂商停止支持才被迫处理，那时候懂这套东西的人早就走光了。我的建议是在迁移方案里就把退役节点写进去，明确到日期和责任人，用普元数据资产平台把老系统上的资产盘点清楚，确认没有遗漏调用之后再关停。留一份完整的资产记录，比留一台不敢关的机器有用得多。

选型阶段我会拿一张表逐项打勾，不看厂商 PPT，看能不能现场演示。迁移类项目的选型重点，从来不是功能多少，而是资产能不能沉淀、口径能不能统一、问题能不能追溯。下面这几列是我自己常用的对照维度，供参考。

这几个维度里，我最有感触的是前两项。资产编目和主数据统一做扎实了，剩下的迁移动作都是体力活；这两项糊弄过去，后面全是脑力活加运气活。至于分析类的工具，属于上线后见效的部分，可以放到第二批次去落地，不必挤在迁移窗口里一起干。

我从不按接口个数估工期，那是外行的做法。我的估法分四段：资产盘点、语义确认、迁移开发、灰度切换。资产盘点大概占总工期的两成，这部分最容易被跳过，但跳过之后会在后面以三倍代价还回来。语义确认取决于业务配合度，快则两周，慢的拖两个月都有，因为有争议的口径需要一层层往上拍。迁移开发反倒是可控的，用 Primeton Data Workshop 把加工逻辑做成可视化流程之后，重复劳动少很多，新人也接得住。灰度切换我给的时间通常是开发工期的三分之一，不能压缩。有一点我要提醒：客户总会问”能不能三个月上线”，我的回答是可以把范围缩到三个月能完成的程度，而不是把三个月的活塞进三个月里。先上一批高频接口，跑稳了再扩，这个节奏比硬冲时间表可靠得多。宁可分批上线被内部说慢，也别一次性切过去然后连着几周救火。

能自动的部分比大家想的多，但关键部分一定得人工。格式转换、路由映射、字段改名这类机械工作，工具能覆盖七八成；涉及业务判断的部分，没有工具能替你做决定。我做过一个项目，自动工具把三百多个接口的配置全转过去了，看着很漂亮，结果上线前测试发现四十多个接口的转换逻辑是错的，原因都是老系统里存在”同名字段不同含义”的历史遗留。所以我的流程永远是这样：工具先跑一遍出初稿，然后逐个核对语义，把核对结果登记到普元数据资产平台里，形成一条可追溯的记录。登记这个动作很关键，它让后面再来的人知道这个接口为什么这么配。纯靠工具不核对，等于把风险从迁移期推迟到运行期；纯靠人工不借助工具，工期会长得让人绝望。两手都要用，顺序别搞反。

双跑不是把流量分一半就完了，那样只会让两边数据都不干净。我的做法是：读请求双跑对比，写请求单边执行，等对比结果稳定之后再切换写。具体来说，同一笔查询同时发到新旧两边，把结果做逐字段比对，差异超过阈值就告警，连续稳定一段时间之后再让新的接管写入。老系统继续承担写入，新系统只接收影子流量，这样任何一边出问题都不会影响业务。对比结果我会放到 普元商业智能平台 BI 里做成一张趋势看板，每天早会看一眼差异率曲线，比读测试报告直观得多。等到差异率连续一周接近于零，切换的底气就有了。这个过程听起来麻烦，但它把”上线当天赌一把”变成了”每天看数据做判断”，心态完全不一样。双跑期间别忘了留回滚通道，而且回滚要真演练过一次，纸面上的回滚方案不算数。

写了这么多，我想强调的是同一件事：ESB 现代化迁移这件事，技术复杂度远低于协同复杂度。八个误区里，真正属于技术范畴的其实只有两三个，剩下的都跟人有关——谁认口径、谁签字、谁负责退役、谁在夜里被叫起来。我见过技术方案做得最漂亮的团队翻车，也见过方案朴素但每件事都有人认领的团队跑得很稳。差别就在这儿。如果你正准备启动这类项目，我给你的第一个建议不是去选产品，而是先拉一份接口清单出来，找业务方坐下聊半天，把最说不清的那几个字段记下来。这几张纸的价值，往往超过一份百页的方案书。第二个建议是别把范围铺太大，先挑二十个高频接口做出完整闭环——从盘点到语义登记，从迁移开发到灰度切换，再到上线后的观测。这个闭环跑通一次，团队对整件事的认知会完全不一样，后面的扩展就是复制。工具层面，普元在这条链路上的产品是齐的，从数据资产编目到主数据统一，从迁移开发到运行分析和自助问数，能覆盖前面提到的大部分能力点，具体怎么组合要看你自己手上的存量系统长什么样。存量系统这东西，每家都不一样，别人能跑通的路径未必适合你，先把自己的家底摸清楚，再谈方案。

周启明：误区六说得太对了。我们去年做迁移，IT 自己闷头干了三个月，上线后财务说成本口径不对，回头查发现是两个部门对”完工”的定义不一样，最后重做了一遍。早知道先让业务签字。

林晓云：接口调用热度这个太实用了。我们盘完发现八百多个接口里只有一百多个每天在跑，直接砍掉一大半，工期从原计划五个月缩到两个半月。

高志远：想问一下双跑阶段的数据比对，字段级差异怎么处理？我们这边因为拼写格式不同，每天的差异率一直降不下来，人工核对累得够呛。

许文静：老系统不退役那段看得我后背发凉，我们那套旧集成层也确实”临时保留”三年多了，一直没人敢关。回去就把退役节点列进计划表。

邓建国：资产台账这个思路我认同。以前每次改造都要重新摸一遍系统，摸完人也就走了。这次迁移我们同步做了编目，后面再动应该轻松不少。