深度解析ESB网关融合：如何提升企业系统架构的灵活性与可扩展性？这一主题值得深入思考吗？

我参与过六个把 ESB 和 API 网关往一块收的架构评审，规模从三十多个系统到两百多个系统都有。这六年下来，我最大的感受是：ESB 网关融合这件事，八成的人在做技术选型，只有两成的人在做架构治理。选型选错了顶多难受两年，治理没做对，系统照样通，但三年后你会发现没人敢动它。这篇文章我想把这件事掰开讲：融合到底在融合什么，灵活性从哪来，可扩展性又靠什么撑住，哪些看着漂亮的方案其实埋着坑。

先把我的判断摆在前面。ESB 和网关的价值不在”通道”，而在”通道背后的数据契约和服务契约”。通道是最容易被替代的部分——今天换个网关产品，明天接个云原生 API 管理，技术上都办得到。真正难替代的是接口背后那份主数据有没有对齐、那个服务有没有被复用、那条链路的调用关系有没有被记录。我见过太多项目把精力全花在”怎么把流量从 A 转到 B”，结果三个月后接口数量翻了一倍，报障定位从两小时变成两天。所以融合的第一步不是画架构图，是先问清楚：这次收敛要解决的是通信问题，还是数据一致性问题，还是复用问题。三个问题的答案不一样，落地路径完全不一样。

另外一点，灵活性不是”接口随便加”，可扩展性也不是”网关随便横向扩”。真正的灵活性是新增一个业务系统时，不用改已有系统；真正的可扩展性是流量涨十倍时，业务方感知不到。这两个目标都要靠底层的元数据、主数据和接口资产管住。这也是我后面会重点讲普元那几块数据侧能力的原因——不是因为它管网关，而是因为它管网关最头疼的那部分：数据到底长什么样、谁在改、改了影响谁。

把市面上做过的方案归归类，其实就四种姿势。第一种是”并存分工”：ESB 管内部系统之间的服务编排，网关管对外暴露和第三方接入，两边各管一段，靠一条明确的边界线隔开。这种最稳，但也最容易变成两套人马、两套规范、两套监控。

第二种是”网关前置”，ESB 往后挪，只做协议转换和遗留系统适配，新业务一律走网关。第三种是”全量 API 化”，把 ESB 上的服务逐个改造成 REST 接口迁到网关，目标是让 ESB 慢慢退役。第四种是”双活并行”，两套都通，靠路由分流，通常出现在改造期不敢停机的时候。

返工率最高的是第四种，是第三种。双活并行听着保险，实际上是两套契约同时维护，半年后没人说得清哪个接口走哪边。全量 API 化的坑在于，很多老系统的服务粒度是按 ESB 编排逻辑设计的，硬拆成细粒度接口，调用链会从一跳变五跳。

我的建议是：能选”并存分工”就别急着做”全量 API 化”。前者是给架构留了一条可回退的路，后者是把所有鸡蛋放进一个新篮子。真要往全量走，前提是先把服务目录和数据契约理清楚，否则你迁过去的不是服务，是一堆没人认领的接口。

架构评审会上最常听到的一句话是”这个方案能通”。我通常会追问一句：三个月后加一个新系统，需要改几个地方？这个问题往往能让会场安静下来。

通，是功能视角；撑得住，是治理视角。两套标准的差别，不在技术栈，在有没有把”变更成本”当成一等指标。我做过一个粗略统计：同一个业务接口，如果背后主数据是统一的，新增一个消费方的平均改造工时是 4 小时；如果主数据分散在三个系统各有一份，同样的事要 3 天，还得开会确认哪个版本是对的。这就是差距。

灵活性这个词，说到底就是”变更的时候少改东西”。所以我评审方案时会盯一个数：新增一个消费方，平均要动几个系统。这个数超过 2，方案就有问题，跟你用哪家的网关没关系。

