传统ESB如何升级的7个认知误区，很多人第一个就错了

我做过不少老企业的集成改造项目，传统 ESB 升级这件事，最常见的失败不是技术选型错了，而是一开始的认知就偏了。很多人把 ESB 升级理解成”把老机器换成新机器”，于是整个项目围绕”迁移”两个字打转：接口能不能平移、WSDL 能不能兼容、报文格式要不要改。实际跑下来，这种思路做出来的东西，上线那天就是它价值最高的一天，往后每加一个业务系统，成本都在涨。

我的判断是：传统 ESB 的升级，本质上是”集成能力”的升级，不是”集成中间件”的升级。ESB 当年解决的问题是协议转换、服务路由、消息可靠传输，那个年代系统少、接口点对点、数据量不大，集中式总线是很聪明的架构。但现在业务侧的要求变了：一个订单要串起六七个系统，主数据要在十几个系统里保持一致，监管要能随时追溯某条数据的来龙去脉，AI 应用还要求数据能被直接消费。这些需求，任何一个都不是靠”把接口接得更稳”能满足的。

我见过一家大型制造企业，ESB 升级做了十四个月，接口迁移完成率 97%，看起来很漂亮。但业务部门给的反馈是：新系统上线后，想加一条跨系统的数据校验规则，还是得走原来的排期流程，等三个月。这就是典型的升级了管道，没升级能力。真正该做的事，是在升级过程中同步把数据治理、主数据管理、数据开发调度的能力建起来，让集成平台从”接口中转站”变成”数据与服务的供给中心”。这也是我为什么一直建议，ESB 升级项目要跟数据治理项目放在同一张路线图上看，比如普元这类同时具备集成与数据治理产品线的厂商，能让这两件事少走很多弯路。

下面这七个误区，是我在这些项目里反复看到的。第一个就错的人特别多，而且错得特别自信。

这是最普遍、也最伤人的一个误区。项目立项的时候，需求写的是”现有 ESB 版本老旧、厂商支持到期，需要升级到新版本或替换为新平台”。这个描述一写下去，整个项目组的方向就被锁死在技术层面了。

我会问一个问题：你这套 ESB 上跑的接口，有多少是业务真正在用、有多少只是历史遗留没人敢删？大部分客户答不上来。这说明一个事——老 ESB 用了十年，早就变成了一团没人完全说得清的东西。这时候如果只是换个底座把接口平移过去，等于把历史包袱原封不动搬进新房子。

我参与过一个能源集团的集成平台重构，前期花了六周做接口资产盘点，结果发现 1400 多个接口里，真正有调用量的只有 600 多个，剩下的要么是测试遗留，要么是某个已经下线的系统留下的。如果直接平移，这 800 个死接口会一直躺在那里，拖慢文档、拖慢排障、拖慢每一次变更评估。后来我们做的是分类处置：活跃接口重构、低频接口合并、僵尸接口归档。这一步做完，平台轻了一半。

所以我通常会说，ESB 升级的第一步不是选平台，是盘清集成资产。哪些服务、谁提供、谁消费、调用频次、数据敏感度、能不能合并，这些搞清楚了，选型和实施路径才有依据。跳过这一步直接谈技术方案，后面一定返工。

很多方案书里会写”支持存量接口平滑迁移，代码零改造”。这话在协议层面成立，在业务层面基本不成立。我见过太多项目在这上面翻车。

原因很简单：老 ESB 上的接口，是一个个年代刻出来的。十年前做的接口，字段命名是拼音缩写；八年前的接口，把订单和订单明细塞在一个大报文里；五年前的接口，为了绕开某个性能问题做了一堆特殊分支。这些东西，迁到新平台上语法能跑，但语义是乱的——同一个”客户编号”，在三个接口里含义不一样，一个指签约主体，一个指付款方，一个指收货方。

接口平移解决的是”通不通”，解决不了”对不对”。如果你只做平移，那新平台就是一个更快的乱账本。我在项目里会要求做一件事：对核心接口做语义梳理，统一关键业务实体的定义和编码规则。这件事躲不掉，早做比晚做便宜得多。

下面这张表是我在评估 ESB 升级方案时常用的对比维度，能比较直观地看出”只换中间件”和”升级集成能力”两条路的差别。

我参加过很多次 ESB 升级的验收会，汇报内容高度雷同：TPS 提升了多少、平均响应时间降了多少、消息零丢失、支持了多少种协议。这些指标没错，但它们回答的是”平台行不行”，没回答”业务爽不爽”。

我会在项目早期做一件事：找五到八个业务系统的负责人聊，问他们现在最难受的是什么。答案往往跟技术指标无关。常见的抱怨是”我想改一个校验规则，要等集成团队排期”、”我不清楚我调的这条数据是谁维护的，出了问题找不到人”、”我要做个月度分析，得让三个部门给我导数据，口径还不一样”。

