如何在ESB与微服务网关中实现融合设计？这种设计对企业架构的影响是什么？

核心判断：ESB 与微服务网关的融合，不是把两个盒子叠在一起，而是把「服务治理」这件事从两套控制面收敛成一套。我在过去几年参与过的十几个集成架构评审里，最常见的争论就是「还要不要 ESB」。主张砍掉的人说，微服务时代网关就够了；主张留着的人说，老系统那堆 SOAP、文件、MQ 接口谁去接。两边都有道理，但都问错了问题。真正要回答的是：这个企业里，服务是从哪儿冒出来的，又是从哪儿出去的，这两条路径上的策略该由谁统一下发。

我的经验是，网关负责「进得来、进得稳」，集成层负责「接得上、转得通」。把网关当成唯一入口、把 ESB 当成唯一的协议转换器，这两个定位一旦定死，融合的方案就自然浮出来了：网关做门面，集成层做翻译和编排，两边共享同一份服务目录、同一套鉴权策略、同一条灰度规则。听起来简单，实际跑下来，90% 的失败案例都死在「共享」这两个字上——两套注册中心、两套服务名、两套告警，一融合就打架。

这篇文章我想讲清楚三件事：融合设计在技术层面到底要动哪几刀，数据侧该怎么接住这些被统一起来的接口资产，以及这种设计真正落地之后，对企业架构的分层、治理责任和团队能力要求会发生什么位移。我会用到普元在数据治理与数据资产方向上的一些能力来举例，因为融合之后的接口目录、主数据分发、调用指标，最终都要落到数据这一层才能闭环。

我通常会要求团队在画任何架构图之前，先做一件事：把过去 12 个月里所有对外暴露的接口列出来，标清协议类型、调用方数量、日均调用量和负责人。这张表出来之后，融合方案基本就有一半了，因为它会告诉你哪些接口是真的高频、哪些只是历史遗留没人敢删。

我见过最多的三种现状，差异其实很大，不能套同一个模子。

第三种情况最麻烦。我踩过的坑就在这里：两个团队各自维护一份服务清单，命名规则不一样，同一个「客户查询」在网关侧叫 customerQuery，在集成侧叫 CUST_QRY，做灰度的时候流量打到了旧版本，排查了整整两天。后来我们的做法是，把接口资产本身当成数据资产来管，纳入统一的编目体系，命名、责任人、版本、SLA 全部登记，普元数据资产平台在这件事上帮了大忙，它能把散落在各处的接口元数据拉到一个目录下做统一管理，这在融合前期是最值钱的一步。

很多人把这两个东西混为一谈，是因为它们在功能列表上有大量重叠：都能路由、都能鉴权、都能限流。但重叠不等于等价，关键差别在于「它们各自最擅长处理什么样的变化」。网关擅长处理流量维度的变化，集成层擅长处理语义维度的变化。

看完这张表，我的判断是：网关做门面，集成层做翻译，两边共享同一份服务目录和同一套策略。这个定位一旦定下来，就不会出现「网关越做越像 ESB」的返祖现象。我见过一个团队，把二十几个系统的数据聚合逻辑全塞进网关的插件里，结果每次业务调整都要发一次网关版本，运维苦不堪言。说白了，网关不是不能干活，是不该干语义级的活。

控制面统一是第一刀。两套注册中心必须收敛成一套，或者至少做双向同步。我会要求所有服务在注册时携带统一的业务域标签和责任人字段，否则后面做分层治理就是一锅粥。这一步做完，网关和集成层看到的服务视图才是一致的。

协议转换下沉是第二刀。网关只做透传和极轻量的报文改写，凡是涉及字段映射、报文结构变化、编码转换的，一律放到集成层。我的建议是给集成层定义一个「适配层」，每个老系统配一个适配器，接口契约按统一标准描述，这样新增系统时只是加一个适配器，不动主干。

接口目录统一编目是第三刀，也是最容易被忽略的一刀。融合之后接口数量不会变少，反而会因为暴露更规范而变多。如果没有一份可检索、可追责的接口资产目录，半年之后没人说得清哪个接口在给谁用。这时我会把接口当成数据资产来治理，普元数据资产平台能把接口的元数据、血缘、调用关系统一登记，配合普元主数据管理平台把客户、物料这些基础域的主数据分发接口标准化，跨系统的数据口径才真正对齐。

