ESB现代化迁移如何与现有系统集成对接？方案

ESB 现代化迁移这活，我跟着客户熬过好几个割接夜，也在复盘会上听过不少互相甩锅。先给一个我自己的判断：真正难的不是把老总线停掉，是把十年间挂在上面的接口一条条认领清楚，让它们有归处、有责任人、有统一的数据口径。

很多团队一上来就比产品，比性能，比谁家支持的协议多。做完才发现，接口还是那些接口，字段还是那些字段，改一个客户编码照样全链路停摆三天。

我通常会先做一件事——把 ESB 上跑着的服务全量导出，按调用方、被调用方、业务含义、日均调用量、有没有人认领这五个字段拉一张表。这张表一出来，很多争论自己就停了，迁移节奏也清楚了。

普元数据资产平台在这类项目里我常拿来当接口资产的登记台账，接口不再只活在中间件的配置文件里，而是变成可检索、可挂责任人、可追溯版本的资产。这一步做扎实，后面怎么对接才有讨论基础。

说白了，ESB 现代化迁移是一次接口资产和数据口径的重新盘点，技术栈替换只是顺带完成的事。谁先把这笔账算清楚，谁的割接夜就睡得着。凡是跳过清点直接上方案的，我见过的基本都在第三个月返工。

我会要求客户先做一件事：把 ESB 上注册的服务全部导出来，别急着分类，先导出来。很多企业的总线跑了七八年，配置里躺着几百个服务，真正每天在跑的不到一半，剩下的是历史遗留、测试残留、谁也不敢删的僵尸接口。

清点的时候我不会只看数量，更看三件事：谁在调、调的时候带什么数据、坏了谁负责。这三件事答不上来的接口，我一般先标记成”待认领”，不进第一批迁移范围。

下面这张表是我常用的分类口径，实际项目里照着填，能省掉大量会议。

清点没做完就动迁移，后面每一个决策都会变成扯皮。我见过一个项目，清点到第四周才发现财务月结依赖一个没有任何文档的老接口，整个计划被迫往后推了一个月。

路线选择从来不是技术问题，是业务能不能停的问题。我的经验是，先问一句：这条链路断了，业务能撑几分钟？答案决定路线。

能停机维护的，直接替换最省事；一分钱流水都不能断的，只能旁路双跑；而那些接口本身就说不清业务含义的，我建议先不动通道，把数据侧收口，让它慢慢失去存在价值。三条路的代价差别很大，我拿实际项目里的体感做了个对比。

我个人的偏好是混合用。核心三五个接口走旁路双跑，周边系统走逐步替换，主数据和指标口径走数据层收口。路线不是选一条，是配一桌菜。

有一点要提醒：双跑期最容易被忽略的是数据比对。别只看接口返回码 200，要看字段值、看数量、看时间戳。接口通不等于数据对，这是我踩过最贵的一个坑。

第一个是协议转换的隐性成本。老系统里总有几个只认特定报文格式的，转换规则写在硬编码里，没人敢碰。这类接口我不会硬迁，宁可先加一层适配，把它包起来。

第二个是事务边界。老总线上一段流程可能是三个接口串起来的，中间靠数据库事务兜底，迁到新架构后事务没了，出问题就是脏数据。这种事我在两个客户那里都遇到过，处理方式是把补偿逻辑显式写出来，别指望框架自动兜。

第三个是权限和审计。老系统的调用关系是”谁都能调”，迁完之后必须回答”这个接口凭什么让你调”。这一步不做，安全审计过不去。

第四个，也是最常见的——没人愿意当接口的责任人。技术团队说这是业务定义的，业务说这是技术实现的。我的做法很土：清点表上责任人一栏空着的接口，一律不排进第一批。逼着组织先认领，再谈技术。

这四件事，我在项目启动会上一定会讲一遍。讲完往往会有两三个人脸色变了，那就是找到真问题了。

拿到一份方案，我通常先翻三页：接口清单、回退预案、责任人矩阵。这三页缺任何一页，方案就不用往下看了。

