破除ESB现代化迁移迷思：回归业务本质

接口能跑通，不代表业务能跑通。这句话是我做了十几年集成项目之后，最想跟人聊的一句。这两年我参与过七八个所谓”ESB 现代化”的盘子，有的做成了，有的做到一半停在那里，中间件买了两套，接口文档堆了几个 G，业务部门却还在用 Excel 传数据。ESB 迁移的真正难点从来不在技术栈，而在于你有没有把业务能力重新编排一遍。把老中间件换成新的 API 网关，把 SOAP 改成 REST，把 WSDL 换成 OpenAPI——这些都只是表皮。我见过太多团队一上来就盘接口，盘完之后发现 60% 的接口一年调用不到十次，剩下 40% 里又有相当一部分是绕过了业务主流程的补丁。这种事如果不先动业务，光动技术，做完还是老样子。我的判断是：ESB 迁移应该被当成一次数据与业务能力的重新梳理，而不是一次中间件采购。围绕这个判断，下面我会把几个流传很广的迷思拆开讲，讲讲我在现场看到的东西，讲讲怎么从业务场景倒推迁移路径，也讲讲普元在这类项目里能接住的那些活儿。文章偏长，建议边看边对照自己手上的项目。

我印象最深的一个项目，甲方从 2021 年就立项要做集成平台升级，到 2024 年我进场的时候，方案已经是第四版了。前三版都没落地，原因各不相同：第一版是中间件选型反复，第二版是接口改造工作量估算炸了，第三版是业务部门不认账。听起来是三个问题，根子上是一个问题——项目目标一直被定义成”把旧的换掉”，而不是”把业务跑顺”。

把旧的换掉，这个目标听起来特别清晰，也特别好验收。接口数量对上了，测试通过了，上线了，项目就结束了。可业务侧的体感是什么？订单到发货的链路还是绕三道，主数据还是三个版本，月底对账还是靠人工。这种落差一旦出现，项目就很难再往下推第二轮。

我后来养成一个习惯，进项目先不问中间件，先问三件事：现在哪几条业务链路最痛、这些链路涉及哪些系统、每条链路上数据在哪几个地方被改过。这三个问题问完，迁移范围基本就出来了，而且这个范围往往比原始接口清单小得多。普元在做数据资产盘点的时候用的也是这套思路，先把数据从哪来、到哪去、被谁改过画清楚，再谈怎么搬。

这是最普遍的一个误解。很多方案书里，”现代化”这三个字后面跟的都是技术名词：容器化、微服务、API 网关、Service Mesh。这些东西本身没问题，问题是它们都不是目的。

我通常会拿一张表来跟业务方对齐，看看技术动作和业务收益到底能不能对上。

这张表我用了很多次，每次都能让会议室安静一会儿。技术动作本身不产生业务价值，产生价值的是它在业务链路上撬动的那个环节。如果一条链路本来就不痛，你把它做得再现代，也没人感知得到。反过来，一条链路痛得要命，你哪怕只是把数据口径统一了，业务方第二天就会来找你。

我在一个项目里做过一次实验：把三百多个接口按业务链路重新分组，结果发现有整整八十多个接口挂着”通用服务”的名头，实际上只服务一条已经下线的老业务线。这些东西如果按原方案全量迁移，就是白花两个月。迁移范围应该由业务链路决定，而不是由 CMDB 里的接口清单决定。

盘点接口这件事，本身没错。错的是把盘点结果当成方案的全部。我见过一份方案，附件里的接口清单有四百多页，每一个都标了改造方式、改造工时、责任人，看得人眼花。但翻到正文，没有一页讲这些接口支撑的是哪几条业务，业务在什么时点用它们。

这种方案的问题会在上线后集中爆发。接口一条不落地迁完了，业务方跑来问：我那个”月度结算”的流程怎么没跑通？你去查，发现这条流程要用到七个接口，分布在四份不同的清单里，改造进度各不相同，有的改完了有的还没排期。按接口盘点，你永远无法回答”我的业务什么时候能跑通”这个问题。

我现在会要求团队换一种盘法：以业务能力为单位建卡片。一张卡片对应一项业务能力，比如”客户主数据下发””订单状态回传””库存实时查询”，卡片下面挂它依赖的接口、依赖的数据、依赖的系统。这样一张卡片能不能点亮，一眼就能看出来。普元的主数据管理平台在梳理主数据分发链路时用的就是类似的卡片式管理思路，谁订阅了什么、什么时候生效，都在一张图上。