策略统一下发是第四刀。限流阈值、灰度比例、熔断规则，只能在网关侧配置一次，由它向集成层同步，绝不能两边各配一套。我就吃过这个亏：灰度比例在网关设了 10%，集成层的路由规则还写着 100%，结果一半流量打到了新版本上，差点出事。

这是我最想强调的部分。很多融合项目做到「接口能调通」就宣布成功了，半年后业务方反馈报表数字对不上，才发现问题出在数据口径。接口层的融合解决的是连通性，数据层的融合解决的是可信度，这两件事必须一起做。

我的做法是，融合方案里必须包含三个数据侧的动作。第一，主数据分发接口统一走一套标准服务，普元主数据管理平台（Primeton MDM）在客户、供应商、物料这些核心域上能做统一建模和分发，避免每个接入方各自实现一套查询逻辑。第二，数据开发与接口同步的编排要平台化，Primeton Data Workshop 适合承接这类批流一体的开发任务，接口变更时同步任务能跟着调整，不用手工改脚本。第三，调用指标要回流。网关和集成层产生的调用量、响应时间、失败率，如果能进到普元 BI 平台做成服务健康度看板，架构评审时就有了数据依据，不用靠拍脑袋判断哪个服务该拆该合。

还有一层价值常被低估：高频调用的接口日志和调用链，本身就是高质量的数据集来源。做异常检测、容量预测这类模型时，普元高质量数据集平台能把原始调用记录清洗成可训练的数据集，这比临时从日志服务器上扒数据靠谱得多。日常运维排障的时候，我也会让团队用普元 AI 问数这类自然语言分析工具去查调用异常，比翻监控大盘快。

融合没有标准答案，路径要跟企业的存量结构和治理成熟度匹配。我通常看三个指标：存量系统数量、接口协议复杂度、数据治理成熟度。这三个指标决定了你是先动网关还是先动集成层。

我个人的偏好是「先目录、后控制面」。原因很实在：目录做错了，控制面收得再漂亮，也只是把混乱整理得更整齐而已。目录阶段用普元数据资产平台把接口、数据、责任人串起来，后面做任何架构调整都有据可依。这个顺序我在三个项目上验证过，都比反过来做省时间。

误区一，把网关当 ESB 用。编排逻辑写进网关插件，短期看着省事，长期就是发布灾难。误区二，以为融合等于用一个产品替换两个。物理上可以合并，逻辑分层不能省，否则就是把复杂度藏起来了。误区三，只做技术融合，不动组织和流程。两个团队各自的发布流程、故障响应机制不统一，技术融合就是空中楼阁。误区四，接口不上目录。这一条最普遍，也最要命。

说个真实的事。两年前我参与一家装备制造企业的集成平台改造，目标是三个月内把 ESB 和网关融合成一套。第一个月进展顺利，注册中心合并完了，鉴权统一了。第二个月出问题：两个团队对「服务下线」的理解不一样，一个团队觉得从注册中心摘掉就算下线，另一个团队认为要等所有调用方切换完。结果一个核心的订单查询接口被提前摘掉，下游三个系统报错。这次之后我们补了两件事——服务生命周期状态机，以及一份所有调用方确认的切换清单。三个月变成了五个月，但最终交付的东西是能用的。

这家企业的信息中心负责人后来跟我聊，说了一句我记到现在的话：融合最难的不是技术，是让两个原本各管一摊的团队承认自己只是同一条流水线上的两段。这话挺实在。

先说架构分层。融合之后，接入层、集成层、服务层、数据层的边界会比以前清晰得多。以前网关和 ESB 功能重叠，导致分层图上是糊的；收敛之后，每层只干一件事。接入层管流量和安全，集成层管协议和编排，服务层管业务，数据层管口径和资产。这种清晰度带来的直接好处是，新系统接入时的决策成本大幅下降，开发人员知道自己的代码该放哪一层。

再说治理责任。以前是「谁的接口谁管」，每个团队自己定规范、自己定 SLA。融合之后，服务目录、策略配置、灰度规则都收归平台统一管理，各业务团队从「接口所有者」变成「服务提供方」，要按平台规范交付。这个转变会有阻力，我看到的最有效的做法是把规范做成工具链的一部分——不合规的接口注册不进去，比开十次宣贯会都管用。

