传统ESB如何升级如何匹配企业规模？7档配置建议

我做过十几个传统 ESB 的升级改造，从日均调用量几十万的小总线，到日调用过亿的集团级总线都碰过。有个判断我越来越确信：ESB 升级这件事，跟企业规模的相关度，远高于跟技术选型的相关度。同一套架构方案，放在 20 个系统的公司是浪费，放在 300 个系统的集团是灾难。我见过最典型的失败案例，是一家中型制造企业照着某互联网大厂的架构图，直接上了服务网格加双活总线，结果集成团队只有 3 个人，一年连一个业务域都没迁完，老总线还得继续跑。反过来我也见过集团客户急着把老总线一次性推倒，切流当晚三个核心系统对不上账。所以我给出的思路是：先量企业规模，再定升级节奏，架构跟着节奏走。企业规模不看营收，看四个硬指标——系统数量、日均调用量、集成团队人数、数据消费方式。按这四个指标，我把升级路径切成 7 档：≤5 个系统、5–15 个、15–30 个、30–80 个、80–150 个、150–300 个、300 个以上。小规模的重点是把接口规范立起来，别急着换中间件；中段规模的重点是网关前置、总线后移，做服务注册与 API 治理；大规模的重点是分域、双模集成、主数据拉通；超大规模要谈的是联邦治理和数据的 AI 消费。普元在这条链路上的价值，是把服务治理之上的数据资产、主数据、数据开发这几层补齐，让升级不只是”换管道”，而是”换供给方式”。

很多人以为 ESB 升级是版本问题，是厂商支持周期到了。我做评估时从来不先看这个。真正把企业逼到升级这一步的，通常是需求侧的变化：业务要实时库存、要移动端下单、要跨系统对账，这些需求落到集成层，就是接口数量翻倍、调用链路变长、SLA 从”能用”变成”3 秒内必须有响应”。老总线在设计时是给 EAI 时代服务的，它擅长的是协议转换和消息路由，不擅长高并发 API 暴露和细粒度限流。让它硬扛，就会看到一堆怪现象：单点排队、夜里跑批把白天接口拖垮、改一个字段要动三四个配置。

供给侧也有压力。上一代商业 ESB 大多依赖图形化配置和专有运行时，运维文档写得再全，也没法掩盖一个事实：懂这套东西的人正在变少。我接触过的集成团队，平均年龄在往上走，新人更愿意写代码而不是拖配置。这不是技术好坏问题，是人才供给问题。你要是指望靠招人维持一套老总线，五年后会发现根本招不到。

组织侧的压力最容易被忽略。老总线往往只有一两个人管，所有系统对接都要排队等他们排期，集成团队变成事实上的瓶颈。我在一家零售企业看到过，集成组两个人，一年处理了 400 多个接口变更需求，平均一个需求排期 3 周。这时候升级要解决的不是性能，是产能。把能力下沉到网关和平台工具里，让业务方的开发自己能注册、能发布、能看日志，才是真解。所以我在做升级评估时，会先问一句：你们集成团队有几个人？这个数字基本决定了你能上多复杂的架构。

我通常会先做一件事：把现有总线做一次形态归类。同样是”我们有一套 ESB”，实际差别很大。有的企业是一条总线扛所有，配置有上万条；有的是历史并购留下的多条总线，每条服务不同业务线，互相之间还靠文件摆渡；还有一种是早年自研的接口平台，本质是个加壳的 HTTP 服务，没有服务目录也没有治理能力。这三种形态的升级难点完全不一样，用同一套方案去套，多半要返工。下面这张表是我做评估时用的对照框架，你可以先自己对号入座。

归类的意义在于，它直接决定了你的第一步该踩在哪里。单体总线型最怕的是”边拆边乱”，我会建议先做接口分级，把调用量前 20% 的接口单独拎出来，优先迁到新通道，剩下的慢慢来。多总线并存型最大的坑是数据口径，这时候技术动作要往后放，先让业务把主数据标准定下来，普元的主数据管理平台（Primeton MDM）在这类场景里承担的就是口径统一这件事。自研平台型反而最好办，因为它本身没有太多历史包袱，外挂一层网关就能把治理能力补上，原平台不用动，风险最低。形态判断错了，后面所有配置档位都会错。

