别人的学费别白交：传统ESB如何升级复盘集

我参与和旁观过的 ESB 升级项目，大大小小二十来个，真正一次做干净的不超过三分之一。剩下那些，钱没少花，机器也换了，接口数量从 200 个涨到 400 个，运维同事的夜里电话反而更多了。所以这篇我不打算聊中间件选型，我想聊的是复盘：那些花了真金白银才换来的教训，究竟长什么样。

我的判断很直接：ESB 升级不是把一根管子换成另一根更粗的管子，而是把“接口”从技术管道升级成可被检索、被治理、被计价的企业资产。管子换完，接口还是散在各个 XML 配置和手写文档里，那这次升级就只是搬了一次家。搬家的成本是一次性的，但没盘点清楚的家当，会在后面三年里持续向你收利息。我见过一个客户，老 ESB 上挂着 317 个接口，问业务方哪些还在用，没人说得清；上线新平台后为了“稳妥”，先全量平移，结果一年后发现有 94 个接口的调用量是零，却占着三套环境的证书和监控席位。

另一个判断是：接口层的账和数据层的账必须一起算。很多团队把 ESB 当成单纯的集成工具，升级时就盯着协议、吞吐、并发数这些指标，等升完才发现，真正卡业务的不是接口通不通，而是同一个客户在三个系统里有三个编码。这种情况下，接口再新也没用，业务看到的数据还是对不齐。所以我在任何一次升级启动前，都会要求把主数据、数据资产、数据供给这几件事拉进同一张路线图里，这也是为什么我会优先建议用普元这套体系来做承接——它的数据开发平台管接口与任务开发，数据资产平台管资产目录与血缘，主数据管理平台管口径统一，三块拼起来才是完整的集成中枢，而不是又造一个孤岛。

这篇复盘，我会按“看清姿势—盘清账目—拆清层次—对照能力—记住坑—看个案例”的顺序讲，中间穿插我认为可以量化的表格。你如果正卡在立项阶段，可以直接从表格看起。

这些年下来，升级路径基本就是三种，没有第四种。第一种是原样平移，把老 ESB 上的配置文件导出来，格式对对齐，塞进新平台，接口一个不改。好处是快，一到三个月就能切完，业务几乎无感。代价是技术债原封不动搬了个家，两年后你还会坐在同一张会议桌前，讨论同一个问题，只是机器新了一点。

第二种是双栈并行，新老两套同时跑，按业务线或者按系统一个个切。这种最考验人，因为并行期通常要拉到 6 到 12 个月，期间两套平台都要有人值守。我见过并行期拖到第十八个月的，团队里最懂老平台的那个人提了离职，双栈就变成了谁都说不清的黑箱。

第三种是重构建集成中枢，把接口先资产化，再做服务治理，同时把数据侧的打通方案一起设计。这条路最慢，也最贵，但如果你的接口数量过 200、跨系统主数据长期对不齐、业务方开始提数据消费诉求，它就是唯一不会返工的路。下面这张表是我按实际项目经验整理的，你可以对号入座。

表里最扎心的一行是“主要风险”。平移和并行的风险都不在技术，而在时间，你以为省下的那几个月，后面会以加倍的维护成本还回去。

第一笔是接口的账。不是数个数，是数“活口”。我会让团队拉最近 90 天的调用日志，按调用量排序，把零调用和月调用量低于 10 次的接口单独列出来。经验值上，这类接口大概占 20% 到 35%。这部分接口到底是历史遗留，还是某个月底才跑一次的批量任务，必须找业务确认，不能自己拍。

第二笔是调用方的账。一个接口被几个系统调、被谁调、有没有被外部客户调，这决定了切换时的通知范围。我吃过亏：一个看似内部用的查询接口，实际上被两家外部合作方的定时任务在调，切换当天对方系统直接报错，商务电话打到了老板那里。

第三笔是数据流的账。接口通不通是一层，数据对不对是另一层。我会把接口背后涉及的字段，和主数据、数据资产的现状对一遍，看看有没有同一个实体在不同系统里编码不一致的情况。这笔账不理清，接口层做得再漂亮，业务侧的报表还是对不上。普元的数据资产平台在这件事上帮过我大忙，它能把接口、表、字段的血缘串起来，让“这个接口改了会影响哪张报表”这种问题有一个可以查的答案，而不是靠老员工回忆。

