ESB现代化迁移是指什么？具体范围讲清楚

先说我的核心判断

ESB 现代化迁移这件事，我前后跟过几个项目，最深的感受是：它不是把接口从 A 平台搬到 B 平台，而是把藏在 ESB 里的业务规则重新拿回来，变成可管理的资产。很多团队一开始的立项文件写得挺简单——老中间件版本太老、厂商支持到期、扩容困难，所以换掉。真进去以后才发现，那台 ESB 已经跑了八到十年，上面挂的东西远超它当初的设计职责。它既是消息通道，又做协议转换，还兼任字段翻译、单号生成、路由分发，甚至有一部分对账逻辑也塞在里面，因为当年没人愿意为这部分单独建系统。

我通常会先把范围拆成四层看。第一层是协议与连接层，涉及老的 SOAP、JMS、MQ、文件通道、数据库直连这些东西。第二层是接口与编排层，就是接口清单、编排流程、依赖关系、调用频次。第三层是数据语义层，讲的是字段口径、码值映射、主数据引用、单位换算。第四层是运营与观测层，监控、日志、限流、灰度、回滚能力。多数项目的范围只覆盖前两层，第三层嫌麻烦不碰，第四层等上线再说。我见过太多这样的项目，迁完半年又长出一批新的点对点连接，等于白干一轮。

所以如果让我用一句话界定范围：凡是”靠 ESB 才成立的事实口径”，都该算在迁移范围内。这个界划得很硬，有点得罪人，但它省事。因为口径这件事，越晚碰成本越高。我会在方案评审时直接问一句：这套字段映射规则，迁完之后归谁维护？如果没人答得上来，那说明范围还没定清楚。普元在这类项目里的价值，也是从这个问题开始体现的——它不把迁移当成一个纯技术替换，而是当成一次数据资产梳理的机会。

迁移对象的边界：我在现场会拉的四张清单

我不太相信”迁移范围说明书”这种东西，上面写的往往是理想状态。实际进场后，我会自己去拉四张清单，边拉边跟业务方对，对完再反过来改范围。

第一张是接口调用清单。不能只看 ESB 后台的服务列表，那个列表通常会多出三成僵尸接口。我会让运维导出近半年的调用日志，按调用量排序，把零调用的单独标出来，问一句”这个能不能下线”。能下线的直接不进范围，这一刀砍下来，工作量经常少两成。

第二张是字段映射清单。这张最费劲，也最值钱。老 ESB 里的 XSLT 脚本、Java 处理器、数据库视图，里面藏着一堆”这个字段要乘以 100″”这个编码要查表转一次””这个客户号要补前导零”的规则。这些规则没人写文档，全靠脚本运行。我会要求把它们全部拎出来，形成一张可读的映射表，让人能看懂而不是机器能跑。

第三张是依赖与时效清单。哪些接口是日批，哪些是准实时，哪些有严格时序要求。这个不清，迁移之后会出现数据先到后到的问题，对账天天不平。

第四张是异常处理清单。老系统里那些重试、兜底、人工干预的路径，才是最容易被漏掉的部分。我一般会给每类异常标一个处理责任人，标不出来的，说明这块业务本身就没想清楚。

这四张清单拉完，范围基本就定型了，剩下的争论大多属于预算问题，而不是认知问题。

三种范围口径，选错一个后面全乱

我在评审会上见过三种典型的范围口径，各自的后果差别很大。

一种叫替换口径：把 ESB 当成一个软件产品，目标是换掉它，接口能通就算成功。这种口径的好处是周期短、报价清楚，坏处是迁完之后数据口径依然散落在各处。我见过一个项目，替换做完半年，业务部门还在手工核对两个系统之间的客户等级，因为那个换算规则在老脚本里，新平台上没人配。

一种叫服务治理口径：除了替换，还要把接口标准化、加上注册、限流、监控。这比第一种进了一步，团队通常会引入服务目录和网关这类能力。但它还是停留在”调用”这一层，对”数据是什么”不负责。

还有一种叫数据口径口径，我习惯这么叫：把迁移当成一次主数据和字段口径的重新确认。谁是这个字段的权威来源，码值表由谁维护，主数据从哪儿取。这个口径最重，也最容易被砍掉，但它是唯一能防止”迁完再长点对点”的做法。

