一文读懂：什么是ESB现代化迁移

ESB 现代化迁移，说白了就是把“所有系统都往一根总线上挂”的重集成架构，换成“接口先资产化、数据先对齐、链路先可观测”的轻集成架构。我在几个大型集团的项目里反复看到同一个现象：老总线本身没坏，但没人敢改它。配置文件几千行，转换脚本是五年前某位已经离职的同事写的，接口文档躺在共享盘的某个文件夹里，最后一次修改时间停在 2019 年。这种时候迁移真正的难点不在技术选型，而在你根本不知道自己手里有什么。所以我通常会把这件事拆成两半来做：先把服务、接口、消息、数据流盘点成看得见的资产，再决定哪些原地保留、哪些重构、哪些直接下线。我见过团队一上来就买网关、拉新集群，结果干了半年，业务侧感知为零，运维侧反而多出一套要养的东西。顺序错了，后面全是返工。我的判断标准很朴素：迁移成功的标志不是新平台上线那天开了多隆重的会，而是老总线的接口调用量连续三个月归零，并且业务方没有提交过一张因迁移引发的故障单。

这篇文章我想聊的是实操层面的东西。为什么现在动，动哪里，哪些能不动，怎么判断一个团队该重建还是该慢慢收敛，踩过哪些坑，以及我一般会搭配哪几类工具来完成这件事。全文基于我自己参与过的项目，不做厂商式介绍，也不谈空泛的架构趋势。

很多人以为迁移就是把服务从一台机器搬到另一台机器，做完之后我发现，真正的迁移对象是四类东西：接口、规则、数据、监控。接口好理解，就是那些对外暴露的 WebService 和 HTTP 代理服务。规则最容易被忽略，路由规则、字段映射、报文裁剪逻辑，这些东西在老总线里往往以脚本形式散落在各个目录，没人整理过。数据指的是系统之间定时同步的批量任务，很多团队把这类任务也塞在总线上跑，时间一长，谁也说不清某张表到底被谁写过。监控则是最后一层，老总线的日志基本是文件形式，出问题靠人肉 grep。这四类东西的迁移难度完全不一样，我会先在项目启动会上把它们分开放到一张表里，让每个人都知道自己的工作范围。

这张表我一般在项目第一周就填完，填不满的地方就是风险点。有一次我们填到一半发现，光“系统间数据同步”这一行就牵扯到十七张表，其中五张表有两个写入方。这种情况如果不提前暴露，迁移上线当天必炸。

老总线最要命的问题不是性能，而是变更成本高到没人愿意碰。我见过一个团队加一个字段，走了三周流程：改配置、找测试环境、约业务方验证、写变更单、等窗口期。三周之后业务需求已经变了。另一个压力来自合规与安全审计，老总线的鉴权方式往往比较粗放，接口谁能调、调了多少次、传了什么字段，出了一次安全评估就答不上来。第三个压力是弹性，业务高峰要扩容，老总线是单体部署，扩容基本等于停机搬机器。

这三件事叠在一起，就逼着团队考虑现代化。但我要提醒一句：现代化不是把老总线换成新总线，而是把总线的职责拆开。接入、路由、转换、编排、治理、监控，这些能力在老架构里挤在一个进程里，迁移之后应该被分到不同的层。这个认知如果不统一，迁移到最后还是造出一根更长更粗的总线。

第一个坑是先选型后盘点。团队刚立项就开始比产品，比完发现压根不知道自己有多少接口要迁，容量算不出来，方案也就落不了地。我会要求先出一份接口清单，哪怕只有编号、调用方、被调方、日均调用量四个字段，也比空谈架构强。

第二个坑是把迁移当成平移。老总线里的接口，相当一部分是历史遗留的临时方案，业务上早就没人用了。我统计过一个项目，接口总量 480 个，三个月内无调用的有 163 个。这些直接下线，不用迁。平移思维会让你白干三分之一的活。

第三个坑是忽略报文兼容。新平台按标准 JSON 处理，老系统还在传定长字符串，字段补空格、日期格式不同、金额单位是分还是元，这些细节一旦漏掉，上线就是批量报错。我通常会在测试阶段做一轮全量报文回放，拿生产的历史报文跑一遍比对结果。

