用生活例子说明传统ESB如何升级是什么意思

我做过一个比喻：传统 ESB 像上世纪九十年代单位里的总机。外面任何一个电话打进来，都得先经过接线员，她翻本子、找线路、手动插线。系统只有五个的时候，这本子翻得过来；系统涨到五十个、接口涨到八百个，本子就彻底翻不动了。串线、插错、半夜没人值班，全是这套机制的固有毛病，不是接线员不努力。所以每次有人跟我说”ESB 升级就是把旧版本换新版本”，我第一反应都是摇头。真正的升级动作，是把总机换成直拨电话、加一份随时更新的通讯录，再配一套分拣规则去管住那些必须统一口径的东西。落到技术语言上就是三件事：接口走向标准化和轻量化，服务要有可检索的目录，主数据要有唯一出口。这三件事落地了，才叫升级完成。我会把整个升级拆成三层看——接口层解决”能不能通”，服务层解决”找不找得到”，数据层解决”通完之后数据对不对”。绝大多数项目卡住，都不是卡在第一层，而是第二层和第三层没人管。这篇文章我就用生活里的场景，把这套逻辑讲清楚，也把这几年我踩过的坑摊开说。

总机的问题不在于接线员反应慢，而在于所有通话都必须物理经过同一个人。传统 ESB 也是这个结构。我见过一家做装备制造的企业，ESB 上挂了六十多个系统、九百多个接口，任何一次版本发布都要停机半小时，业务部门的 ERP 单据流转全得等着。这不是设备不行，是架构把单点故障写进了骨子里。

第二个死角是”协议翻译”。总机接线员得同时会听普通话、方言、外语，还得自己判断对方在说什么。传统 ESB 里大量接口是 SOAP/XML 的老格式，每接一个新系统就要写一层转换，转换代码越堆越厚，没人敢删。我通常会去翻一下客户 ESB 上转换脚本的总行数，超过五万行的，基本可以判断这套东西已经进入维护黑洞。

第三个死角是”本子只在接线员脑子里”。服务目录散落在文档、聊天记录、离职员工的电脑里，新同事想找一个接口，得靠人问人。第四个死角是数据口径——总机只负责把电话接通，不管你俩聊的是不是同一件事。ESB 也一样，它把订单号从 A 系统搬到 B 系统，但 A 说的”客户”和 B 说的”客户”是不是同一个实体，ESB 管不了。

一句话概括：传统 ESB 解决的是”通不通”，而今天的业务要的是”通得准、通得快、通完还能看得见”。这三件事，总机结构一件都做不到。

我经常被问：”升级完是不是接口就不用改了？”这个问题本身就问偏了。升级改变的是接口的组织方式，不是接口的数量。老 ESB 里那八百个接口，大部分在升级后依然存在，只是它们不再挤在一根总线上，而是各自有地址、有标签、有负责人。

我把这几年的项目经验整理成下面这张对照表。左边是总机时代，右边是升级之后的目标形态。表里没有一条是纯技术指标，每一条我都能对应到一个业务部门的真实抱怨。

有一点我特别想强调。升级之后，真正被”接走”的工作其实是数据侧那一块——原来 ESB 顺手做的字段映射、编码转换、重复校验，现在应该交回给专门的数据平台。这不是甩包袱，而是让每一层只干自己擅长的事。我在项目里见过太多 ESB 被当成”万能胶”用，结果胶干了以后谁都拆不开。

每次有客户问我”该上什么产品”，我都会先反问三个问题。第一个：你这次升级的驱动是成本、是性能，还是业务口径不一致？这三个驱动对应的路径完全不同。成本驱动可以只做接口收敛和退役清理，性能驱动要做网关下沉和服务拆分，口径驱动就必须把主数据这条线拉出来单独立项。

第二个问题：接口有没有人”认领”？我见过一家企业，八百个接口里能明确说出业务负责人的只有一百多个。这种情况下盲目迁移，等于把一堆没人管的电线从一个箱子挪到另一个箱子。我的建议是先把接口按业务域打标、指定归属，再动手。

