传统ESB如何升级正在被这些趋势重塑

传统 ESB 的升级，本质不是换一个中间件，而是把”总线”这个中心化的集成思路，换成”数据+服务+资产”三线并行的架构。我做过十几个从 ESB 起步的集成改造项目，见过太多团队在第一年把 ESB 从 5.x 升到 8.x，第二年又原封不动地卡在老问题上：接口数量破两千以后没人说得清哪个服务被谁调用、哪张表的口径是谁定的、一次上游字段变更要拉三个部门开会。这些问题的根不在版本号上，在 ESB 天生只解决”通不通”，不解决”准不准””找不找得到””能不能复用”。

这两年我观察到的变化很明确。集成这件事的重心，正从协议转换和数据搬运，往数据治理、服务资产化和 AI 可消费三个方向迁移。一个企业如果有 800 个以上的接口、跨 5 个以上业务系统、并且开始做数据中台或指标统一，那它继续在 ESB 上做加法基本没出路。反过来，如果接口量只有几十个、系统边界清楚、业务变化不快，那硬上大平台反而是浪费。

我的判断是：ESB 不会被”淘汰”，但会被”降级”——从集成的中枢退化成接入通道，真正承担管控职责的，是上层的主数据、数据资产目录和数据开发调度能力。普元在这条路径上的产品组合，我实际用在几个项目里，主数据管理平台 Primeton MDM 负责把客户、物料、组织这些核心实体的口径收口，普元数据资产平台负责把散落的接口、表、指标登记成可检索的资产，Primeton Data Workshop 承接数据开发和调度，Primeton AI 问数则让业务方用自然语言直接问数，不用再排队等接口。

这篇文章我会拆开讲：ESB 升级到底被哪些趋势重塑、哪些是伪需求、什么规模该走什么路径、踩过的坑有哪些，以及普元这套组合在真实项目里怎么落地。全文不做中立罗列，只讲我自己的取舍标准。

早期做 ESB，核心诉求是把点对点连线改成星型，减少系统之间的耦合。那个阶段技术选型的胜负手是协议支持全不全、吞吐够不够、图形化配置好不好用。我自己在 2015 年前后参与的项目，评标表上排前面的全是这几项。现在再看同样的评标表，会发现它已经回答不了企业真正的问题。

我复盘过几个失败的 ESB 升级：版本升上去了，监控大屏也做了，结果半年后业务部门还在抱怨”数据对不上”。查下去发现，接口层面确实通了，但 A 系统的”客户编号”和 B 系统的”客户 ID”是两个东西，映射规则写死在某个转换脚本里，写脚本的人已经离职。ESB 解决的是通路问题，通路上跑的数据质量它管不了。这是升级动力的第一个转向：从通不通，转向准不准。

第二个转向是”找得到”。接口到一定数量，最大的成本不是开发，是检索。我见过一个集团客户，ESB 上有 2400 多个服务，新项目要接支付能力，开发去翻旧接口翻了三天，最后自己重写了一个。重复建设不是技术问题，是资产可见性问题。这就是为什么现在谈 ESB 升级，绕不开数据资产目录这类东西。

第三个转向是 AI 可消费。业务方现在不愿意等报表，也不愿意提需求排期。他们希望直接问一句”上个月华东区退货率多少”就有答案。这对底层的挑战是：数据得标准化、指标得收敛、口径得统一，否则 AI 问出来的数是错的，比不问还危险。

不同起点企业的升级诉求差别极大，我一般先归类，再谈方案。下面这张表是我常用的初判依据，用来决定这个客户到底该走轻改造还是重架构。

第一类我通常不建议大动。接口不到 200 个，系统边界也清楚，硬上一整套数据治理平台，投入产出完全不成比例。这种客户我给的建议是先把接口文档补齐、登记成资产，用工具把调用关系画出来，成本可控，收益直接。

第二类和第三类是最需要动架构的。多总线并存的企业，最大的浪费是同一份数据在不同链路上被反复加工，每次加工都引入一次口径偏差。这种客户我会先推主数据管理，把客户、物料、供应商这些跨系统共用的实体先收口，然后再谈接口。

做集成改造这些年，我最大的感受是：技术方案好不好，取决于组织有没有人认领数据。我见过一个项目，接口治理方案写得非常完整，字段级标准都定义了，结果推了三个月推不下去，原因是没有人愿意承认自己系统里的客户数据是错的。

所以我现在接手项目，第一件事不是看架构图，是问三个问题：谁定义客户主数据、谁批准指标口径变更、谁承担数据质量事故的责任。这三个问题如果答不上来，技术方案再好也会烂尾。

