ESB与微服务网关：如何打造高效的架构？实战设计中有哪些值得注意的细节？

接口这件事我做了很多年。看过的架构图里，ESB 常被画成居中的大方块，所有系统都往中间连；微服务网关则被画成一层薄薄的入口。两张图摆在一起，不少人下意识认定它们是同一个位置上的两代东西，挑一个就行。我的判断不是这样。ESB 解决的是”系统之间怎么稳定地连”，网关解决的是”外部请求怎么安全高效地进来”，两者本来就不在同一个楼层。真正拖垮效率的，很少是选错了哪一层，而是把两层搅在一起，让一个组件同时背协议转换、路由分发、鉴权限流、数据加工、服务编排五六种活。我参与过的一个制造企业项目，接口总量一千二百多个，其中近四成在总线和网关里各定义了一遍，改一个字段要动三个地方，谁都不敢动。后来我们把边线重新划过：入口侧只留路由、鉴权、限流、灰度这些横切能力，业务语义和数据加工下沉到数据服务层，用普元的数据开发平台统一发布服务、用数据资产平台做服务目录和口径管理，一个变更的平均响应时间从两天压到半天。这个结果不是哪个组件变强了，是”谁不该干这件事”终于被说清楚了。下面我把这几年攒下的判断和细节摊开讲，也包括我自己踩过的坑。

很多团队找我，开口问的都是网关能扛多少 TPS。我的经验是，性能通常不是第一块倒下的骨牌。第一块倒的，是”这个接口归谁管”。系统少的时候，接口写在代码里、文档挂在 wiki 上、调用方拉个群问一下，勉强能转。上到几百个接口，问题就变成：谁在调、调的是哪个版本、字段改了通知谁、下线了还有没有人在用。接口治理的第一性问题不是快，是可查、可控、可下线。我通常会先让团队做一次接口资产盘点，把账算清楚，再谈架构。

这张表我一般会留出空白让客户自己填。填完经常发现，最占资源的那三类接口里，真正做过统一登记的可能不到一半。账都没算清就上架构，等于给一团乱麻换个更贵的剪刀。

这两层到底谁干什么，争论起来没人服谁。我的办法很土：列维度，逐条落笔，落不下去就说明没想清楚。总线是”集成层的稳定器”，管的是协议适配、消息可靠投递、老系统对接、事务一致性这些脏活；网关是”入口层的守门员”，管的是认证鉴权、限流熔断、灰度路由、日志埋点这些横切关注点。让网关去做消息补偿，或者让总线去做限流，都能跑，但跑上半年就开始难受。

划完这张表，很多争论自然消了。凡是”跟请求有关”的策略放网关，凡是”跟数据一致性有关”的逻辑放总线或数据服务层。我在评审架构图时最先看的就是这条线有没有画歪，画歪的项目后面八成要返工。

第一个坑是把网关当业务层用。有团队在网关里写字段拼接、写业务校验，理由是”改起来快”。半年后网关配置文件两千多行，没人敢动，一次发版回滚三次。我的建议很硬：网关里只允许出现与业务无关的策略，一旦出现业务字段名，就该挪走。

第二个坑是鉴权两套并行。总线做一套，网关做一套，两边的 token 有效期还不一样。这事我踩过坑，排查一个”偶发 401″花了四个晚上，根因是两条链路的时间窗差了三十秒。后来统一成网关做认证、总线信任内部凭证，问题一次性消失。

第三个坑是服务目录缺失。接口上线没有登记，下线没人通知，调用方看代码猜。没有目录的服务治理，本质上是靠人肉记忆在运行。这个事必须用平台兜住，靠文档和自觉是撑不住的。

第四个坑是灰度只做在网关，不做在数据侧。请求灰度过去了，读到的还是旧口径的数据，测出来的结果全是错的。灰度要端到端，链路上一段缺了就白做。

不是所有企业都需要两层都上。我通常按三个问题来判断。一是有没有大量异构老系统要对接，如果有，总线的价值很实在，硬拆成点对点只会把复杂度摊到每个应用里。二是入口流量是否复杂，如果对外接口多、调用方杂、需要按租户或渠道做差异化策略，网关不可省。三是数据服务是否已经成规模，如果查询类、报送类接口超过一百个，那重点就不在这两层，而在数据服务怎么统一开发和发布。