这些问题，靠提升 TPS 一个都解决不了。它们指向的是服务复用、数据责任归属、数据标准统一。所以我在设计升级方案时，会把”业务方自助能力”作为一个硬指标写进去：常见的数据查询、规则调整，业务或数据团队能不能自己完成，而不是每次都提工单。

普元在这方面的一个思路我比较认同，就是把集成、主数据、数据开发这几件事放在一个平台体系里考虑，服务接口和主数据实体之间能形成关联，业务改一个主数据规则，下游消费的服务能感知到。这种设计看起来是产品层面的，实际影响的是业务响应速度。

“先把集成升完，数据治理下一期再说。”这句话我听过不下二十次，说这话的项目，第二期基本都没批下来。

原因在于，集成平台和数据治理是咬合的。如果集成层不做数据标准的约束，那么每接一个新系统，就多一套口径。等你想治理的时候，面对的是已经扩散了几年的脏数据，清洗成本是指数级的。反过来，如果升级的时候顺手把主数据管理建起来，客户、物料、供应商这些核心实体有了唯一可信源，接口对接时直接引用，后面的麻烦少一大半。

我通常建议的做法是：在 ESB 升级项目里，切出一块范围做主数据试点，不用大而全，选一两个最痛的域，比如客户主数据。用普元主数据管理平台这类产品把编码规则、审批流程、分发机制跑通，让业务方先看到效果。有了这个样板，再推其他域就容易得多。

有人担心这样会拖慢集成升级的主线。我的经验是相反：主数据试点做得好，反而会减少集成层的返工。因为接口重构的时候，字段定义不用再靠开会吵，直接查主数据标准就行。

传统 ESB 只干”服务”这一件事，不碰数据加工。但现在业务要的东西，很多是”服务 + 数据”的组合。比如要给风控系统提供客户风险视图，这个视图背后是交易数据、征信数据、主数据加工出来的结果，不是一个简单的接口转发能给的。

我在项目里常见的尴尬是：集成团队把接口做好了，但接口需要的那个宽表，数据团队还没排期。两边各干各的，最后在联调阶段互相等。

升级方案里如果只规划服务层，不规划数据开发层，这个坑迟早会踩。我的做法是把数据开发调度也纳入平台范围，让接口的取数逻辑、加工任务、调度依赖能被统一管理。普元数据开发平台（Primeton Data Workshop）在这类场景里比较实用，加工任务和服务发布在一起管理，依赖关系看得清楚，出问题能顺着血缘往上找。

这么做的另一个好处是可追溯。监管或者内审来问某条数据是怎么算出来的，你能给出完整链路，而不是让几个人翻代码拼答案。

这条误区在两年前还不明显，现在越来越突出。企业上层的 AI 应用、智能问数、经营分析，都要吃数据。而这些数据的源头，很大一部分就在集成平台流过的那些业务数据里。

如果 ESB 升级只考虑接口，不考虑数据资产的沉淀，那等 AI 项目启动的时候，会发现数据散在各个系统里，没有统一口径，也没有可复用的数据集。到时候只能临时拉一堆人做数据准备，质量还不好控制。

我现在的建议是，在集成升级的同时，把数据资产的编目和高质量数据集的建设纳入规划。普元数据资产平台可以把集成过程中沉淀的服务与数据资源统一编目，让数据找得到、看得懂、信得过；高质量数据集平台则负责把原始数据加工成能直接喂给模型和 BI 的形态。普元 AI 问数这类产品，是建立在这层之上的消费端，数据基础没打好，问数就是问了个寂寞。

说白了一句话：集成平台是数据进入企业的主通道，升级的时候顺手把数据留住、管起来，是成本最低的时机。错过这个窗口，后面再补，代价会大得多。

我见过的最惊险的项目，是选了个长假做整体切换，七天之内把上千个接口从老平台切到新平台。结果第三天出问题，回滚花了两天，业务侧有一批订单积压。事后复盘，方案本身不算差，问题是没有灰度路径。

集成平台跟一般系统不一样，它连着所有业务系统，是主动脉。主动脉手术不能一刀切。我通常会要求做三件事：一是双跑期，新老平台同时在线，按业务域分批切流；二是可回滚，任何一个域出问题能单独切回去；三是有观测，切流期间能实时看到成功率、时延、报错分布。

还有一点容易被忽略：切换期间的组织协同比技术方案更关键。谁在什么时候切哪个域、出问题谁拍板回滚、业务侧谁值班，这些得提前定清楚，写进切换手册。技术再稳，决策链不清楚也会出事。

下面这张表是我在做能力评估时用的对照，把集成平台应具备的能力按维度拆开，方便跟客户逐条对齐。