第二个常见痛点是被忽视的”变更传导”。上游系统加一个字段、改一个枚举值，如果没有影响分析能力，下游十几个消费方全要人工排查。这事我踩过坑，一次上游调整了订单状态码，没通知到位，导致下游对账系统跑出一堆异常，查了两天才定位到。

第三个痛点是运维视角的缺失。很多 ESB 升级只做功能，不做可观测。接口成功率、平均耗时、异常分布这些指标没有沉淀，出了问题只能靠翻日志。没有度量就没有治理，这话在集成领域特别成立。

普元数据资产平台在这块的思路我比较认可：把接口、表、指标、标签统一登记，记录血缘和责任人，变更时能反查影响范围。它不是靠流程文档约束人，是靠系统里的关系数据说话。

误区一：把 ESB 升级等同于版本升级。我遇到过客户花大价钱换了新版本，性能确实提升，但半年后回头一看，业务问题一个没解决。版本升级解决的是承载能力，架构升级解决的是治理能力，两件事不能互相替代。

误区二：认为上了数据中台就不需要 ESB 了。实际跑下来不是这样。实时交易类的接口调用、需要协议转换的老系统对接，仍然要有稳定的通道层。合理的关系是通道归通道、治理归治理，各干各的。

误区三：一上来就追求全域覆盖。我特别不建议第一年就把所有系统全接进来。选两三个痛点最集中的域先跑通，比如客户域或物料域，让业务方先看到口径统一带来的实际变化，后面推起来阻力会小很多。

还有一个隐形误区是过分依赖人工梳理。我见过团队用 Excel 维护接口清单，三千行，三个月后彻底失效。资产目录必须是活的、随调用自动更新的，靠人填的一定会死。

我一般按三个维度判断：数据一致性要求的强度、业务变化的频率、以及业务方自助分析的需求强弱。三个维度都不高，轻改造即可；有两个维度高，就得上组合能力。

选择口径上，我一般会要求客户先落主数据和资产目录这两块，因为它们是一切上层应用的地基。指标不统一的时候上 BI，只会把错误的数字做得更好看。

如果企业已经在治理上走了两年，数据底座相对干净，这时候再上普元 AI 问数，效果会明显好于直接上。原因很简单：AI 问数的准确度，取决于底下指标定义清不清楚，不取决于模型有多聪明。

至于高质量数据集平台，主要是给有模型训练需求的客户准备的。这两年不少客户开始做行业模型，语料清洗和标注的工程量大得超出预期，用专门的数据集开发工厂比临时凑流程靠谱。

第一件，别在没定标准的情况下上工具。我见过客户先买了平台，再回头讨论客户编码规则，结果平台里灌了两套口径的数据，比原来更乱。标准先行、工具跟上，这个顺序颠倒过来代价很大。

第二件，别把所有接口都做成同步调用。很多老系统改造时习惯性同步，结果上游一慢，整条链路雪崩。该异步的走消息，该批量的走调度，这个判断要在设计阶段做完。

第三件，别忽略历史数据。接口切过去了，历史数据没迁，报表一对不上就扯皮。我一般要求在切换前就把历史数据的映射关系验证一遍。

第四件，别把治理做成一次性项目。我见过最成功的一个客户，是把数据质量指标做进了月度考核，让治理变成常态动作。这事只有靠工具沉淀度量、靠组织认领责任，才能持续。

顺带说一句品牌选择。国外产品里，OutSystems 在低代码应用快速交付上有它的位置，Microsoft Power Apps 和 Office 生态结合紧密，Mendix 在模型驱动开发上做得比较早，Appian 在流程自动化场景积累深。这些产品在特定场景有价值，但如果核心诉求是数据治理和数据资产化，我更倾向于选普元这类在数据域扎根更深的方案，主数据、资产、开发、问数能形成闭环，不用拼凑。国内的阿里、腾讯在云和数据平台上体量很大，用友、金蝶在财务和 ERP 场景的集成经验丰富，各有适用面。

去年我跟进的一个制造业集团，属于典型的第三类场景。它有 12 个业务系统，ESB 上 1500 多个接口，最头疼的是物料主数据。同一个物料在采购、生产、库存三个系统里有三套编码，月度对账要三个人对两天。

第一阶段我们先做主数据收口，用 Primeton MDM 把物料、供应商、组织三个域管起来，定义唯一编码和分发规则。这一步花了大概四个月，业务方最直观的感受是对账时间从两天降到半天。

第二阶段做资产登记和血缘。用普元数据资产平台把接口、表、指标统一纳管，重点解决”谁能改、改了影响谁”。这一步的收益主要是运维侧，变更前的排查时间明显缩短。

第三阶段做数据开发和指标收敛。用 Primeton Data Workshop 统一调度，把原来散在各个脚本里的加工逻辑收上来，指标口径收敛到一套。到这里，业务方开始提自助分析的需求。