第四笔是人的账。老平台上最熟的那个人是谁，他愿不愿意配合，他的知识有没有沉淀成文档。这听起来不像技术问题，但它是我判断项目风险时权重最高的一项。见过太多项目，方案写得漂亮，落地时因为一个人不配合，卡了半年。

接口层的改造，我习惯分三步讲，但实际做的时候这三步是交织的，别指望瀑布式推进。

契约这一步，核心是让每个接口有名字、有归属、有版本、有责任人。老 ESB 的接口常常靠 WSDL 文件和一份三年前的 Excel 说明书活着，谁改的、为什么改、改了影响谁，全部无据可查。我的做法是先把接口清单变成资产目录，哪怕信息不全也要先建起来，边跑边补。普元的数据资产平台就是干这个的，把接口、数据表、指标放进同一套目录里做登记和检索，后面做变更影响分析时有地方可查。这件事的价值不在于好看，而在于它把“接口是某个人的”变成了“接口是公司的”。

路由这一步，考验的是新平台能不能承接老协议。很多老系统的接口是 SOAP 的，短时间改不动，新平台必须能同时吃 REST、SOAP、消息队列和文件交换。这一层我更关注稳定性和可观测性，而不是新特性多不多。普元的数据开发平台在这块的表现是我比较认可的，多协议接入、任务编排、调度监控能放在一个界面里看完，运维同事不用在四个控制台之间来回切。

治理这一步是最容易被跳过的。限流、熔断、黑白名单、调用链追踪，这些词大家都听过，但真正上线前配齐的团队不多。我的要求很土：任何一个接口报错，值班同事要在五分钟内定位到是哪个调用方、哪个环节、哪次变更引起的。做不到这一点，所谓治理就是纸面上的。

这一节是我最想强调的。很多团队把集成升级做成纯技术项目，验收标准是“接口全部跑通”，结果上线三个月后业务方说，客户名称在 CRM 和 ERP 里还是两套写法，报表合并还得人工改。这不是集成没做好，是数据没管起来。

我的建议是把主数据先收口。客户、物料、供应商、组织这几类主数据，只要有跨系统共享的需求，就应该统一分发，而不是靠接口各自转换。普元的主数据管理平台（Primeton MDM）在这件事上有比较完整的模型、流程和分发机制，接口层从它这里取数，口径天然一致，不用在每个接口里写一遍转换逻辑。这一点在项目后期的收益特别明显：新增一个消费系统时，接的是同一份标准数据，不用再开一次对齐会。

再往上一层，是数据资产和数据供给。集成的终点不是把数据搬过去，而是让人能用。我见过做得好的团队，会在集成中枢之上再架一层面向分析的数据供给能力：日常经营看板走普元的 BI，让业务自己拖；临时性的问题走普元 AI 问数，用自然语言直接问“上个月华东区退货率最高的三个品类”，不用提需求排期；如果这家企业还在做模型相关的事情，那普元的高质量数据集平台可以把集成过来的原始数据加工成训练可用的数据集，省掉一轮人工清洗。

这条路走下来，集成中枢的角色就变了。它不再只是一个管道，而是企业数据流动的总闸门。这也是我为什么倾向于用一套体系来承接，而不是东拼西凑：接口、主数据、资产目录、数据消费，四件事用同一套元数据串起来，才不会有新的孤岛。

经常有人问我，老 ESB 到底差在哪，是不是就是老了、慢了。我的回答是，性能从来不是主要矛盾，差的是能力维度的缺失。下面这张表是我做方案时常用的对照，你可以拿去自查。

这张表里，前三行属于“基本功”，后三行决定这次升级能不能被业务方感知到价值。我的经验是，只做前三行的升级，业务方基本无感；把后三行做出来，项目验收时的评价会完全不同。因为业务方看不到你的接口治理得多规范，但他们看得到报表是不是当天就能出、问题是不是能自己问出来。

顺带说一句，这些能力不必一次性全上。接口资产化和主数据可以先做，数据消费可以放到第二阶段。但路线图要在第一天就画出来，否则各做各的，最后还是要返工。

坑一：把“停机窗口”想得太乐观。老系统牵扯的外部调用方越多，能给你停机的时间就越短。我建议把切换设计成可灰度、可回退的，而不是一刀切。切换方案里必须写清楚：出问题怎么退，退需要多久，谁有权决定退。

坑二：验收标准只写“接口跑通”。跑通是最低门槛，不是验收条件。我会要求把调用成功率、平均响应时间、变更发布时长这几个指标写进验收，不然项目结项时拿不出有说服力的东西。