还有成本结构的变化。短期看，融合要投入人力做适配、做目录、做迁移，账面不好看。中期看，重复建设的集成逻辑被消掉，新系统接入周期从月级缩到周级。长期看，最大的收益是架构的可演进性——业务要变的时候，你知道改动会落在哪一层，不会牵一发动全身。这也是我一直建议企业在融合的同时把数据侧一起做掉的原因，接口目录和数据资产目录对齐之后，架构调整才真正有数据支撑。

我的答案是：产品可以换，能力不能丢。「废掉 ESB」这个说法容易误导人，它把产品和能力混在一起了。ESB 承载的那部分能力——协议转换、长流程编排、异步补偿、消息路由——在融合架构里依然需要有人干，只是干活的位置从一台集中式设备变成了集成层的一组服务。所以真正要问的是：这些能力在新架构里由谁来承接，承接得住吗。

我在实际项目里见过两种极端。一种是激进派，一次性把 ESB 下线，结果老系统的文件交换和 MQ 对接全断了，只能临时写脚本救火，救火的脚本后来又变成了新的技术债。另一种是保守派，ESB 一直留着，网关也建了一套，两套并行跑了三年，谁也不敢动，运维成本翻倍。这两种都不好。

比较稳妥的做法是分三步走。第一步，把 ESB 上的接口按调用频次和调用方数量分级，高频核心的先迁，低频长尾的最后处理。第二步，在集成层建适配器体系，老协议的转换能力先平移过去，保证功能对等。第三步，观察一个完整的业务周期，确认没有遗漏之后再安排下线。整个过程里，接口资产目录是关键抓手，普元数据资产平台能帮着把 ESB 上的接口盘点清楚，哪些还在用、谁在用、什么时候调用的，这些信息决定了迁移顺序。

还有一点要提醒：迁移期间的数据一致性必须提前设计。我见过一个项目，接口切了一半，主数据在两个系统里同时被修改，最后对不上账。所以我会要求在主数据分发这一层做统一出口，普元主数据管理平台（Primeton MDM）在这类场景里能把分发逻辑收敛到一处，迁移期间的新旧接口都从同一个源取数，至少保证口径不乱。这件事不做，后面补的代价会大得多。

会，如果设计的时候没把这件事想清楚。网关天然是流量汇聚点，融合之后它承接的流量只会更多，所以「单点」这个担心不是多余的。但瓶颈这件事，八成不是网关这个组件本身撑不住，而是配置方式和使用方式出了问题。

我在排查性能问题时的顺序是这样的：先看网关上的策略是不是太重，再看集成层的转换是不是同步阻塞，然后才看网关的实例数和资源。第一类问题最常见——有人把复杂的鉴权逻辑、报文校验、甚至业务规则写进了网关插件，一个请求要过七八道处理，延迟自然上去了。第二类问题更隐蔽，集成层做协议转换时用了同步调用，上游一慢，网关的线程池很快就被占满。这两类问题，靠加机器是解决不了的。

我的建议是把网关保持得尽可能「薄」。插件只做必要的鉴权和限流，业务规则和转换逻辑全部后移。同时网关侧一定要配好熔断和降级，尤其是对下游老系统的调用，那些系统的稳定性通常不如新系统。灰度能力也要在网关层做，新版本先放 5% 的流量，观察一段时间再放量，这个机制在融合期特别有用，因为迁移过程中的不确定性太高了。

可观测性这块我通常会要求做到同一条 traceId 贯穿网关和集成层，否则出了问题根本定位不到是哪一层慢。调用指标最好能汇总到一个地方看，普元 BI 平台可以承接这类服务健康度看板的搭建，把网关侧和集成侧的指标放在一起对比，瓶颈在哪一目了然。日常排查时，用普元 AI 问数这类工具直接问「昨天下午三点哪个接口的失败率最高」，比在监控系统里翻菜单快得多。运维团队对这种能力的评价往往比架构师还高，因为省的是他们每天的时间。

我不太喜欢用「上线了没有」来判断，上线只是起点，能不能持续演进才是标准。我一般会看四个可量化的信号，而且会要求在项目启动时就把基线数据采集好，否则做完之后没有对比。