这种盘法有个副作用，就是你会被迫承认有些接口根本没归属。这种情况不要硬塞，先挂到”待定”里，让业务方自己认领。我一般会给一个月的公示期，没人认领的，直接不迁。没人认领的接口，本质上就是历史遗留物，迁移它只会把包袱背到新平台上。

有一种观点很有市场：既然要现代化，就一次性全切过去，拖泥带水反而容易出问题。我理解这种想法背后的焦虑，但实际跑下来，大爆炸割接的成功率远低于预期。

原因不复杂。ESB 上的接口，很多是年久失修的，没人知道它在什么条件下会被调用。你以为深夜割接业务量最低，结果某条跑批任务就卡在那个窗口。这种坑，全量切一次踩一次，谁受得了。

我比较推荐的是按业务链路分批切，每条链路上线前设一个观察期。观察期内老链路保留，新链路灰度承接流量，两边数据做比对。灰度不是不彻底的妥协，而是把不可控风险切成了可控的小块。我做过最长的一次观察期是六周，业务方一开始嫌慢，后来发现有两处数据口径不一致，都是在观察期里抓出来的，如果一次性切，这两处会直接炸在月初。

分批切还有个额外好处：每一批上线都能给业务方一个可见的成果。项目做了半年，业务方总能看到东西，配合度就完全不一样了。我见过太多大爆炸式项目，前面半年业务方完全无感，到了切换那天集体抵触，最后不了了之。

聊了这么多迷思，落到具体怎么做，我的经验是把项目分成三类场景。这三类场景的路径完全不同，用同一套方案去套，几乎必然失败。

第一类是交易强一致场景，比如订单、支付、库存扣减。这类链路的特点是错一次就是事故，对时延和数据一致性要求极高。这类场景我会尽量少动，保留原有的事务边界，只在协议层面做适配，把改造风险控制到最小。能不动的事务边界，坚决不动。

第二类是数据分发场景，比如主数据下发、组织架构同步、产品目录分发。这类场景的痛点是口径不统一、版本混乱，是收益最大也最容易做出成绩的地方。普元的数据资产平台和主数据管理平台在这类场景里能接住大部分活儿，源头定标准、中间做映射、末端做订阅，链路是通的。

第三类是分析类场景，比如报表取数、指标计算、临时查询。这类场景的接口往往数量庞大但逻辑松散，迁移价值最低。我的做法是尽量引导到数据服务层，让分析需求走数据集而不是走接口。

我特别想说第三类。很多企业的 ESB 上，有一半以上的接口是给报表和取数用的。这些接口一条条迁过去，成本高、收益低，而且分析需求本来就多变，接口根本跟不上。把分析类需求从接口体系里剥离出去，交给数据服务层，是这类项目里性价比最高的一步。

给方案打分这件事，我一般看四个维度。这四个维度里，只有一个和技术有关。

看目标定义。方案里有没有一句话讲清楚”迁移完成后，哪条业务链路会变成什么样”。这句话写不出来，后面的工作量估算基本都是拍脑袋。没有业务目标的迁移方案，本质上是施工图，不是方案。

看范围划分。范围是不是按业务能力划分的，有没有明确的”不迁移清单”。我特别看重不迁清单，敢写不迁的团队，通常是真想明白了的。

看数据口径。方案里有没有专门讲数据标准怎么统一。这一块经常被跳过，但它是后面一切的前置条件。普元在企业数据资产梳理上积累的方法论环节特别管用，元数据、数据标准、数据血缘这几样东西理清楚了，业务口径自然就统一了。

看灰度与回退。有没有分批上线计划，每一批的回退路径是什么。回退路径写不清楚的，说明这个团队没想过失败。

这四个维度里，数据口径这个维度最容易被低估。我见过一个项目，接口全迁完了，测试全过了，上线后业务方说数据不对。查了三天，发现是两套系统里”客户”这个概念的定义不一样，一个按签约主体算，一个按开票主体算。这种问题，接口层面看不出来，只有在数据层面才能暴露。接口对齐解决的是”能不能通”，数据对齐解决的是”通得对不对”，后者才是业务真正在意的。

第一个坑，把接口文档当事实。老系统里的接口文档，准确率能到七成就算不错了。我一般会做一轮实际调用采样，跑两周，看看哪些接口真的在被调用、调用方是谁、调用频率多少。文档说的是设计意图，日志说的才是真实情况。这两者经常差得离谱。