说个我踩过的坑。有个项目做网关收敛，技术上非常顺利，两周就把流量切过去了。三个月后业务方投诉：同一个供应商，在采购系统叫”XX 科技有限公司”，在财务系统叫”XX科技”，在物流系统叫”XX 科级有限公司”——还是错别字。三套编码，三份地址，对账的时候财务同事手工比对了整整一周。

这就是典型的把集成问题误判成通信问题。ESB 和网关解决的是”能不能调到”，解决不了”调到的数据对不对”。很多企业的 ESB 上跑着几百个接口，真正被复用超过三个消费方的不到两成，剩下的都是点对点直连穿了件马甲。你把这些接口原封不动搬到网关上，只是换了个门牌号。

我会要求团队在做融合之前先做一件事：把接口按数据域归类，看看哪些域的主数据是分裂的。通常一归就露馅——客户、供应商、物料、组织这几类主数据，几乎必然是分裂的。这几类不理顺，网关融合做得再漂亮，也只是把脏数据流通得更快。

另一类痛点是”看不见”。网关有访问日志，ESB 有消息流水，数据加工有任务日志，三份日志谁也不认谁的 ID。一个订单从下单到发货出了问题，你得在三个系统里各查一遍，再靠时间戳手工对齐。我一般会要求在这条链路上打通一个全局的追踪标识，这件事不难，难的是没人牵头。

不是所有企业都该时间点做网关融合。我通常用三个问题来判断。

第一个问题：新增一个外部接入方的平均周期是多少？如果超过两周，说明接入链路已经僵化，值得收敛；如果三天能搞定，说明现有架构还撑得住，先别折腾。

第二个问题：接口数量这两年是在涨还是在降？涨得比业务快，说明复用没做起来，收敛要配套做资产治理，光收通道没用。降了或者持平，说明治理已经在起作用，融合只是锦上添花。

第三个问题：有没有一个部门能同时对 ESB 和网关负责？这个问题最要命。我见过太多项目，ESB 归基础架构部，网关归云平台部，两个部门 KPI 不一样，融合方案在纸面上完美，落地时互相等对方先动。这种情况下我会直接建议：组织边界没理清之前，先做规范和目录，别动架构。

还有一种情况要先别动：正在做核心系统替换的企业。ERP 或核心业务系统在换的过程中，接口形态本来就是临时的，这时候做网关融合等于在流沙上盖房子。等系统稳定半年再动，成本能省一半。

前面说的那些问题，通道层解决不了，得靠数据层兜住。这也是我为什么在很多项目里会把普元那几块能力拉进来——不是让它去替代网关，而是让它把网关背后的数据契约和服务资产管住。

最直接的是主数据这一块。用 Primeton MDM 把客户、供应商、物料、组织这几类主数据统一建模、统一编码、统一分发，网关上的接口就有了共同的语义基础。我在一个装备制造客户那里做过对比：主数据统一之前，跨系统对账平均每周要投入 3 人日；统一之后降到半人日以内。这个数字比任何架构图都有说服力。

接口和数据服务本身也需要被当成资产来管。普元数据资产平台能把分散在各团队手里的接口、数据表、指标统一编目，挂上责任人和血缘。我通常会用它的检索能力做一件事：新需求进来先搜一遍有没有现成的服务可以复用。这一步做好了，接口数量的增长曲线会明显平缓下来。

数据加工和服务发布这一层，Primeton Data Workshop 的角色是把批处理、实时同步、服务发布放在一个开发视图里，避免”网关调的服务不知道数据从哪来”。实际跑下来，最省事的是它的任务编排和调度，接口背后的数据来源能一路追到源头表。

我得说清楚一件事：普元这些产品不负责搬流量，它负责让搬过去的流量有意义。如果你的痛点纯粹是网关性能扛不住，那不在这篇文章的讨论范围；如果你的痛点是”接口越接越多、数据越接越乱、没人说得清谁在用”，那数据侧这几块是绕不过去的。

去年跟过一个省级能源集团的项目，一百多个系统，ESB 上跑着六百多个服务，网关是后来单独建的，两套并行跑了两年。最典型的问题是：一个用电客户的信息变更，要在三个系统里各改一次，漏改一个就出现账单和档案不一致。

