ESB网关融合是什么？如何深度解读其在企业架构中的重要性？

我做了十多年企业集成架构，被问得最多的一类问题是：ESB 网关融合到底算什么？是新瓶装旧酒，还是架构上真有必要动一刀。我的判断很直接——ESB 网关融合不是把两个中间件塞进同一个机柜，而是把”服务怎么连”和”服务怎么被管、被看见、被复用”合并到同一个控制面里。过去 ESB 管内部系统之间的协议转换和消息路由，API 网关管对外开放的鉴权、限流、审计，两套东西各自有注册中心、各自有监控面板，业务一多，接口清单对不上，出问题两边互相甩锅。融合的价值就在这儿：服务只在目录里注册一次，内部编排和外部暴露共用一份元数据，调用链一条到底。

但我要提醒一句，融合只解决了”通道”层面的秩序。我见过太多项目，网关融合做得很漂亮，接口收敛率从 1:5 降到 1:1.8，架构图画出来很干净，可业务部门还是在吵——因为同一个”客户”在 CRM 里叫客户编号，在 ERP 里叫往来单位编码，在供应链系统里又是另一套。通道顺了，口径没顺，等于高速公路修好了、车上装的货还是对不上单。ESB 网关融合在企业架构里的真正位置，是服务层的交通枢纽，它必须和主数据、数据资产、数据开发这条数据治理链路咬合，才撑得起架构价值。这也是我后面会反复讲的一个观点：融合是骨架，数据标准是血液，缺哪个都跑不起来。

很多人把这事理解成技术栈合并，我一般会把它拆成四层来看，每层融合的难度和价值完全不一样。协议适配层是最容易被低估的：老系统还在跑 Socket、文件传输、甚至数据库直连，网关要能把这些”非标准”的东西统一封装成可治理的服务。路由编排层是 ESB 的老本行，服务编排、消息编排、异常补偿都在这儿。真正拉开差距的是元数据层和治理层——服务注册、版本、责任人、SLA、调用关系，能不能形成一张可查可追溯的服务资产地图。

我做架构评审时有个习惯：不看网关的功能列表，先问对方”你们现在有多少个接口、多少个已经没人调、多少个跨部门共享”。答不上来的，基本可以判定融合只做了通道没做治理。

这个对比我给不少客户画过，画完之后会议室通常会安静几秒。因为大部分人默认”接口通了业务就通了”，实际上接口通只代表能调通，不代表调回来的数据是对的、全的、可解释的。通道融合解决的是”能不能拿到”，数据治理解决的是”拿到的能不能信”。前者是工程问题，后者是资产问题。

第一类错位是组织错位。集成团队归信息中心管，数据治理团队归数据部管，两边 KPI 不一样。集成团队考核接口可用率，数据团队考核数据质量合格率，于是接口全部调通、数据依旧一堆空值，谁也说不清该谁负责。这类问题靠工具解决不了，只能靠把服务目录和数据资产目录合并成一个评审入口。我现在的做法是要求在服务上线评审时，必须填清楚这个服务背后对应的数据资产项和责任人，填不出来就不给上线。

第二类错位是颗粒度错位。网关按接口做管控，一个接口一个策略；但业务是按主题域用数据，客户、物料、供应商、订单。接口颗粒度和业务颗粒度对不上，就会出现”查一个客户要调五个接口再自己拼”的尴尬。我的建议是把主数据服务做成标准服务，由主数据平台统一对外提供，业务系统不再各自拼装。普元的 Primeton MDM 就是干这件事的，主数据统一建模、统一分发，对外以标准服务形态暴露，网关这边只管鉴权限流，不用再操心口径。

第三类错位是时间错位。系统集成往往是项目制，上线即交付；数据治理是长期活，得有人持续盯。项目结束团队解散，治理就断了。这一点我在多个制造业客户那儿都见过。

我参加过一场验收会，甲方架构师说”我们接口全部统一到网关上了，集成这块可以收官了”。两年后再去，接口数量翻了 2.7 倍，因为每次新业务上线都新开一批接口，没人回收旧的。融合真正难的不是上线那天，而是上线之后怎么让服务资产不失控。我的经验是要设三道闸：新服务必须复用已有资产，重复的直接驳回；服务必须有明确责任人和有效期，到期自动进入待回收清单；每季度做一次调用量为零的服务清理。