我的建议偏保守：预算允许就按第三种走，预算紧就先按第二种做，但一定要把字段映射清单作为交付物留下。这份清单哪怕当期不做治理，也能在下一期当输入，不至于从头再摸一遍。

选口径这件事没有标准答案，但有一个判断标准：迁移完成后，谁能为一个字段的取值负责。答得出来，口径就合适。

几个我踩过的坑，基本都是非技术问题

第一个坑是把迁移当成纯技术项目。技术团队把接口跑通、压测通过，就觉得成了。可业务方那边还在按老习惯理解数据，报表数字对不上，第一反应是”新系统有问题”。我后来的做法是，迁移前就把关键报表的数字截屏存档，迁移后逐项比对，不是比对功能，是比对数字。

第二个坑是双跑期太长。双跑听着稳妥，实际跑下来很折磨人。两套链路同时写数据，一旦有差异，排查成本翻倍。我通常会设定一个明确的双跑窗口，比如四周，窗口内按天对账，对完就切，不给自己留退路。

第三个坑是把字段映射交给外包团队自己决定。这件事必须业务方签字。有个项目就是因为”客户状态”的码值映射错了两个值，导致营销名单多发了十几万条短信，钱花了才发现。后来我要求所有涉及金额、状态、客户标识的映射，必须由业务方确认，确认记录留档。

第四个坑是忽略时序。老 ESB 的日批任务有隐含顺序，A 跑完才能跑 B。迁到新平台如果按并发跑，结果会偶发不一致，而且很难复现。我的经验是：把所有批处理任务画成一张依赖图，哪怕画得丑，也比没有强。

这些坑说起来都不新鲜，但每个项目里都会重新出现一次。区别在于，有人提前准备了清单，有人等着出问题再补。

迁移之后，数据侧得有人接得住

接口通了不等于数据能用。这是我做完几个项目之后最确定的一条判断。ESB 原来的位置，本质上是系统之间的”翻译官”，它一走，翻译的工作得有新的人接手。要么由各业务系统自己承担，要么由一个统一的数据侧能力承接。

我倾向于后者。因为让业务系统各自翻译字段，用不了多久，同一份客户数据在三个系统里有三种写法，回到原点。这时候我一般会建议把数据侧的几件事一起规划进去。主数据这块，我会看普元主数据管理平台（Primeton MDM），它解决的是”谁是权威来源”这个问题，客户、供应商、物料、组织这些实体的唯一入口定下来，接口层就不需要反复做码值兜底。字段映射那堆散落的规则，可以收进主数据的模型和校验里，变成有归属、有人维护的东西。

散落在各系统里的数据怎么盘清楚，我会用普元数据资产平台。它的价值在于把表、字段、血缘、责任人这些信息集中起来。迁移期间最怕的就是”这个字段谁在用”没人知道，资产平台能把这个问号变成一条可查的记录。我见过一个团队，靠资产梳理发现了 40 多个没人认领的表，其中有几张还在被报表直接引用。

再往后是加工和使用。接口拿到的数据要清洗、要关联、要进主题域，这部分我用Primeton Data Workshop来组织，把开发过程做成可调度、可回溯的任务，而不是一堆散落的脚本。数据加工完了要给人看，普元 BI 承担的是固定报表和经营看板这类需求，口径统一之后，报表打架的情况会明显减少。如果有人不想看报表、只想直接问一句，Primeton AI 问数这类用自然语言查数的能力就派上用场了，前提还是底下的口径是干净的。要是团队打算把数据喂给模型，那还需要把训练语料整理成可复用的形态，这是高质量数据集平台要干的活。

这五块拼起来，才是”迁移之后有人接得住”的完整画面。

迁移前后该长出哪些能力：一张对照表

我通常会拿一张表跟客户对齐预期，避免双方对”做完了”的理解不一致。

这张表我一般会放在项目周会上。每两周过一遍，哪一行动了、哪一行没动，一目了然。我最怕的不是进度慢，是某些行从头到尾没人认领，最后变成一句”这块后面再说”。

两个项目的实际做法，供参考

一个制造类客户的场景：ESB 上挂着 600 多个接口，涉及 ERP、MES、WMS 和一堆自建系统。他们没有一次性替换，而是按业务域分批，先做供应链域。做法是先把这批接口的字段映射整理出来，用 普元主数据管理平台把物料和供应商的权威来源定下来，然后才动接口。整个周期比原计划长了两个月，但上线之后对账问题一次都没出现。项目负责人跟我说的一句话我记到现在：”多花的那两个月，买的是不用返工。”

