API网关是什么

API 网关是系统架构里常见的组件，通俗说就是系统的"统一前台"。 这篇讲清是什么、解决什么、要不要用。

API网关是什么

在微服务架构里，后端可能拆分成几十个甚至上百个服务。如果每个服务都直接对外提供接口，客户端要记住每个服务的地址、每个服务都要自己处理鉴权限流——这会非常混乱。API 网关就是解决这个问题的。

所有外部请求先到网关，网关统一处理后转发到后端：

客户端 → API网关（鉴权/限流/监控）→ 后端服务

类比公司前台：访客（客户端请求）先到前台登记（鉴权/限流），前台再引导到对应部门（转发到后端服务）。访客不用记每个部门在哪，部门也不用自己设前台。

网关做什么

API 网关的核心职责是把各服务都要做的"公共事"统一收口。

1. 统一入口

• 所有请求统一入口：客户端只需要知道网关地址，不用记每个服务的地址。
• 后端服务不直接暴露：后端服务可以部署在内网，只把网关暴露在外网，安全风险降低。

2. 鉴权

• 统一身份验证：所有请求的鉴权在网关统一做，比如验证 token、校验权限。
• 后端不用各自鉴权：后端服务可以信任网关已通过的请求，专注业务逻辑，不用重复写鉴权代码。

3. 限流

• 防止过载和恶意请求：网关按规则限制每个客户端、每个接口的调用频率，防止恶意刷接口或突发流量压垮后端。
• 保护后端：流量超出后端承受能力时，网关可以拒绝或排队，保护后端不被打挂。

4. 路由转发

• 请求转发到对应服务：网关根据请求路径、头部等信息，把请求转发到正确的后端服务。
• 负载均衡：一个服务有多个实例时，网关把请求分发到不同实例，提升整体处理能力。

5. 监控日志

• 统一监控和日志：所有请求的调用量、响应时间、错误率在网关统一采集，不用每个服务各自做。
• 可观测性：网关的监控数据是排查问题、优化性能的重要依据。

6. 协议转换

• 不同协议转换：客户端用 HTTP，后端用 gRPC 或 Dubbo，网关可以做协议转换，让前后端用各自适合的协议。

为什么用网关

不用网关的情况下，每个服务都要自己实现鉴权、限流、监控、日志，代码重复、维护成本高，还容易出不一致的问题。网关把这些公共能力收口，后端服务可以更专注业务。

用 vs 不用

网关不是所有系统都需要，要看规模和复杂度。

• 服务少、简单：比如一个单体应用就两三个接口，上不上网关差别不大，反而增加复杂度。
• 微服务、服务多：服务一多，没有网关统一管理会很痛苦，网关价值就体现出来了。
• 开放 API：对外提供 API 的场景，网关几乎是必需品——鉴权、限流、文档、监控都要在网关层做。
• 多端接入：APP、小程序、Web、第三方多端接入，网关统一入口能简化接入复杂度。

别踩的坑

• 简单系统上重网关：就两三个服务的简单系统，非要上 Kong 或 APISIX 这种重网关，属于过度设计，增加运维负担。
• 自己从头开发：网关是成熟领域，有很多开源和商业产品（Kong、APISIX、云厂商网关），自己从头开发既慢又容易出问题。
• 网关成单点：网关挂了整个系统就访问不了，必须做高可用部署（多实例、负载均衡）。
• 鉴权还散在各服务：上了网关但鉴权还在各服务自己做，等于没用上网关的核心价值。

成本参考

主流网关产品（Kong、APISIX）开源免费，主要成本是部署运维。云厂商的网关服务（阿里云、腾讯云、AWS）按量计费，用量不大的话成本不高。自己定制集成成本中等，适合有特殊需求的场景。

怎么选

1. 评估服务数量和复杂度：服务多、架构复杂才考虑网关。
2. 简单系统不一定需要：两三个服务的单体应用不用上网关。
3. 微服务/开放API用网关：服务多、对外开放的场景，网关价值大。
4. 优先成熟产品：用 Kong、APISIX、云厂商网关，不要自己从头开发。

广州市汉诺雷斯（HNREIS）帮企业做系统架构设计，含API网关选型和集成。把你的系统需求告诉我们，我们给出架构建议。