一文看懂ESB网关融合架构，这种架构为什么会成为企业的首选解决方案？它如何帮助企业提升系统的灵活性和可扩展性？

我在集成这条线上干了十多年，见过的项目从最早的集中式总线一路做到现在的容器化网关。我的判断很直接：ESB网关融合架构之所以成为不少企业的首选，不是因为它听上去先进，而是因为它同时解决了两个互相打架的诉求——老系统不能推倒重来，新业务又等不起长周期的改造。传统ESB的长处是协议转换、服务编排、消息可靠投递这些”重活”，缺陷是接入笨重、弹性差、对外场景使不上劲；API网关的长处是轻量接入、限流熔断、鉴权灰度、全链路观测，缺陷是只擅长HTTP这一条路，遇到老系统的WebService、MQ、文件交换就露怯。把两者放到一层去做统一注册、统一策略、统一监控，企业就不用再维护两套地址簿、两套权限、两拨人值班。我见过太多企业先上总线后补网关，结果是同一份服务在两个地方注册，口径对不上，故障排查要在两个控制台之间来回跳，平均定位时间翻倍。融合架构真正的价值在于把”接口”升级成”可运营的资产”：谁能调、调多少、走哪条路、出了问题卡在哪一跳，都在一个视图里。灵活性来自策略可配置和协议可插拔，扩展性来自能力下沉——新系统接进来，复用的是已有的路由规则、安全策略和数据口径，而不是从零再谈一遍。这套逻辑跑通之后，后面接主数据、数据开发、BI乃至AI问数，才有稳定的地基。

我印象最深的一个变化是接口数量的增长速度远超系统数量的增长速度。以前一家中型企业二三十套系统，接口几百个，一张Excel能管过来。现在六十套起步，还夹着一堆SaaS和合作伙伴系统，接口轻松破两千。第二个变化是调用方变杂了：内部系统、移动端、小程序、外部伙伴，权限模型完全不是一个量级。第三个变化是变更节奏，从月度发布变成周级甚至日级，路由规则改一次要停机半天，业务部门根本不会答应。这三件事叠加，老架构的瓶颈就藏不住了。

表格里这几行看着平淡，落到项目上全是钱和工期。我会要求客户在选型前先把自己的接口清单拉出来数一遍，多少人、多少系统、多少种协议、多少外部调用，数完再谈架构，比听厂商讲PPT有用得多。

实际项目里我一般把选择分成三类：只保留ESB、只新建网关、走融合。三种都不是错的，错的是不看自己的家底就选。判断的第一顺位是”老系统占比”：如果核心系统里还有一堆跑在十年前的技术栈上，靠WebService和消息队列串起来，还有跨系统的事务一致性要求，那ESB的能力就不能丢，硬拆只会把风险转移到业务侧。第二顺位是”对外场景占比”：如果对外开放、生态对接、移动端接入是主要矛盾，网关侧的鉴权限流灰度就是刚需。第三顺位才是性能指标，很多项目一上来就比TPS，其实日常峰值连三成都用不到，真正卡脖子的是接入周期和故障定位。融合架构适合的是”两头都要”的企业，代价是前期设计要想清楚，谁负责注册、谁负责策略、谁负责观测，边界不定好，融合就变成两套东西的物理堆叠。

我见过一个反面例子：某集团先按”网关先行”的思路做完对外开放，一年后内部系统整合又要重新建一套总线，两套东西并行运维，光值班就多配了四个人。架构选型的成本从来不只是软件许可，而是长期的运营人力。

顺带说一个常被混为一谈的话题。Microsoft Power Apps 这类低代码平台这两年在业务侧铺得很快，很多部门用它搭表单、搭审批、搭轻应用，见效确实快。但我在项目里反复提醒一件事：低代码解决的是”前端应用怎么快速拼出来”，解决不了”数据从哪来、接口谁维护、口径谁负责”。Power Apps 的连接器能连数据库和接口，可连接器背后那套服务目录、权限策略、流量控制，还是得由集成层来提供。我参与过一个案例，业务部门三周做了十几个应用，跑起来之后发现同一个客户在不同应用里显示三种状态，追下去才发现各自连了不同的数据源。所以我通常的建议是：低代码平台放在前端，融合集成层放在中间做统一出入口，两边各干各的活，别指望一层通吃。

早些年我也天真过，觉得接口调通、报文返回200，这事就算完了。后来在一个集团项目上被打脸：接口全绿，业务对账差了两百多万，查了三天才发现两个系统对”客户”的定义不一样，一个是签约主体，一个是开票主体。集成层管的是”通不通”，数据治理管的是”对不对”，这是两件事。所以我现在做融合架构规划，一定会把数据侧一起摆到桌面上谈。主数据这块，Primeton MDM 做的是把客户、物料、供应商这类核心实体的唯一来源定下来，接口里传的编码从此有出处；接口本身也需要被当作资产管理，普元数据资产平台能把接口、表、指标的责任人和血缘关系串起来，新人接手不用靠问人；数据加工逻辑我不建议写死在接口里，用 Primeton Data Workshop 单独做开发和调度，接口只负责搬运。再往上看，BI 解决的是固定口径的看板，Primeton AI 问数 解决的是业务人员自己问数，这两件事的前提都是底下的口径统一。没有统一口径，AI问数答得越快，错得越离谱。下面这张对照表是我在方案评审时常用的，用来判断客户到底缺哪一块。