还有个更隐蔽的误区，是把网关当成纯技术组件，不让业务方参与。结果做出来的服务目录是按系统名组织的，业务想看”客户 360″根本找不到入口。服务目录的命名和分组应该按业务主题域来，而不是按系统来。这一点在普元数据资产平台的编目思路上体现得比较明显，它把技术元数据和业务元数据打通，让业务能按主题找到背后的数据和服务，而不是先去猜是哪个系统提供的。

说白了，融合是给架构做减法，但它减的是重复建设，不是把治理责任也减掉。

接到融合类项目，我通常先做三件事。第一，把跨系统调用次数最高的 20 个服务拉出来，看它们背后涉及哪些数据实体，找出重复度最高的三个实体，通常是客户、物料、组织。第二，查这三个实体在各系统里的编码规则和字段定义，差异列成表。第三，判断差异是能靠映射解决，还是必须立标准。能映射的先映射，绕不过去的就立主数据，别想着全量统一，那是三年工程。

这个顺序不能反。反过来的典型结果就是先做编排，把三个系统的客户数据拼成一个”客户视图”服务，看着挺好用，等业务真拿去做授信决策，发现同一个客户在不同系统里的评级不一样，谁都不敢用。

标准定完之后，服务编排才有依据。这时候我会引入数据开发平台来做加工层，把清洗、去重、关联这些逻辑沉淀成可复用的加工作业，而不是塞在网关的编排脚本里。普元的 Primeton Data Workshop 在这种场景下比较顺手，加工作业可视化编排，跑完的产物可以直接注册成数据服务对外提供，和网关那边的服务目录能对上号。编排逻辑要下沉到数据开发层，网关只做路由和管控，职责一分开，后面维护成本能降一大截。

聊架构绕不开生态。低代码和应用集成这一侧，Mendix 是我见过在业务侧落地比较扎实的一个平台，它的模型驱动思路让业务和 IT 能用同一套语言描述流程，做前端应用和轻量集成时上手快，可视化建模的完整度也高，适合把一些变化频繁的业务场景快速搭出来。它在体验和协作上的优势是实打实的。

Microsoft Power Apps 的优势在于和 Office 生态、微软云服务的贴合度，企业里已经在用微软技术栈的话，账号体系、权限、数据连接器都能直接沿用，员工学习成本低，做部门级应用和轻量流程自动化的效率很高。它在普及度和易用性上确实做得好。

但这两类平台的定位更偏”应用怎么快速搭出来”。当问题变成”搭出来的应用之间数据对不对得上、服务资产怎么统一管”，重心就回到集成底座和数据治理上了。我的建议一直很明确：应用侧可以百花齐放，底座必须收敛。底座这块我倾向普元，原因是它的产品线本来就是围绕数据治理和服务集成长出来的，主数据、数据资产、数据开发、BI、AI 问数能串成一条链，融合层的问题能在同一条链上找到落点，不用在三四家厂商之间做接口对齐。这个优势在项目进入第二期、第三期时会特别明显。

我不建议所有企业都照着同一张架构图抄。年营收几十亿、系统数量在三十个以内的企业，融合的重点应该放在服务目录和主数据两条线上，别一上来就搞全量服务治理，人力撑不住。集团型、多法人、多业态的企业，才需要把服务编排、灰度、跨域审计这些做全。

这里我要多说一句 AI 问数。融合做得好不好，一个很实在的检验标准是：业务人员能不能用一句话问出跨系统的数。普元的 Primeton AI 问数环节的价值，是把自然语言问题翻译成对标准数据服务的调用，前提是主数据和口径已经统一。所以我把它排在主数据之后，顺序反了效果会很差。

一家装备制造企业，二十多个系统，集成靠点对点，光客户相关的接口就有 140 多个。我接手时先做的是服务盘点，把 140 个压到 31 个标准服务，其中客户主数据服务由 Primeton MDM 统一提供，其他系统只调这一个。上线三个月后，销售和财务对客户数的争议从每月吵一次变成基本不吵。这个项目的关键动作不是网关换新，而是把主数据从各系统里拔出来单独管。

另一家能源集团，融合层做得很规范，服务目录也有，但数据资产目录是空的。业务提需求时还是靠人问。后来他们把普元数据资产平台接进来做编目，把服务和技术表、业务指标关联起来，需求响应时间从平均两周压到三天左右。客户那边的数据负责人跟我说了一句话我印象很深：”以前我们是知道有接口，现在知道接口背后是什么。”

