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

📝 前言

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

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

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

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

🧭 为什么需要 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 网关 有什么不同？

简单来说：

  • Ingress / Gateway：属于“流量层”网关，主要处理 HTTP 路由、TCP/UDP 转发等基础流量控制。
  • API 网关：属于“应用层”网关，除了流量控制，还具备 认证、限流、日志、监控、插件扩展 等功能，更关注服务治理与API管理。

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

🚀 与微服务注册中心的关系

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

  • 注册中心：负责告诉网关有哪些服务、各自的地址是什么；
  • API 网关：根据注册信息将请求路由到正确的服务实例，并在中间处理流量治理。

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

☁️ 云原生下的 API 网关实践

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: ncalendar-route
spec:
  http:
  - name: ncalendar
    match:
      hosts:
      - ncalendar.lusyoe.com
      paths:
      - /ncalendar/*
    backend:
      serviceName: ncalendar-service
      servicePort: 8080

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

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

通过 Admin API 创建路由：

1
2
3
4
5
6
7
8
9
10
11
12
13
PUT http://127.0.0.1:9180/apisix/admin/routes/ncalendar-route

{
  "uri": "/*",
  "name": "ncalendar",
  "host": "ncalendar.lusyoe.com",
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "ncalendar-service:8080": 1
    }
  }
}

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

✅ 总结

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

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

通过这三者的协作，系统才能实现 动态化、可观察、安全与高可用，真正释放微服务的价值。