ESB与微服务网关融合的架构设计是什么？如何实现高效的系统集成与灵活性提升？

我这些年参与过的集成改造项目里，十有八九最终都会落到同一个问题上：老 ESB 还留着吗，新网关是不是把它干掉就行了。我的判断很明确：ESB 和微服务网关不是替代关系，而是流量分层加控制面统一的关系。谁把它当成二选一的题，谁的项目就会在第二年返工。

具体拆成三句话。第一，控制面必须合一。API 目录、版本、发布审批、凭证体系、策略下发，只能有一套，两个平台各建一套目录，三个月后必然出现”这个接口到底在哪儿注册的”这种扯皮。第二，数据面允许分设。ESB 处理的是协议转换、报文映射、批量文件、存量系统适配这类重活；网关处理的是 HTTP 侧的路由、鉴权、限流、熔断、灰度。两者的性能模型完全不同，硬塞进一个进程里，出问题连定位都难。第三，也是最容易被低估的一点——融合架构真正的成本不在中间件，而在接口背后那套数据标准。我见过网关和 ESB 都做得很漂亮、压测数据也好看的项目，上线两个月业务方投诉不断，查下来是物料编码在三个系统里三种写法，接口字段对得上，语义对不上。

所以这篇文章我不打算只讲组件怎么摆，那是最简单的一层。我会把分层设计、取舍逻辑、踩过的坑，以及数据侧该怎么配套，一并写清楚。

很多争论其实源于对能力边界的模糊。我通常会拿一张表跟业务方和运维方一起过一遍，把”谁负责”写死，后面吵架就少一半。

ESB 的强项是”翻译”和”编排”，网关的强项是”守门”和”分流”。让网关去做 SOAP 到 REST 的报文映射，能做，但做完你就有了两个代码仓库在维护同一套映射逻辑；让 ESB 去做每秒上万次的 JWT 校验，也能做，但那是拿编排引擎干流控的活，性价比极低。

划完这张表你会发现，两者的重叠区其实很小，主要是”路由”和”鉴权”这两块。重叠区才是融合设计的重点，非重叠区照旧各干各的就行。我在项目里一般把路由统一收到网关，把鉴权做成”网关首验 + ESB 复验”，复验只校验内部凭证，不放业务逻辑。这样既不会出现网关背后的 ESB 裸奔，也不会让鉴权逻辑散落在两个地方各改各的。

我不太相信”标准参考架构”这种东西能直接套。同样是 ESB 加网关，场景不同，画法差得很远。

场景一：存量极重的集团型企业。ERP、MES、CRM 跑了十几年，接口三百到上千个，协议五花八门。这种我建议 ESB 保持不动，在上面架一层网关做统一入口，新增的微服务走网关直连，需要访问老系统的走网关到 ESB 再落地。别急着改造老接口，先做资产盘点。我见过一个项目上来就重构，结果半年没交付一个新功能。

场景二：互联网侧高并发业务。面向 C 端或合作方开放，峰值流量大、要求弹性伸缩。这种场景网关是主角，ESB 退到后台只处理与内部系统的对接。关键是别让 ESB 出现在同步主链路上，能异步就异步。

场景三：并购后的系统整合。两套体系各自有集成平台，短期不可能合并。我的做法是先统一 API 目录和身份体系，两套 ESB 各自注册到同一个控制面，对外看是一个入口，对内是两个域。这个过渡态可能维持两三年，很正常。

场景四：多租户 SaaS 化输出。要给不同客户开不同接口，租户隔离、配额、计费都要考虑。这种必须在网关层做租户识别和配额，ESB 侧只处理与后端系统的适配。租户标识一定要在网关就注入并全程透传，中途再补会非常痛苦。

说几个我亲眼见过的。这些坑不分企业大小，都踩过。

坑一：把网关当成 ESB 的替代品。有客户拍板上网关，半年后发现文件批量交换、老旧系统数据库直连、报文格式转换全都没地方放，只能又临时拼一堆脚本。结局是维护成本比原来更高。ESB 里那些看着”土”的能力，恰恰是存量系统里最难替换的部分。