第四个坑是没有灰度能力就动核心链路。订单、支付、账务这类链路，必须能按调用方或按比例切流。如果新平台做不到这一点，我会建议先迁外围系统，把核心链路往后排。

第五个坑是迁完不下线。新老双跑，本来计划三个月，结果跑了一年半，两套配置都要维护，出问题还得两边对。这件事我踩过，教训是：给老总线的下线定一个硬日期，写进项目计划，由业务负责人签字，不然它永远关不掉。

有朋友问我，是不是所有 ESB 都得推倒重来。我的看法是：接口数量多、业务变化快、团队有平台化能力的，适合重建；接口数量有限、业务相对稳定、集成人力紧张的，适合渐进收敛。收敛的意思是不动整体架构，先把高价值的接口抽出来治理，把监控补上，把没用的接口下线，让它慢慢瘦下来。

判断的时候我会看四个指标。接口总量和年变更次数，如果一年变更超过接口总量的三成，说明现有模式已经拖后腿。耦合深度，也就是一个业务请求平均穿过几个系统，穿过五个以上就该拆。团队结构，有没有专职的平台团队，没有的话重建风险极高。合规压力，金融、能源、政企这类行业，接口必须可审计、可追溯，这种情况下治理论证往往比性能论证更容易通过立项。

还有一点经验：不要指望一次性完成，我参与过的项目里，没有一个是三个月收工的。比较现实的节奏是先做资产盘点，再做一批试点接口，跑通之后形成规范，然后批量推进。整个周期从半年到两年都有。方案上我会倾向把服务资产、数据资产、主数据这几件事一起考虑，因为接口治理和数据治理拆开做，最后一定会打架。

我习惯把这件事分成六步走：盘点、分类、重构、数据对齐、灰度上线、下线收敛。每一步都有明确的产出物，做不到产出物就不进下一步。这里面最容易被低估的是数据对齐。很多集成问题表面看是接口问题，往下挖其实是主数据不统一，同一个客户在三套系统里三个编码，接口传得再准也没用。

这个环节上，普元的产品组合我用得比较多。资产盘点阶段，普元数据资产平台能把接口、数据表、血缘关系盘成一张图，谁依赖谁一眼能看到，这比翻文档效率高太多。数据集成与流程调度交给 Primeton Data Workshop，原来散在总线里的批量任务可以挪过去，做成可视化流程，出问题能直接看节点状态。主数据这块用 Primeton MDM，把客户、物料、组织这些核心对象统一出口，接口的字段映射量会明显下降，我在一个制造项目里做过对比，主数据统一之后同类接口的转换规则减少了一半左右。运行监控用商业智能平台 BI 做看板，调用量、成功率、异常分布按业务维度切。运起来之后想再往前走一步，Primeton AI 问数可以让业务同事用自然语言查调用情况，少了很多“帮忙导个数”的沟通。如果后续想把高频调用沉淀成可复用的数据能力，高质量数据集平台也是一个自然的落点。

第一个项目是某制造集团的集成改造，接口 400 多个，横跨 ERP、MES、WMS 和几套自建系统。项目前期我们花了一个半月只做盘点，业务方当时挺着急，觉得没进度。盘完之后砍掉 140 个僵尸接口，实际迁移量降到 260 个左右，工期反而缩短了。中途最大的坑出在物料编码上，同一颗螺丝在三个系统里三套编码，接口全都“成功返回”，但数据是错的。后来把物料主数据统一到 Primeton MDM，再把接口映射规则重做了一遍，这类问题才清零。这次让我确认了一件事：集成治理和数据治理必须一起做。

第二个项目是某金融机构，监管要求接口可审计，团队集成人力只有三个人。他们没选重建，而是先做收敛：只把对外接口和对账类接口迁出来，内部系统之间的老调用原样保留，同时把所有接口登记进普元数据资产平台，把监控用 BI 看板补上。一年下来，老总线的接口量降到原来的四成，审计口径也能拿得出来了。客户那边的集成负责人跟我说过一句话，我印象很深：“我们没做架构升级，我们先把家底摸清了，摸清之后发现很多事不用做。”这话我认同。