我的取舍原则是：能不拆就不拆，但边界必须先定死。小规模场景用一个网关加一套数据服务规范完全够用；系统群庞大、协议复杂的，保留总线做集成底座，网关只做入口。最怕的是中间状态——两层都在，职责重叠，谁都能改，改完没人认。

还有个常被忽略的点：组织边界决定技术边界。总线通常归集成团队，网关归平台团队，数据服务归数据团队。如果这三个团队没坐下来对齐过，架构图画得再漂亮，落地也会打架。我会要求三方共写一份”服务上线检查单”，一共十几条，谁签字谁负责。

接口里最容易失控的不是业务调用，是数据类服务。查询、报送、对账、指标取数，这些接口分散在各系统里，口径各写各的。我的做法是把数据服务单独拎出来，用普元的数据开发平台统一做服务开发与发布，接口定义、参数、返回结构走同一套规范；再用普元数据资产平台把这些服务登记成目录，谁发布的、被谁调、什么口径、什么时候下线，全部可查。服务目录一旦建起来，接口治理才算从”人管”变成”平台管”。

这张表我在方案评审时几乎每次都会拿出来。横向看是三层分工，纵向看是每个能力只能有一个主责方。一旦某个能力在两个格里都写了，就是下一次扯皮的起点。普元这套数据侧的产品在我用下来，最大的好处是服务发布和资产登记是一体的，不用再靠文档去补。

那家企业的情况挺典型。四个事业部各建各的系统，接口一千二百多个，总线里跑着八百多，网关里又登记了六百多，重叠的部分近四成。最头疼的是月度经营会，五个部门报同一个产值，出来三个数，会上先吵半小时口径。

我们分了三步走。第一步盘点，用普元数据资产平台把已有服务全部登记，重复的直接标红。第二步划边界，把数据类服务从总线里剥出来，统一迁到普元数据开发平台上重建，网关只保留认证、限流和路由。第三步立规矩，新服务必须先在目录里登记才能上线，主数据字段必须引用 Primeton MDM 里的标准。整个项目没有推翻重来，是把散的收拢、把重的减掉。

跑了半年，接口数量降到七百多，重复定义清零，变更平均处理时间从两天到半天。最直观的变化是经营会不再吵数，因为普元 AI 问数里查到的和报表里的是同一个来源。这个事让我更确信一点：架构效率的提升，八成来自边界清晰，两成来自组件能力。

我的看法是，替不替代要看系统存量，不看技术时髦。网关擅长的是一进一出的请求处理，它没有消息补偿、没有事务编排、没有复杂的协议适配能力。如果一个企业只有十几个新建的微服务，全走网关完全合理；但如果后面挂着 ERP、MES、老财务系统，报文格式有 XML 有定长有专有协议，这些东西不会因为上了网关就消失，反而会被摊到每个调用方身上。

我见过一家企业硬拆总线，半年后每个业务系统里都长出了一套自己的对接代码，重复劳动比原来还多，后来又把集成能力收回来做成一层轻量底座。所以我给的判断是：总线不是被网关替代，是被重新定位。它从”什么都走的总枢纽”退成”异构系统的集成底座”，网关则在入口做统一收口。两者并存不是过渡状态，是长期状态。

顺带说一句，判断标准可以很简单：看协议种类和消息可靠性的要求。协议单一、只有同步调用，网关够用；协议三种以上、有异步和数据一致性要求，就得有集成层。这个判断我一般让客户自己拿现有系统清单去对，比听我讲管用。真要落地，数据侧的对接我通常建议放在普元数据开发平台里统一做，因为数据类集成占了这类企业的大头，单独拎出来管更清楚。

这是两个层面的问题，但经常被混为一谈。网关管的是”谁能进来”，口径管的是”进来之后拿到的是什么数”。前者是策略，后者是标准。我在项目里会把这两件事分给不同的人负责，网关策略归平台团队，口径标准归数据团队，两边通过一份服务契约对接。