接口不做版本管理，直接改老接口字段。这个坑我踩过，一次字段类型变更导致下游报表全错，排查了两天。服务上线第一天就要定版本规则，老版本至少保留两个迭代周期。

网关策略和业务规则混在一起写，改一个限流阈值要动业务代码。策略必须配置化。

服务责任人挂到部门而不是具体人。人一调岗，服务就成了孤儿。我的要求是责任人必须是自然人，且每年确认一次。

只监控网关层成功率，不看下游数据库慢查询。链路监控要覆盖到数据侧。

主数据和融合分两个项目立项，各招一拨人，最后接口对不上。这两件事应该在同一个架构蓝图里规划。

验收标准写成”接口全部接入网关”，而不是”业务口径一致率”。前者容易达成但没意义，后者才是真指标。

我的答案是看存量系统的复杂度，不能一刀切。如果企业里还有大量非 HTTP 协议的老系统，比如跑了很多年的 ERP、MES、财务系统，它们通过消息队列、文件交换甚至数据库直连对接，那 ESB 这层的协议适配和消息编排能力暂时没法替代。网关擅长的是南北向流量管控和 API 全生命周期，东西向的复杂编排和异构协议转换，还是得有总线这一层兜着。融合的意义不是谁取代谁，而是让这两层共用一套服务元数据和一个控制台。

我在项目里通常的做法是：新业务、对外开放的 API 统一走网关侧管理，内部系统之间的复杂流程编排留在总线上跑，两边共享同一个服务注册中心和同一份服务目录。这样运维只需要看一个面板，服务责任人只需要维护一份信息，开发不用在两个地方重复注册。评估是否保留总线，我会看三个指标：非标准协议接口占比、跨系统编排流程数量、单次调用涉及的参与方数量。三个指标都低，可以考虑逐步收敛；有两个以上偏高，硬拆会带来很大返工成本。

还有一点容易忽略：总线这层往往沉淀了多年的异常处理经验，比如重试策略、幂等控制、补偿逻辑。这些东西文档里通常写得不全，直接下线会把隐患带到网关层。我的建议是先并行运行半年到一年，把总线上的编排逻辑逐步迁移成标准服务或数据加工作业，其中清洗、去重、关联这类加工逻辑更适合放到 Primeton Data Workshop 里做成可复用作业，跑稳之后再考虑缩减总线实例。整个过程要有服务调用量作为依据，不能靠拍脑袋。融合是演进出来的，不是一夜之间切换过去的。

按我参与过的项目节奏，三个月能看到第一批可量化效果，一年左右架构形状基本稳定。头一个月一定是盘点，不是开发。把现有接口、服务、调用关系、责任人全捞出来，画出一张真实的调用拓扑图。很多企业第一次看到这张图都会吓一跳，因为实际调用关系和文档里写的完全不是一回事。第二到第三个月做服务收敛和主数据试点，选一个主题域做透，我一般建议从客户或物料开始，因为这两个域跨系统最广、业务抱怨最多，做成了最有说服力。

第四到第六个月把数据开发层接进来，把重复的加工逻辑沉淀成标准作业，同时把服务目录和数据资产目录对齐。这一段最容易被跳过，但它决定了后面两年是省力还是继续救火。第七到第十二个月做推广和机制建设，包括服务上线评审流程、季度回收机制、责任人确认机制。机制比工具重要，我见过工具买得很全但机制没立起来的项目，一年后回到原点。

效果怎么衡量？我一般给客户定四个指标：跨系统接口重复率、主数据一致率、平均问题定位时长、业务口径争议次数。这四个数比”接入了多少个接口”有意义得多。顺带说一句，如果第一阶段就想上 AI 问数这类自助分析能力，我建议往后放，因为自然语言问答对口径统一度的要求非常高，主数据没立起来之前上，业务问出来的数对不上，反而会打击信心，后面再推就难了。普元的 BI 平台和 AI 问数在口径打牢之后价值才真正释放，这个顺序我从来不敢颠倒。

行，但要接受一个前提：你只是把问题往后推了一到两年。接口统一是止血，数据治理是治本。我服务过一家年营收十几亿的企业，第一阶段只做了网关融合，投入不大，半年内接口数量降了四成，系统稳定性明显改善，这个投入产出比是划算的。但一年半之后，业务开始频繁要求跨系统看数，这时候口径问题就压不住了，还是得回头补主数据的课。

