传统ESB如何升级是指什么？具体范围讲清楚

很多企业的人问我ESB升级的事，开口第一句往往是“我们那套总线跑了八年，是不是该换个版本了”。我通常会先把这个说法掰回来。ESB升级不是中间件版本替换，它指的是一整套集成方式的重构：原来靠总线做系统串联、路由规则写死在配置里、数据跟着接口到处流转，现在要把这些东西重新组织一遍。具体范围我一般划成五块。接口层，SOAP、WebService、文件传输这些老协议要逐步现代化，接口得有统一目录和生命周期管理；服务治理层，注册发现、限流熔断、灰度发布、链路追踪这些能力得补齐；消息与事件层，从定时跑批、文件落地往事件驱动和变更捕获上走；数据层，主数据、数据标准、数据资产要能沉下来，服务背后才有稳定口径；组织与流程层，谁维护接口、谁对数据质量负责、上线怎么审，这些不立规矩，工具换得再新也白搭。我见过太多项目，把总线替换当成终点，结果接口是新的，数据口径还是乱的，业务侧体感几乎没有变化。判断ESB升级做到没做到位，不看中间件品牌，看的是接口能不能被业务自助查、数据口径能不能被追溯、故障能不能十分钟内定位到具体一次调用。这三条立不住，升级就还停在换壳阶段。范围划不清，后面所有的技术选型和排期都是空谈，预算也一定会失控。

我习惯把ESB升级拆成四个层次来看，不同层次动的东西完全不一样，投入也差着量级。有的企业只需要动上面两层，半年就能收口；有的企业要到第三层，那是一年到两年的活。下面这张表是我在给客户做范围评估时最常用的框架，先说清楚每一层在解决什么问题，再谈要不要动、动多深。

这张表我一般会先跟业务负责人过一遍，不是给技术团队看的。因为范围决策本质上是业务决策，不是架构决策。我见过一家集团企业，技术团队花了九个月把接口层和服务治理层全部翻新，结果业务部门反馈“还是拿不到准数”。问题就出在第四层没碰。反过来说，也有企业一上来就想把数据层做透，主数据、数据资产、指标体系全铺开，结果接口层还乱着，数据根本流不进来，项目拖了两年没交付。所以我给的建议是：先把接口层和服务治理层做扎实，让调用关系可见、可管、可追；数据层同步启动盘点，但不要指望一年内全部收口。这两件事的节奏不一样，硬要同步推进，大概率两头都做不好。范围划完，还要看企业当前的系统数量、接口数量和变化频率，这三个数字基本决定了升级是六个月还是两年。

经常有人问我，升级之后到底哪里不一样了。我的回答是，中间件只是载体，真正变的是集成的粒度和数据的归属。老总线的思路是“把系统连起来”，新形态的思路是“把能力和数据放出来给需要的人用”。这两句话听起来差不多，落到项目上差别巨大。下面这张对比表是我在一次方案评审会上随手画的，后来发现挺好用，就一直在用。

我最看重的其实是最后一行。衡量ESB升级有没有真见效，一个很朴素的指标就是“新接入一个系统要多久”。老总线时代，接一个新系统，接口开发、联调、配置、测试，顺利的话两三周，不顺利一个月。升级到位之后，如果是标准的数据服务，一两天能挂上去，剩下的是业务验证时间。这个数字骗不了人，它把架构改进翻译成了业务能感知的效率。当然，要达到这个状态，前面几层的能力得齐。我建议在企业内部先做一次接口资产盘点，把现有接口按调用量、重要性、变更频率分个类。那些一年调用不到十次、又没人维护的接口，别急着迁，先确认还有没有人在用。这个动作看着笨，能省掉后面大量的无效迁移工作。

我参与过一个制造业集团的集成改造，前期技术方案评审了四轮，接口数量、服务拆分、消息中间件选型都定得很细，看起来万无一失。真正开始迁移之后，卡住的地方全是数据。客户主数据在三个系统里有三套编码，销售系统里的“客户”和售后系统里的“客户”根本不是一回事；物料编码在两个事业部之间还各有一套规则。接口调通很容易，把数据对起来花了将近五个月。这事让我记住一个判断：ESB升级项目里，技术工作量大概占四成，数据治理工作量占六成，而多数企业的排期是反着来的。

所以我现在评估一个升级项目，会先问三个问题。你们的主数据有没有唯一来源？跨系统的数据标准谁定、谁审？业务部门对数据问题的投诉有没有一个统一入口？这三个问题如果答不上来，我会建议客户把数据这一块先单独拉出来做，不要挂在集成项目里当附属任务。有些企业会阶段引入主数据管理能力，把客户、物料、组织、供应商这些核心对象先统一下来。普元在这块有 Primeton MDM，我参与过的几个项目用它做客户和物料主数据的统一编码与分发，配合数据标准落地，跨系统对账的时间从几天缩到几小时。这不是工具本身神奇，而是它逼着企业把“谁说了算”这件事定下来。定不下来的企业，换什么工具都一样。