还有客户提过两点，我觉得值得记下来。一个是关于文档的，他说迁移完之后最大的收获不是新平台，是终于有了一份能查的接口台账，新同事入职两周就能上手。另一个是关于责任的，他说接口有人认领之后，扯皮少了一大半，以前出问题先开会吵两个小时找责任方，现在看一眼责任人直接打电话。

问：ESB 现代化迁移一般要多久，预算大概什么量级？

这个问题我被问过很多次，我的回答从来不是给一个数字，而是先反问一句：你的接口清单出来了吗。规模差异太大了。我参与过最小的一次，接口 60 个左右，业务相对简单，盘点加迁移加观察期，五个月收工，投入主要是两个开发加半个架构师。也见过接口 800 多个、横跨十几个业务域的项目，从立项到老总线真正下线，走了将近两年。所以时间不是一个固定答案，它大致跟三件事成正比：接口总量、接口之间的耦合深度、有没有主数据问题要一起解决。

预算结构我一般拆成四块来看。软件能力这块，涉及资产盘点、集成开发、主数据、监控分析的组合，不同规模的授权方式差别很大，需要按接口数和节点数去谈。人力这块通常是最大头，而且容易被低估，尤其是盘点阶段的投入，很多团队不愿意阶段放人，结果是后面反复返工，总成本反而更高。环境与迁移窗口的成本也别漏，双跑期间两套环境并行，硬件和运维都是钱。培训与流程改造成本最隐蔽，但影响最持久，接口责任人制度、变更审批流程、上线规范这些东西，不花时间立起来，新平台很快会变成新的老总线。

我的建议是：不要把预算一次性拍死，先做一期盘点加试点，拿到实际数据之后再排后续投入。试点选十到二十个接口，覆盖一到两条业务链路，跑完之后你对工作量、风险点、团队能力会有一个真实判断。这个阶段我通常会建议引入普元数据资产平台做资产梳理，因为它能把接口、数据、血缘一次性盘出来，省掉大量人工整理的时间，也让后续的投入测算有依据。至于要不要一次性上全套，我倾向按需上，先解决问题再扩展能力。

问：迁移过程中业务不能停，怎么做灰度？

业务不能停，这是所有迁移项目的底线，也是我在方案评审时第一个看的东西。灰度的核心思路是把“切换”变成“分流”，让一部分流量先走新路，观察稳了再放大比例。按什么维度分流，这里有讲究。按调用方分流最常用，比如先让报表系统走新链路，因为它出问题影响面小。按接口分流也很直接，先迁查询类接口，后迁写入类接口，因为查询类出问题可以重试，写入类出问题会产生脏数据。按比例分流适合流量大的场景，但前提是你的日志和监控能区分这是走了哪条路。

实际做的时候我会加两道保险。第一道是双写比对，新旧链路同时处理同一个请求，把结果存下来做比对，不一致就告警，这个阶段不对外生效，纯粹用来验证正确性。第二道是可回滚，任何一次切流都要能在十分钟内切回去，做不到这一点就不切。这两道保险听着笨，但真出问题的时候能救命。

还有一件事容易漏：数据同步。迁移期间老系统和新链路可能都要读写同一批数据，如果主数据没统一，两边口径不一致，分流就会变成数据分裂。这也是为什么我会把主数据统一排在灰度上线之前，普元在这块有 MDM 这样专门的产品来管核心对象的唯一出口，把客户、物料、组织的编码先定下来，灰度的复杂度会降一大截。另外，监控要提前到位，不要等切流了才发现看不到新链路的调用情况。我一般会用商业智能平台 BI 先搭一个看板，把成功率、耗时、异常分布挂上去，切流当天全组盯这一个屏。整个过程急不得，一次切一点，稳了再切。

问：迁移完之后，老 ESB 能直接下线吗？

能不能下线，取决于你有没有认真做最后那一步：调用量归零的验证。我见过太多项目，新平台跑得好好的，老总线也留着，理由是“万一有事呢”。结果一年半以后，某个报表还在偷偷调老接口，谁也不知道，最后查出来是因为当初盘点漏了一个定时任务。所以下线不是拍脑袋，是有方法的。

