1. API网关基础：什么是API网关、核心功能、常见产品对比
大家好，我是你们这门课的老朋友。今天咱们聊聊API网关。
说实话，我刚接触微服务那会儿，对API网关的理解特别肤浅。觉得不就是个反向代理嘛，加个路由转发就完事了。后来在项目中踩了不少坑，才慢慢摸清楚这东西到底有多重要。
嗯，咱们今天就把API网关的底裤扒干净。
1.1 什么是API网关？
API网关，说白了就是系统的「总入口」。所有客户端请求，不管是来自手机App、网页还是IoT设备，都得先经过它，再由它转发给后端的各个微服务。
你想想看，如果没有网关，客户端得知道每个微服务的具体地址。订单服务在192.168.1.10:8080，用户服务在192.168.1.11:8081……这维护起来得多痛苦？而且一旦服务地址变了，所有客户端都得跟着改。
API网关就是来解决这个问题的。它把后端服务「藏」起来，对外只暴露一个统一的入口。客户端只需要知道网关的地址就够了。
核心价值：API网关是微服务架构的「门面」，负责请求路由、协议转换、安全防护等横切关注点。
我在项目中遇到过最典型的场景：一个老系统要迁移到新架构，但客户端不能停。怎么办？在网关层做路由切换，灰度发布，慢慢把流量从旧系统导到新系统。整个过程对客户端完全透明。
1.2 核心功能
API网关的功能很多，但最核心的就三个：路由、限流、鉴权。其他的像日志、监控、协议转换，都是锦上添花。
1.2.1 路由
路由是网关最基础的功能。它根据请求的路径、方法、Header等信息，把请求转发到对应的后端服务。
举个例子：
# 路由配置示例（伪代码）
GET /api/users/* -> user-service:8080
GET /api/orders/* -> order-service:8081
POST /api/payments/* -> payment-service:8082我曾经接手过一个项目，路由配置写得一塌糊涂。一个请求能匹配到三个不同的路由规则，结果请求被随机转发，数据全乱了。嗯，这里要注意：路由规则的优先级一定要明确，通常精确匹配优先于通配符匹配。
1.2.2 限流
限流是为了防止系统被突发流量打垮。你想想看，双十一零点那会儿，流量瞬间暴涨几十倍。如果没有限流，后端服务直接雪崩，整个系统就挂了。
常见的限流算法有：
- 令牌桶：以固定速率往桶里放令牌，请求来了就拿令牌，拿不到就等或拒绝。适合允许突发流量的场景。
- 漏桶：请求先进桶，然后以固定速率流出。不管流量多猛，出口速度恒定。适合需要平滑流量的场景。
- 滑动窗口：把时间切成小段，统计每段内的请求数。比固定窗口更精确，能避免「临界突变」问题。
我的建议：生产环境中，我习惯用令牌桶+滑动窗口的组合。令牌桶应对突发，滑动窗口做精细化控制。单用令牌桶，容易被刷子钻空子。
1.2.3 鉴权
鉴权就是检查「你是谁，你有没有权限」。没有鉴权的网关，就像没锁的大门，谁都能进。
常见的鉴权方式：
- JWT（JSON Web Token）：客户端登录后拿到一个Token，每次请求带上它。网关验证Token的签名和有效期。无状态，适合分布式系统。
- OAuth2：更复杂的授权框架，支持第三方应用授权。比如你用微信登录某个App，背后就是OAuth2在跑。
- API Key：最简单的鉴权方式，给每个客户端分配一个Key。适合内部服务之间的调用。
我记得有一次，一个团队把JWT的密钥写死在代码里，还提交到了GitHub。结果被人扫到，直接伪造Token访问了所有接口。嗯，密钥管理一定要用专门的密钥管理服务，别图省事。
1.3 常见网关产品对比
市面上API网关产品很多，我挑三个最有代表性的：Kong、APISIX、AWS API Gateway。它们代表了三种不同的路线。
| 特性 | Kong | APISIX | AWS API Gateway |
|---|---|---|---|
| 开源/商业 | 开源+企业版 | 开源+商业版 | 商业（AWS托管） |
| 核心语言 | Lua（基于OpenResty） | Lua（基于OpenResty） | Java（AWS自研） |
| 性能 | 中等 | 高（号称是Kong的2-3倍） | 高（但受限于网络延迟） |
| 插件生态 | 丰富（官方+社区） | 丰富（官方插件多） | 有限（依赖AWS服务） |
| 部署方式 | 传统部署/K8s | 传统部署/K8s | 全托管，无需运维 |
| Serverless集成 | 需额外配置 | 原生支持 | 原生支持（Lambda） |
| 学习成本 | 中等 | 中等偏低 | 低（但绑定AWS） |
1.3.1 Kong
Kong是API网关里的老大哥，社区活跃，文档齐全。它基于OpenResty（Nginx+Lua），插件机制非常灵活。
我最早接触API网关就是用的Kong。那时候它还是0.x版本，功能没现在这么全，但胜在稳定。不过说实话，Kong的配置管理有点重，尤其是用声明式配置时，YAML文件能写到几百行。
避坑指南：我曾经在生产环境中遇到Kong的DB模式（使用PostgreSQL）在高并发下出现连接池耗尽的问题。后来切换到DB-less模式（声明式配置），问题才解决。如果你的流量很大，建议优先考虑DB-less模式。
1.3.2 APISIX
APISIX是后起之秀，也是基于OpenResty，但性能比Kong好不少。它的路由匹配用的是基数树（Radix Tree），比Kong的哈希表更高效。
我个人特别喜欢APISIX的一点是：它原生支持Serverless。你可以直接在路由规则里配置一个函数，不用启动任何后端服务。这个在咱们后面的课程里会详细讲。
APISIX的插件热加载也很方便。改完插件配置，不用重启网关，几秒钟就生效。Kong的话，改完插件得reload，这在生产环境里挺麻烦的。
1.3.3 AWS API Gateway
AWS API Gateway是全托管的服务，你不需要关心服务器、负载均衡这些东西。它和AWS Lambda的集成是天生的，点几下鼠标就能创建一个Serverless API。
但问题也很明显：绑定AWS。一旦用了，想迁走就难了。而且它的定价是按请求量和数据传输量收费的，流量大的时候成本不低。
我记得有个创业公司，初期用AWS API Gateway很爽，后来用户量上来了，每个月网关费用比服务器还贵。最后不得不迁移到自建网关，折腾了两个月。
我的选择建议：
- 如果你在AWS生态里，且团队运维能力弱 → 选AWS API Gateway
- 如果你需要高性能、灵活定制，且团队有运维能力 → 选APISIX
- 如果你需要成熟稳定、社区支持好 → 选Kong
1.4 小结
API网关不是银弹，但它确实是微服务架构里不可或缺的一环。路由、限流、鉴权这三个基本功，一定要吃透。
下一章，咱们会深入APISIX，手把手搭建一个生产级的API网关。到时候我会把我在项目中踩过的坑、总结的经验，全都抖出来。
嗯，今天就到这儿。有什么问题，咱们评论区见。