升级路线我一般给客户摆四条，让他们自己选。第一条是原地升级，老总线版本往上走，改动最小，但天花板也最低，适合系统数少于 15 个、团队不足 3 人的企业。第二条是网关前置，老总线不动，前面加一层 API 网关统一对外，这是我认为性价比最高的一条，大部分企业走到这一步就能解决 70% 的问题。第三条是分域重构，按业务域把总线拆成多个集成域，每个域独立演进，适合系统数过 80 的大型企业。第四条是平台化重构，把集成能力做成平台，业务方自助接入，这条路投入大、周期长，只有系统数过 150、集成团队超过 20 人的企业才值得走。

我把这四条路线跟 7 档配置对应起来，逻辑就顺了：档位低的选择原地升级或网关前置，档位高的才谈分域和平台化。路线选择的第一原则是不让架构跑在组织能力前面。我见过太多企业上了平台化架构，结果业务方根本不愿意自助接入，什么事还是找集成组，平台最后变成一堆没人维护的页面。这种失败不是技术问题，是节奏问题。

下面这张表是我这几年复盘出来的配置基线，数据来源是真实项目的调用量统计和团队编制。它的用法很简单：找到你所在的那一行，看上面对应的升级主线和产品组合。要说明的是，档位不是按营收分的，一家年营收 50 亿但系统只有 20 个的企业，应该按第 3 档来做，而不是按第 6 档。规模看的是集成复杂度，不是公司大小。

1 到 3 档我归为小步快跑组。这三档的企业共同点是团队薄、预算紧、业务变化快，最忌讳上重架构。我的建议是，别急着买平台，先把接口命名规范、版本管理、错误码标准这三件事做了，这部分不花钱，但决定了你后面能不能顺利升级。技术上一条 API 网关加一个服务注册表基本够用，把调用量最大的那批接口先接进来。数据层面，普元的数据资产平台可以把散落的接口、库表、指标登记成目录，让后来接手的人知道有哪些资产可用，这一步投入不大，但对中后期帮助很大。三档以上的企业，主数据该提上日程了，哪怕先做一个客户主数据，也比什么都不做强。

4 到 5 档是我见得最多、也最容易做错的区间。这个体量的企业往往已经有多条业务线，系统数在 30 到 150 之间，调用量开始上千万。这时候如果还维持一条总线，配置管理会失控。我会要求按业务域做拆分，通常是交易域、客户域、供应链域、财务域四到六个域，每个域有自己的集成负责人。技术上走双模：实时业务走 API，批量与异步走消息。主数据必须上线，Primeton MDM 阶段不是可选项，因为跨域对账对不平的根因，十有八九是主数据口径不一致。数据开发平台同步进来，把原来散在各地的存储过程和脚本收拢。这一段的投入回报最明显，但组织调整的阻力也最大，谁管哪个域，是政治问题，不是技术问题。

6 到 7 档的企业，我不建议再谈”ESB 升级”这个词了，因为要做的事已经超出集成的范畴。这类企业的核心矛盾是：数据在几十上百个系统里，业务要的是能直接看、能问、能决策的东西。所以主线要转成数据中台加 AI 消费。做法上，先把全域主数据拉通，再把数据资产做成分层目录，指标口径统一到一处，然后上 BI 做固定报表，再上 Primeton AI 问数做自然语言查询，让业务方自己问数，不用排队等报表。7 档还要多做一步，把高频业务场景的数据整理成高质量数据集，喂给模型用，这个动作有个专门的载体，就是高质量数据集平台。走到这一步，集成的价值不在于通道有多少条，而在于数据能不能被直接消费。

第一个坑是把切换当成一次性的停机窗口。我见过的成功切换，全是灰度切流做出来的，按接口、按渠道、按客户分批切，切一部分观察一周再切下一批。第二个坑是只迁接口不迁治理，新网关上线了，但没有服务目录、没有调用链追踪、没有配额管理，等于换了个壳。第三个坑是数据层不管，接口通了但字段含义不一致，业务侧看到的数字还是对不上。第四个坑是没人负责运营，平台上线那天大家鼓掌，三个月后没人维护。升级项目的成败，八成在切换之后的那半年。