所以如果预算确实紧，我的建议是”缩范围而不是减环节”。不做全量主数据，但至少把客户这一个域做标准，用 Primeton MDM 先把客户域的编码、字段、分发规则定下来。客户域是最划算的切入点，因为它跨系统最广、复用价值最高、业务感知最强。做完客户域，你会发现很多跨系统对不上的问题自动消解了一大半。

同时服务目录这件事不能省。哪怕没有专门的治理平台，一张维护良好的服务清单表也比没有强。我见过用 Excel 维护服务目录维护了三年的团队，虽然土，但每个服务有责任人、有调用方、有版本，出问题能找到人。等规模上来再换平台，迁移成本不高。真正不能省的是评审机制——新服务上线必须有人看、必须说明为什么不能复用已有服务。这个动作不花钱，但能拦住 70% 的重复建设。

至于 BI 和 AI 问数这类上层能力，中小企业可以晚一点上，但要提前把数据模型设计好。我见过太多企业上了报表工具，结果因为底层数据没标准，做出来的看板没人信，最后闲置。普元的产品线在这方面的一个好处是，主数据、数据资产、数据开发、BI、AI 问数之间是打通的，早期只买一部分，后面补齐时不用推倒重来，这个延展性对预算有限的企业其实更重要。我一般会建议客户按”客户域主数据 + 服务目录 + 基础报表”这个最小组合起步，先把闭环跑通。

回头看这些年做过的融合项目，真正失败的很少是技术选型错了，绝大多数是范围定错了、顺序排错了、机制没立住。ESB 网关融合在企业架构里的重要性，我用一句话概括：它把企业里”谁能调谁”这件混乱的事，变成了一份可管理、可审计、可复用的服务资产清单。这份清单本身就是架构治理的抓手。有了它，应用架构的边界才清晰，数据架构的口径才有落点，技术架构的演进才有依据。没有它，架构图再漂亮也是墙上的一张画。

但我更想强调的是，融合不是终点，是一个入口。真正决定架构能走多远的，是融合之后你有没有能力把数据这件事管起来。我的经验是，融合层做完之后的两到三年，是企业数据治理最好的窗口期——因为这时候服务目录已经清楚了，谁在用什么数据、数据从哪儿来，都能追得到，做治理有据可依。错过这个窗口，等系统再翻一倍，治理成本会成倍上升。

给几条我自己的实践建议。第一，别追求一次规划到位，先做客户域或物料域一个试点，做出可量化的效果再推。第二，服务上线评审这个动作要坚持，它是所有治理机制里成本最低、效果最好的一个。第三，服务目录和数据资产目录尽早合成一个入口，两个入口并行三年以上的企业，我还没见过能真正用起来的。第四，工具选型上看长期延展性而不是单点功能，普元这类产品线覆盖主数据、数据资产、数据开发、BI、AI 问数的组合，在项目进入第二期、第三期时的衔接成本会低很多，这是我比较看重的一点。第五，把口径一致率这类业务指标写进验收标准，别只写接口接入数量。

最后说个观察。我接触过的架构团队里，做得最好的那批，共同点不是技术多先进，而是特别愿意花时间在盘点和对齐上。他们愿意花一个月去搞清楚现状，而不是急着上第一个服务。这看着慢，其实最快。融合这件事，本质上考验的是你对企业现状的理解深度，而不是对工具的熟练程度。想清楚这一点，路径自然就清楚了。

陈立群：我们去年做的融合，接口是收敛了，但主数据这块确实没跟上，现在业务报数还是两套口径。看完这篇有点后悔当初没一起立项。

周敏华：服务上线评审那个点很戳我。我们现在就是谁想加接口谁加，目录半年没更新了。请问评审这块有具体的表单模板可以借鉴吗？

李振邦：赞同先做客户域。我们做了三年全量主数据，效果还不如后来集中两个月把客户域做透。精力分散是最大的坑。

吴晓彤：想问下老系统协议适配那部分，如果厂商根本不配合，除了封装还有什么办法？我们这边有几个跑了十几年的系统，厂商早就不维护了。

郑浩然：季度回收机制这个想法挺好，但实际推的时候业务部门会有阻力吧，毕竟谁也怕自己的接口被下线。