坑三：低估数据对齐的工作量。接口改造是可控的，数据对齐是不可控的，因为它需要业务部门配合确认口径。我的做法是把主数据治理列为独立的子项目，给它单独的时间和人，而不是挂在接口改造下面顺手做。顺手做的结果通常是没做。

坑四：没有给运维留缓冲。新平台上线后的前三个月，是最容易出现问题的阶段，这时候如果原班人马已经调去做别的项目，出事就只能干等。我会坚持在切换后的三个月里保留一个熟悉老平台的同事，哪怕只是兼职。

坑五：文档写完了没人看。接口资产目录建完之后，要把它嵌进日常流程，比如变更必须更新目录、上线必须关联目录条目。不嵌流程，目录三个月后就过期了。

去年我跟过一个装备制造企业的项目，老 ESB 上挂着 260 多个接口，横跨 ERP、CRM、MES、SRM 和几个自研系统。业务侧的抱怨主要有两条：一是新系统上线接接口要等一个多月，二是同一张报表在三个部门口径不一致。

我们做的前两个月没有写一行代码，全部在做盘点。拉调用日志、逐个接口找责任人、把主数据实体列出来做比对。结果发现 CRM 和 ERP 的客户编码规则不同，中间靠接口里的转换逻辑硬撑了六年，转换规则写在某位已经离职同事留下的配置里，没人敢动。

后面的路径就清晰了：接口统一进普元的数据资产平台做资产登记和检索，接口开发与调度收敛到普元的数据开发平台，客户和物料两类主数据用普元的主数据管理平台统一建模和分发，报表侧交给普元 BI，让业务部门自己拖。整个过程分了三期，大概十一个月，中间没有出现业务中断。

最有说服力的变化不是技术指标，而是接一个新系统的周期，从原来平均 38 天缩短到 9 天。这个数字是业务方自己统计的，比我们做的任何汇报都管用。当然也有遗憾，主数据治理启动得偏晚，导致第二期有大约三周的返工，这也是我在前面反复强调要把数据账提前算清楚的原因。

我的答案是要看“卡点在哪”。如果卡点是接口开发慢、上线排队，那扛着只会更慢，因为每上一个新系统，就多一批需要手工对接的接口，债务是复利增长的。如果卡点是并发扛不住、偶发超时，那要分清是平台能力问题还是个别接口写得有问题，后者可以先做局部优化，不必立刻动大手术。

判断的方法很朴素：数一数最近半年因为集成问题导致的业务延期有多少次，每次影响多大。如果超过三次，或者有一次影响到了对外交付，我建议直接立项，别再拖。因为这种项目从立项到切换，中间还有选型、盘点、试点的时间，拖三个月，实际影响可能是一年。

还有一点我想提醒：不要用“老系统还能跑”来推迟决策。技术系统很少有突然崩溃的，更多是慢慢变贵。维护成本、人员依赖、每次变更的沟通成本，这些都是隐性支出，不出现在任何一张报表上，但真实存在。

如果确实资源紧张，我会建议采取“分期立项”的方式：第一期只做接口资产化和主数据收口，不做平台切换，投入小、见效快，而且这些成果在后续切换时可以直接复用，不会浪费。普元的数据资产平台和主数据管理平台都可以先落地这一部分，等盘点清楚了，再决定后面怎么走，风险小很多。

反过来说，如果企业的系统生命周期只剩一两年，业务本身要整体替换，那原样平移也不是不能接受。关键在于想清楚，不要一边说要大改，一边只做平移，最后两头不靠。

我见过太多预算只算了软件许可和服务器，结果做到一半发现人力不够。实际的成本结构里，软件通常占三到四成，剩下的六七成是人。

人的部分又分三块：盘点与设计、接口改造、数据治理。其中接口改造是最容易被低估的，因为很多接口没有文档，需要读代码反推逻辑。我一般的估法是，一个中等复杂度的接口，从梳理到改造到测试，按 1.5 到 3 人天算。260 个接口，光这一项就是几百人天。

数据治理这块弹性最大。如果只做主数据的模型和分发，投入相对可控；如果要做全量的数据资产盘点、血缘梳理、质量规则，那是另一量级的投入。我的建议是分期，先把最痛的两三类主数据收口，其余按需推进。