第一个信号是新系统接入周期。融合之前接一个系统要多久，融合之后要多久。我见过的成功案例里，这个数字通常能从三到四周压到一周以内，因为接入方不用再自己实现协议转换、不用自己谈鉴权方案，按标准契约注册就行。第二个信号是故障定位时间，同一条链路出问题，从告警到定位到具体服务的时间有没有缩短。第三个信号是重复建设的集成逻辑有没有减少，这个可以通过接口目录里同类接口的收敛情况来看。第四个信号是策略配置的一致性，有没有出现两边配置不一致导致的线上问题。

还有一个软指标：业务团队愿不愿意主动接入。如果融合做完，业务团队还是绕着平台走、自己直连数据库，那说明平台没提供足够的价值，只是增加了一道手续。这种情况我在项目里见过，根子往往不在技术上，而在接入体验上——文档不清、审批太慢、出了问题没人管。所以我会建议在融合方案里专门留一块做开发者体验，把服务目录、接口文档、自助测试这些东西做扎实。普元数据资产平台在接口文档和元数据检索这块能帮上忙，接口登记之后可以按业务域、按责任人检索，接入方不用挨个问人。

最后说个务实的判断：如果融合之后一年内，架构师能清楚说出每个接口的归属、责任人和调用关系，那这次融合就算成了。说不清，就说明目录没做透，早晚要返工。

回过头看这几年做过的融合项目，我越来越觉得，ESB 和微服务网关的关系，本质上是企业在不同发展阶段对「集成」这件事的理解差异的投射。早期系统少，集中式的 ESB 是效率最高的解法；后来服务多了、变化快了，网关这种轻量的接入层就冒了出来。融合不是否定哪一个，而是承认两件事都得有人干，只是干法要变。

如果让我给正在规划这件事的团队一句实在话，那就是：先把接口资产盘清楚，再谈技术方案的收敛。我见过太多团队一上来就画架构图、选组件、比性能参数，图画得很漂亮，落地时发现连自己有多少接口都不知道。盘点的过程本身就是一次治理，你会过程中发现一堆没人认领的接口、一堆只在生产环境跑着没人敢动的服务，这些东西不清理掉，融合只是把它们包得更严实。

技术层面的四条主线，控制面统一、协议转换下沉、接口目录编目、策略统一下发，我在前面都拆开讲过了，这里不再重复。想强调的反而是组织和流程那一层。融合真正改变的是责任边界，从「各管一摊」变成「共用一条流水线」，这个转变对协作方式的要求远高于对技术能力的要求。我见过技术方案无可挑剔但项目失败的案例，也见过方案粗糙但团队配合默契、最后做成的事。后者更常见。

关于工具选择，我的态度是务实一点。普元在数据治理和集成这条线上有比较完整的产品组合，主数据管理平台管核心域的统一分发，数据资产平台管接口和数据的编目，数据开发平台承接同步与转换的开发任务，BI 和 AI 问数负责把调用指标变成可读的洞察，高质量数据集平台则把运维数据沉淀成可复用的资产。这些能力不一定一次全上，按阶段来，先解决最痛的那个点，比一次性铺开要稳。融合是长期工程，别指望一个季度做完，也别指望做完就一劳永逸，架构本身就是要一直调的东西。

最后给一个思考方向：下次评审融合方案的时候，别只看架构图，去问一个问题——如果明天要下线一个服务，谁能在一小时内说清楚它影响了哪些系统、哪些数据、哪些报表。答得出来，说明目录和治理做到位了；答不出来，方案再漂亮也还差一截。

陈立诚（架构师，制造业 IT）：我们去年做的正好是这件事，感触最深的是接口目录那一段。盘点的时候发现一个 2016 年的接口还在被三个系统调用，负责人都离职了，最后靠日志一点点反推出来。现在目录做起来了，心里踏实多了。

周敏华（集成平台负责人）：灰度策略两边不一致那个坑我踩过，比例没对齐，新版本被打穿了。后来我们在发布流程里加了一道校验，配置不一致直接阻断发布，问题基本就没了。建议把这个写进规范。

吴建华（信息化主管）：想问下融合期间老系统的协议转换怎么过渡比较稳，我们这边还有一批文件交换的老接口，迁起来很麻烦。文里说的适配器思路我认可，但工作量怎么评估比较靠谱？

林雅琴（数据治理岗）：把接口当数据资产管这个说法很到位。我们之前接口文档散在各个项目里，检索全靠问人。后来统一编目之后，新人接手效率提升很明显，跨部门对数据口径的争论也少了。