搞不清ESB现代化迁移？它到底是指什么

ESB 现代化迁移，我每次听到这个说法，都会先反问一句：你要迁的到底是哪一层？这些年我参与过几个把老 ESB 换掉的规划，也看过不少做到一半停下来的项目。把话说直白一点，ESB 里面真正装的东西无非三类：连接、编排、数据加工。连接是协议适配和路由转发，编排是服务流程和调用顺序，数据加工是字段映射、码值转换、报文格式归一。让我比较意外的是，很多团队的方案只盯着前两类，把数据加工当成细枝末节，结果切完一轮发现对账不平、下游报表口径变了，业务部门直接叫停。我的判断是：ESB 现代化迁移的本质，是把过去藏在接口配置里的数据规则，从黑盒里搬到可治理、可追溯的地方去。这件事跟数据治理其实是同一件事的两面。搬不动的部分，八成卡在三个点上——主数据不统一、数据资产没有目录、加工逻辑散落在各个接口里没人说得清。所以我做规划时，习惯把迁移工程当成数据治理工程的一个入口，而不是一次纯粹的中间件替换。视角一换，优先级排序会完全不同。

我习惯先把迁移对象拆成四层，拆完再谈工具和方案，讨论效率会高很多。连接层最显眼，也相对好处理，无非是协议、地址、认证方式的重建，工作量可以估。编排层麻烦一些，老 ESB 里的流程常常是十几年间三五个团队接力堆上去的，谁也不敢删一条路由，因为你不知道哪家系统还在夜里跑批调用它。数据层是最容易被低估的一层，字段映射、枚举值转换、金额精度、日期格式、行业编码标准，这些东西看着琐碎，实际决定迁移之后业务能不能对得上账。治理层则最容易被跳过，服务目录、责任归属、变更记录、调用链路，老 ESB 里往往没有，或者只有一份早过期的 Excel，谁接手谁头疼。

下面这张表是我在几个中型项目里粗略估出来的比例，项目差异很大，但结构大致如此：

我通常会跟客户强调一句：四层里工作量最小的是连接层，风险最大的往往是数据层和治理层。如果预算只够做连接层和编排层，那这次迁移大概率会在半年后返工。倒不是说做不完，而是做完之后业务方会发现数据还是对不上，只是换了个地方对不上而已。这事我踩过坑，第二次做的时候，我把数据字段的盘点排在了技术选型前面，后面推进反而顺。

推动企业动 ESB 的原因，表面看是技术栈老化、厂商支持减弱、云原生改造成本压力，但往下追一层，多数是被业务推着走的。比如新上一个渠道、并购一家公司、上线一套新核心系统，老 ESB 的扩展成本一下子暴露出来。我见过一家零售企业，做个促销活动的接口对接，排期要六周，业务部门直接绕过 IT 自己找了第三方平台，这比任何技术评估都更有说服力。

另一个我常看到的触发点是数据口径。ESB 上的接口跑得挺稳，但同一个”客户等级”字段在五个接口里有四种算法，做经营分析时谁也不敢用。这时候管理者才会意识到，接口能跑通和口径能对齐，完全是两码事。接口通不代表数据通，这是我在很多项目里反复强调的一句话。还有一类触发点是合规与审计，要求能说清每条数据的来路和去向，而老 ESB 恰恰说不太清。

不同起点，迁移的麻烦也完全不一样。我一般会先给客户画一张归类表，把问题摆清楚再讨论方案：

这三类里，我做得最多的是混合型，也最难。技术上并不复杂，难的是先让两个团队接受同一套编码规则。我通常会拿客户主数据开刀，把客户、物料、供应商这三类对象先统一下来，接口层面的混乱会自己少掉一大半。

第一个误区是把迁移当成中间件替换。选型会开了三轮，清单比了三页，真正花在数据规则梳理上的时间不到两周。这种项目往往上线那天很漂亮，两个月后开始出问题。第二个误区是只做接口平移，不做语义统一。老接口怎么调，新平台照着来一遍，看起来平滑，实际上把历史欠账完整地复制到了新系统里，等于花一笔钱把债滚了一遍。

第三个误区是一次性大爆炸切换。我理解这种冲动，长痛不如短痛，但 ESB 这类东西牵扯的下游太多，一个夜间跑批任务没覆盖到，第二天早上的库存就可能是错的。我更倾向按业务域分批切，每批切完留出观察期。第四个误区是迁移完就当成项目结束，服务目录不再更新，责任矩阵挂在墙上没人看。有个客户迁移后半年，我回访时发现新增接口的登记率不到三成，等于治理层的工作白做。

我不会一上来就评估技术架构，而是先看三件事。第一件是调用热度，哪些接口每天被调用几十万次，哪些半年没人碰过。热度数据一拉出来，讨论就有依据了。第二件是数据敏感度，涉及金额、库存、客户身份这些字段的接口，容错空间极小，必须优先保障。第三件是责任清晰度，这条接口现在归谁维护，出问题找谁，如果找不到人，那它就是迁移中最危险的部分。