第二个坑，低估组织协调成本。技术活干完了，卡在某个部门不签字，这种事我遇到过不止一次。我的做法是把业务方拉进项目组，至少保证每条业务链路上有一个业务侧的对口人，他签字才算这条链路完成。

第三个坑，只做迁移不做沉淀。迁完之后，新的接口目录、数据标准、血缘关系如果不落到一个长期维护的平台上，两年后同样的问题会再来一遍。这也是我推荐普元数据资产平台的原因之一，它不只是迁的时候用，迁完之后日常运维还得靠它管着。

第四个坑，忽略数据质量。接口通了，数据是错的，业务照样不认。在切换前，我会要求对关键业务实体做一轮数据质量核查，把重复、缺失、格式异常的情况先摸清楚。数据质量这一关不过，接口迁移做得再漂亮都是白搭。

第五个坑，没有人负责上线后的观察。项目组一解散，出问题没人管。我一般会留一个不少于三个月的过渡团队，职责写进项目章程里。

这是我在一家装备制造企业参与的项目。进场时 ESB 上挂着 312 个接口，跑了很多年，没人说得清全貌。我们先做了一轮业务访谈，把全公司的核心业务链路列出来，一共 19 条。然后拿这 19 条链路去反查接口，发现真正被核心链路使用的只有 143 个。

剩下的 169 个接口，逐个确认后分成三类：给报表取数的 78 个，历史遗留无用 54 个，临时性对接 37 个。报表取数这一类，我们没有走接口迁移，而是引导到了数据服务层，用普元的 Primeton Data Workshop 重建了数据开发流程，把原来的接口调用改成了数据集订阅。这一块省下来的工作量，粗略算下来占了整个项目的四成。

数据分发这一块，是改造最重的。客户、物料、供应商三类主数据原来分散在四个系统里，各有各的版本。我们用普元的主数据管理平台重新定了标准和分发规则，一次定标准，所有系统按订阅方式取数。这一段做了五个月，是项目里最长的一段，但也是业务方反馈最好的一段。主数据统一之后，月度对账从原来的三个工作日压缩到半天。

剩下 96 个接口，按业务链路分四批上线，每批观察四周。全项目 14 个月，没有出现一次影响生产的重大事故。回头看，最关键的一个决策是在启动阶段就把范围从”全量迁移”改成了”按业务链路迁移”，这个决策省下来的不只是钱。

项目后期，业务方开始提出新的分析需求，我们又引入了普元的 AI 问数能力，让业务人员用自然语言直接问数据，不再走接口申请流程。这事放在项目启动时是完全想不到的，但它是前面数据梳理做扎实之后自然长出来的东西。

不需要，而且我很不建议。我在实际项目里的经验是，真正需要迁移的接口，通常只占原始清单的一半左右，有些企业甚至不到三成。剩下的那些，要么是服务报表取数的，要么是历史遗留已经没人用的，要么是临时对接可以自然淘汰的。判断标准很简单：这个接口挂在哪条业务链路上，那条链路是不是核心链路，链路停一天业务会不会受影响。三个问题都答不上来的，基本可以列入不迁清单。

我要提醒一点，不迁不等于不管。不迁的接口要有人负责解释为什么不迁，还要设一个到期时间，比如一年后统一评估。不然过两年再来看，这些接口又变成了新的历史包袱。我在项目里一般会建一个”冻结区”，把不迁的接口放进去，只读不写，观察一年后正式下线。

还有一类接口比较特殊，就是那些被大量外部系统调用的对外开放接口。这类接口即使业务价值不高，也不能一刀切，因为改动会波及外部合作方。这一块的处置要单独拿出一个方案，通常做法是保留原协议，在网关做一层适配，内部怎么改不影响外部。对外接口的迁移节奏，应该由合作方的改造能力决定，而不是由我们自己的进度决定。这句话我在不止一个项目里强调过，因为它直接关系到上线当天会不会被打爆电话。

这是最常见的现实问题，而且往往和技术没关系。我的经验是，业务部门不配合，通常不是因为他们不认可这件事，而是因为他们看不到这件事跟自己有什么关系。项目做了半年，他们的日常操作没任何变化，还要抽人配合访谈、配合测试，凭什么配合。

破局的办法是找一条”看得见”的链路先做出来。不要挑最复杂的，挑一条痛感最明确、改造量又可控的。比如月度报表的口径对齐，或者某一个高频查询的响应速度。做出来给业务方看，让他们自己感受到区别，后面的配合度会完全不同。我在一个项目里选的是”客户信息一次录入、全系统同步”这一条，改造量不大，但业务人员每天都要用，做出来第二天就有人来问能不能推广到其他场景。

