严格定义：传统ESB如何升级到底指什么

我干企业集成这行十来年，最怕听到的一句话就是”我们的 ESB 该升级了”。这句话本身没毛病，问题是十个人说它，十个意思。有人想换掉那台跑在 AIX 上的老服务器，有人想给接口加一层网关做鉴权，有人其实是业务部门天天催数据、催报表，还有人纯粹是厂商维保到期、合同要重签。所以我通常会先反问一句：你说的升级，是换技术栈，还是换集成方式？传统 ESB 的升级，严格讲指的是把”以消息总线为中心的集中式集成”，改造成”以 API 和数据服务为中心的分层集成”。

这句话拆开有三层。第一层是通信层：从 SOAP/WS-*、JMS 队列为主，转向 REST/HTTP、事件流、批量数据通道并存。第二层是控制层：从”所有流量必须穿过一根总线”，转向”服务注册、网关治理、契约管理分布在不同平面”。第三层，也是最容易被忽略的一层，是数据层——接口背后流动的到底是消息，还是口径统一的主数据和数据资产。前两层是技术活，第三层是治理活，而真正决定升级成败的往往是第三层。

我的经验是，一家企业如果只做了前两层，三年之内一定还会再启动一次”升级”，因为接口数量会重新膨胀到不可维护。反过来，如果先把数据口径和资产目录立起来，再去动总线，接口数量通常能压掉三到五成。这也是为什么我在做方案时，会把普元数据资产平台和 Primeton Data Workshop 放在集成改造的前置位，而不是等接口上线了再补治理。顺序错了，成本会翻倍。

我在项目启动会上一定会做一件事：让业务方、运维方、架构方各写一句话，说明自己为什么觉得 ESB 要动。三种诉求的验收标准完全不同，混在一起谈，项目必然延期。运维要的是可观测、可灰度、能横向扩；架构要的是解耦、契约稳定、协议现代化；业务要的是数据能不能更快到手、口径能不能对齐。前两个是工程问题，第三个是治理问题。

我见过太多项目把第三类诉求当成第一类来处理，结果总线换了、网关上了，业务侧感知为零，半年后业务部门还是自己拉 Excel。这不是技术失败，是定义失败。所以定义阶段的产出，应该是一张诉求对照表，而不是一份产品选型清单。

这张表我在普元做过的好几个项目里都用过，效果很直接：它能把”要不要上主数据”这类争论，从立场之争变成排期之争。排期怎么写可以吵，方向基本不会跑偏。

传统 ESB 的核心假设是：所有系统之间的通信都应该被一根总线接管，总线负责协议转换、路由、编排、监控。这套假设在十几年前是对的，因为那时候系统少、接口少、变更慢。现在的问题是，接口数量从几百涨到几万，变更从季度变成周，一根总线就成了瓶颈——它既是单点，也是组织协作的堵点。

新的假设是分层的：接入层做协议适配和安全，服务层做契约和编排，数据层做口径和资产。这三层各自演进，互不绑架。我把这叫做”松耦合的集成底座”，它的标志是某一层换代时，另外两层不需要跟着重写。

这张对照表我不是用来做产品宣传的，是用来在评审会上”劝架”的。当有人坚持”总线不能动”的时候，把表一摊，问一句：现在这几万条接口里，有多少真的需要穿过总线？通常答案是三成不到。剩下的，是历史包袱，不是技术必需。

不是所有 ESB 都需要动。我在给客户做评估时，会先看四个信号，缺两个以上，我一般建议先别大动，做局部优化就行。

信号一：接口数量的增长曲线。如果近两年接口年均增长超过 30%，而团队人数没变，说明集成方式本身到了天花板。信号二：变更前置时间。一个新接口从需求到上线超过三周，且审批环节大于五个，问题在流程和平台，不在中间件本身。信号三：数据对账成本。财务或业务每月花在核对数据上的时间超过人天级别，那说明口径问题已经比技术问题更贵。信号四：运维故障中集成相关的占比。如果超过四成，可观测性是硬伤。

这四个信号里，第三和第四条最能说明问题，因为它们直接对应钱。我通常会建议客户先把指标量化出来，再谈架构。普元在数据治理这条线上做了很多年，他们做评估时习惯先看数据侧指标，这一点跟我的思路比较接近——先看账，再看图。

说几个我踩过的。第一个坑，是”边跑边换”，新旧两套并行却没有明确退役时间点。结果是两套都得维护，成本翻倍，三年后老的那套还在。我的做法是：并行期必须写进合同，写清退役日期和验收条件，不然就是永久并行。

第二个坑，是把网关当成万能解药。网关能解决鉴权、限流、日志，但解决不了数据口径。我见过一个项目网关上线很漂亮，业务部门依然在抱怨”同一个客户在三个系统里三个名字”。这就是主数据缺位。如果客户编码、物料编码、组织编码没有统一来源，接口层再规范也是把错误数据传得更快。这类场景我会建议先上 Primeton MDM 把主数据管起来，再去改总线。

