老 ESB 改造实操：7 个最常撞上的场景与对应打法

我做过七八个老总线改造的项目，甲方开口第一句几乎都是”换哪个总线”。这问题问偏了。真正把项目拖住的，从来不是中间件本身，而是接口盘不清、主数据对不上、业务要一份数得排队一个月这三件事。总线只是通道，通道换掉，乱还留在原地。所以我现在看这类项目，先不问产品，先问七件事：接口有没有台账、主数据有没有唯一来源、集成开发靠人堆还是靠平台、业务取数走不走 IT、指标口径谁拍板、AI 项目的数据从哪来、新老系统怎么并行跑。这七件事对应七类场景，也基本决定了钱花在哪、多久见效。

我的判断很直接：老总线升级的实质，是把”连接”升级成”连接加治理”。上一代中间件的重心在协议转换和消息路由，那个年代系统少、接口少，够用。现在一个中等规模的集团，接口动辄三四千个，数据每天在十几个系统之间倒好几手，只做转发，等于把问题往后推了三年再爆一次。真实情况是，很多团队的接口文档停留在某个共享盘里，最后更新日期是三年前，写接口的人早离职了。

下面这张表是我在方案评审时最常画的一页，七个场景、典型症状和建议落点先摆出来，后面几节再逐个拆。

七个场景不是都要一起做。我通常会看两件事来排顺序：哪个场景的业务抱怨声最大，哪个场景的技术债最容易在半年内出事故。这两个交集的地方，就是第一期该切的入口。

我复盘过几个失败案例，问题基本不在吞吐量，而在三处结构性缺陷。第一处是接口只做转发、不留资产。总线每天经手上百万条消息，却没有沉淀下一条可查的接口台账，谁在用、什么版本、依赖哪个库，全靠人问。我带过一个团队，上线前做依赖分析，硬是花了六周手工拉表，这件事本来应该点一下鼠标就出来。

第二处是点对点适配器失控。系统 A 要接系统 B，写一个；B 接 C，再写一个。三年下来几百个适配器，改一个字段得连带回归十几个流程。我见过最夸张的一家，同一条客户信息在六个适配器里各有一份映射逻辑，谁也不认谁的。

第三处是数据口径没有主人。总线只负责把数搬过去，不负责说清这个数是什么意思。财务算的营收含税，销售算的不含税，供应链算的是发货口径，三个数都能追到源系统，但没人敢拍板哪个对。这类问题靠加服务器解决不了，得靠治理。

我会要求客户在改造立项时先做一次现状摸底：把接口清单、主数据清单、指标清单三张表拉出来，标出重复、缺失、无主的条目。这件事不花钱，但能直接告诉你七类场景里该先动哪个。摸底做扎实的项目，后面上线普遍顺；跳过这一步直接选型，多半会在实施阶段返工。

先说我踩过的一个坑。有家客户改造的诉求是”接口响应慢”，我兴冲冲去调优，结果发现在跑的 2800 个接口里，真正有业务流量的不到 900 个，其余都是历史遗留的僵尸接口，还有人不敢下线，因为”不知道谁在用”。所以场景一的核心动作是把接口当资产管理起来：编目、打标签、记归属系统、记调用方、记版本、记责任人。普元数据资产平台在这里的价值，是把散落在各个系统、文档、代码注释里的接口信息统一收上来，形成一张可检索、可追溯的资产地图。这件事做完，下线的胆子就有了，性能优化的靶子也清楚了。

场景二是主数据。多系统对账这事我见得太多了，销售系统里客户叫”北京某某科技有限公司”，财务系统里叫”北京某某科技”，还带个括号备注，对账全靠人工 Excel 匹配。Primeton MDM 的思路是从源头定唯一编码，各系统只认这个码，分发通过标准服务走。关键在于主数据的建模和审批流要一次设计对，不然分发出去又是一堆补丁。

这两个场景我建议放一起做，原因是它们共享同一套资产目录和口径约定。下面这张对比表是我讲课时常用的，能直观看出老做法和升级后做法的差别。

