API 网关在微服务架构中的角色与边界

一、网关解决的是什么问题

当系统从单体应用拆成多个服务之后，会立刻遇到一类新问题：客户端要怎么访问这些服务。

如果没有网关，客户端就得知道每个服务的地址、各自不同的鉴权方式、各自的接口约定。服务一多，客户端越来越重，任何一次服务拆分或迁移都会波及所有调用方。更麻烦的是，鉴权、限流、日志这些每个服务都要做的事，会散落在各处重复实现，权限收回不彻底，问题排查也对不上口径。

API 网关正是为解决这类问题而出现的：它把「所有请求都要经过的共同处理」集中到一个入口，让各个服务只关注自己的业务逻辑。它的价值不在于技术多新，而在于把横切关注点收拢，避免重复与失控。

这篇文章讨论网关的职责边界：它应该承担什么、不应该承担什么、常见的误区有哪些。理解边界比记住功能清单更重要，因为网关用过了头，会变成新的瓶颈与单点风险。

关于我们的整体技术思路，可参考 技术能力。

二、网关应该承担的职责

统一入口与路由

网关最基础的职责是统一入口与请求路由：客户端只面向一个地址，网关根据路径、域名或请求特征把请求转发到对应的后端服务。

好处有三点。其一，客户端无需感知内部服务拓扑，服务拆分与迁移对客户端透明。其二，可以做统一的服务发现与负载均衡，某个实例不可用时自动切换。其三，可以做统一的路径与版本管理，让接口演进不至于影响老客户端。

路由规则的设计应当尽量简单、可读、可维护。复杂的路由条件虽然灵活，但也更容易出错，且难以排查。

认证与鉴权

鉴权是网关最能体现价值的地方之一。

把认证逻辑集中在网关，意味着每个后端服务不必各自实现一套登录校验与令牌解析。网关负责校验身份凭证（例如令牌的有效性与签名），把解析出的身份信息以约定的方式传递给下游服务。下游服务则专注业务权限判断。

需要强调的是：网关通常负责「你是谁」，业务的「你能不能做这件事」应留在服务内部。把细粒度的业务权限也塞进网关，会导致网关与业务强耦合，规则一改就要动网关，反而增加风险。

同时，鉴权入口统一还有两个附加收益：权限收回时只需在一处生效，避免遗漏；所有访问记录集中在网关，便于审计。

限流与熔断

限流是网关的典型职责。当某个客户端、某个接口或整站流量超过阈值时，网关可以按预设策略拒绝或排队，避免流量直接冲击后端服务。

常见的限流维度包括：按来源（应用、用户、IP）、按接口、按时间窗口。选择哪种取决于业务目的——保护后端资源、约束单个调用方、还是防止异常刷量。

熔断与降级则用于应对后端异常：当某个服务连续失败或响应过慢，网关可以暂时停止转发并返回预设响应，避免故障扩散引发连锁等待。需要注意的是，熔断策略要经过压测与灰度验证，不能凭设置拍脑袋。

灰度与流量治理

网关是流量治理的天然位置。

基于请求特征，它可以实现按用户、按地域、按比例把流量导向不同版本的服务，从而支持灰度发布与 A/B 验证。这比在每个服务里各自实现一套分流逻辑要清晰得多。

流量治理还包括请求重写、超时控制、重试策略等。这里要特别注意重试：无条件的自动重试可能放大故障，对非幂等接口还可能造成重复写入。重试策略必须与接口的幂等设计配合。关于幂等与一致性的设计，我们在 工程与质量保障 中有相关说明，这类问题在 AI 应用链路里同样存在。

日志、追踪与可观测性

网关是所有请求的必经之路，因此也是采集日志与追踪信息的位置。

统一的访问日志能回答「谁在什么时候调用了哪个接口、结果如何」；统一的追踪标识能把一次请求在多个服务间的调用串起来，便于定位性能瓶颈与错误链路。这些信息对排障、容量规划与安全审计都有价值。

需要提醒的是：日志本身也要有规范。哪些字段必须记录、敏感信息如何脱敏、保留多久，都应有明确约定，否则日志既不好用，也可能带来隐私风险。

协议转换与响应聚合

网关还常承担协议转换（例如对外提供更通用的接口形式，对内调用服务原生的接口）与响应聚合（把多个服务的返回合并为一次响应）的职责。

这两项有一定价值，但也最容易用过头。协议转换能让客户端更简单，但过度转换会让网关承担业务语义；响应聚合能减少往返次数，但聚合逻辑一旦复杂，网关就会变成隐形的业务服务。是否承担这两项，取决于聚合是否是通用能力，还是只服务某几个特定页面。

三、网关不该承担什么

划清「不该做什么」比罗列「能做什么」更能避免踩坑。

不宜承担业务逻辑。 网关应保持薄而稳定。业务规则、计算逻辑一旦写进网关，网关就与具体业务耦合，任何需求变化都要动这一层，风险被放大到全站。业务逻辑应留在服务里。

不宜承担数据持久化。 网关通常是无状态的转发与治理层，不应成为业务数据的存储位置。把状态放在网关会让扩容、故障恢复、数据一致性都变复杂。

不宜做服务间内部调用。 网关面向的是「外部进入系统」的流量。服务之间的内部调用直接走服务发现即可，若绕行网关，会引入不必要的跳数与单点压力。