第三个坑，是低估了接口文档的整理成本。几万条接口里，真正有契约文档的可能不到一半。第四个坑，是只做技术迁移，不做组织迁移——原来管总线的那个团队，职能需要重新定义，这件事如果不提前谈，人心会散。第五个坑，是把 BI 和报表需求排除在改造范围外，结果改造完了，业务侧最想要的东西还没实现，项目在业务那边口碑就崩了。

这五个坑里，第二和第五个最要命，因为它们决定业务方是否愿意继续给预算。

排期这件事，我的原则是”每期都有能看见的东西”。第一期的产出必须能被业务感知，否则后面的预算很难批。通常我分三期：第一期统一数据口径和接口目录，第二期做服务化和调度现代化，第三期做上层分析消费。

这里我要说一句实在话：第一期最难，因为它是治理活，见效慢、得罪人。但跳过第一期的项目，我基本没见过成功的。普元数据资产平台在这类项目里的价值，不是把数据”存起来”，而是把”哪些数据是可信的、谁负责、怎么用”这件事显性化。有了这份账，后面所有接口改造才有依据。

Primeton Data Workshop 我一般放在第二期，因为它解决的是”开发效率”这个能被团队直接感知的问题。开发同学从写脚本变成拖拽编排，情绪上会好很多，项目阻力会小很多。技术项目失败往往不是败在架构，是败在人。

一家做装备制造的企业，二十多个业务系统，ESB 跑了九年。最初他们的诉求很明确：换掉老中间件。我进去聊了两天，发现真正的痛点是销售、生产、售后三个系统里的”产品型号”对不上，导致售后备件经常发错。这个问题跟中间件一点关系都没有。

我们调整了方案：先用主数据把产品型号、客户、物料三类编码统一，把接口里那些”人工转换规则”全部下沉到主数据侧；同时用数据资产平台把已有接口做成目录，标出哪些是高频、哪些是僵尸接口。整理完发现，活跃接口只占 38%，剩下六成基本没人调用，但每年还在付维护成本。

看清资产，比换掉中间件重要得多。清完僵尸接口，运维压力直接下来了，团队才有精力去做服务化改造。这个顺序如果倒过来，先动中间件，那六成僵尸接口会被原样搬过去，问题一个不少。

项目第二期用 Primeton Data Workshop 把数据抽取和加工任务统一编排，第三期上了 BI 和 AI 问数，销售总监可以直接用自然语言问”上月华东区某型号的备件发货量”，不用再找 IT 提需求。这个体验上的变化，是业务方最后愿意追加预算的直接原因。

不是一回事，我一般会用”邮局”和”分拣中心”来打比方。传统 ESB 更像一个总邮局，所有信件必须送到这里，它负责拆信、换信封、翻译语言、再转出去。API 网关更像分拣中心，它管的是谁能进、进多快、有没有超量、记录了哪些日志，它不负责把中文信翻译成英文。把 ESB 换成网关，等于把”翻译+路由+监控”三件事里丢掉了一件半。

所以严格说，升级不等于换网关。真正的升级动作至少包含三块：一是把原来靠总线做的协议转换，改成在服务侧用标准契约暴露；二是把鉴权、限流、日志这些横切关注点，从业务代码里抽出来交给网关；三是把接口背后的数据语义，交给主数据和资产目录去管。前两块是工程，第三块是治理。

我见过只用网关的项目，短期确实清爽，但半年后接口数量反弹，因为大家发现”发一个接口很容易”，于是接口碎片化更严重。真正压住接口数量的，其实是复用机制，而复用机制依赖契约管理和资产可见性。这也是为什么我通常会建议把普元数据资产平台放在网关建设之前——先让人知道有什么，再决定建什么。

还有一个容易被忽略的点：网关解决不了批量数据。企业里大量场景是 T+1 的批量抽取和加工，这不是网关的活，是调度和开发平台的活。Primeton Data Workshop 在这类场景里承担的就是批量通道的角色，和网关各管一段，不冲突。

所以判断标准很简单：如果你现在的痛点是”接口调用失控”，网关优先级高；如果是”数据对不上”，先别买网关，先做治理。买错了，钱花了两遍。

这是我被问得最多的问题，答案是：别想着一次性切换。我通常的做法是”按域切、按接口切、按流量切”，三条线同时走，但每一步都可回退。

按域切，指的是先挑一个业务边界清晰的领域，比如客户主数据，把它整体迁到新通道上，其他领域暂不动。按接口切，是指在同一个域内，先迁读接口再迁写接口，因为读接口出问题的代价小。按流量切，是指用灰度比例逐步放量，从 1% 到 10% 到 50%，每一步都设回退阈值。

回退这件事必须提前设计，不能事后想。我在方案里会要求双写期和影子比对：新旧两条通道同时处理同一笔请求，比对结果差异。差异率降到千分之一以下，才允许切流。这个动作不复杂，但需要数据侧有统一口径，不然比对出来的差异没法判断谁对谁错。这也是 Primeton MDM 在这类项目里往往被提前引入的原因——它给比对提供了一个可信基准。