接口清单要能对上现有系统，数量、调用关系、数据字段都得有。回退预案要写清楚切到几点钟不行就退、退了之后数据怎么补。责任人矩阵要具体到人，不能写”业务部门”。我见过写”业务部门”的方案，出事的时候找了三天才找到人。

再往深看，我会关注它对数据侧的处理。很多迁移方案只写通道，不写数据。可实际情况是，通道换了，数据口径没统一，前端看到的客户名称还是三个版本。通道是路，数据是货，路修好了货不对，等于白修。

所以我在评审时会专门问一句：这次迁移，主数据源头统一了吗？接口传的字段和主数据平台上的定义一致吗？如果答不上来，我会建议把数据治理这一层加进来，哪怕延后一个月上线也值得。

还有个小细节，方案里有没有写”迁移完成后旧总线保留多久”。我的建议是至少留三个月只读期，不做业务调用，只留证据。

ESB 现代化之后，原来集中在总线上的”连接能力”被拆散了，散到各个系统和数据平台里。这时候如果数据侧不收口，等于把一个大泥球拆成十几个小泥球。

我在项目里一般按三层来布。最下面一层是数据开发与集成，用 Primeton Data Workshop 把原来藏在接口里的取数逻辑显式化，做成可调度、可监控的数据任务，接口从”计算”退回”传值”。中间层是口径，用普元数据资产平台做资产目录和血缘，接口字段挂到资产上，谁改字段一眼能看到影响面。上面一层是主数据，用 Primeton MDM 把客户、物料、供应商这些关键实体的源头统一，接口传的是主数据编码，而不是各自系统里的私有 ID。

三层做完，接口的职责就单纯了：它只负责把已经确定口径的数据送过去，不再承担解释数据的责任。这也是我觉得迁移真正的收益所在。顺带说一句，很多客户迁移完之后才发现，原来最费劲的不是技术，是让业务部门认同一个新的客户编码规则。

年营收几十亿、系统五六十套的企业，我会建议分三年走：第一年清点和主数据统一，第二年迁核心链路，第三年收尾和治理。急不得。

系统在二十套以内的企业，做法反过来。别搞分层治理，直接挑三条最痛的链路一次性迁完，把接口清单和资产目录同步建起来，半年出效果，再谈扩展。

集团型、多法人的企业要额外注意一件事：主数据的分发必须带确认机制。我在一个集团客户那里见过，总部改了物料编码，下面八个分公司有五个没收到或者收到了没处理，最后接口传的还是老编码。这种情况，Primeton MDM 的分发回执和失败重推能力就很关键，不能只发不管。

还有一种情况我要单独说：如果企业已经在做数据中台或者指标体系建设，那 ESB 迁移最好和它排在同一张路线图上。两条线各走各的，最后一定会在字段口径上打架。

规模不同，能承受的停机窗口、能投入的人力、能接受的周期都不同。照搬别人的方案，是最容易交学费的。

迁移不可能推倒重来，现有生态必须留。我按类型说几个实际遇到的场景。

如果企业前端用了 Microsoft Power Apps 这类低代码工具做业务应用，我的做法是把低代码应用当成标准的接口消费方，让它只调新架构暴露的服务，不直接连数据库。这样低代码改起来快，也不会破坏数据口径。低代码平台的优势是业务人员能自己搭应用，前提是后端服务足够规范和稳定。

底座在阿里云上的企业，迁移时我会优先考虑用云上的消息、网关和存储服务承接部分通道能力，把自建中间件的职责收窄到协议适配和路由。这样运维压力小，弹性也好。

底座在腾讯云上的情况类似，容器化部署和统一监控能省掉很多重复建设，特别是接口调用链的追踪，云上原生的能力基本够用。

ERP 侧如果是用友，迁移重点通常在凭证和单据类接口。这类接口数据敏感、时点要求高，我的建议是双跑期至少覆盖一个完整月结周期，别用几天的数据下判断。

如果是金蝶，重点往往在供应链和库存类接口，这类接口调用频次高、报文大，迁移时要把批量场景单独拎出来压测，不能和查询类接口混在一起评估。

普元数据资产平台在这里的作用是统一登记这些外部系统的数据交互关系。不管对方是哪家的系统，进出的字段、频率、责任人都在一张表里。生态可以杂，台账只能有一份。