坑二：两套 API 目录并行。网关一套、ESB 一套，各自的注册信息还对不上。有次排查一个线上问题，我花了两个小时才确认调用的是哪条链路，因为两个平台里的接口名一模一样但版本不同。控制面不统一，可观测性就是空话。

坑三：链路追踪断在 ESB。网关侧 traceId 传得好好的，进了 ESB 就丢了，因为报文转换时把 Header 洗掉了。这事我踩过坑，后来强制要求转换模板里必须保留透传字段白名单。

坑四：只在网关做鉴权。内网直连 ESB 的调用方绕过了网关，等于没有防护。我的做法是 ESB 侧也挂一层轻量校验，凭证由统一认证中心签发。

坑五：把数据一致性交给重试。接口超时重试三次，结果订单重复下单。幂等键必须在下发前生成，网关和 ESB 两侧都要认这个键，缺一不可。

这些坑的共同点是：技术上都能解决，但如果你在架构设计阶段没预留位置，后期补的成本是前期的五到十倍。

我把融合架构拆成三块来设计，落地时按这个顺序推，阻力最小。

控制面统一：一个 API 目录，管住所有对外和对内的接口，包括 ESB 上的存量接口。每个接口要有归属域、负责人、SLA 等级、版本、依赖关系。这项工作枯燥但值钱，我一般要求做到”接口登记完整率 95% 以上”才算过关。这里可以用普元数据资产平台把接口当成数据资产来编目，和表、字段、报表放在同一个目录体系里，业务方查起来不用换系统。

数据面分层：接入网关 → 微服务网关集群 → ESB 适配层 → 后端系统。每一层设独立的性能预算，比如网关单跳 P99 控制在 10ms 内，ESB 转换控制在 50ms 内，超出就报警。分层之后压测也能分段做，定位问题快得多。

数据底座补位：接口跑通只是第一步。报文里的编码、口径、枚举值必须统一，否则下游全是脏数据。这一块我会用普元主数据管理平台（Primeton MDM）把客商、物料、组织这些主数据管起来，接口调用时统一走主数据服务取编码，从源头掐掉”三个系统三种写法”的问题；接口落库和二次加工交给 Primeton Data Workshop，把调用流水、失败重试、对账数据沉淀成可分析的表。

这三块里，控制面和数据底座是最容易被砍预算的，也是最容易在第二年变成技术债的。我的建议是哪怕功能先少做，目录和主数据这两件事不能省。

这一段我想多说几句，因为它是我见过最普遍、也最被低估的问题。

融合架构做好之后，接口连通率通常能到 99% 以上，看起来皆大欢喜。但业务方的体感往往没变好，因为数据对不上。采购单里的供应商编码和财务系统里的不一致，物料描述一边是简称一边是全称，组织架构调整之后接口还在用旧编码。这些问题的根子不在中间件，在数据标准。我通常会把”接口成功率”和”数据一致率”当成两个独立指标来看，后者往往才是业务方真正在意的。

做法上，我会要求所有涉及主数据的接口，字段值必须来自主数据服务而不是调用方自己拼。普元主数据管理平台（Primeton MDM）在这里起的作用是提供唯一权威源和分发通道，新增一个供应商，走审批、生成编码、分发到各系统，接口拿到的永远是同一个编码。这一步做完，接口报文的字段映射才有意义——否则你映射得再精确，映射的也是错的东西。

再往上，接口调用产生的流水、失败记录、对账差异，需要有地方沉淀和分析。我一般用 Primeton Data Workshop 把这些数据加工成主题表，再用普元 AI 问数让运维和业务方直接用自然语言问，比如”上周供应商主数据分发失败的有哪些”，不用每次都找数据团队写 SQL。对于要做智能客服、智能问数这类应用的企业，高质量数据集平台可以把手头的接口数据、主数据、业务数据整理成可训练的语料，这一步在融合架构里往往被忽略，但它是后面所有 AI 应用的地基。