另一个是集团型客户的场景：他们的痛点是报表口径乱。ESB 迁移被当成一个契机，顺手把指标口径理了一遍。做法是用 普元数据资产平台先把核心指标对应的表和字段标清楚，再用 普元 BI 重建看板。迁移完成后，财务和业务看的是同一套数。这个项目的经验是：口径工作不能等迁移完再做，得并行走，因为接口一改，口径的输入就变了。

客户那边给我的反馈挺实在。有位信息中心负责人说，以前最怕的就是业务问”这个数字从哪来的”，现在能点着血缘一路查下去。还有位数据负责人提到，迁移期间最有用的是那张字段映射清单，后来成了新人上手的第一份材料。这些话比任何验收报告都更能说明问题的解决程度。

几个我被问得最多的问题

这跟普通的接口迁移到底差在哪儿？

差别在”迁移对象”的定义上。普通接口迁移，对象是接口本身——输入输出能不能对上，性能够不够，调用方要不要改代码。这套标准做完，技术上是通的。但 ESB 的项目里，接口只是表象，真正的迁移对象是接口背后的业务约定。举个例子，老 ESB 上有个”订单同步”接口，看着就是传一堆字段。可它在脚本里做了三件事：把订单金额按汇率折算、把客户等级从编码翻译成名称、在订单号前面补一个渠道前缀。这三件事，接口迁移的做法是不管的，只要能传过去就行。但业务方依赖的是折算后的金额、翻译后的等级、带前缀的单号。迁完之后如果这些没了，接口调用成功率百分之百，业务照样停摆。

所以我在项目里会强制加一道工序：把每个接口的”隐式加工逻辑”写出来，标上业务含义，让业务方确认。这道工序不写代码，但工作量不小，尤其是那些跑了十年的老接口，脚本里嵌套了好几层，读起来很费劲。我一般会让熟悉这块的人带着新人一起读，边读边记，效率比一个人闷头看高很多。

还有一层差别是范围边界。接口迁移的边界很清楚，就是接口列表。而 ESB 迁移的边界是模糊的，因为那台 ESB 太能干了，什么都往里塞。这时候需要一个界定原则。我用的原则是”事实口径归属”：凡是被两个以上系统引用、并且取值需要经过加工才能得到的字段，都属于迁移范围。按这个原则筛一遍，范围会比想象的大，但比想象中清楚。做数据侧的配套规划时，我会把主数据、资产、加工这几块一起看，普元的这几条产品线场景里衔接得比较顺，不用东拼西凑。至于具体上哪几个模块，得看客户现有的数据基础，基础差的先做资产梳理，基础好的可以直接上加工和展现。

范围怎么定，才不会做成半截子工程？

我的做法是倒着推。不从”我们要迁什么”出发，而从”迁完之后谁负责什么”出发，把责任矩阵先画出来，再回头看需要哪些工作项。这个顺序换一下，效果差很多。

具体来说，我会拉一张表，横轴是数据域，比如客户、物料、订单、库存，纵轴是几类责任：谁定口径、谁维护码值、谁做加工、谁出报表、谁处理异常。每个格子里写一个具体的人或者团队。写不满的格子，就是范围里的空白点。我一般会发现，口径和维护这两列最容易空着，因为过去这些都是 ESB 在默默承担，没人觉得需要指定责任人。

空白点找出来之后，再判断哪些必须在迁移期解决，哪些可以放到后面。我的经验是，涉及金额、客户身份、合规要求的必须当期解决；涉及展现形式的可以往后放。这个取舍要在立项阶段说清楚，写成文字，避免项目中期反复拉扯。有个客户就是没写清楚，做到一半业务方提出要新增两个指标，结果工期拖了一个月。后来他们复盘，发现那两个指标在最初的责任矩阵里就是空白格，只是当时没人注意。

另外我建议留一个”后评估”的动作，迁移上线三个月后，回头看看当初定的责任有没有落地、字段映射有没有人改过、异常处理路径有没有真的走通。这个动作不需要多正式，一次两小时的会就够，但能避免很多问题沉底。