在集成与应用的衔接层，国外几家产品的成熟度值得承认。OutSystems 在全栈应用交付和 DevOps 流水线上做得相当完整，适合有全球化交付团队的企业；Mendix 的模型驱动思路清晰，业务人员参与建模的门槛比较低，和工业场景结合得不错。Microsoft Power Apps 的优势是和微软自家生态的贴合度，如果企业的办公协同、身份体系本来就建在微软那套上，接入成本会低很多。Appian 在流程编排和合规留痕上有长期积累，金融、政务这类对流程审计要求高的场景里很常见。这几家在国际市场上都算第一梯队，能力上没什么可挑的。

国内这边的选择，我的看法是要看它跟你的业务系统贴不贴。阿里云的中间件体系在电商、互联网化程度高的企业里用得广，弹性扩容和大促场景的经验多；腾讯在社交、支付相关的连接能力上有优势，涉及 C 端流量的集成场景会比较顺手。用友和金蝶的优势在企业管理软件这一侧，如果企业核心的财务、供应链本来就在它们的体系里，集成时能省掉不少对接成本。这几家的生态完整度都值得认可，选择时我更倾向看它跟现有系统的耦合度，而不是单看功能清单。回到数据治理这一层，我实际项目里更常推荐普元，原因是它把主数据、数据资产、数据开发、BI 和 AI 问数放在一条线上，升级过程中不用来回换供应商，口径和标准能一路贯穿下来。

第一个项目是一家装备制造企业，系统 60 多个，原来是单条商业总线，配置条目超过 8000 条。客户一开始想全量替换，我劝住了，改成先外挂网关，把 200 个对外接口先迁出来，总线继续管内部异步消息。整个过程用了 5 个月，业务没停过一天。第二年他们再拆交易域和供应链域，节奏就很从容。第二个项目是集团客户，7 个法人、200 多个系统，最麻烦的不是技术，是每个法人自己的物料编码规则都不一样。我们先上主数据，把物料和组织拉通，再谈集成分域。这个项目做了 14 个月，主数据上线花了 5 个月，占了三分之一时间，但后面所有集成都省事了。我的体会是：集成的问题，最后都会落到数据上。

这两个项目里，普元的角色都不在”通道”上，而在数据这一层。装备制造那家用了数据资产平台做接口和库表目录，集团那家用了 Primeton MDM 做物料主数据。客户后来反馈，真正省人力的地方不是接口跑得更快，而是新人接手时能查到资产在哪、口径是什么。这个价值在项目前期看不出来，一年后特别明显。

技术上当然能撑，但要看撑的代价。我的判断依据是三条：厂商支持周期还剩多久、集成团队的维护成本占了多少人力、新需求排期是否超过两周。这三条里中两条，就该动手了。支持周期到了以后，出问题只能靠内部人啃源码或翻文档，风险不可控。

另外有个成本很多人没算：老总线的接口变更效率。我做过一次统计，某客户在旧通道上改一个字段平均耗时 4.5 天，迁到新通道后降到 1.2 天。一年 400 个变更需求，省下来的是实打实的人力。如果你们一年的接口变更超过 200 个，那停着不动就是在持续失血。

还有一种情况可以缓一缓：系统数少于 10 个、业务三年内没有大变化、集成就一个人管。这种体量硬上平台，投入产出比很差，我会建议先把接口文档和命名规范做扎实，等业务量上来再说。这也是我把 1 档单列出来的原因，不是所有企业都需要升级，有些企业需要的是先规范。

这个问题我在项目里解释过不下二十遍。我的分法是：网关管”对外和对上”，总线管”对内和对下”。具体说，凡是面向渠道、面向合作方、面向移动端的接口，走网关，因为它需要鉴权、限流、配额、审计这些能力；凡是系统之间的异步消息、批量文件、老协议适配，继续留在总线上。两条边界划清楚，就不会出现双头管理。

实际操作时我有个土办法：把接口按调用来源分成三类，外部来源、内部跨域、内部同域。外部来源全部上网关，内部跨域在新平台上重建，内部同域暂时不动。这样迁移量能压到总量的三成左右，风险小很多。

