API网关概述：概念、作用与主流产品
说实话，做了这么多年后端，我越来越觉得API网关是个躲不开的东西。不管你是做微服务、单体拆解，还是搞前后端分离，只要系统一复杂，流量一上来，API网关就会自然出现在你的架构里。它不是锦上添花，而是刚需。这一章我们就来把它彻底聊透。
1.1 什么是API网关
说白了，API网关就是一个"守门员"。它站在客户端和服务端之间，是所有API流量的统一入口。你想想看，如果没有它，客户端要直接面对一堆微服务，地址散落、认证混乱、限流没法做……那画面太美我不敢看。
我个人习惯把API网关理解成一个"智能路由器"——它不止转发请求，还能在转发前后做一堆有用的事。比如你发一个HTTP请求到网关，网关会先检查你有没有权限，再看要不要限流，然后把这个请求路由到正确的后端服务，最后还能把响应格式统一一下再返回给你。
我在项目中遇到过最典型的一个场景：老系统用的是XML over HTTP，新服务全改成JSON over gRPC。中间如果不用网关做协议转换，客户端就得同时维护两套调用方式，那维护成本直接翻倍。网关在这里就像个翻译官，帮两边省了大麻烦。
1.2 API网关的核心作用
API网关到底能干什么？我列了7个最常用的能力，也是你在选型时最该关注的。
| 能力 | 说明 | 典型场景 |
|---|---|---|
| 认证与授权 | 统一校验、OAuth2、JWT等 | 所有请求先在网关过一遍身份认证 |
| 流量控制 | 限流、熔断、降级 | 双11大促时按用户等级限流 |
| 请求路由 | 根据URL/Header转发到不同后端 | /api/v1/ → 订单服务，/api/v2/ → 新订单服务 |
| 协议转换 | HTTP ↔ gRPC、JSON ↔ XML | 旧客户端用XML，新客户端用JSON |
| 日志与监控 | 记录请求日志、采集Metrics | 统一做调用链分析和告警 |
| 跨域管理 | 统一处理CORS策略 | 前后端分离下的跨域配置集中化 |
| 安全防护 | SQL注入、XSS、CSRF等攻击拦截 | 在网关层做基础安全过滤 |
你可能会问，这些能力难道不能在每个服务里自己实现吗？当然可以。但你想想看，如果有20个微服务，每个服务都要写一遍JWT校验、限流逻辑、CORS配置……那不仅重复劳动，而且极易出现"这个服务忘了加限流"之类的隐患。网关把这些横切关注点统一收口，后端服务只专注业务逻辑就行了。
1.3 主流API网关产品
市面上API网关产品不少，我挑5个最有代表性的给你盘一盘。每个我都实际用过或深度调研过，踩过坑，也有偏爱。
| 产品 | 开源/商业 | 编程语言 | 核心特点 | 适合场景 |
|---|---|---|---|---|
| Kong | 开源 + 商业版 | Lua / Go | 插件生态丰富，性能强 | 微服务架构，需大量自定义插件 |
| Nginx Plus / OpenResty | 开源 + 商业版 | C / Lua | 稳定、高性能、配置灵活 | 已有Nginx技术栈，需轻量网关 |
| AWS API Gateway | 商业 | 托管服务 | 无缝集成AWS生态，Serverless友好 | 全栈AWS用户 |
| Apigee (Google) | 商业 | 托管服务 | API管理、分析、开发者门户 | 企业级API管理平台 |
| Traefik | 开源 | Go | 云原生，自动发现服务 | Kubernetes环境，容器化部署 |
拿我自己来说，我最常用的组合是 Kong + 自定义Lua插件。之前在做一个金融项目时，需要在网关层做字段级别的加密，Kong的插件机制让我们能在不修改后端代码的情况下把加密逻辑插进去，那感觉确实很爽。
1.4 API网关知识体系
为了帮你快速建立全局视图，我把这一章的核心内容整理成了一张知识体系图。你可以把它当作后续学习的导航地图。