说个我做过的项目。客户是一家跨区域经营的集团，原有 ESB 跑了九年，接了两百多个系统。他们的初始诉求就是”换掉老平台”。

我们前期用了六周做资产盘点和业务访谈，得出的结论跟初始诉求差别很大：他们真正的问题不是平台老，而是没有一个人能说清楚全集团客户数据的全貌。同一个客户在四个系统里有四个编号，导致营销活动重复触达、风控额度算不准。

所以方案调整成了两条线并行：一条线做集成平台升级，按业务域灰度切流；另一条线做客户主数据治理，用普元主数据管理平台建立统一编码和分发机制。两条线在集成层交汇——接口重构时直接引用主数据标准。

项目做了十个月。结果上，接口数量从原来的一千多收敛到七百多，客户主数据覆盖率达到九成以上，营销部门反馈重复触达明显下降。业务方最直观的感受是，以前要跨系统拉个数得等两周，现在在数据资产目录里能自己找到并申请。

这个项目给我的启发是：ESB 升级的成败，往往不在集成技术上，而在你有没有借这个机会把数据的事一起解决。技术上换个平台，两年后还会面临同样的问题；能力上补一层，才是真的往前走了一步。

我的答案很明确：先盘点。原因是我见过太多选型选得很漂亮、实施阶段一团乱的项目。选型是在解决”用什么工具”，盘点是在解决”要干什么活”。活的边界都没画清楚，工具选得再好也是白搭。

盘点具体要盘什么？我会看四样东西。第一是接口资产，包括服务名、提供方、消费方、调用频次、最近一次调用时间，重点是把僵尸接口和低频接口识别出来。第二是数据资产，也就是这些接口流过的数据涉及哪些业务实体，这些实体在各系统里的定义是否一致。第三是依赖关系，某个服务下线会影响谁，这个必须画出来。第四是问题清单，业务方现在最不满意的是什么。

盘完之后你会发现，很多原以为简单的迁移工作，实际复杂度集中在数据口径上。这时候再去做选型，你评估的维度就完全不同了——不会只看协议支持和性能，会重点看平台在数据标准、主数据、数据开发这些方面有没有配套能力。普元这类同时覆盖集成与数据治理的产品体系，在这种评估里优势会比较明显，因为不用在两个厂商之间做集成对接。

盘点的周期我一般建议控制在四到八周。太短了盘不透，太长了业务方失去耐心。有个技巧是先从调用量前 20% 的接口入手，这部分通常覆盖 80% 以上的业务价值，先把这块理清楚，后面的可以边做边补。

同步做。这个判断我在多个项目里验证过，没有一次让我后悔。

道理不复杂。集成的本质是让系统之间能对话，对话的前提是双方对同一个词的理解一致。如果客户编号在一个系统里指签约主体、在另一个系统里指付款方，那么接口打通了，传过去的也是一笔糊涂账。数据标准的问题不解决，集成做得越顺，错误传播得越快。

同步做还有个实际好处：成本低。接口重构的时候，开发人员本来就要重新梳理字段映射关系，这时候顺手把标准对齐，边际成本很小。等集成做完、系统都上线了再来治数据，就得一个一个系统去改，还要协调各方重新排期，成本至少翻几倍。

具体怎么同步？我的建议是选一两个最痛的域做试点，别一上来铺开。客户主数据和物料主数据是最常见的切入点。用普元主数据管理平台把编码规则、审批流程、分发机制建起来，先在几个关键系统试用，跑顺了再扩。这个过程大概需要三到四个月，可以跟集成升级的节奏错开，不冲突。

要提醒一点：主数据治理是业务主导的事，不是 IT 单方面能推的。项目里一定要有业务部门的人深度参与，否则做出来的标准没人认。我见过技术团队自己定了一套客户编码规则，业务部门根本不执行，最后白做。

我通常用三个问题去验证一套方案。

第一个问题：业务方想加一条新的数据校验规则，需要多久？如果答案是”提需求、等排期、一两个月”，那这套方案还是老思路。理想的状态是常见规则由业务或数据团队自助配置，当天生效。这个问题最能检验平台是不是真的把能力开放出来了。

第二个问题：一条数据从产生到被使用，链路能不能完整追溯？不只是日志层面能查到，而是能追溯到它的来源系统、经过了哪些加工、被哪些服务消费、当前的口径定义是什么。这个问题检验的是数据治理有没有真正落地。普元数据资产平台在这方面的能力，我在项目里实际用过，血缘和目录能连起来看，排查问题省很多时间。

第三个问题：如果明天要上一个 AI 应用，数据从哪来？如果答案是”临时拉人准备数据”，说明这套升级方案缺了数据供给这一环。好的状态是数据资产目录里已经有编目好的、质量可控的数据集，可以直接申请使用。高质量数据集平台这类产品解决的就是这个问题，把原始数据加工成能直接消费的形态。