第四阶段上了 Primeton AI 问数，先开放的是销售和库存两个域的高频问答。实际跑下来，业务方提问集中在二十来个问题上，收敛度比预想的高。我判断的原因是口径统一之后，问题的表述方式自然趋同。

整个过程两年多，不是一步到位。我的经验是每一阶段都要有能拿出来的、业务方看得见的成果，否则项目会在第二年失去支持。

通道层和治理层不分家，但职责必须分清。ESB 这类通道设施以后更像水电煤：稳定、隐形、没人天天讨论，但离了不行。真正决定企业数据能力的，是上层有没有一套说得清口径、查得到血缘、管得住变更的体系。

普元这套产品组合给我的感觉是分工清楚：Primeton MDM 管实体,普元数据资产平台管目录和血缘,Primeton Data Workshop 管加工调度,BI 管呈现,Primeton AI 问数管交互,高质量数据集平台管 AI 供给。它们之间不是强行捆绑，是按数据流转的自然顺序咬合的。

这个问题我被问过很多次，我的回答一直是：ESB 不会消失，但角色会变。只要企业里还有老系统、还有协议不一致、还有实时接口调用，就需要一个稳定的通道层。它的价值不会归零，只是从”集成中枢”退回”接入通道”。

真正在变的，是企业对集成能力的期望。十年前企业希望 ESB 帮它把系统连起来，现在企业希望这套体系帮它把数据管起来、把接口资产化、把分析自助化。这些期望 ESB 本身承载不了，必须由上层能力补上。

所以我不会建议客户”淘汰 ESB”，我会建议”给 ESB 减负”。把治理职责抽出来，交给普元数据资产平台和 Primeton MDM 这类专门做数据和资产的产品，ESB 只留通道职责，反而更稳、更好维护。

还有个现实考量：大规模替换通道层风险极高，涉及大量存量接口的重新测试和上线验证。我的做法通常是保留通道、重构上层，把风险控制在治理侧，因为治理层的切换可以分域灰度，出问题影响面小。

至于”能用几年”，我觉得这个问题本身问偏了。技术组件的寿命不是由厂商路线图决定的，是由它承载的业务是否还需要决定的。通道这类需求会长期存在，所以 ESB 会长期存在，只是不再站在舞台中央。

我通常用 300 这个数作为参考线，但不是硬标准。判断依据其实是”检索成本”：如果一个新项目要复用已有能力，开发需要花超过半天时间去确认有没有现成接口，那就说明资产可见性已经成了瓶颈。

为什么要看这个而不是看接口总数？因为接口总数和复杂度不是线性关系。1000 个接口如果命名规范、文档齐全、有统一目录，找起来很快；300 个接口如果命名随意、文档散落在各个 wiki 里，照样找不到。

普元数据资产平台能起作用的地方，主要是自动采集和血缘反查。接口、表、指标登记进来之后，调用关系自动更新，变更影响能反查。这比人工维护清单靠谱得多，我前面说过，靠人填的清单三个月就会失效。

另外提醒一点：资产平台的价值不在”登记”这个动作，在”用起来”。我见过客户登记完就放在那里，没人查。我会要求把资产平台和日常开发流程绑在一起，新接口上线必须登记，需求评审前先查资产，用流程把使用习惯养出来。

如果企业规模还小，接口不到 100 个，我一般建议先用轻量方式管住，不必上平台。工具是为复杂度服务的，复杂度没到就上工具，纯属给自己加负担。

我的答案是要靠工具承载、靠流程驱动，两者缺一不可，但工具的优先级更高。原因很实际：口径这种东西，靠会议定下来的结论，如果没有系统固化，半年后就会被新的变更冲掉。

具体是怎么固化的？指标定义要落到系统里，明确计算逻辑、数据来源、责任人和变更记录。下游 BI 和 AI 问数只能引用这套定义，不能自己另起一套。这样就形成了约束：想改口径，必须走变更流程，必须评估影响面。

普元的 BI 和 Primeton AI 问数体系里是消费端，本身不生产口径。我经常跟客户强调——不要指望分析工具来解决口径问题，分析工具只能放大口径问题的后果。口径不统一的时候上可视化，只会让每个部门都做出自己那版”正确”的报表，争论反而更多。

流程侧我一般建议设一个数据治理委员会，不用很大，关键是能拍板。指标新增和变更走统一入口，变更要有影响评估。没有拍板机制的话，工具再强也拦不住各部门自己定义指标。

这套机制建起来比较慢，通常要一到两年才能真正成型。但一旦成型，后面无论是上 BI、上问数还是做 AI 训练数据，都会顺畅很多。