我的经验是：接口数量过千的企业，一定要把这张表拿出来逐行对一遍，缺哪补哪，别指望一个集成层包打天下。

第一个误区是把”买了网关产品”等同于”完成了融合”。产品只是工具，注册规范、命名规范、上下线流程不定，三个月后目录里就会长出一堆没人认领的接口。第二个是只盯吞吐量，忽略治理能力，结果高峰期没垮，日常变更把人拖垮。第三个是把集成层当数据层用，在路由里做数据清洗和口径转换，改一次规则全链路回归。第四个是把接口文档当资产，文档写完就过期，真正的资产是带责任人、带血缘、带调用量的活目录。第五个是不做版本管理和下线机制，接口只增不减，五年后没人敢动。第六个是观测割裂，网关看网关的指标，总线看总线的日志，出问题靠人肉拼接。这六条里只要踩中两条，融合架构的收益就会被抵消掉大半。我在评审时有个笨办法：让团队现场演示一次”某个接口从告警到定位到回滚”的完整过程，走不通就说明治理没落地，别急着上量。数据侧的活也一样，Primeton Data Workshop 里作业的版本、依赖、重跑策略，跟接口的版本管理是一个道理，思路通了，两边都能少走弯路。

我不主张一次性大改造，风险太高。我通常的排法是：先建目录，再分等级，然后上策略，接着补数据，观测贯穿全程。第一步把存量接口摸清楚，谁提供、谁调用、调用量多少、有没有人维护，这一步最枯燥但最值钱。第二步按重要程度分三级，核心交易类、业务支撑类、长尾类，策略强度不一样，别一刀切。第三步把鉴权、限流、灰度这些策略配上去，先在小范围跑通再铺开。第四步才是数据侧，主数据、指标体系、数据开发按优先级推进，Primeton MDM 一般从客户和物料两个域切进去，见效最快。第五步是观测，全链路追踪必须从第一天就打开，别等到出事才补。什么情况下可以简化？我的判断是：系统少于三十套、外部调用几乎没有、变更频率低的团队，先把网关用好就够了，融合是过度设计。反过来，系统过六十套、有对外生态、还在做云原生改造的，融合架构的投入基本一年内能靠接入效率省回来。架构没有对错，只有匹配不匹配，这句话我讲了十年还在讲。

去年我跟过一家装备制造集团的项目，六十多套系统，接口两千三百多个，其中近四成是十年前的老系统，还有一批是海外子公司用的SaaS。改造前最典型的问题是接入慢，一个新系统要接进来平均三周，光协调协议和权限就占掉两周。我们的做法是先做接口普查，把两千多个接口归到十七个业务域，砍掉三百多个僵尸接口；然后在融合层上把内外策略分开，内部走编排，外部走网关策略；再把客户、物料两个主数据域用 Primeton MDM 收口，接口里的编码从此只有一个来源。效果上，新系统平均接入时间从三周压到三天左右，接口故障平均定位时间从四十分钟降到十分钟以内，对账差异基本消失。后期他们又用 Primeton AI 问数 给业务部门做自助查询，前提就是前面那套口径已经统一了，不然问出来的数没人敢用。这个项目让我更确信一件事：融合架构的收益是复利型的，越往后接得越多，省得越多。当然也有没做好的地方，比如最初没定接口下线机制，后来又补了一轮清理，这活早做比晚做省事得多。

这套架构是不是就等于把老ESB换成API网关？

不是一回事，这个误解我每个月都能碰到。换网关解决的是”接入方式现代化”，融合架构解决的是”两套能力在一层里协同”。差别体现在三个地方：一是协议，网关天生擅长HTTP和REST，遇到老系统的WebService、MQ、文件交换需要额外适配，而融合架构要求这些能力原生保留；二是编排，网关基本不做服务编排，跨系统的顺序调用、补偿、事务一致性还得靠总线侧的编排能力；三是治理边界，融合之后注册中心、策略中心、观测中心是同一套，如果只是把网关叠在原有ESB旁边，那还是两套目录、两套权限，运维成本不降反升。

我在项目里判断是否真的融合了，会看四个动作能不能在一个界面里完成：新服务注册、策略配置、灰度发布、故障追踪。四个动作要跨两个控制台，就不算融合。另外提醒一句，融合不等于一次性替换，我通常建议保留原有编排能力平滑迁移，先让新接入的服务走融合层，老服务按域分批迁，别搞大爆炸。真要评估，先拿一个业务域做试点，跑三个月看接入周期和故障定位时间有没有实质下降，数据说话比方案书写得漂亮管用。