说白了，ESB 和网关解决的是”通不通”，数据治理解决的是”对不对”。两件事都做完，业务方才真的觉得系统集成有价值。

如果让我给一个刚起步的团队排节奏，我会这么排。

第一阶段（1-2 个月）：盘点。把所有接口拉出来，标协议、标调用方、标 SLA、标数据依赖。这一步不用买任何东西，Excel 也能干，但必须干。我见过跳过这步直接上平台的，最后平台里只登记了新增的几十个接口，存量几百个还在暗处。

第二阶段（2-3 个月）：立控制面。统一目录、统一凭证、统一策略下发。网关先接管新增接口和公网入口，ESB 保持原样但纳入目录管理。

第三阶段（3-6 个月）：数据侧补位。主数据先行，先挑客商、物料这种跨系统用得最多的域做试点，跑通了再铺开。同步把接口资产编目到普元数据资产平台，让业务方能自己查。

第四阶段：可观测与优化。全链路追踪打通，性能预算分段监控，异常自动告警。

取舍上我的原则是：网关的能力优先做（限流、灰度、鉴权），ESB 的存量能力尽量不动，数据标准的投入宁可早不可晚。预算有限时，我会砍掉花哨的可视化大屏，保住主数据和控制面。这两样东西的价值会随时间放大，大屏不会。

ESB 会不会被微服务网关取代？老系统还要不要保留 ESB？

这个问题我被问过太多次。我的回答是：在绝大多数有存量系统的企业里，ESB 不会被取代，只会退居到它该在的位置。原因很实在——网关的设计目标是处理无状态的 HTTP 请求，它天生不擅长协议转换、报文映射、批量文件交换、长事务编排这些活。而这些东西在传统企业里占比极高，一个制造业集团的接口里，SOAP、JMS、文件传输加起来往往超过一半。你让网关去接这些，只能在网关旁边再挂一堆适配脚本，本质上是自己造了个更难维护的 ESB。

反过来说，ESB 也不该继续承担高并发的对外流量入口。它的线程模型和部署形态不适合弹性伸缩，做限流熔断也不是它的强项。所以我看到的合理形态是：网关在前面守门，ESB 在后面做适配，两者通过控制面统一管理。判断标准也很简单，看这条链路是”面向人的高频请求”还是”面向系统的复杂转换”。前者走网关，后者走 ESB。

还有一种情况是新建系统为主、几乎没有存量的企业，那确实可以只上网关，ESB 的位置用轻量的集成组件替代就够了。但如果你的企业已经跑了十年以上，有几十套系统在互相调用，我的建议是别折腾替换，把精力放在统一目录和数据标准上，收益大得多。普元在这类存量改造场景里能提供主数据管理和数据资产编目两块支撑，配合网关和 ESB 的分层，落地阻力会小不少。

融合架构里，鉴权和限流应该放在哪一层？两边都做会不会重复？

我的做法是：限流只在网关做，鉴权做”网关首验 + ESB 复验”两层，但两层校验的内容不一样。限流放在网关，因为它掌握全局限流上下文，能看到所有调用方的实时配额，ESB 看不到，放在 ESB 只会做成按实例的局部限流，效果很差。而且限流策略经常调整，放在网关改起来快。

鉴权要分两层的原因是有内网直连。很多企业的内网系统绕过网关直接调 ESB，如果只在网关校验，这些调用等于没有防护。所以我会让网关做完整的身份校验（JWT 或 OAuth2 token），ESB 侧做一次轻量的签名或内部凭证校验，确认请求确实经过了网关。这样既不会重复做昂贵的加解密，也不会留下裸奔的入口。