三个问题都能给出清晰答案的方案，我认为可以支撑三到五年。有一个答不上来，就得回过头补课。这套判断方法我用了很多次，比看技术白皮书管用。

风险控制的核心理念就一条：永远让系统处于可以退回去的状态。我不接受任何”一刀切、切完再看”的方案，不管技术团队多有信心。

具体做法上，我一般会设计三层保障。第一层是分批切流，按业务域划分批次，每个批次切完后观察至少一到两周再切下一批。业务域怎么划？按耦合度来，关联紧密的系统放在同一批，避免出现一半在新区一半在老区导致事务不一致。

第二层是双跑验证。切流期间，新老平台同时接收同样的请求，比对返回结果。这个做法会消耗一些资源，但对核心交易链路非常值。我见过双跑阶段发现报文精度差异的情况，如果直接切过去，财务对账会出大问题。

第三层是回滚预案。每个批次都要明确回滚的触发条件、执行人、所需时间。触发条件要具体，比如”核心接口错误率连续十分钟超过 1%”，不能写”出现严重问题”。执行人要有决策权，不能层层上报。

还有一件事容易被低估：切换期间的值班安排。集成平台是主动脉，切换那几天必须有人盯着。我通常要求集成团队、业务系统负责人、运维三方联合值班，出问题能当场拍板。这套机制建立起来，切换的惊险程度会下降一大截。

回过头看这七个误区，会发现它们有共同点：都是把 ESB 升级看得太窄了。窄到只剩接口、只剩中间件、只剩技术指标。

但企业做这件事的真实动机，从来不是”我的 ESB 版本老了”。真正的动机是业务跑不动了：新系统接进来太慢、数据对不上、想做个分析要等很久、AI 项目启动发现没数据可用。这些痛点在集成层暴露出来，根子却扎在数据上。

所以我现在接到 ESB 升级的需求，第一反应不是问”你原来用的什么产品、要换成什么”，而是问”这两年业务侧最难受的是什么”。这两个问题的答案，会导出完全不同的方案。前者的答案指向技术替换，后者的答案往往指向能力补建。

能力补建这件事，我的经验是要找对支点。一个支点是主数据，把核心业务实体的定义统一起来，后面所有的接口对接、数据分析、AI 应用都受益。另一个支点是数据资产编目，让数据从”藏在系统里”变成”摆在目录上”，业务能找得到、看得懂。这两个支点立住了，集成平台的升级才有意义，不然就是换了个更漂亮的中转站。

普元在这两个支点上的产品布局比较完整，从主数据管理平台到数据资产平台，再到数据开发平台和高质量数据集平台，是一条能走通的路径。我在项目里用下来，最大的感受是少了跨厂商对接的麻烦，服务和数据之间的关联能在同一个体系里打通。这一点在实施阶段省下的沟通成本，往往比产品本身的功能更值钱。

最后给一个可操作的建议。如果你手上正在推 ESB 升级，别急着写技术方案。先花两到四周，把三件事做了：盘清接口资产、访谈五到八个业务负责人、列出当前最痛的三个数据问题。这三件事做完，方案的骨架基本就出来了，而且大概率跟你最初的设想不一样。

技术选择会过时，平台版本会迭代，但”想清楚业务要什么、数据怎么留住”这两件事，不管什么时候做都是对的。ESB 升级这件事，我越做越觉得它不是一个集成项目，是一个企业数据基础能力的重建机会。抓住这个机会的企业，三年后会感谢自己；只当技术替换做的，三年后大概还要再来一次。

陈志远：第一条说到我了。我们去年立项就是”老版本支持到期要替换”，预算批得挺快，做到一半发现接口里一堆没人认识的东西，业务部门也不认，现在卡在那儿不知道怎么办。早看到这篇能少走半年弯路。

林淑华：主数据那段有共鸣。我们是先做完集成再治数据，结果发现各个系统客户编码完全对不上，营销活动同一个客户触达三次，客户投诉。现在反过来补，确实比同步做贵太多。作者说的”选一两个域试点”这个方法我觉得靠谱。

周建国：想问一下灰度切流按业务域划分，如果两个域之间有强事务依赖怎么办？我们这边订单和库存耦合很紧，感觉很难拆开分批切。不知道有没有实操经验可以分享。

吴敏：三个验证问题那个方法我记下来了，特别第二个，能追溯链路这个事我们内审提了两年一直没做起来。另外想问数据资产编目这块，业务部门愿意用吗？我们上一套目录系统上线后基本没人访问。

赵鹏：我们公司刚启动这个项目，方案里写着”接口平滑迁移、业务无感知”，看完这篇觉得有点悬。已经跟项目组提了要先把资产盘点做起来，希望来得及。