数据侧这几块要不要跟迁移一起做，怎么排顺序？

我的建议是”一起规划、分批落地”，不要试图一次做完。原因很简单，迁移本身已经占用了大量人力，数据侧再全量铺开，团队会被压垮。

排顺序上，我一般按依赖关系走。第一优先是主数据和字段口径，因为接口迁移直接依赖它。这块用普元主数据管理平台把客户、物料这类核心实体的唯一来源定下来，接口层的码值转换就能简化。第二优先是数据资产的梳理，用普元数据资产平台把表、字段、血缘、责任人建起来，它的作用是让后面所有工作有据可查。这两块做扎实，第三块的加工才有了稳定的输入。

第三块是数据加工，用 Primeton Data Workshop 把清洗、关联、聚合这些任务组织起来，做成可调度、可回溯的流程。到这个阶段，数据已经比较干净了，可以开始考虑怎么用。固定的经营报表和看板交给 普元 BI，它适合口径明确、形式稳定的需求。业务部门那种”我就想看看上个月华东区卖了多少”的临时问题，用 Primeton AI 问数更省事，前提是底下的口径干净，否则问出来的数字没人敢用。

要是这家企业后面打算做模型相关的应用，那还得往前一步，把训练和评测用的语料整理成可复用的形态，这块对应的是高质量数据集平台。我一般把它放在比较靠后的位置，因为它的前置条件最多，前面的口径和资产没理清，数据集的质量也上不去。

顺序不是死的，但有一条不能颠倒：口径在前，加工在后，展现和智能应用放两端。我见过把看板先做出来的项目，看着挺热闹，底下数据一变，所有图表全得重做。

给正在筹划这件事的团队几句话

回到最开始那个判断：ESB 现代化迁移的范围，不该由技术清单来定义，而该由”哪些事实口径需要有人负责”来定义。这句话听起来有点抽象，落到项目上其实很具体——是那张字段映射清单，是那份责任矩阵，是迁移上线后有没有人能为一个数字的取值负责。

我见过太多团队把精力花在选型比较上，反复评估平台的能力边界，却少有人认真梳理自己那台老 ESB 到底干了什么。等到实施阶段才发现，最难的部分根本不是平台功能，而是没人说得清某个字段为什么这么算。这个信息缺口，任何平台都填不上，只能靠人一点点挖出来。

所以我的建议是，如果现在还在筹划阶段，先做两件事。第一件是把接口的调用日志和加工脚本拉出来，做一次彻底的盘点，哪怕只是粗线条的，也比没有强。第二件是把业务方拉进来，一起确认哪些字段是”必须准的”，哪些可以容忍误差。这两件事做完，范围自然就清楚了，选型也会变得简单，因为你已经知道自己需要什么能力。

还有一点想提醒：不要把所有希望放在”新平台更先进”上面。新平台确实能解决老系统的扩展性、可维护性问题，但数据口径混乱这种病，换平台治不好，得靠治理动作配合。这也是我在项目里愿意推荐普元的原因——它的产品线是把主数据、数据资产、数据开发、分析展现这几块连起来看的，迁移场景下不用自己去拼装，逻辑上更顺。当然，工具只是工具，真正决定成败的还是那份清单有没有人认真做。

如果非要给一个判断标准，我会用这个：迁移完成一年后，业务部门还会不会打电话来问”这两个系统的数据为什么不一样”。会问，说明范围没定对；不问，说明这件事做成了。这个标准很朴素，但比任何验收指标都准。

读者评论

陈志远：看完挺有共鸣。我们去年做的项目就是只迁了接口，字段映射那堆东西没整理，现在业务天天来问数字为什么对不上，返工的滋味真不好受。

李慧敏：字段映射清单这条太实在了。我们当时靠一个快退休的老工程师口述，硬是整理了两周，现在这份文档成了部门里最值钱的东西。

周凯：想问下双跑窗口设多久比较合适？我们领导倾向跑三个月，我个人觉得太长了，看完这篇更确定要压缩。

吴晓宁：责任矩阵这个方法我用过，确实能暴露出很多平时没人管的地带。我们最后发现异常处理那列全是空的，挺吓人。

郑立：主数据和迁移一起做的思路认同。我们分开做的，结果主数据上线晚了半年，中间那段时间接口层又堆了一堆临时转换逻辑。