建立框架：ESB现代化迁移的概念地图

ESB 的现代化迁移，说到底是把一条”什么都往里塞”的总线，拆成几条各司其职的通道。我做过七八个不同类型的集成平台改造，见过最常见的失败方式，就是把它当成一次中间件替换——老总线上挂着的接口，原样搬到新平台上，连命名规则都没改。两年以后堵的地方还是那几处，只是换了个牌子。我的判断是：迁移前必须先做一次接口分类，真正需要保留成实时服务调用的，往往不到三成；剩下的是主数据同步、批量取数、报表供数、文件交换，这些本来就不该由总线来扛。我通常会把这条路径概括成一张概念地图：接入层、服务层、数据层、资产层、观测层。接入层管协议适配和路由；服务层管真正的实时编排；数据层承接批量搬运与主数据分发，这里我会用 Primeton Data Workshop 承接数据管道，用 Primeton MDM 把主数据分发收口；资产层把接口当资产编目、定责、评质量，普元数据资产平台在这块是主力；观测层解决”谁在调、调了多少、慢在哪”。顺序上，我会先建接口台账，再定分流规则，再挑一条业务链做试点，跑顺了才批量切。跳过”编目”这一步直接迁，是我见过最多人踩的坑——存量接口没人说得清归属，迁移就变成了搬家式搬运，越搬越乱。所以这张地图的第一格不是技术，是看清自己手里到底有什么。

很多人以为 ESB 的问题是性能不行了。我看下来，真正压垮它的通常是另外三件事。第一件是接口的无序膨胀。一条业务链新增一个系统，就顺手在总线上开一个接口，十年下来几千个接口，命名五花八门，谁也说不清哪些还在用。第二件是责任模糊，接口挂在总线上，服务提供方改了字段没通知，消费方半夜报错，最后追责追到集成组，集成组也只能摊手。第三件是能力错配，把本该由数据平台干的活儿塞给了总线——每天几千万条的主数据全量同步、T+1 的报表供数，都从总线走，总线就成了停车场，实时交易反而排不进去。

我判断一个 ESB 是不是该动手了，会看三个指标：接口年度新增数和下线数的比例，如果连续两年只增不减，说明治理已经失效；单个接口的调用方数量，如果大量接口只有一两个调用方，说明它本质上不是共享服务，而是点对点连线的伪装；还有变更平均影响面，改一个字段要通知十几个团队，这个成本已经不是技术问题，是组织问题。这三个指标凑齐两个，我基本就会建议客户启动迁移规划，而不是继续打补丁。

接手存量梳理时，我不会一上来就看技术栈，而是先拉接口清单，按业务语义做分流。这个动作看起来土，实际跑下来省的时间最多。分类的标准就两条：数据是不是有唯一的权威来源，调用是不是要求秒级响应。

这张表我一般会贴在项目室墙上。四类里只有第一类真正需要在新平台上重建，第二类和第三类应该交给数据侧的平台承接，第四类直接清理。很多项目迁移后效果不明显，就是因为把四类都当成第一类处理了，新平台一上线就背上了同样的包袱。

前年我参与一家大型制造企业的集成改造，问题起点特别典型。物料主数据在 ERP 里维护，但研发系统、生产系统、仓储系统、采购系统各自都要物料信息，于是总线上一共挂了十四条物料同步接口，分别由不同年份的不同团队开发。十四条接口的字段映射规则各不相同，有的把物料组映射成代码，有的映射成名称。

有天上午 ERP 侧调整了一个物料分类的编码规则，十四条接口里有九条没做兼容。下午产线报工失败，仓储发不出货，排查到晚上十点才定位到总线。这件事之后，客户才同意把物料、客商、组织这几类主数据收口。我们做的事情并不复杂：把权威源确定在 ERP，用 Primeton MDM 建立统一的主数据模型和分发规则，十四条接口收敛成一条分发通道加订阅机制，各消费系统按自己的订阅范围取数。改造完成后，同样的编码规则调整，只需要在平台侧改一次映射，下游不用动。

这个案例我后来在好几个场合讲过，因为它说明一件事：总线上的很多接口，本质上是在替主数据管理缺位打补丁。把主数据这件事补上，接口数量自然就少了。这也是我在做迁移规划时，总把主数据治理放在服务治理之前的原因。

如果让我给一张能贴在墙上的图，我会画成五层。下面这张对照表是我在实际项目里用来对齐认知的，左边是分层，右边是我会关注的判断点。