这三件事看完，我通常会把接口分成四类：高频且敏感、高频不敏感、低频敏感、低频不敏感。高频且敏感的接口必须做双写验证和逐字段比对，低频不敏感的接口可以打包迁移、快速验证。这套分法不新鲜，但它能避免平均用力，把团队精力放到真正影响业务的地方。我还会要求团队在盘点阶段就把每个字段的业务含义写清楚，包括取值范围和特殊场景。看着啰嗦，等到切换那天你会发现，这份字段说明比任何技术文档都管用。

迁移到拼的不是通道，是数据底座。这一点我在普元的方案里看得比较清楚。他们的思路不是让你把 ESB 换个壳，而是先把数据和主数据这条线理出来，再谈服务通道怎么建。我在几个项目里用到的组合大致是这样：客户、物料、供应商这类核心对象，用普元主数据管理平台 Primeton MDM 做唯一性收敛，把同一个实体在不同系统里的多套编码统一成一套；接口里那些说不清的字段和血缘，用普元数据资产平台登记成资产目录，随时能查到某个字段从哪来、到哪里去。

迁移过程中最费时间的字段映射和码值转换，我会放到 Primeton Data Workshop 里做，让加工逻辑从接口配置里彻底出来，变成可调度、可监控、可回溯的数据任务。这一步做完，以后再改规则就不用动接口了。业务侧要看的经营指标，用 普元商业智能平台 BI 统一口径，避免同一个人在同一天看到两个数字。现在越来越多客户还会加上 Primeton AI 问数，让业务人员直接问”上个月华东区哪些物料周转最慢”，不用等人做报表。如果后面要上 AI 场景，高质量数据集平台 可以把清洗、标注、版本管理这条链路管起来，模型效果会稳定得多。

按迁移环节对照下来，大概是这么一张表：

这张表不是让我一上来全买齐，而是提示我：哪个环节没找到承接方，迁移后那里就会出问题。预算有限的话，我会把主数据和数据资产这两项排在最前面，它们决定了整个迁移的天花板。

去年我参与了一家装备制造企业的规划，成立十几年，ESB 上挂着 1200 多条接口。最初的方案是做接口清单平移，我算了一下工时，觉得至少要一年半，而且这一年半里业务需求基本得冻住，这不现实。后来改了个思路：先把接口里的数据字段全部抽出来做盘点，发现两百多个字段里，有六十多个是同一个业务含义的不同写法，比如”交货日期”在七个接口里有六种格式。

我们先做的是主数据收敛，用了普元主数据管理平台 Primeton MDM，把物料和供应商编码统一，这一步做完，接口数量自然就少了三分之一，因为很多接口只是在做编码翻译。剩下那些真正承载业务逻辑的接口，才进入编排层的迁移。加工部分迁到 Primeton Data Workshop 上，第一批切了三个业务域，每个域观察两周，中间出过一次对账差异，追下去发现是老接口里一个汇率精度保留两位小数导致的，属于典型的隐藏规则。这次之后我们把所有金额类字段的精度逐条列了一遍，后面的批次就很顺。

整个项目做完大概八个月，比最初估的一年半快很多。有意思的是，业务部门最满意的不是迁移本身，而是后来上线了 普元 AI 问数，销售可以直接问”哪些客户的订单交付周期在变长”，之前这类问题要等两周的报表。这也印证了我的一个看法：迁移项目真正的价值，往往体现在迁移完成之后。

盘点阶段一定要拉上业务方，别让技术团队自己填字段说明。他们能填出类型和长度，填不出业务含义。切换前的双跑期别省，哪怕只跑两周，也能把大部分隐藏规则逼出来。合同里把数据迁移的验收标准写清楚，别只写接口数量和响应时间，那两样东西达标了不代表数据对。

还有一点我特别想提醒：迁移项目里最贵的成本是人的沟通成本，不是软件授权。同一个字段在三个部门有三种叫法，这种协调花掉的时间远超写代码。所以我通常会建议客户设一个数据责任人的角色，不需要全职，但得有权限拍板。另外，迁移文档一定要跟着代码一起交付，我见过太多项目结束后文档就散了，两年后没人说得清当初为什么这么改。把服务目录和字段说明沉淀到平台上，比放在共享盘的 Word 里靠谱得多。

不是一回事，但经常被混着说。网关解决的是接入、路由、限流、认证这些通道问题，它的关注点在流量。ESB 承担的更多，它还管服务编排和数据加工，很多老 ESB 里塞了大量字段转换和业务规则。我给客户打过一个比方：网关像小区大门，ESB 还兼着物业和快递分拣。你换了大门的门禁，物业和分拣的工作还在原地。