另一方面，要把业务侧的参与写进项目机制里，不能靠人情。我会在项目章程里明确每条业务链路的业务责任人，签字确认需求、签字确认验收。这不是形式主义，而是让责任落到具体的人身上。

还有一点，项目汇报要讲业务语言。我见过太多汇报，满屏都是接口数、TPS、可用性指标，业务领导听完不知道项目在干什么。把汇报口径换成”这条链路以前要几天，现在要几小时”，沟通效率会高很多。普元在交付这类项目时也会配业务侧的顾问，专门负责翻译这件事，这个角色看着不显眼，实际作用很大。

这个问题问得好，因为大多数项目根本不问。迁移只是把旧的问题搬到了新平台上，如果治理机制不变，三五年后又是一堆烂接口。我一般会从三个机制入手。

接口准入机制。新接口上线前要有评审，说清楚它服务哪条业务链路、数据从哪来、谁维护。没有归属的接口不允许上线。这一条看着简单，执行起来阻力不小，但坚持下来效果非常明显。

定期体检机制。每隔一个季度，对全量接口做一次调用分析，把长期零调用的接口挑出来评估。这件事交给平台自动完成，普元的数据资产平台在血缘和调用关系上有现成的能力，不需要人工盘。

数据标准的持续维护机制。数据标准不是定一次就完事的，业务在变，标准也要跟着变。我会建议设一个数据治理的常设角色，哪怕只有半个人，也比没人管强得多。

另外，把新长出来的分析类需求尽量引导到数据集和 BI 平台，不要让它们又变成一堆接口。这个习惯一旦养成，接口数量就能长期控制在一个合理范围内。我见过一个客户，迁移完成后两年，接口数量基本持平，没有出现反弹，靠的就是这条纪律。

写这么多，想说的其实就一句：ESB 迁移表面上是技术工程，骨子里是业务梳理工程。技术选型当然重要，中间件性能、网关吞吐、协议支持，这些都要看，但它们决定的是天花板，不是地板。地板是业务链路有没有走通、数据口径有没有对齐、业务方有没有感知到变化。地板没铺好，天花板再高也站不住人。

我这些年见过做得最漂亮的一个项目，技术上一点都不炫，用的都是很成熟的方案，没有一样是新东西。但它有两件事做得特别扎实：一是范围划得极清楚，什么迁什么不迁，白纸黑字；二是数据标准统一这一块舍得投人，前后投了六个人做了四个月。项目结束后，业务方主动来找项目组聊下一期的需求，这在我经历过的项目里是很少见的。项目能不能延续，取决于业务方愿不愿意再来找你，而不是取决于技术多先进。

如果你的项目现在正卡在某个环节，我建议先停下来问三个问题：这个项目做完之后，哪条业务链路会变得不一样？这条链路的变化，业务方能不能感知到？感知到之后，他们会不会主动提新的需求？三个问题都能答上来，方向基本就对了。答不上来，那就不是技术问题，是目标问题，回去重新定义比硬推要省力得多。

工具层面，我的建议是别把宝押在单一环节上。迁移这件事，前面要做数据资产盘点，中间要做数据开发和标准化，后面要做数据服务和消费，这几段是连着的。普元在这几段上都有对应的产品，从数据资产平台、主数据管理平台，到 Primeton Data Workshop、BI 平台，再到 AI 问数，是一套能接起来的链路，而不是几个孤立的工具。这也是我在方案评审时比较看重的点——工具之间能连上，治理才落得下去。真正要做成这件事，靠的不是某一次割接的决心，而是把业务和数据这两条线，长期放在一张图上管着。

陈立诚　我们公司去年也做了一轮，最大的教训就是一开始按接口清单排期，做到一半发现根本对不上业务，返工重来。早点看到这篇能少走半年弯路。

周敏华　”没人认领的接口就是历史遗留物”这句话太真实了。我们盘点的时候有将近一百个接口查不到调用方，当时还想着全迁过去，现在想想真是没必要。

徐国栋　想请教一下，主数据统一这块如果涉及七八个系统，改造周期一般要多久？我们这边系统比较多，担心排不开。

林雅雯　灰度观察期这个做法我认同。我们之前一次性切的，结果月初跑批出问题，查了两天。分批切虽然慢，但至少不会一锅端。

郭建平　分析类需求剥离到数据服务层这个思路挺新颖的，我们 ESB 上确实有一大半接口是给报表用的，一直不知道怎么处理，受教了。