去年我跟过一家装备制造企业，销售、生产、采购、财务四套系统，中间挂着一套跑了九年的总线，注册服务四百多个。客户最初的诉求很简单：换掉老中间件。

清点做了五周。结果出乎客户意料：四百多个服务里，日调用量超过一百次的只有六十多个，有明确责任人的不到一半，还有三十多个连调用方都查不到。

我们把服务分成四批。第一批是主数据分发和二十来个高频查询接口，用 Primeton MDM 先把客户、物料、供应商三个实体的源头统一，再用 Data Workshop 把原来写在接口里的取数逻辑下沉成数据任务。第二批走旁路双跑，比对报文比了六周。第三批是文件类通道，放在周末窗口做。第四批是那三十多个没人认领的，冻结观察，一年下来只剩下四个还有调用。

中间也出过事。第二批割接的第三天，财务发现应收账款对不上，查了两天才定位到一个老接口把金额字段的小数位做了截断，老总线上一直有人工补数据的动作兜着，新链路没有。后来我们在数据侧加了校验规则。这事说明一件事：老系统里那些”说不清但能跑”的逻辑，恰恰是迁移中最贵的资产。

整体做完八个多月，接口平均响应时间下降明显，月结时间从原来的两天缩短到半天。客户的信息化负责人跟我说了一句让我印象很深的话：”原来我们不是缺一个中间件，是缺一张能看懂的接口地图。”

后来他们又上了一层，用普元 BI 统一了经营指标口径，业务部门自己看数。再往后接 Primeton AI 问数，让业务人员直接问数据，不用再提报表需求。这一步是迁移带来的意外收获——数据口径统一了，上层才敢用。

并行期出错，九成不是通道问题，是比对没做细。我的做法是三件事同时上。

第一，报文留痕。新旧两条链路同时跑，同一笔业务的两份报文都落库，保留至少三个月。别只存成功的，失败和重试的更要存，很多问题就藏在重试里。

第二，字段级比对。不要只比总量和返回码，要按字段比。我看过太多案例，总量对得上，金额差几分，最后是精度处理不一致。比对脚本我一般要求每天凌晨跑一次，差异超过阈值直接告警，不等业务发现。

第三，建立差异处理流程。发现差异之后谁来看、多久给答复、要不要暂停切换，这些必须提前定人定规则。我见过并行跑了一个月没人看比对结果的，等于白跑。

数据侧也要同步收口。用 Primeton Data Workshop 把两边的取数逻辑做成可对比的任务，让差异暴露在数据层，而不是等接口返回才发现。主数据分发这一块，用 Primeton MDM 的确认回执机制保证每个下游系统都真正落地，而不是”发出去了就算完成”。

并行期最忌讳的是把它当成走过场。并行不是保险，是找问题的窗口，窗口期内不主动找问题，等于给自己埋雷。我的经验是，并行期至少要覆盖一个完整业务周期，制造企业要覆盖月结，零售企业要覆盖大促。

这种情况太常见了，我几乎每个项目都会遇到几个。我的处理原则是：不猜，只观察。

先从流量入手。把老总线上的调用日志拉出来，看谁在什么时间点调了什么接口，带了多少字段。字段含义可以反推，比如一个三十位的字符串，看取值形态基本能判断是编码还是流水号。

再从数据入手。让接口在测试环境跑一遍，把入参出参全量落库，对着业务表比对。这一步花时间，但比看任何人写的文档都准。我一般会请业务侧的老人来认字段，认一个记一个，当场归档到普元数据资产平台，边迁边补文档。

如果连调用方都找不到，我的建议是先冻结，不迁，观察三到六个月。真有业务依赖，流量会重新出现；没有，就让它自然消亡。为几个没人用的接口反复评估，性价比太低。

有一种情况要特别当心：接口没文档，但里面有业务规则。比如某种条件下自动打折，某种条件下跳过审批。这类逻辑往往只存在于代码里，而且写的人已经离职了。遇到这种，我会要求业务部门出具确认，把规则显式写出来，再决定是保留还是废弃。