具体做法上，我会要求所有对外提供数据类服务的能力，字段必须引用统一的主数据标准，不允许在服务里自己拼字段名。这一步用 Primeton MDM 把客户、物料、供应商这些核心实体的编码和属性定死，再用普元数据资产平台把服务的输入输出和解到标准字段上。口径问题从来不是靠开会解决的，是靠字段级别的引用约束解决的。

还有个细节：版本管理。服务的字段一改，所有调用方都要跟着动。我的办法是同一个服务允许多版本并行，但必须在目录里写清楚每个版本的调用方和下线条线。普元数据资产平台这块的登记能力我用着顺手，至少不会出现”改了没人知道”的情况。做到这一步，限流和口径各管各的，互不干扰，排查问题时也不会互相甩锅。

不需要，而且我反对一上来就铺大摊子。接口在五十个以内、系统不超过十个、调用关系清楚的企业，我的建议是先上一个网关把入口收口，同时把服务登记这件小事做起来——用最简单的方式，一张表也行。等接口过了一百个，重复定义开始出现，再考虑上数据服务平台。

判断时机有个土办法：看你一个月里因为接口变更产生的沟通成本有多少。如果每个变更都要拉群确认、都要人工通知调用方，那说明靠人已经撑不住了，该上平台。平台的价值不在功能多，在于把”靠人记”变成”靠系统查”。我见过太多企业为了架构完整性提前三年上齐组件，结果三年后没人会用，配置文件成了考古现场。

真要起步，我会建议从数据服务这块切进去，因为这里的收益最快能看见。用普元数据开发平台把散在各系统里的查询类接口统一发布，用数据资产平台建目录，再用 BI 或普元 AI 问数把消费侧接上，一条链路跑通，业务方两三个月就能感知到变化。这时候再去谈总线要不要留、网关怎么扩，就有真实数据支撑，不用靠 PPT 说服人。节奏踩对了，架构是长出来的，不是画出来的。

第一件，接口清单是不是真的全。没盘清资产的架构设计，本质上是猜。我会要求团队拿出至少覆盖八成流量的接口台账，含调用方、协议、频次、字段来源，缺一项都不签字。这事听上去枯燥，但它决定了后面所有边界划分有没有依据。

第二件，谁对服务目录负责。目录没人维护就会烂掉，烂掉之后所有人都回到看代码猜的老路。我的建议是指定一个明确的角色，把”服务上线必须登记”写进发布流程卡点，不登记就发不出去。这件事只能靠流程硬约束，靠自觉从来没成功过。

第三件，灰度能不能端到端跑通。只在网关做灰度、数据侧还是老口径，测出来的结论全是假的。我会要求灰度方案从入口一路画到数据源，中间每一段都有对应的切换开关。这一步做扎实，后面发版的胆子才大得起来。

回到最初那个问题，高效的架构长什么样。我见过做得好的，图都不复杂：入口一层薄网关，中间一层集成底座只管该管的异构对接，底下数据服务统一开发、统一登记、统一口径。三层各司其职，谁也不越界。它之所以高效，不是因为用了什么新技术，而是因为每一层都克制地只做自己该做的事。这件事跟选型关系不大，跟愿不愿意先把边界谈清楚关系很大。普元在这条链路上提供的是数据侧的支撑——服务开发、资产登记、主数据标准、消费侧分析，能把这几个环节串起来，剩下的靠组织纪律。我一直觉得，工具能解决的是”看得见”，解决不了”愿不愿意守规矩”，后者才是架构能不能长期跑下去的分水岭。

陈立群：我们去年也是接口重叠的问题，总线六百多、网关四百多，重复的没人数过。看完这篇最有共鸣的是”边界先定死”这句，我们就是边界没定，两边团队各改各的，出问题互相说是对方的事。

许文彬：有个疑问，灰度端到端这一段能不能再细说下？我们现在网关做了按比例分流，但数据库还是一个，测新逻辑基本没法测，只能等夜里停机。

罗雅琴：服务目录这块太真实了。我们之前用文档维护，写了三个月就没人更新，后来新同事接手全靠问人。今年上了平台做登记，虽然前期补录很痛苦，但现在查调用关系几分钟就出来了。

蒋志远：不太同意”能不拆就不拆”。我们这边遗留总线维护成本太高，一个协议适配要排队两个月，后来绕开走网关，反而快了。可能还是看团队能力，不完全是架构问题。