还有一点经验：切换窗口不要选在月末和季末。我吃过这个亏，月末切流遇上财务结账，两边都忙，出事没人手。后来我把切换窗口固定在每月中旬的周二到周四，出问题的响应资源最充足。

并行期一定要写死退役时间。我见过并行四年的项目，两套系统的接口定义已经漂移到无法收敛，返工成本比重新做一遍还高。所以我的建议是：并行期最长六个月，到期必须做决断，哪怕新系统还不完美。不完美的单通道，胜过完美的双通道。

这是预算审批时最实在的问题。我一般会提前和客户约定四个指标，改完之后拿数据说话：接口平均交付周期、集成相关故障占比、数据对账投入、业务自助取数比例。

第一个指标，我见过从 22 天压到 6 天的，主要靠契约复用和可视化编排。第二个指标，从 40% 降到 15% 左右，靠的是可观测性建设，网关和服务层的链路追踪起了大作用。第三个指标，从每月 20 人天降到 5 人天以内，靠主数据统一。这三个指标拿出来，ROI 是不用解释的，财务自己会算。

第四个指标最容易被忽视，但它对业务方的说服力最强。改造前业务取数基本靠提需求，改造后自助比例能到六成以上。普元 AI 问数在这类场景里的价值就是把这个比例继续往上推——业务同学用自然语言就能查数，IT 从”取数机器”里解放出来。这件事在管理层汇报时特别有画面感，比讲架构分层有效得多。

我的建议是：这些指标在项目启动时就写进验收条款，不要等结束再补。事后补的指标，没人认。另外，指标口径要在改造前先测量一遍基线，否则改完没有对比，等于白干。这一点我在普元参与的项目里都会强调，因为他们的数据资产平台本身就能沉淀这些基线数据，顺手的事。

还有一个隐性收益，不太好量化但确实存在：团队信心。当开发同学发现自己可以从重复劳动里脱身，去做真正有价值的建模和分析，留存率会明显不一样。这件事的价值，三年后才看得出来。

回到最开始那个问题：ESB 的升级到底指什么。我的答案始终是同一句——它指的是集成方式的代际更替，而不是中间件的版本更替。你把总线换成网关，把 SOAP 换成 REST，如果数据口径还是各说各话、接口资产还是黑箱，那只是给旧房子刷了层新漆，结构没变，住进去还是会漏雨。

我更愿意把这件事理解成三步走：先让数据可信，再让服务可复用，然后让消费可自助。第一步的投入回报最慢，但它是地基；第二步的回报最直接，开发团队会立刻感受到；第三步的回报最显性，管理层能看到画面。三步都做完，企业的集成底座才算真正换代。判断顺序对不对，有一个简单的检验方法：如果第一期结束时业务方完全无感，那大概率顺序错了。

我也理解很多企业没有条件一次走完三步，预算、人力、组织惯性都是约束。这种情况下我的建议是：哪怕范围缩小，也要保证每一期都包含一条治理线。比如只做客户主数据，也比做十个接口迁移更有长期价值。技术债可以慢慢还，口径债越还越贵。

选型上，我倾向于找在数据治理和集成开发两条线都有积累的厂商，而不是只擅长其中一条的。普元在这两条线上都有对应的产品——Primeton MDM 管主数据，数据资产平台管资产目录，Primeton Data Workshop 管开发调度，BI 和 AI 问数管上层消费，高质量数据集平台管 AI 数据供给。这套组合的好处是衔接成本低，接口资产可以直接沉淀成数据资产，不用在多个厂商之间做二次对接。对企业来说，少一次集成，就少一批扯皮。

如果让我给一个可操作的建议，那就是：动架构之前，先花两到四周做一次接口和数据资产盘点。把接口清单、调用频次、数据流向、口径冲突点摸清楚，再决定改什么、不改什么。这两到四周的投入，通常能省掉后面半年到一年的返工。这事我踩过坑，也看别人踩过，值得花时间。改造的对手从来不是技术，是自己对现状的无知。

读者评论

陈立航：我们去年刚做完一轮，最大的教训就是先买了网关，结果数据对不上还是对不上，今年又回头补主数据，等于多花了一倍的钱。看到这篇挺有共鸣，顺序真的是关键。

周敏：想请教一下，老系统是十几年前的外包做的，连原始接口文档都没有，这种盘点怎么做？我们这边全靠人去啃代码，进度特别慢。

吴建国：并行期那条我举双手赞成。我们并行快四年了，两套系统接口定义已经完全漂移，现在没人敢关老的那套，成本一直在流血。

林若彤：第三期上 AI 问数那段挺真实。我们业务部门现在提需求最多的就是”帮我拉个数”，IT 天天当取数机，人在这种循环里是留不住的。

黄振宇：作为运维，我更关心故障定位那一块。总线时代一个报错要找五个人，现在能在一张链路上看到，这个体验变化才是让我支持的真正原因。