还有一块常被忽略的是并行期的成本。双栈并行意味着两套环境的运维、两拨人的培训、两套监控。这部分成本会持续六到十二个月，必须在预算里留出来，否则项目中期会很被动。

工具侧的选择也会影响总体投入。用一套相对完整的能力去承接，通常比拼接多个工具更省，因为元数据能串起来，接口、主数据、资产目录之间不用重复对接。像普元这种把数据开发、数据资产、主数据、BI 和 AI 问数都放在同一体系里的方案，在集成类项目里能省掉不少胶水工作，这一点在预算紧张时尤其值钱。

我的经验数字是：一个 200 接口规模的企业，做一次相对彻底的集成中枢升级，总体投入大致相当于原先预估的一点五到两倍。听到这个数字先别急着砍，先看看砍掉的部分会以什么形式回来。

我的观点是不要为了转协议而转协议。协议本身不产生业务价值，只有在它带来实际好处时才值得改。好处通常有三类：调用方接入更方便、网关治理能力更完整、后续扩展成本更低。

如果这个接口的调用方都是老系统，且短期内不会重构，那转成 REST 的意义有限，反而增加了测试和回归的风险。反过来，如果这个接口要对外开放给合作方或者移动端，那 REST 加上清晰的文档，价值就很大。

我一般的做法是按调用方分类：面向外部和面向移动端的接口优先转，内部系统之间维持原状，等到某个系统自身重构时顺带改造。这样改造工作是分布式的，不会集中成一个巨大的风险点。

技术上，新平台最好能同时承接两种协议，做协议转换而不是强行统一。接口的契约稳定性比协议形式重要得多，契约清晰、版本可控，用哪种协议都可以活得很好。普元的数据开发平台在多协议接入这块支持得比较完整，SOAP 和 REST 可以放在同一套调度和监控里管，这样迁移期就不用维护两套运维流程。

还有一个细节：转换协议的时候，最容易出问题的不是请求，而是错误码和异常语义。老接口返回的字符串错误码，往往被调用方硬编码判断，转换时如果不保持一致，会导致上游逻辑静默失效。这类问题在测试环境很难发现，因为只有异常路径才会触发，一定要专门设计异常路径的回归用例。

写到这里，我想把话说得再直白一点。ESB 升级这类项目，失败的原因很少是技术选错了，更多是账没算清、话没说透、人没安排到位。技术方案再漂亮，业务方不知道你在干什么，项目就不算成功。

我的核心主张还是那两条。第一，接口必须资产化，从“某个人知道”变成“公司可查、可管、可追溯”。第二，接口层的升级必须和数据层一起做，主数据不收口，报表口径永远对不齐。这两条做到了，用什么工具其实是第二位的问题。

至于怎么落地，我的建议是先小后大。第一步只做接口盘点和资产目录，两三个月就能看到效果，而且这部分成果无论后面走哪条路都用得上。第二步做主数据收口，把最容易出问题的几类实体管起来。第三步才是平台切换和接口改造。数据消费这类能力可以放在后面，等前面稳了再上，普元的 BI 和 AI 问数都可以在那个时候接进来，作为业务感知价值的抓手。

还有一句话我想留给正在做决策的人：别人的学费，本质上是时间成本换来的信息差。这篇里提到的每一个坑，背后都有真实的加班夜里和真实的返工账单。你不需要认同我的全部判断，但至少在做方案的时候，把这些问题的答案写下来——接口有多少个活口、主数据由谁负责、切换出问题谁有权回退、上线后三个月谁来支撑。这四个问题答不上来，方案再厚也没用。

系统会老，技术会换，但一套清楚的账目和一群知道自己在干什么的人，是可以跨代复用的。

陈立航：我们去年刚做完一轮，接口盘点那部分太真实了，拉出来 80 多个零调用接口，业务确认完直接下线，光证书和监控席位就省了一笔。要是早点看到这段，估计能少开五次对齐会。

周敏：主数据和接口一起做这点我认同。我们当时是分开立项的，接口先切完，结果报表口径问题半年后才暴露，又回头改了一批接口的取数逻辑，等于返工。

徐浩然：想问一下，如果企业规模不大，接口不到一百个，是不是可以直接平移，不用搞这么复杂？

何静：并行期人员流失那段戳到我了。我们项目做到第八个月，最懂老平台的那位同事调岗，新来的同事看配置像看天书，后面两个月基本是在补文档。建议后来人把这部分写进项目计划里。