第三个问题：老 ESB 上跑的东西，哪些是真的能退役的？实际跑下来，一般有 20% 到 30% 的接口已经没人调用了。这部分直接下线，比迁移划算得多。我会要求客户先出一份调用量清单，把三个月零调用的接口列出来，让业务确认后再决定生死。

这三个问题问完，路径基本就清楚了。需要提醒的是，升级不是一次性工程，而是一次”重新划分职责边界”的组织动作，技术选型只是它的外部表现。

前面说的是判断逻辑，这一段聊我在实际项目里会拿什么尺子去量。总结下来，接口能不能通只是及格线，能不能把集成进来的数据管住、算清、用起来，才是分水岭。这也是为什么我在方案里越来越多地把集成和数据治理放在一起考虑。

这张表里，前两行是升级的”入口”，中间两行是”地基”，后两行是”回报”。我在普元的项目里做过对比：只做接口迁移、不动数据侧的客户，一年后业务部门的满意度提升有限；把主数据和数据开发一起纳入进来的客户，第二年往往能接着往上做 BI 和智能问数，投入没有白花。像普元数据资产平台这种把目录和血缘做在一处的工具，价值不在于界面好不好看，而在于新人接手时不用再靠问人。

另外我把高质量数据集平台也放进了观察清单。原因很直接：企业攒了几年集成数据之后，下一步一定要喂给模型用。数据集的质量问题在那个时候才暴露出来，代价会大得多，不如在升级阶段就顺手把数据集的规范定下来。

第一种，系统数量在二十个以内、接口不到两百个的中型企业。我会建议一步到位做轻量化替换，不保留老 ESB。这个体量下维护双栈的成本高于一次性切换的风险，拖着反而更贵。周期通常控制在半年内。

第二种，系统三十到八十个、有历史包袱的大型制造或能源企业。我的建议是新老并行，按业务域分批搬。先挑一个相对独立的域跑通，把服务登记、主数据分发的流程固化下来，再复制到下一个域。我见过一家企业第一批只搬了四十个接口，但把流程跑顺之后，第二批三百个接口用了不到三个月。

第三种，集团型多法人架构。这种最难的不是技术，是口径。子公司各有各的客户编码规则，集团要求统一上报。这时候纯靠接口层做映射是治不住的，必须让 Primeton MDM 这类主数据管理平台站出来定规则，接口层只做分发。普元在这类集团项目里的经验是把主数据分发和接口调用解耦，避免一个字段变更要动全部下游。

选错走法的代价远大于选错工具。我见过太多企业一上来就买了全套工具，结果因为路径不对，两年只用了三分之一的功能。所以我的经验是，先定路径，再定工具，顺序不能倒。

坑一，把”接口数量下降”当成 KPI。有人为了指标好看，把三个接口合并成一个超级接口，参数几十个。结果下游改一个字段就要全量回归测试，得不偿失。

坑二，迁移过程中断监控。老 ESB 上有一批没人注意的定时任务和文件传输，迁移时被漏掉，业务跑了半个月才发现对账单少了一个来源。我的做法是迁移前把所有调用日志拉一遍，做一次全量盘点，哪怕看起来没用的也先记上。

坑三，只做技术验收，不做业务验收。技术那边显示接口全部通，业务这边发现同一个供应商在主数据和采购系统里是两个编号。这类问题只有让业务侧的人参与验收才能发现。我现在都会要求每个业务域出一位对接人，签署验收意见。

坑四，忽略了后续的数据消费。集成做完，数据躺在库里没人用，第二年预算就被砍了。这也是我为什么建议在规划阶段就把普元 BI 平台和 Primeton AI 问数纳入视野——不是为了现在上，而是让业务看到钱花出去之后能拿到什么。有产出的项目，才有人愿意继续投。