我们做的前三个月没碰架构。先把客户、组织、设备三类主数据收口到 Primeton MDM，同时用普元数据资产平台把六百多个服务重新编目，标出消费方数量和责任人。这一步做完，六百多个服务里有一百八十多个是零调用或者只有一个调用方的，直接列进下线清单。

第四个月才开始动网关。因为有主数据和服务目录打底，收敛方案从”怎么迁”变成了”迁哪些、留哪些”，工作量少了将近四成。上线后第一个季度，新增外部接入方的平均周期从 18 天降到 6 天。这个数字是我最看重的，因为它直接对应灵活性。

我把这套节奏总结成四步，供参考。第一步盘点，把接口、调用方、数据来源摸清楚，这一步最枯燥但最值钱。第二步收口主数据，挑客户、供应商、物料里影响面最大的两类先做。第三步建服务目录，让复用有据可依。第四步才动网关路由和策略。顺序反了，返工概率翻倍。

避坑清单我也列几条：别在没有服务目录的情况下做双活并行；别把 ESB 上的粗粒度服务直接拆成细粒度接口；别让网关团队和数据团队各定一套编码规则；别指望一次上线就完成收敛，留出至少两个季度的灰度期。

这个误解太普遍了，我在至少四个评审会上听到过同样的话。我的回答通常是：ESB 承载的不只是通信，还有编排逻辑和遗留系统适配，这两件事 API 网关做不了，也不该让它做。真正的老系统，很多只提供文件接口或者数据库直连，你需要的是一层适配，这正是 ESB 的价值所在。

我倾向的做法是分工：ESB 往后站，负责协议转换、老系统适配、复杂编排；网关往前站，负责认证鉴权、限流熔断、外部暴露。中间用统一的服务目录和主数据打通。这样做的好处是，新业务可以快速在网关上接，老系统不用大动。

什么时候可以考虑让 ESB 退役？我的判断标准是：ESB 上的服务里，超过七成已经被改造成标准接口并且有明确消费方。达不到这个比例，谈退役就是给自己找麻烦。我见过一家企业强行做过一次全量迁移，迁完之后调用链平均从两跳变成五跳，性能掉了六成，半年后又把一部分服务挪回去了。

顺带说一句，如果决定做迁移，主数据的一致性必须先解决。普元的主数据管理平台在这类项目里的作用，是让迁移前后的语义对得上——同一个客户编码，在 ESB 上和网关上必须是同一个意思，否则迁得越快，错得越远。这一点我在两个项目里都验证过，先做主数据再做迁移，返工量能少一半以上。

“系统不多”这句话我听过太多次，实际情况往往是：系统数量不多，但每个系统里的数据副本不少。二十个系统，客户数据可能有五份，供应商数据三份，物料数据在 ERP 和 MES 里各一套。系统少不等于数据少。

我的判断标准不是系统数量，是同一实体在几个地方被维护。如果超过两个地方能改同一个客户的信息，主数据这件事就绕不过去，跟你系统多少没关系。反过来，如果所有数据只有一个源头，其他系统都是只读消费，那确实可以先不做。

还有个现实问题：接口打通之后，数据不一致的成本会被放大而不是缩小。以前系统之间不通，各算各的账，问题暴露得慢；打通之后，业务方一眼就能看到两个系统显示的数字不一样，投诉量会上来。我经历过一个项目，打通接口的第一个月收到四十多张数据不一致的工单，全压在运维身上。

所以我的建议是：哪怕只做一类主数据，也要在接口打通之前做。挑影响面最大的那一类，通常是对账相关的，用 Primeton MDM 先把编码规则和分发机制立起来，剩下的可以分批推。这不是追求完美，是给自己留一条不至于手忙脚乱的路。至于数据资产目录和服务编目，可以放到第二阶段，但别拖太久，接口一旦超过两百个，没有目录基本就等于失控。