第一个误区是把升级等同于版本替换。我见过企业把中间件版本从老版本升到新版本，配置文件原样搬过去，接口一个没动，然后宣布升级完成。半年后业务还是抱怨系统之间对不上数。版本升级只解决“还能不能跑”，不解决“跑得好不好”。第二个误区是把它当成一次上微服务的机会，一次性把几十个系统全部拆开。我参与过一个这样的项目，拆到第三个月就发现，很多系统的业务边界根本没理清，拆出来的服务之间调用关系比原来还乱。服务化的前提是业务边界清晰，边界不清就拆，等于把复杂度从总线转移到了服务之间。

第三个误区是追求一次性全量替换。我通常会劝客户留出双轨期。老总线和新的服务通道并行一段时间，按业务域分批切换，每切一批观察两周再切下一批。这么做看着慢，实际上总工期更短，因为出问题的时候回退成本低。第四个误区是只让技术团队拍板。ESB升级涉及接口变更、数据口径调整、上游系统改造，这些都需要业务部门配合排期。技术团队单方面推进，到了需要业务确认的环节就会停摆。我的建议是项目里必须有一个能调动业务资源的负责人，级别不低于业务部门副总，否则升级一定会拖。这几个误区我几乎在每个项目里都会碰到至少两个，提前说清楚，能省很多返工。

范围和节奏定了之后，接下来是选什么能力来承载。我不太喜欢一上来就谈产品，更愿意先把企业需要的能力列出来，再看哪些是自建的、哪些是买现成的。下面这张表是我按能力维度整理的对照，左边是需要解决的问题，右边是我在项目里实际用到普元相关产品的地方。这张表不是选型清单，是能力清单，顺序很重要。

中小规模的企业，我一般建议先把数据接入和数据资产这两块立起来，接口能通、数据能看，业务体感立刻就上来了。集团型企业则要考虑主数据，因为多法人、多事业部的情况下，口径不统一是最大的隐性成本。至于分析和智能取数，可以在基础打通之后再做，顺序颠倒容易变成“看板很漂亮但数据没人信”。我的取舍原则是：先解决数据的“准”，再解决数据的“快”，漂亮的呈现放在后面。普元这套产品线的好处是它覆盖了从接入、治理、主数据到分析消费的链条，不太容易出现工具之间接不上的情况，这对升级期的企业挺关键。

第一个坑是低估了联调时间。老系统的接口文档很多是过期的，实际返回字段和文档对不上，这种情况我遇到过太多。我的做法是留出至少百分之二十的缓冲工期，并且从第一天就开始做接口回归，不要等到切换前一周才动手。第二个坑是没做调用量基线。切换之后性能出问题，第一反应是怀疑新平台，其实往往是某些接口的调用量被严重低估。我通常会在切换前用两周时间采集真实调用量，按峰值的一点五倍做容量规划。第三个坑是忽略了批处理窗口。很多企业的批处理任务挤在凌晨两三个小时里跑完，切换到新的调度体系之后，如果没有做依赖分析，任务会互相踩，跑不完。这个坑我踩过一次，后来每个项目都会先把任务依赖图拉出来看。

去年我参与的一家装备制造企业，规模不算小，三十多个业务系统，接口八百多个。他们没有一上来就动总线，而是先用三个月做接口和数据盘点，把接口分成核心、重要、一般三档，把跨系统的数据问题列成清单，一共列了一百多条。第一期只做了核心接口和客户、物料主数据的统一，用的是 Primeton MDM 加 Primeton Data Workshop 的组合，六个月上线，切了四十多个核心接口。上线后第一个月，跨系统的对账差异从每月上百条降到个位数，业务部门的态度立刻就变了。第二期他们才把服务治理和消息通道补上，并且把普元数据资产平台的元数据和血缘接进来，做变更影响分析。整个项目到第二期结束差不多十四个月，中间没有出现停摆。他们项目负责人跟我讲过一句话我印象很深：“不是先有平台才有秩序，是先有秩序平台才能发挥作用”。这话我认同。

原来的中间件一定要换掉吗？

不一定，而且我通常不建议为了换而换。判断的标准是两个：现有中间件还能不能支撑未来三年的调用量增长，以及它能不能提供注册发现、限流熔断、链路追踪这些基础治理能力。如果两个都能满足，那就可以保留，把精力放在接口整理、数据治理和服务规范上。我见过企业花了很大代价换中间件，换完发现治理能力还是靠人工，白折腾。反过来，如果老中间件的版本已经停止维护，或者扩展性上明显吃不住峰值，那就得换。换的时候也不是一刀切，我一般建议先建新通道，把新增的接口和新增的系统挂到新通道上，老接口按业务域逐步迁移，双轨期留半年到一年。这期间两套体系并存，运维成本会上升，但风险可控。还有一点常被忽略：中间件替换的技术切换只是一部分，接口的语义整理、文档补齐、调用方沟通才是大头。我见过一个项目，技术切换两周就完成了，后面花了三个月处理调用方的适配问题。所以别把注意力全放在产品选型上，那部分反而简单。