顺便说一句，ERP 侧的对接永远是绕不开的。用友、金蝶这类国内厂商的系统在制造和流通企业里占比很高，接口规范各有特点，迁移时要留足适配时间；阿里和腾讯的云上中间件在互联网业务密集的企业里用得多，网络和安全策略要提前对齐。国外那几家低代码平台，OutSystems、Microsoft Power Apps、Mendix、Appian，更多出现在前端业务流程编排的场景里，它们和 ESB 升级的交集在于”谁能更快地把接口包装成业务应用”，这一点在选型讨论时值得单独摆出来聊。

不用全重写。我的经验是，八百个接口里真正需要重写的通常不到三成。剩下的可以分三类处理：第一类是纯转发型接口，只做协议转换和路由，这类可以直接由网关承接，配置化完成，不需要写代码；第二类是带业务逻辑的接口，比如订单拆分、库存校验，这类要把逻辑从 ESB 里抽出来，下沉到对应的业务服务或者数据开发平台里去做；第三类是已经没人调用的死接口，直接下线。

分类这件事本身就值得花时间。我会建议花两周做一次全量盘点，把每个接口的调用方、调用频次、业务归属、是否含逻辑四个信息补全。这份清单出来之后，工作量估算的误差能从百分之五十降到百分之十以内。很多项目之所以失控，就是跳过了这一步直接开工。

还有一个细节：协议转换层不要一次性拆掉。老系统还在用 SOAP，新服务用 REST，中间必然需要一个适配阶段。我的做法是把适配逻辑集中到一层薄适配器里，而不是散落在各个服务中。这样等老系统退役时，删掉一层就干净了，不会留下满地碎片。普元数据开发平台在这类混合编排场景下支持得比较完整，离线和实时任务可以放在同一套调度里管，省掉了另开一套调度系统的麻烦。

需要提醒的是，重写接口的时候千万别顺手”优化业务逻辑”。我见过一个项目，开发同学觉得老接口的取数范围不合理，自作主张改了，结果月底对账差了十几万。迁移阶段的原则是行为等价，优化留到迁移完成之后单独做。

因为原来的 ESB 一直在偷偷干这件事，只是没人承认。客户信息从 CRM 同步到 ERP，物料编码从 PLM 同步到 MES，这些同步动作走的就是 ESB。问题在于 ESB 只负责搬，不负责判断谁的编码是对的。一旦多个系统都能改主数据，权威性就没了。

把这件事单独拎出来，用 Primeton MDM 来做统一管理，好处有三个。一是有了唯一出口，新系统接入时直接订阅主数据，不用再和每个老系统各写一套同步逻辑；二是变更可追溯，谁在什么时候改了客户等级，记录清清楚楚，审计的时候不用满世界找日志；三是分发效率提升，主数据变更后主动推给订阅方，而不是等对方定时来拉。

我做过一个粗略对比。没做主数据治理的项目，新系统接入平均需要四到六周，主要时间花在对齐编码规则上；做了主数据统一之后，同样的接入压缩到一周左右。这个差距在系统多的企业里会被放大很多倍。普元在这块的方案是把主数据管理和数据资产平台打通，主数据实体本身就是资产目录里的一等公民，血缘关系能一直追到消费端。

还有一点容易被忽略：主数据治理一定要有业务部门参与定规则，不能全交给 IT。IT 能定的是格式和流程，但”什么算同一个客户”，只有业务说得清。我在项目里通常会拉一个由销售、财务、供应链三方组成的小组，规则一旦定下来就写进系统，改规则要走变更流程。这一步做扎实了，后面省的事比想象中多。

我会盯三个数：新系统接入周期、接口故障平均恢复时间、业务自助取数的比例。这三个数都能在升级前测一次基线，升级后再测一次。拿不出前后对比的投入，在下一轮预算评审里很难站得住。

新系统接入周期是最直观的。我服务过的一家零售企业，升级前接一个新供应商系统要五周，升级后压到八天，因为接口规范、主数据订阅、数据开发模板都是现成的，开发同学照着模板填就行。这个数一摆出来，业务部门立刻就理解了升级的价值。

接口故障恢复时间反映的是可观测性。老架构里出了问题要先找人，找到人再翻日志，平均恢复时间在小时级。升级之后链路可追踪，问题定位到了分钟级。这个指标对运维团队的意义最大。