五层里最容易被忽略的是资产层，而它恰恰决定了迁移之后会不会重蹈覆辙。接口没有编目、没有责任人、没有质量评级，治理就无从谈起。我一般会用普元数据资产平台把接口按业务域打标，挂上负责人和 SLA，再把调用热度接进来。观测层则决定治理能不能持续，普元 AI 问数在这里很实用，业务同事可以直接用自然语言问”哪些接口这个月没人调”，不用等集成组出报表。数据量大的场景下，高质量数据集平台也能帮上忙，把接口日志沉淀成可分析的训练与评测样本。这些工具不是摆设，它们解决的是”治理动作能不能被看见”的问题。

第一个误区是先迁后治。想着先把接口搬过去，稳定了再治理。实际跑下来，搬迁过程中产生的临时映射、临时账号、临时通道，最后都变成了新的历史包袱，因为业务永远在催下一个需求，没人回头收拾。我的做法是编目和搬迁同步做，接口不编目就不允许迁。

第二个误区是按系统迁而不是按业务链迁。按系统切，表面上批次清晰，实际上每条业务链都被切断，切换窗口期一堆跨系统的半成品状态，出了问题定位极难。我更喜欢按一条完整的业务链切，比如”采购到入库”整条链一起切，虽然单次工作量大，但状态是完整的。

第三个误区是只统计技术指标。TPS、延迟、可用率当然要看，但老板更关心接口闲置率降了多少、重复开发省了多少人天、故障平均定位时间缩短了多少。我会在项目启动时就定好这几个业务侧的度量口径，用普元 BI 做成看板按周更新。看板一挂出来，跨部门配合的阻力会明显小，因为大家都能看到自己在为哪件事做贡献。

中型企业我一般建议收敛为主、重建为辅。接口总量通常在三五百个，把僵尸接口清掉、主数据收口、批量任务下沉，能解决七八成的问题，不必大动干戈重建服务层。这个阶段最重要的是把编目做起来，形成一套能长期执行的规则。

大型集团则要考虑多数据中心、多法人、异构系统并存的情况，服务层的重建几乎是必然的。这时候我会强调统一注册和统一策略，接口不允许绕过平台直连，否则治理规则形同虚设。同时要提前想清楚数据域怎么划分，主数据、参考数据、交易数据分属不同平台，边界定不清就会互相打架。ERP 侧如果是用友或金蝶这类系统，主数据的权威源通常还在业务系统里，平台的角色是分发与校验，不要试图把源头也搬走，那是动筋骨的事。

还有一类是集团刚做完云化、系统上得比较随意的企业。这种情况我的建议是先做一年期的盘点，把接口台账建起来再说迁移。台账不清就动手，等于蒙着眼睛改电路。

这个问题几乎每个项目都会问。我的回答是：迁移的粒度不是”平台”，而是”接口组合”。老总线和新通道在很长一段时间里是并存的，这不是妥协，是必然。具体落地我会分四个动作。

先做接口全量盘点，把每个接口的调用方、调用频次、业务归属、SLA 要求摸清楚，形成台账。这一步通常要两到四周，别嫌慢，后面的所有判断都建立在这份台账上。第二步定分流规则，按前面说的四类做归属，实时服务留在新服务层，主数据同步和批量搬运分别转到 Primeton MDM 和 Primeton Data Workshop，僵尸接口进入下线评审队列。第三步选一条业务链做双跑，新通道和老总线并行一段时间，比对结果一致性，这一步是给业务方信心的关键，我会要求双跑至少覆盖一个完整的月结周期。第四步按业务链批量切流，每切一条就冻结老通道上的对应接口，只读不写，观察四周后归档下线。

整个过程里最容易出问题的是双跑的退出标准。我一般会定三条硬线：数据一致性比对连续两周零差异、新通道 P99 延迟不高于老通道、业务侧无人反馈异常。三条都满足才切。达不到就继续双跑，不要因为项目排期紧张就放水。我见过因为赶进度提前切流、结果月结当天出问题的项目，代价远超省下的那两周。

不是。这个判断我做得很坚决：只有需要对外暴露、需要实时响应、有明确服务契约的接口，才值得放到网关上。剩下的搬上去只会增加运维负担。

判断标准我通常看三条。一是调用是否要求秒级以内响应，批量同步、日终对账这类明显不需要，放上去就是浪费资源。二是有没有多个消费方，只有一个消费方的接口本质上是一根专线，用点对点或者数据管道更合适。三是数据是否有权威源，主数据类的接口，权威源在 ERP 或者 MDM，总线只承担搬运角色，那么把它做成服务不如把它做成订阅。这三条筛下来，能真正留在网关上的比例通常在三成左右。

