云原生微服务应用的 API 网关介绍

type

status

date

slug

summary

📝 前言

在上一篇文章《云原生微服务应用的注册/配置中心》中，我们讨论了微服务在云原生时代的服务发现与配置管理。

这一篇，我们继续聊聊微服务体系中的另一个关键组件 —— API 网关（API Gateway）。

随着服务拆分越来越细，一个系统往往包含数十甚至上百个微服务。

此时，API 网关就成为连接前端与后端、外部与内部的核心中枢。

在微服务架构中，一个系统可能由数十甚至上百个服务组成。如果客户端（如 Web、移动端）直接与这些服务通信，将面临以下问题：

于是，API 网关诞生了。它是微服务世界的“门面” —— 所有外部请求先经过网关，再由网关转发到具体的服务。

API 网关可以理解为系统的“智能反向代理”，常见功能包括：

功能类别	典型功能	说明
路由转发	根据路径、域名、Header 等规则将请求转发到对应服务	核心功能
身份认证与鉴权	支持 JWT、OAuth2、API Key 等多种认证方式	可与统一认证系统（如 Dex、Keycloak）集成
流量控制	限流（Limit）、熔断（Circuit Breaker）、重试、超时控制	防止下游服务被过载
协议转换	REST ↔ gRPC、HTTP ↔ WebSocket 等	解决协议兼容问题
日志与监控	请求日志、访问统计、Tracing 链路追踪	与 Prometheus、Grafana、Jaeger 对接
插件扩展	插件化架构支持动态加载	方便根据业务扩展功能（如灰度、A/B 测试）

很多人会疑惑：Kubernetes 中的 Ingress 和 Gateway 不是也能做流量转发吗？那它们与 API 网关有什么不同？

简单来说：

用户请求的大致流程如下：

在微服务体系中，注册中心与 API 网关通常是配合使用的：

在云原生环境下，像 APISIX + etcd + Kubernetes 的组合，就能实现注册、发现与流量治理的一体化方案。

在 Kubernetes 环境中，API 网关的形态已经从传统的反向代理演化为云原生基础设施的一部分。以 APISIX 为例，它既可以作为独立网关部署，也能以 Ingress Controller 的形式与 Kubernetes 深度集成，通过 CRD 声明式管理路由与插件。例如：

在这种方式下，开发者只需提交 YAML 文件，APISIX 就能自动生成对应路由、绑定插件、应用限流或鉴权策略。

如果不依赖 Kubernetes，APISIX 也支持通过自带的 Dashboard 或 Admin API 进行管理。

通过 Admin API 创建路由：

apisix 不仅包含了大量的认证、限流、监控日志等插件，还支持灵活的自定义扩展插件，是API网关的一个很好的选择。

最后总结一下微服务架构的核心在于“分而治之”，而能让这些“分”重新协调运作的正是以下关键组件：

模块	职责	示例
注册中心	服务注册与发现	Eureka / Nacos / Kubernetes Service
配置中心	统一配置与动态下发	Nacos / ConfigMap
API 网关	请求路由与流量治理	APISIX / Kong / Traefik