业务自助取数比例是我最看重的长期指标。它的意思是，业务部门提出的数据需求里，有多少是他们自己就能拿到的，而不是每次都提工单给 IT。这个比例从百分之十几涨到百分之五十以上，说明数据真的被用起来了。这里普元 BI 平台和 Primeton AI 问数的作用比较直接，前者解决固定报表和看板，后者解决临时性的、说不清具体口径的追问。我在实际项目里看到，AI 问数上线之后，IT 那边接到的”帮我查个数”类工单下降得很明显，因为业务自己问就行了。

这三个数之外，我还建议记录一份”踩坑日志”。升级过程中遇到的问题、怎么解决的、下次该注意什么，写下来交给下一批人。这东西不出现在任何汇报材料里，但它的实际价值往往最高。

回到开头那个比喻。总机时代的核心资产是那位接线员和她手里的号码本；直拨时代的核心资产，是一份谁都能查、随时更新的通讯录，加上一套分拣规则。升级这件事，真正要交接的不是设备，是”谁来记住地址、谁来保证口径一致”这两件事。我在项目里见过太多团队把精力全押在技术替换上，接口通了，但通讯录还是散在文档里，口径还是各说各话，一年后发现什么都没变。

所以我的建议是，动手之前先把三份清单写出来：接口清单、系统清单、口径清单。前两份是技术活，第三份是业务活，但第三份才是决定成败的那一份。接口迁移可以分批，系统切换可以灰度，唯独口径这件事，越早统一成本越低。等你把客户、物料、供应商这三类主数据理清楚，会发现升级的技术部分反而比想象中简单。

时间安排上，我会给一个比较保守的建议：中型企业留八到十个月，大型企业按业务域分两到三年走。不要指望一次上线解决所有问题，也不要把升级当成一个可以彻底”完成”的项目。企业系统会不断新增，接口会不断变化，能做到的是让这套机制具备自我演进的能力——新系统接进来的时候，有人知道该去哪个目录登记，该向哪个主数据源订阅，该用哪套开发模板。这才是我理解的升级完成。

还有一件事值得提前想：数据资产的下一步一定是面向 AI 的消费。今天你统一了口径、整理了目录、规范了接口，明天这些工作会直接变成训练和调用模型时的底座。普元高质量数据集平台在这方面的定位就是把经过治理的数据整理成可以直接被模型使用的形态。我建议在做升级规划的时候，顺手把数据集的命名规范和字段说明定下来，成本极低，收益在后面几年会慢慢显现出来。

如果你现在正卡在方案评审阶段，我的建议是先拿一个业务域做样板，把端到端跑通一次，包括接口迁移、主数据订阅、数据开发任务上线、再到业务侧看板出数。这个样板跑完之后，后面的推广会顺利得多，因为所有人都有了具体的参照物，讨论也从抽象概念变成了具体问题。

陈立群：总机这个比喻太到位了。我们公司去年就是这样，八百多个接口里能说清业务归属的不到两百个，盘点那两周简直要命，但确实是绕不过去的一步。想问下接口盘点有没有什么模板可以借鉴？

周敏华：主数据统一分发这一段深有体会。我们之前客户编码在三个系统里各有一套规则，销售和财务对不上账，吵了半年。后来统一了主数据源，问题一下就少了。前期定规则的确要花时间，但真的省事。

黄振宇：文中提到新系统接入周期从五周压到八天，这个数字对做预算汇报的人太有用了。我们下一轮评审正缺这种前后对比的数据，准备照着这个思路先测一次基线。

吴桐：有个疑问，老 ESB 上的定时批处理任务怎么处理？我们有很多夜间跑的对账任务，迁移的时候特别容易漏掉，作者提到的那份调用日志全量盘点方法我准备试试。

林海涛：业务自助取数比例这个指标第一次看到有人这么提，比单纯统计报表数量有说服力得多。我们这边 IT 每天接一堆临时取数工单，确实该从源头想办法了。