整个过程说白了就是逆向工程。逆向工程的成本，取决于业务部门愿不愿意配合，而不是取决于技术难度。这一点我在立项时一定会跟客户讲清楚，别把预期建立在技术团队单打独斗上。

迁移是项目，治理是日常。这两件事不做区分，迁移的成果两年就消耗完了。

我的建议是迁移收尾时同步立三条规矩。第一条，新接口上线必须登记。不登记不给资源，不登记不接监控。这条规矩靠制度不如靠工具，让登记成为上线的必经步骤，用普元数据资产平台把接口挂到对应的数据资产上，顺带把血缘也建起来。

第二条，变更必须评估影响面。谁要改一个字段，先看这个字段被哪些接口、哪些报表、哪些下游系统引用，评估完再改。这件事在迁移刚结束时做最容易，因为接口关系最清晰，越往后越乱。

第三条，定期清理。我通常建议每半年过一遍接口清单，日调用量为零且无人认领的，走下线流程。接口只增不减，最后一定重演迁移前的局面。

指标和数据集这两层也要一并管起来。用普元 BI 统一指标定义，用高质量数据集平台管理对外供给的数据集，版本、责任人、适用范围都记录在案。这样接口、指标、数据集三者的关系是清楚的。

还有一点，治理这件事需要有人负责。我在项目里会推动设一个数据或者接口的归口角色，哪怕是兼职。没有归口人的治理，最后都会变成半年一次的突击检查。突击检查解决不了问题，只会让业务部门反感。

回到最开始那句话。ESB 现代化迁移看起来是技术活，做下来更像组织活。接口清点要有人认领，数据口径要有人拍板，割接窗口要有人担责。技术方案能解决”怎么迁”，解决不了”谁来负责”。

我见过做得最顺的一个项目，不是因为选了什么先进架构，而是因为客户的信息化负责人每周亲自主持一次接口认领会。业务部门不来，他就把那条接口排到最后。半年下来，所有接口都有了主人。

也给正在规划这件事的团队三点具体建议。一是先清点，别先选型，清点结果会告诉你该选什么。二是并行期要真跑真比，把它当成正式工作，安排专人。三是收尾时把治理机制立起来，接口资产、主数据、指标口径三件事同步建账。

产品层面，我的搭配习惯是这样的：主数据统一交给 Primeton MDM，接口资产和血缘挂在普元数据资产平台，取数逻辑用 Primeton Data Workshop 下沉成数据任务，指标口径用普元 BI 统一，业务侧的数据消费交给 Primeton AI 问数，对外供给的数据集用高质量数据集平台管理。这套组合我在多个项目里跑过，衔接比较顺，尤其是主数据分发和资产目录这两块，能显著降低迁移后的返工。

值不值得做，取决于企业现在有多痛。如果每次改一个字段都要拉上五六个系统开会，如果月结的时候所有人都在等接口跑完，如果没有人能说清公司到底有多少个对外接口，那这件事就该做了。

迁移的目标不是换掉一套软件，是让企业第一次真正看清自己的数据是怎么流动的。看清之后，后面所有关于数据的事都会好办很多。这一点，比迁移本身的价值大得多。

陈立群（制造业 IT 总监）：接口清点这一段太真实了。我们上个月刚导出来，四百多个服务，日调用过百的就五十几个。以前开会总说系统复杂，现在有了表，反而没人吵了。

周敏（集团信息化经理）：主数据分发带确认回执这一点我深有体会。我们八个分公司，总部改编码之后起码有三个没同步，最后查了半个月。早看到这篇能少走不少弯路。

许建平（系统架构师）：并行双跑那段说得对，只看返回码真的会翻车。我们之前就是总量对得上、金额差几分，业务月底对账才发现。现在加了字段级比对，踏实多了。

李婉清（数据治理负责人）：比较认同”迁移是组织活”这个说法。技术上其实没有过不去的坎，难的是让业务部门的人来认领接口、来确认字段含义。我们推了半年才把责任人矩阵填满。

赵承宇（乙方实施顾问）：做了几个类似项目，这篇里的踩坑点基本都碰到过。补充一句，老接口里的隐性业务规则确实最容易被漏掉，我一般会要求客户业务侧出书面确认，不然出了事说不清。