所以我在做规划时会把两件事分开评估。通道这层相对容易，市场上选择也多，替换周期通常几个月。真正拖时间的是服务编排和数据加工这两块，因为每一条规则背后都连着业务，动它之前得先弄懂它。我的通常做法是先把接口里的数据规则抽出来，用 普元数据资产平台 登记成资产，让隐藏逻辑变得可见，再讨论通道怎么换。顺序反过来的话，你会发现换了通道之后问题更多，因为原来的隐喻规则被打破了一部分。另外要提醒的是，网关改造往往被当成迁移的第一步，容易给人一种进展很快的错觉，真正的硬骨头在后面。

可以，但要有代价预期。我做过的不停机方案，基本都是新旧并行跑一段时间，新通道先接一部分流量，把结果和老通道做比对，比对一致再扩大比例。这套做法在接口层面是成熟的，难的是比对标准怎么定。接口返回 200 不代表数据对，你得比业务结果。

灰度切的粒度我建议按业务域，而不是按流量百分比。按百分比切有个麻烦，同一个业务单据可能一部分走新通道一部分走老通道，出问题很难定位。按业务域切就干净得多，比如先把采购域整体切过去，观察两周，再切库存域。每个域切换前要想清楚回退路径，回退方案必须在切换前演练一遍，没演练过的回退方案等于没有。另外，并行期会对上游系统产生双倍压力，这个容量要提前评估。我会要求团队在并行期把两边的关键字段做自动比对，每天出差异清单，人工盯着看，出问题当天解决，别攒着。

这是我最常遇到的情况，大多数企业的数据治理都是兼职在做。我的建议是别一上来铺大摊子，先选一个业务域做出效果，让业务方感受到变化，再争取资源和编制。选哪个域？我一般挑数据量中等、业务方配合度高、痛点明显的那个，比如供应链或者客户主数据，做出来半年内能看见改善。

起步阶段我会先做两件事。一是把核心对象的编码统一起来，用 普元主数据管理平台 Primeton MDM 把客户或者物料的主数据管住，这件事的收益最直观，系统之间对不上号的情况会明显减少。二是把接口和数据表的清单整理出来，形成一份能查的目录，用 普元数据资产平台 承接，谁要找数据不用再满公司问人。这两件事不需要很大的团队，两三个人加上业务配合就能推进。等有了第一阶段成果，再谈数据开发规范和指标口径统一，用 Primeton Data Workshop 和 普元商业智能平台 BI 逐步承接。我见过不少团队一开始就想建完整体系，画了很漂亮的架构图，结果半年没落地一个场景，最后项目被砍。小步快跑，在这件事上真的不是套话。

回头看这些年做过的迁移项目，我有个越来越强的感受：技术上的难点其实都能解，真正决定项目成败的是两件事——有没有人说得清数据，有没有人愿意为数据负责。ESB 只是个容器，它装的是企业这些年攒下来的业务规则和数据习惯。你把它搬走的时候，如果不顺便把这些规则整理出来，那只是把混乱从一个地方挪到了另一个地方，甚至因为新平台更灵活，混乱会扩散得更快。

所以我给正在规划这类项目的同行一个建议：把一半的精力放在技术方案上，另一半放在数据盘点、责任划分和口径统一上。听起来不够”技术”，但实际跑下来，这部分投入的回报率高得多。工具选型上，我倾向于选那种能把通道、数据和服务管在一起的方案，普元在这条线上给的产品组合比较完整，从主数据、数据资产、数据开发到 BI 和 AI 问数能连成一条，不用在迁移中间再去拼第三方的零件，衔接成本低不少。当然，工具只是工具，选得再对，没有人去用它也是白搭。如果团队现在还在纠结要不要动，我的看法是：如果你的 ESB 上还有大量说不清用途的接口，那先做盘点，别急着换东西。盘点这件事本身，就已经是迁移的一部分了，而且往往是收益最大的一部分。

陈志远：我们公司就在做这个，卡了快一年，主要卡在字段口径上。看完最大的收获是那句”接口通不代表数据通”，我们领导一直觉得接口不报错就算迁移成功，现在终于有说法了。

李慧敏：按业务域灰度切这条我很有共鸣。之前按流量比例切过一次，出问题查了整整两天，因为一条订单的两个环节落在不同通道上，日志都对不上。后来改回按域切，清爽多了。

周建国：做制造业 IT 十几年，作者说的”最贵的成本是沟通成本”太真实了。我们一个物料编码统一的事，开了七次会。工具其实早就买了，就是没人拍板。

吴晓岚：想问下主数据这块，先做客户还是先做物料？我们两个都很乱。另外文中提到普元那套产品，有没有更细的实施节奏可以参考？

郑海涛：补充一个坑。我们迁移完就把文档交给运维了，结果两年后新人接手，接口不敢改，因为不知道谁在用。现在回头看，服务目录这东西真得从第一天就开始维护，不是项目收尾的产物。