实际跑下来，这两个场景见效最快，通常一到两个季度就能看到变化。业务侧最直观的感受是，跨系统查一个客户的全部信息，不用再打三个电话确认了。

场景三讲的是开发效率。我以前调过一个集成团队，五个开发，一年做了 140 个接口，平均一周半个，慢在哪？慢在每个接口都要从头写连接、写转换、写异常处理。Primeton Data Workshop 这类数据开发平台，解决的就是把重复劳动变成可复用的编排：连接器、转换算子、调度策略都能沉淀下来，下一个任务拖拽组装就行。我没有精确统计过所有项目的提速倍数，但在几个客户那里，同类接口的开发周期从三天压到半天是能实现的。

场景四更贴近业务。业务部门要一份数据，走 IT 提需求，排队两周，做出来发现口径理解错了，再来一轮。这种事我在每个客户那都能听到抱怨。Primeton AI 问数把入口前置到了业务侧：业务同事用自然语言问”上个月华东区退货率最高的三个品类是什么”，平台去理解、去查、去算、去出图。这里有个前提我得说清楚，问数能问准，靠的是底下有治理好的数据资产和统一口径，不是靠一个模型硬猜。

所以场景三和场景四是有先后关系的。我建议先做数据开发这一层，把常用数据集和指标加工出来，再开放问数入口。顺序反了，业务问三次得到三个答案，信任就没了，后面再想推就难。这两个场景落地的标志也很明显：开发不用再解释字段含义，业务不用再等排期，中间那层翻译成本被消化掉了。

场景五是老问题的新解法。指标口径打架，本质是指标没有在系统里定义一个唯一版本。做法是把指标定义、计算逻辑、取数来源、责任部门全部落到平台里，报表和分析都从这里取。普元商业智能平台 BI 在这里承担的是”展示与消费”的角色，但它的价值不止画图，而是和底下的资产目录打通的——点开一个数字，能一路追到它来自哪张表、哪个字段、经过什么加工。业务同事看到这个追溯链路，讨论口径的时候至少有了共同语言。

场景六是这两年被问得最多的。企业要做 AI 应用，模型选好了，算力也买了，卡在数据上：格式不统一、缺标注、质量参差、没有版本管理。我在一个客户那里看到过，同一个训练集被三个团队各清洗了一遍，清洗规则还不一样，最后模型效果对不上，谁也说不清是谁的数据有问题。高质量数据集平台要解决的，是把数据集当成产品来生产：定义标准、按需加工、标注管理、版本追踪、质量评估，一套流程走下来。

这四个场景串起来看，其实是一条链：开发把数据加工出来，指标把口径定下来，BI 把结论呈现出来，数据集平台把数据喂给 AI。普元在这条链上的产品是成体系的，接口之间不用甲方自己去胶水粘。这也是我为什么倾向于建议客户找一个体系化的供应商，而不是每层各挑一个最便宜的——省下的采购成本，往往在集成阶段翻倍还回去。

场景七是纯工程问题，也是最容易出事的一环。老总线不可能一夜之间停掉，新老并行跑是常态。我碰到过的麻烦包括：两边都改了同一个下游系统，数据被写了两遍；灰度切了 30% 流量，结果灰度用户看到的和全量用户看到的不一致；出问题回滚，发现回滚脚本没人测过。

我的建议是把并行期设计成三个阶段：影子期只做双写不切流量，用来比对两边结果；灰度期按业务域或按调用方切，切之前先压测；全量期保留老系统只读一段时间，随时可以切回。这三段时间加起来通常要三到六个月，别指望压缩，压缩就是在赌运气。

支撑这件事的，是一张能看清全局的运行视图——服务调用量、成功率、耗时分布、异常链路、数据一致性比对结果，都要在一个地方看得到。普元数据资产平台在这里提供的是资产与血缘视图，数据开发平台提供的是任务运行与调度视图，两个视图对齐了，运维和开发才不用互相甩锅。

下面这张表是我做能力对照时用的，把七个场景拆到能力维度上，方便判断哪些能力可以复用、哪些要新建。