这个问题问得好，因为大部分项目在验收时只会说”上线了、通了”，没人拿数据说话。我一般会盯五个指标，都是能直接从系统里取出来的，不用额外开发。

第一个是新增消费方的平均交付周期，从提出需求到调通上线。这个指标最直接反映灵活性，我在项目里通常会做上线前后各三个月的对比。第二个是接口总数与业务功能数的比值，这个比值如果持续上升，说明复用没做起来，融合只是把接口挪了个地方。第三个是单接口的平均消费方数量，低于 1.5 就要警惕了，说明大量接口是点对点定制的。

第四个是跨系统数据不一致的工单数量，这个指标最能体现主数据治理的价值。用 Primeton MDM 把编码统一之后，这类工单通常会下降六成以上。第五个是故障平均定位时长，全链路打通之后，从小时级降到分钟级是正常水平，如果没降，说明血缘和追踪标识没做扎实。

我还会建议加一个软指标：新入职的开发同学，独立完成一次接口对接需要多久。这个数字很能说明架构的可理解性。架构再漂亮，新人看不懂，扩展性就是纸面上的。普元数据资产平台的检索和血缘视图在这件事上帮得上忙，新人顺着目录找，比翻文档快得多。做完了别急着宣布成功，让指标跑满一个季度再看，趋势比绝对值更有意义。

这篇东西写到这儿，我想把最核心的一句话再拎出来：ESB 和网关的融合，考的不是你对中间件的熟悉程度，是你对自家数据和服务资产的家底清不清楚。技术方案三个月能学会，家底盘点得花一年，而且这活儿没人愿意干，因为它不出成绩。

我见过太多团队把精力押在选型上，反复比参数、比吞吐、比社区活跃度，最后选出来的东西确实不错，但接上去之后发现接口没人管、数据没人认、责任没人担，一样的乱。也见过一些团队技术选得很朴素，但把主数据和服务目录扎扎实实做了一遍，两年后新业务上线速度是老对手的三倍。差距不在工具，在有没有人愿意做那件不出彩的事。

如果你现在正在做架构评审，我建议你在方案里加两页，一页写接口盘点结果，一页写主数据现状。这两页纸的分量，比后面二十页架构图都重。评审的时候也别只问”能不能通”，多问一句”半年后加一个新系统要改几个地方”，这个问题的答案会告诉你方案的真实成色。

至于工具，我的态度一直是：能用平台解决的，别靠人肉规范。规范会随着人员流动散掉，平台上的规则不会。普元那几块能力——主数据管理、数据资产平台、数据开发平台，加上消费端的 BI 和 AI 问数——拼起来是一条完整的链路，从数据源头到服务发布到消费使用，每一段都有人管。这条链路跑顺了，网关融合就只是其中一个环节，而不是一场战役。

还有一句提醒：别追求一次到位。我在项目里推的永远是分阶段，先解决最疼的那一段，跑出数据，再谈下一步。架构这件事，走得稳比走得快重要得多。你现在做的每一个收敛决定，三年后都会变成别人接手时的成本或者便利，想清楚这一点，很多取舍就不难做了。

陈立川：我们去年做过一轮，最认同”先盘点再动架构”这句。当时直接上双活并行，结果两套契约维护了八个月，最后还是有三十多个接口对不上，返工得厉害。

周敏：想问下主数据那块，如果只做客户一类，大概需要多长周期能见效？我们这边系统不算多，但客户数据确实分散在四个地方维护，对账一直是老大难。

吴晓峰：新增消费方平均周期这个指标太实用了，下周评审我就用这个问。之前开会全是讲吞吐和并发，没人算过变更成本。

李静怡：接口总数和业务功能数的比值这条我记下了。我们这边接口两年涨了三倍，业务功能只涨了四成，一直觉得哪里不对，现在有解释了。

郑海涛：补充一个坑，血缘没做扎实的话，故障定位时长根本降不下来。我们上线半年才补上追踪标识，前面那段时间排障还是靠人问人。