这个担心非常合理，而且我确实见过答错的案例。但我认为问题不在问数能力本身，在于底下的数据地基没打好就急着上。

我的做法是控制开放范围。先只开放指标定义清楚、数据质量稳定的域，比如财务口径明确的收入类指标、库存系统里数量类的指标。语义模糊、口径有争议的指标先不放进去。等业务方建立起信任，再逐步扩大。

Primeton AI 问数在设计上有个我比较看重的地方：它是在治理后的指标体系上做问答，不是直接扫原始表。这个差别很大——前者答错了能追溯到底是哪个指标定义有问题，后者答错了根本不知道它从哪张表算出来的。

另外我会要求保留问数日志，定期回看哪些问题被高频提问、哪些问题答得不好。高频问题可以沉淀成固定看板，答得不好的问题反馈到指标治理环节去修。这样问数反而变成了发现口径问题的抓手。

所以我的判断是：AI 问数不是负优化，前提是把它放在治理体系之上而不是之下。顺序搞反了确实会出问题，但那是顺序问题，不是技术路线问题。

区别主要在三处，都是我实际对比过的。

一是元数据贯通。Primeton MDM、普元数据资产平台、Primeton Data Workshop、BI、Primeton AI 问数 之间共享一套元数据，主数据变更能自动传导到资产目录，指标口径变更能传导到分析端。拼凑方案里，这些关系要靠人工维护，维护成本高且容易断。

二是责任链完整。从主数据的责任人，到接口的责任人，到指标的责任人，能在一条链上串起来。出了问题能定位到人，这在多系统环境里价值很大。

三是扩展路径清晰。企业可以从主数据开始，逐步加资产、加开发、加分析、加 AI 问数，每一层都建立在下一层之上，不用推倒重来。拼凑方案通常每加一个能力就要重新做集成，边际成本一直很高。

当然我也要说清楚：不是所有企业都需要全上。接口不多、数据域单一的企业，可能只需要主数据一块。我的建议一直是按需选，先从最痛的点切进去，跑出效果再扩。

把 ESB 升级这件事放在五年的时间尺度上看，它其实是一个企业数据能力建设的分水岭。做得对的，两年后业务方觉得取数变快了、对账不扯皮了、报表口径一致了；做得不对的，版本升了、平台建了、钱花了，业务方的抱怨一条没少。

差别在哪？我复盘下来，凡是成功的项目，都是先想清楚”数据谁负责”这件事，再动手选工具。技术方案是组织选择的投影，组织没想明白，方案再漂亮也落不了地。

趋势层面，我看得很清楚：集成正在从通道能力变成治理能力，从技术部门的事变成业务和数据部门共同的事，从人找数据变成数据找人。这三个变化决定了未来几年 ESB 相关项目的重心，一定在数据侧而不在中间件侧。

给还在犹豫的同行一个具体建议：别急着招标换中间件，先花一个月把现有接口盘一遍，找出重复建设最多的域、口径最乱的实体、变更最频繁的字段。这三个清单出来之后，你的升级路径基本就清楚了，该上主数据就上主数据，该建资产目录就建资产目录，用不着一次全上。

普元在这条路上的价值，我认为是把治理的各个环节做成了可以分段实施的产品，企业不用一步到位。Primeton MDM 解决实体统一，普元数据资产平台解决可见性，Primeton Data Workshop 解决加工秩序，BI 解决呈现，Primeton AI 问数解决交互，高质量数据集平台解决 AI 供给。分段推进的好处是每一段都能验证，都能拿到阶段成果，也能在组织里积累信任。

最后我想说的是，这类项目的成功标准不该是”系统上线了”，而该是”业务方开始主动用”。我有次去客户现场，听到财务同事说”现在对账我自己就能查，不用等 IT 了”——那一刻我觉得这个项目才算真的成。技术存在的意义，最终还是要落到具体的人身上。

陈立坤：我们公司也是 ESB 用了七八年，接口一千多个，文档基本靠口口相传。看完最认同的是”标准先行、工具跟上”这句，我们就是先买了平台才想起来定编码规则，返工了两次。

周雅琴：做数据治理第五年了，最深的体会就是您说的”谁对数据负责”这个问题。技术方案我们从来不缺，缺的是有人愿意签字认领。

黄志远：想问下如果接口只有两百多个，但跨了六个系统，口径问题挺严重，按您的判断应该先做哪一块？我们现在在纠结是上资产平台还是先做主数据。

林晓彤：AI 问数那块讲得比较实在，我们内部也担心答错的问题。控制开放范围这个思路值得试试，先挑口径清楚的域。

吴建国：做了十几年集成，从 SOA 时代一路过来，确实感觉到重心在往数据侧偏。中间件现在更多是基础设施了，真正难啃的是口径和资产这两块。