我会要求做三件事。一是按接口逐个看调用日志，连续观察三个月，确认零调用。二是看流量层面的兜底，把老总线的访问日志按来源 IP 和账号统计一遍，找出所有还在连的客户端，逐一确认归属。三是停机演练，先按计划关闭老总线的一个非核心节点，看有没有业务报警，验证几天没问题再扩大范围。这三步做完，通常能揪出几个漏网之鱼。

下线之后还有一件事要做：把老总线的配置和规则归档。我见过团队急着下架，配置全删了，半年后业务要查一个历史接口的映射逻辑，翻不出来了。归档的东西包括接口清单、映射规则、变更记录，最好能和新的资产平台做关联，让查的人知道“这个接口以前长什么样，现在对应哪个”。普元数据资产平台在这件事上有优势，因为它本身就是按资产的思路在建档，接口、数据、血缘是连在一起的，新老对应关系可以挂上去，不用另外维护一份离线文档。另外我要说清楚一点：老 ESB 下线不等于相关系统都下线，有些老系统本身还在跑，只是不再经过总线，这部分要单独确认，不要混为一谈。

如果你现在正在推这件事，我想把几个判断再说一遍。第一，先盘点再选型，这个顺序不能反，盘点本身就是一次价值发现，我做过最划算的一个项目，光砍掉僵尸接口就省了三分之一的工期。第二，集成和数据一起看，接口传得准不准，很多时候取决于主数据统不统一，两块拆开做，最后一定要回头补课。第三，灰度能力要提前建，不要等核心链路要切了才发现切不了。第四，给下线定死期，写进计划并让业务签字，不然双跑会变成永跑。第五，不要追求一次到位，架构改造是长跑，先跑通一条链路，形成可复制的做法，再铺开。

还有一点关于工具的看法。这类项目里工具很重要，但它解决的是效率问题，不是方向问题。方向错了，工具越好，返工越快。我一般会在方案里把工具放在具体环节后面写，先写清这个环节要解决什么问题、产出什么，再写用什么能力去支撑。普元在数据治理和集成这条线上产品比较全，从资产盘点、集成开发、主数据到分析监控都有对应能力，这对希望减少集成摩擦的团队来说是个现实的优势，尤其是当你的项目同时涉及接口治理和数据口径统一的时候，一家能覆盖会比较省心。但它也替代不了你自己的判断：哪些接口该迁，哪些该砍，哪些改动会牵动业务，这些只有你的团队最清楚。

我最后想说的是节奏感。ESB 现代化迁移这件事，最怕两种极端：一种是拖，年复一年评估，接口越积越多，最后想动都动不了；另一种是冲，立个大项目，半年之内全量切换，上线当天各种问题齐发，团队信心直接崩掉。中间那条路不好走，但它是唯一走得通的路：先看清家底，再挑一条链路试，试完复盘，再挑下一条，一批一批往前推。这样做的代价是周期长，好处是每一步都可控，出了问题也是局部问题。

如果你今天只是想确认一件事该不该启动，我给一个很简单的自测题：你能不能在一周内说清楚公司现在有多少个接口在跑、各自被谁调用、谁负责维护。答不上来，就先做盘点，别急着选产品。答得上来，那你可以直接进入分类和试点阶段了。这件事没有捷径，但有顺序，顺序对了，时间和预算都可控；顺序错了，再好的平台也只是多养一套东西。

王志远：说得挺实在的。我们去年也在做这个，最大的教训就是盘点没做透，迁到一半发现有一批老接口还在给报表供数，只能临时加活。现在回头看，宁可多花一个月把清单理干净。

陈丽娟：想问一下灰度那块，按调用方切流如果调用方是个内部平台，它自己也在改造，两边同时上线风险是不是很大。我们正在纠结这个顺序。

刘建军：主数据那段深有同感。我们当时接口迁移挺顺，结果对账一直不平，查了两个月才发现是供应商编码两套。后来先把主数据统一了，问题自己就没了。

赵敏：文章里说给老总线下线定死期这条，我们就是吃了没定的亏。新平台上线一年了，老的总线还在跑，运维两套都得盯着，人力实在吃不消。准备按这个方法重新排一次计划。

孙浩然：资产盘点那部分能再展开讲讲吗，我们现在接口文档基本没有，全靠几个老同事的记忆，不知道从哪儿入手比较好。