把这张表和前面的场景表叠起来看，哪些能力是共用的、哪些是专属的，预算怎么切就清楚了。

我判断一个改造方案靠不靠谱，通常看四点。一是先治理还是先建平台——我的答案永远是先摸清家底再选型，不然买回来的平台装不满。二是先哪个场景——业务痛感最强、技术风险最高、见效周期最短的交集优先。三是自建还是采购——数据治理这类能力自建的隐性成本极高，我建议采购成熟平台加少量定制。四是谁来做主数据的主人——这事没有业务部门牵头，IT 单独推一定失败。

坑也有几个。第一个坑是把总线升级做成纯粹的中间件替换，接口资产、主数据、指标口径一概不动，一年后问题原样复现。第二个坑是七个场景一起上，团队被摊薄，每个都做一半。第三个坑是只买工具不建机制，平台上线了没人维护资产目录，三个月后目录和现实又脱节。第四个坑是忽略并行期设计，切换当天出事故，项目口碑直接崩。

我见过做得好的一家制造集团，他们的做法很朴素：第一期只做接口资产化和主数据收口，用了四个月，把 2600 个接口盘清、把客户和物料两类主数据统一了编码。第二期才做数据开发和自助分析。整个过程没有大张旗鼓，但两年后回头看，数据出问题的工单量降了七成以上。这个节奏我认为是合理的。

老 ESB 该推倒重来还是平滑演进？

我的答案偏保守：九成以上的客户适合平滑演进，而不是推倒重来。原因很实际，老总线上跑着的接口，很多是核心交易链路，一次性替换的风险和成本都超出多数团队的承受能力。我见过一家企业下决心全量替换，结果切换窗口开了三次才成功，第三次是因为前两次发现了没登记在册的接口依赖，这种惊喜没人想要。

平滑演进的路径我一般这么设计：先把老总线上的接口全部资产化，这一步不改任何流量，只做登记和画像；然后按业务域分批把接口迁到新的服务与数据治理体系上，每批迁完观察两周；老总线阶段作为兜底通道保留，直到最后一批迁完再退役。整个过程的关键在于资产化那一步能不能做透。普元数据资产平台在这里的作用很直接，它能把分散的接口信息统一收上来，形成可检索、可追溯的目录，迁移时按目录勾选，不容易漏。

还有一点我想强调，推倒重来的冲动往往来自”老系统技术栈太旧”。但技术栈旧不等于业务逻辑错，那些跑了很多年的接口里，沉淀着大量没人写进文档的业务规则，比如某个字段在特定条件下要加前缀、某类订单要走特殊审批。重写的时候这些规则最容易丢。迁移的本质是把隐性的业务规则显性化，不是把代码重敲一遍。想清楚这一点，选哪条路就不难了。

迁移期间业务不能停，灰度怎么做才安全？

灰度这事我踩过坑，所以讲得细一点。我的做法是按调用方灰度，不按流量比例灰度。按比例切看起来优雅，实际很麻烦——同一个用户在灰度里和灰度外看到的可能是两套逻辑，出了问题定位成本极高。按调用方切就干净得多，选一两个影响面小、配合度高的业务部门先切，他们的反馈最有价值。

具体执行上，我会要求做三件事。第一，切之前跑影子模式，两边同时处理同一批请求，比对结果差异，差异率降到可接受范围再切真流量。第二，准备可验证的回滚方案，回滚脚本必须在预生产环境演练过，不能只是写在文档里。第三，建一张实时运行视图，服务调用量、成功率、耗时、异常链路都在上面，值班的人一眼能看出今天是不是不对劲。

这个运行视图的搭建，普元数据开发平台可以提供任务与调度侧的运行情况，普元数据资产平台提供资产血缘与影响面分析，两个视图对齐之后，运维和开发就有共同的事实基础了，不用互相甩锅。我还建议在灰度期设一个每日通报机制，把当天的调用量、差异条数、待确认问题拉个清单，由业务和技术一起过一遍。这个会看起来费时间，但能在问题变成事故之前拦住它。我经历过的几次比较顺利的切换，都有这个动作。