不宜承担过于复杂的聚合编排。 复杂的跨服务编排更适合放在专门的编排层或业务服务中，而不是塞进网关。

不宜成为唯一的可观测手段。 网关能看到入口流量，但服务内部的执行细节需要服务自身的日志与指标配合。只依赖网关日志，排障时会缺少关键上下文。

一个简单的判断标准：只要是「所有请求都需要、且与具体业务无关」的横切能力，适合放网关；只要涉及业务语义或数据状态，就应该放到服务内部。

四、常见的误区

误区一：把网关当成万能入口，什么都往里放。 结果网关越来越厚，成为全站的变更瓶颈和故障单点。

误区二：忽略网关自身的高可用。 网关是全站入口，一旦不可用影响面极大。它本身就需要多实例部署、健康检查与故障转移，不能只把它当成一个普通服务对待。

误区三：鉴权只在网关做，服务不校验。 如果服务默认信任来自网关的请求而不做任何校验，一旦网关被绕过或配置出错，风险会直接落到服务上。更稳妥的是网关做身份校验，服务做必要的二次校验。

误区四：重试策略与幂等设计脱节。 网关层随意自动重试非幂等接口，可能造成重复下单、重复扣减等后果。

误区五：限流阈值拍脑袋定。 阈值应与后端实际承载能力匹配，并通过压测与灰度验证，否则要么形同虚设，要么误伤正常流量。

误区六：路由与鉴权规则缺少版本与评审。 网关配置本质上也是代码，应当像代码一样被评审、被版本管理、可回滚。

五、网关的形态与选型考虑

网关不是只有一种形态，选型时可以从几个维度判断。

集中式网关与就近网关。 集中式网关是单一入口，所有外部流量都经过它，治理规则集中、运维简单。它的代价是入口压力集中，且一旦规则复杂化容易变厚。另一种思路是把能力下沉到每个服务旁边（即「边车」式代理），让服务自带治理能力，适合服务数量多、团队自治程度高的场景。两种形态并非互斥，也可以取舍组合：对外流量走集中网关，服务间流量走轻量代理。

自建与托管服务。 自建网关可控性强、可深度定制，但需要自己承担高可用、扩容、升级与安全修补的责任。托管服务降低了运维负担，但在定制能力、数据流向与成本结构上有约束。选择的关键是：团队是否有能力长期维护一个全站入口组件。

与 BFF 的区别。 网关面向的是「所有请求的通用治理」，而 BFF（面向具体前端的后端层）面向的是「某一类客户端的体验聚合」，例如为移动端定制接口。二者职责不同：把前端的个性化聚合塞进网关，会让网关变成业务层；把通用治理下沉到 BFF，则会造成重复实现。常见做法是网关在前、BFF 在后，各司其职。

性能与跳数。 每增加一层转发，就会增加一点延迟和一次网络跳数。对于延迟敏感的系统，网关的转发效率、连接复用与超时设置都会影响整体表现，这些指标应通过压测确认。

运维成本。 网关是全站入口，它的发布、回滚、配置变更、证书管理都需要配套的流程与工具。选型时不应只看功能列表，也要评估「出了问题能不能快速定位与恢复」。

一句话总结选型的思路：网关的复杂度应与系统的规模和团队的能力匹配。小微系统上一个功能齐全的重型网关，往往是负担；大规模系统若没有清晰的治理入口，规则又会失控。

六、落地建议

如果你正在设计或评估网关方案，可以参考以下做法。

1. 先明确边界。 在设计前就写清楚哪些能力放网关、哪些留在服务，形成团队共识。
2. 保持网关薄而稳定。 网关的变更频率应显著低于业务服务，任何要放进网关的逻辑都应经过严格评估。
3. 把规则当代码管理。 路由、鉴权、限流、灰度规则纳入版本管理与评审，支持回滚。
4. 重试与幂等配套。 只有幂等的接口才允许自动重试，其余情况应谨慎处理。
5. 保证网关自身高可用。 多实例、健康检查、容量预留与故障演练缺一不可。
6. 统一可观测性。 访问日志、追踪标识、关键指标在网关统一采集，同时保留服务内部的可观测能力。
7. 做压测验证。 限流阈值、超时设置、聚合策略都应通过压测确认，而不是凭经验设定。压测方法可参考我们后续的专门文章。

对于涉及 AI 能力的系统，网关还可以承担模型调用入口的统一治理——鉴权、配额、成本计量与审计集中在一处，便于控制调用规模与追踪来源。这部分能力说明可见 AI 应用与 AIGC 服务。

七、小结

API 网关的核心价值，是把「所有请求共同需要、且与业务无关」的横切能力集中到统一入口，从而消除重复实现、便于治理与审计。鉴权、限流、路由、灰度、日志与追踪，都是它擅长的领域。

但它不是越厚越好。一旦网关承载了业务逻辑、数据状态或复杂编排，它就会从「治理层」变成「风险集中层」。保持薄而稳定、划清职责边界、把配置当代码管理，才能让网关长期发挥正面作用。

对架构设计而言，真正需要提前想清楚的，不是「用不用网关」，而是「哪些事情不属于它」。这个问题想明白了，架构的可维护性会好很多。相关服务与流程可见 软件研发服务 与 常见问题。