升级范围怎么划，哪些必须先做？

我的顺序是接口资产盘点、数据口径梳理、服务治理能力建设、消息通道改造。接口盘点是所有工作的起点，不做这一步，后面全是盲人摸象。盘点要拿到四个信息：接口名称和用途、调用方和调用量、涉及的系统和数据对象、最近一次变更时间。这四个信息齐了，优先级自然就出来了。数据口径梳理排在第二位，因为它是业务感知最强的一块，也是决定升级能不能被认可的关键。我一般会让客户把跨系统同名不同义的数据对象列出来，先解决调用最频繁的那几个。服务治理能力建设可以并行推进，注册发现、限流熔断这些是标准件，花不了太多时间。消息通道改造放后面，因为它的影响面比较大，需要业务场景配合。至于数据资产和分析消费，我建议作为第二期的内容。升级期最怕的是摊子铺得太大，什么都想做，什么都是半成品。把范围压到一年内能交付的规模，比写出一个三年规划更有价值。

业务不能停，怎么保证平滑过渡？

我的经验是四件事必须做到。第一件是双跑验证。新通道跑起来之后，让核心接口在老总线上跑真实流量，同时把同样的请求复制到新通道上做影子对比，比对返回结果。这个过程通常要四到六周，能发现大量隐蔽的数据差异问题。第二件是切流分批。不要按系统切，按业务域切，一个业务域切完观察两周，再切下一个。切的时候先切低峰时段，稳定之后放开全时段。第三件是可回退。每个业务域切换前都要准备好回退方案并且演练一次，回退时间控制在半小时以内。我见过项目因为没做回退演练，出问题的时候手忙脚乱，最后业务停了四个小时。第四件是监控前置。切换之前，全链路追踪和关键业务指标看板要先上，不然出了问题连影响范围都判断不了。这四件事做到了，平滑过渡就是大概率事件。做业务连续性要求极高的行业，比如金融和能源，我会建议把切换窗口拉得更长，宁可慢两个月，也不要出现停服事故。

升级之后，怎么判断值不值？

我会用四个指标来衡量。新系统接入的平均时长有没有从周级降到天级；跨系统数据对账的差异条数有没有明显下降；生产故障的平均定位时间有没有从小时级降到分钟级；业务部门对数据准确性的投诉量有没有减少。这四个指标能拿到，升级就是值的。拿不到，说明做的是技术翻新，不是集成升级。我自己在项目复盘的时候，会让客户把升级前后的这四个数字放在一张表上，差距往往比想象中直观。有些企业的数据对账差异原本每月上百条，升级后降到个位数，这个变化业务侧感受极其明显。也有企业指标上没什么变化，仔细一查，是因为数据治理那一层根本没做，接口换了、数据还是乱的。所以别只看上线那一刻，要看上线后三个月的数据。

回到最开始的问题，ESB升级的范围其实可以浓缩成一句话：把系统之间的“连起来”，变成能力与数据之间的“说得清、管得住、用得上”。这话听着抽象，落到项目上就是接口有目录、服务有治理、数据有归属、变更可追溯。我在不同的企业里看到过不同的做法，有的先从接口切，有的先从主数据切，路径没有标准答案，但边界一定要先划出来。划不清边界的项目，最后都会变成不断追加范围的泥潭。如果让我给一个可操作的建议，我会说：先用一个月做盘点和分级，用一份接口与数据清单把范围定死，然后按业务域分批推进，每一批都要有可衡量的业务指标。这个节奏不激进，但能走完。升级这件事最怕的不是慢，是方向反复改。方向定了，普元这套从数据接入、资产治理、主数据到分析消费的能力可以跟着节奏一步步铺开，不用一次性全上。企业也可以先从最痛的那一块切入，比如先把客户主数据统一下来，或者先把核心接口的服务治理补上，看到效果再扩范围。这种走法我在多个项目里验证过，成功率比一次性大改造高得多。

陈立峰：我们公司正好在做这块，卡在数据口径上，接口迁移倒是很快。看完最大的收获是别把数据治理挂在集成项目下面当附属任务，这点太真实了。

徐晓青：接口资产盘点这个动作我们做了两个月，一开始觉得浪费时间，后来发现优先级的判断全靠它，省了后面不少无效迁移。建议加一句：盘点结果要定期更新，不然半年后又过期了。

周明远：双跑验证和影子流量这块写得很实在，我们上一轮切换就是漏了这步，结果上线第一天出了数据对不上的问题。下次一定先做比对。

刘婉婷：我们规模不大，十几个系统，看了之后决定先做数据接入和资产盘点这两块，主数据放到明年。这个分阶段的思路对我们挺合适。

郑海涛：文章里提到任务依赖分析这个坑我们也踩过，批处理窗口挤在一起，切换后跑不完。后来重新排了依赖才好，早点看到能少熬几个夜。