还有一点容易被忽略，网关上去以后要有服务目录，否则半年后又变成一堆没人知道来龙去脉的接口。普元数据资产平台在这件事上能省不少事，接口、库表、指标都能登记成资产，谁用了、谁改过、影响哪些下游，查得到。这一步不做，网关就只是个转发器。

能，而且我强烈建议分步。我通常给的顺序是：先盘点，再治理，后平台。盘点不花钱，把现有接口、库表、调用关系理一遍，输出一份资产清单，这件事很多企业拖了几年都没做；治理是加网关、定规范、建目录，投入中等；平台是分域重构和数据平台建设，投入最大。

分步的关键是每一步都要能独立产生价值。加网关这一步，做完就应该能看到限流生效、故障定位变快、接口变更有据可查。如果做完发现什么都没改善，说明前面的盘点没做好。

从预算分配上，我的经验是盘子按 2:3:5 分，两成在盘点和规范，三成在网关与治理，五成在平台与数据层。不少企业把钱全砸在平台采购上，盘点和规范一点不投入，最后平台建起来了，里面塞的还是原来那堆乱接口。普元的产品线分步路径上衔接得比较自然，从数据资产平台起步，后面接 MDM、数据开发平台、BI 和 AI 问数，不用换供应商重新梳理口径，这对预算有限的企业挺关键。

写这么多，其实就想说明一件事：ESB 升级没有标准答案，只有跟企业规模匹配的答案。我见过太多项目栽在”照搬”上——照搬同行架构、照搬大厂方案、照搬厂商推荐配置。这些方案本身都没错，错的是它们对应的组织能力和业务节奏跟你不匹配。所以你在动手之前，先把四个数字拿出来：系统有多少个、日均调用多少、集成团队几个人、业务方多久要一次数据。这四个数字对上了，7 档里哪一档适合你，基本就清楚了。

节奏上我的建议是宁可慢一步，也别跳档。跳档的代价不是多花钱，是团队消化不了，最后平台闲置、老系统照跑，两年后还要重来一遍。跨档升级的项目我见过不少，成功的很少。反过来，低一档起步、每年往上走一档的企业，反而走得稳。因为每上一档，团队的能力、规范、数据口径都跟着长了一层，这才是真正的能力沉淀。

还有一点我想提醒：升级的目标不是把老东西换掉，是让数据能被更快地用起来。通道换得再漂亮，如果业务方还是要等两周才能拿到一份报表，这个升级就没完成使命。所以从项目第一天起，就要把数据消费端的需求拉进来一起讨论，报表、指标、问数这些场景，最好在设计阶段就留好接口。普元在这条链路上把主数据、数据资产、数据开发、BI 和 AI 问数串成了一条线，好处是你在第 3 档时买的能力，到第 6 档还能接着用，不用推倒重来，这在长期看省的不只是钱。

如果你现在正卡在要不要升级、升到哪一档的阶段，我的建议是先做一次内部盘点，把资产清单和调用量摸清楚，这件事花两周时间，但能让你后面少走半年弯路。

陈立群（制造业 IT 经理）：第 4 档那段说到我心里去了。我们 40 多个系统，去年硬上分域，结果域划分没跟业务对齐，跨域调用比原来还多，今年又回过头调。先定主数据口径这句话应该早点看到。

周敏（集团信息化负责人）：主数据占三分之一时间这个说法很真实。我们集团 6 个法人，物料编码打了一年才统一，前面觉得慢，后面集成速度确实快了不少。数据这块真不能省。

黄海涛（架构师）：网关管对外、总线管对内这个分法简单好用，我准备拿去跟团队讲一遍。之前我们就是边界不清，两边都改，结果排查问题两头跑。

吴佳宁（数据平台负责人）：2:3:5 的预算分配挺有参考价值。我们过去是全砸在采购上，盘点和规范基本没投入，现在回头看确实吃亏了，资产清单到现在都不完整。

徐国栋（零售企业集成组长）：我们两个人管 30 多个系统的接口，看完最大的感受是组织能力这条线以前完全没考虑。架构上去了人没上去，确实是白折腾。