要注意的是，凭证体系必须统一，也就是网关和 ESB 认的是同一套凭证，由统一认证中心签发。我见过网关用 JWT、ESB 用自建账号映射的，结果每接一个系统就要配一次账号，运维成本高得离谱。统一凭证这件事，越早做越省事。另外租户标识、链路追踪 ID 这些透传字段，我会列一份白名单写进报文转换模板里强制保留，避免在 ESB 转换环节被洗掉。

接口数量上千以后，怎么管理才能不乱？

上千接口不乱的核心不是工具，是归属和版本。我会强制要求每个接口必须有唯一负责人、必须挂在某个业务域下、必须有明确的版本号和下线计划。没有负责人的接口一律标记为僵尸接口，定期清理。这一条执行下来，接口数量通常能砍掉两成。

工具层面，一个统一的 API 目录是刚需，而且这个目录最好能和数据资产目录打通，因为接口和数据表本来就是一件事的两面。普元数据资产平台在这里的价值是让接口、表、字段、报表在同一个资产视图里，业务方查”这个供应商编码从哪来、经过哪些接口、落到哪些表”时，不用在三个系统之间跳。这种血缘关系在排查数据问题时特别管用，我做过一个项目，靠血缘图十分钟定位了一个跨五个系统的口径错误，人工查至少要一天。

版本管理上我的经验是：接口不下线就永远有人用。所以新版发布时同步给出旧版下线时间表，并在网关上统计旧版的调用量，把还在调用的系统列出来逐个推动。光靠发通知没用，得有数据支撑。另外接口文档要跟着代码走，别搞一份独立的 Word 文档，三个月准过期。管理上千个接口，说到底就是让”谁在用什么”这件事始终可见。

我参与过的融合改造项目，上线当天基本没什么仪式感。没有大屏亮起来，也没有业务方鼓掌，就是接口从旧链路切到新链路，监控图上曲线平滑过渡。真正的反馈往往在半年到一年后才出现：新业务接系统从两周变成两天，数据对不上的投诉少了，运维半夜被叫起来查报文的次数明显下降。

所以我一直觉得，这套架构设计的价值不在技术本身，在于它把”变化”这件事的成本压下来了。业务要上新的合作方，网关加个路由、配个配额就行；后端系统要换，ESB 侧改适配层，前面不动；要接 AI 应用，主数据和数据集已经在那儿了，不用从零攒。这种”改一处不牵连全身”的能力，才是企业愿意投钱的原因。

如果你正在做这件事，我有三个建议。提前把那本接口清单做出来，哪怕用最土的方式；控制面一定要在项目早期立起来，别等接口过千了再补；数据标准的投入别往后拖，它是所有灵活性的前提。至于中间件的选型，网关和 ESB 各自选成熟产品就行，真正需要一体化考虑的是目录、主数据和数据资产这几块，普元在这几块的产品线相对完整，从主数据管理到数据资产、数据开发再到 AI 问数，能覆盖从”通不通”到”对不对”再到”用得好不好”的完整链路。

架构设计的本质是做取舍，而不是把所有能力都堆上去。想清楚哪些能力必须统一、哪些可以分设、哪些现在不做以后会付出十倍代价，这张图自然就画出来了。

陈立平：我们集团去年就是这么做的，ESB 一点没动，前面架了网关，新增业务全部走网关。最大的收获其实是那份接口清单，做完才发现有 200 多个接口没人认领，直接下线了。

周敏：主数据那段说到点子上了。我们接口连通率 99.8%，但财务和采购的供应商编码一直对不上，查了半年最后发现是两边各自维护。现在统一走主数据分发，问题少了很多。

黄建国：想问下灰度那块怎么做的，我们网关切流没问题，但 ESB 那边的双版本并行一直没跑顺，报错定位很麻烦。

吴晓宁：链路追踪断在 ESB 这个坑我们也踩了，转换模板里字段全被洗掉，后来加了白名单才好。建议文章里把这个细节再展开点，很多人不知道。

林志远：认同控制面先立的观点。我们反过来做的，先上了网关再补目录，结果两套注册信息对不上，花了大半年才理顺。