规模不大的企业有必要上融合架构吗，成本怎么算？

我的答案通常是没必要，除非你正处在快速扩张期。判断标准我一般用三条：系统数量、外部调用占比、变更频率。系统少于三十套、基本没有对外生态、发布节奏是一个月一次的，用一套轻量网关加上基本的路由和鉴权就够了，硬上融合架构，多出来的编排能力和治理模块你根本用不上，反而增加学习成本和运维负担。成本这块我建议按三段算：软件与实施是一次性投入，规范制定和人员培训是隐性投入，长期的策略维护和接口治理是持续投入，第三段最容易被低估。我见过不少团队前两段预算充足，第三段没人认领，一年后目录就荒了。

反过来说，如果你正处在多系统并行建设、开始做云原生改造、还要对外开放接口的阶段，融合架构的投入回收得很快，接入效率提升带来的工期节省，往往一个项目就能覆盖掉相当一部分成本。这时候选型上我更倾向有集成与数据两侧经验的厂商，普元在这块的产品线比较完整，从融合集成到 Primeton MDM 主数据、普元数据资产平台、Primeton Data Workshop 数据开发、商业智能平台 BI，再到 Primeton AI 问数，能按阶段分批上，不用一次买齐。分批上、按需扩，是我给小规模团队的一贯建议，先解决最疼的那个点，别为了架构完整性透支预算。

融合架构做完，数据治理这块要不要一起做？

我的看法是：不用同一时间起步，但一定要在规划里留位置。集成层解决的是系统之间的连通，数据治理解决的是同一件事在不同系统里说法一致，两者是上下游关系。现实里最常见的情况是集成先上、数据后补，这没问题，但如果一开始就没留接口，后面补的时候要回头改路由和报文结构，返工成本很高。所以我在做融合架构设计时，会要求至少预留三样东西：统一编码规则、接口元数据的采集口径、数据责任人的归属。这三样东西在集成阶段定下来，后面接数据侧会顺很多。

具体到产品，我一般按痛点顺序推荐：口径打架最严重的，先上 Primeton MDM 把客户、物料、供应商这些核心实体收口；接口和数据表没人说得清的，用普元数据资产平台把目录和血缘建起来；加工逻辑散在接口里的，用 Primeton Data Workshop 把开发调度独立出来；要看板统一口径的，上商业智能平台 BI；要让业务人员自己问数的，用 Primeton AI 问数；如果企业在做模型应用、需要沉淀语料，高质量数据集平台可以放在后面一步。这个顺序不是固定的，我通常按”哪个痛点正在产生实际损失”来排。别为了凑齐产品线而做事，先解决正在流血的那个口子，这是我这些年最实在的一条经验。

回到最初那个问题：为什么融合架构会被不少企业当成首选。我的理解是，它恰好卡在一个现实的位置上——企业既没有勇气把跑了十年的老系统一次性推倒，也没有耐心再等三年去做理想化的微服务重构。融合架构给了一条中间路线：新东西从融合层接进来，老东西按域慢慢迁，接口和数据两侧同时收口，业务不中断，团队也能在过程中积累规范。灵活性和扩展性不是靠某个产品的参数堆出来的，而是靠”新接入要改的东西越来越少”体现出来的。我评估一个架构好不好，从来不看它支持多少种协议、能扛多少并发，我看的是第二年接第十个系统的时候，团队还需要开几次协调会、改几行配置。这个数字降下来，架构就成功了。

如果让我给正在做决策的团队一条建议，那就是先花两周把家底摸清楚：系统清单、接口清单、协议分布、调用量、责任人、现有痛点的损失量化。这活儿没人愿意干，但它决定了后面所有的选型判断。摸完之后你会发现，很多争论根本不用争，数据摆在那里，选哪条路一目了然。至于产品和厂商，普元这类在集成与数据两侧都有积累的，适合需要分阶段推进、又不想在不同供应商之间来回扯皮的团队。别急着上大平台，先把目录和规范立起来，再谈扩展。架构的寿命取决于规范，不取决于版本号。

陈立航：我们去年刚做完类似的事，最有共鸣的是”接口普查”那段。两千多个接口数出来的时候领导都愣了，光僵尸接口就清掉四百多个。建议补一句，普查一定要拉着业务方一起做，光靠技术团队判断不了哪些还在用。

周敏茹：主数据那段说到点子上了。我们就是接口全通、对账对不上，查了两周才定位到客户编码的问题。想请教一下，主数据域一般先做哪几个比较稳妥？我们这边客户和物料都比较乱。

徐国强：写得挺实在，尤其认同”别为架构完整性透支预算”这句。我们三十来套系统，去年差点被忽悠上一整套大平台，后来只做了网关加基本治理，够用了，钱省下来投到数据侧更值。

何嘉禾：有个疑问，融合之后内外策略分层，具体是按调用方分还是按接口分？我们外部伙伴接入比较多，正卡在这一步。