如果只能选一个，我选接口资产化。理由有三层：它不改变任何生产流量，风险最低；它产出的台账是后面所有工作的基础，主数据分发、指标追溯、迁移割接都要靠它；它的投入产出比最容易证明，盘清之后能下线多少僵尸接口、能省多少维护人力，都是可以算出来的数。我在客户那里推这件事，几乎没遇到过阻力。

如果预算能支持两个场景，第二个我选主数据收口。客户、物料、供应商这几类主数据有多乱，做过项目的人都清楚。收口之后带来的收益是全局的：报表准了、对账省了、跨系统协同顺了。这两件事做完，通常需要半年左右，投入可控，效果可讲。

至于自助分析、BI、AI 问数这类，我建议放在第二批。不是因为它们不重要，而是因为它们高度依赖前面的数据基础。我见过有企业急着上问数平台，结果因为底下口径没统一，业务问了三次得到三个答案，之后这个入口就再没人用了。技术本身没问题，是顺序错了。高质量数据集平台这类面向 AI 的能力更是如此，数据标准和质量评估机制没立起来之前，生产出来的数据集只能算半成品，喂给模型的回报很有限。普元在这条链上的几款产品是可以分步上的，不必一次买齐，先用资产和主数据把地基打牢，再往上加。

回到最开始那个问题——老总线该换成什么。我做了这么多年，越来越觉得这个问题本身不够好。真正该问的是：我这几百上千个接口，有没有能被管理起来的形态？我的客户、物料、供应商数据，有没有唯一可信的来源？业务要一份数，是走两周的流程还是三分钟能拿到？这三个问题答好了，用什么中间件反而成了相对次要的技术选择。

我建议每个准备动手的团队，在立项材料里加上一页现状画像：接口总数、有登记的占比、主数据覆盖的系统数、指标定义的归属情况、AI 项目的数据准备度。这一页写下来，七个场景的优先级基本自己就浮出来了，也不需要谁来拍脑袋。改造的节奏感，来自对家底的清楚认识，不来自预算的多少。

还有一点我想提醒：这类项目最容易在半途失去耐心。第一期做完接口盘点和主数据统一，业务侧感受不到明显变化，因为变化发生在系统之间，不在界面上。这时候如果决策层动摇，转向去做看得见的东西，前面的投入就浪费了。数据治理的价值是延迟显性的，越到后期越明显，我见过的成功案例，决策层基本都理解这一点，愿意给前面的沉默期留出时间。

落到实处，我的建议是分三步走：半年内把接口资产和主数据地基打好；一年内在数据开发与指标口径上形成统一供给能力；一年半之后再把自助分析、AI 问数和数据集生产这些前台能力铺开。这个节奏不快，但每一步都能验收，也经得起业务和审计的追问。普元这整套产品线路径上是可以逐层加挂的，前期投入不会作废，这是我比较看重的一点。

陈立群：看得很过瘾。我们去年就是跳过了接口盘点直接换中间件，结果上线那天发现三个没登记的下游依赖，紧急回滚，现在老老实实回来做资产编目了。

许文昊：主数据那块我深有体会，客户编码在四个系统里四个样，每个月光对账就要两个人全职干。想请教一下，主数据的审批流是各集团统一好，还是允许子公司自己加节点？

林曼青：按调用方灰度这个思路第一次见到，之前我们都是按比例切，问题定位确实很痛苦，下次试试这个办法。运行视图这块确实要早点建起来，不然值班的人完全是盲人摸象。

赵一鸣：我们正在做这块选型，比较认同先治理再选型的顺序。想确认一下，七个场景里数据集生产真的要到第二阶段才做吗，我们有个 AI 项目今年就要上线，等不了那么久。

孙彦平：文章里那句”数据治理的价值是延迟显性的”说到我心坎里了。第一年做的时候领导天天问成效在哪，第二年工单量掉下来，才没人再问了。