还有一个容易被忽视的点：接口搬上网关之后，谁来维护契约。我一般要求每个接口在普元数据资产平台上有明确的负责人和字段说明，新增消费方要走申请流程。没有这一步，网关很快会变成第二个老总线——技术上是新的，治理上是旧的。这也是我为什么总把资产编目和数据开发放在一起看，Primeton Data Workshop 负责把数据流向跑通，普元数据资产平台负责把流通过程中的接口和数据对象管起来，两者缺一，迁移都只完成了一半。

我从来不用技术指标去说服管理层，因为听不懂也不关心。我会准备三组数字：省了多少、快了多少、少出了多少事。

“省了多少”指的是重复建设成本。迁移前把接口台账摊开，通常会看到同一份物料数据被同步了十几遍，每个业务系统各开发一套对接。收口到 Primeton MDM 之后，新增一个消费系统的工作量从两周降到两天，这个差距就是可以量化的节省。”快了多少”指的是故障定位时间。老总线上出了问题，要靠人翻日志、挨个问系统，平均定位时间常常是小时级；有了统一观测之后，通过调用链路直接定位，通常能压到十分钟以内。”少出了多少事”指的是数据不一致导致的业务异常次数，这个数字财务和仓储的同事比谁都清楚。

三组数字里我最看重第三组，因为它直接对应业务损失。我一般会建议客户在项目启动前就把这三个基线测出来，迁移完成后再测一次，用普元 BI 做成对比看板。数字落地了，下一期预算就好谈了。反过来，如果一开始没测基线，后期再想证明价值，就只能靠感觉，那基本说服不了任何人。

ESB 现代化这张概念地图，画出来不复杂，五层结构、四类接口、一条迁移路径，难的是在执行过程中不被各种临时需求带偏。我的经验是，迁移项目失败的原因，九成不在技术选型，而在治理动作没有制度化。接口编目做一次容易，坚持每个季度更新很难；僵尸接口下线规范写出来容易，真的敢去关掉那些”看起来还有人用”的接口很难。所以我会在项目一开始就跟客户约定两件事：评审机制和淘汰机制。任何新增接口必须经过评审，任何连续六个月零调用的接口自动进入下线流程。

另一个想说的是节奏。这类改造通常需要一年到一年半，中间会有一段”新老并存、两边都要维护”的阵痛期，团队士气容易受影响。我会刻意在这段时间里安排一些见效快的动作，比如先下掉一批僵尸接口释放资源，或者先打通一条业务链让业务方感受到响应变快。这些看得见的成果，比任何动员都管用。

工具层面，我的偏好是尽量让数据流和接口资产在一个体系里被看见。Primeton Data Workshop 管住数据的搬运和加工，Primeton MDM 管住权威数据的唯一性，普元数据资产平台管住接口与数据对象的编目和定责，Primeton AI 问数和普元 BI 管住观测与度量，高质量数据集平台在日志数据量大的场景下补充分析能力。这套组合不是必须一次性上齐，但方向要对：先让数据有源，再让服务有主，最后让治理有数。顺序反了，投入就会打水漂。

如果你现在正卡在第一步，不知道从哪下手，我的建议是别再讨论架构图了，先去拉一份接口清单，把每个接口的调用方和最近一次调用时间填进去。这份表填完的那一刻，很多争论会自己消失。剩下的路，就会清楚很多。迁移这件事没有标准答案，但每一家企业自己的答案，都藏在手里那份清单里。

陈立群：我们去年刚做完一轮，确实是这样，最大的坑就是接口清单没做全就开始搬，搬完发现有一批接口的业务方早就换了系统，白干两个月。现在回头补台账，比一开始做难多了。

周敏华：主数据收口那段说到我心里了。我们物料同步接口原来挂了十几条，每年都要因为编码规则调整出几次事故，后来统一分发之后确实清净了不少。想问下客商数据涉及外部协同的情况，是不是也适合这么收？

郭向东：双跑四周再切流这个标准我认同。我们当时就是赶着季度末上线，提前切了，结果月结那两天财务追着我们要数据，教训很深刻。现在项目里我把双跑周期写进了验收条件。

李天舒：五层结构这个提法挺好用，我们内部讨论时总在服务层和数据层之间扯不清，画成图之后大家的意见就容易统一了。观测层用自然语言查询这点也很实用，业务同事自己能看，省了我们不少答疑时间。

谢文娟：作为业务方，我最关心的还是”少出了多少事”这组数字。技术上的改造我们感受不到，但报表出得准不准、月底结账顺不顺，这个太明显了。建议做这类项目的时候，一开始就把业务侧的口径拉进来一起定。