聊聊API网关：它到底是什么？
好，咱们开始第一课。先问个问题：你手头要维护几十个微服务，每个服务都得做认证、限流、日志记录。你怎么办？每个服务写一遍？那肯定累死。
这时候，就需要一个「前门守卫」——API网关。说白了，它就是所有客户端请求的总入口。所有的流量先到网关，再由网关转发给后面的服务。
我几年前刚接触微服务架构时，第一反应也是「多此一举」。直到有一次线上故障，上游一个服务被刷爆，因为没做限流，直接拖垮了整个集群。嗯，从那以后，我认了。网关这东西，不是花架子。
API网关的核心作用
就我的经验来看，网关干的事情可以归纳为几个大头：
- 路由转发：根据请求路径，把流量分到不同的后端服务。比如
/user/**走用户服务，/order/**走订单服务。 - 认证授权：统一验证请求的合法性，比如校验 JWT 、。后端服务不用再重复写认证逻辑。
- 限流熔断：防止某段时间流量太大把系统打崩。我习惯用令牌桶算法做限流，简单有效。
- 日志与监控：所有请求都会经过网关，所以在这里做全量日志采集和指标上报，再合适不过。
一个小提醒：别把网关当全能工具。它只处理「横切关注点」，别把业务逻辑写进去。我曾经见过有人把数据聚合也塞进网关，结果网关变成了一个巨大的单体应用，维护成本暴增。
常见部署架构
部署方式不一样，效果天差地别。咱们来看看几种主流玩儿法。
| 架构模式 | 特点 | 适合场景 |
|---|---|---|
| 单节点模式 | 部署一台网关实例，所有流量走它 | 开发测试环境、低并发小项目 |
| 高可用模式（HA） | 部署多台网关，前置负载均衡器（比如 Nginx） | 生产环境，保障服务不中断 |
| API网关集群 | 多网关实例共享同一套配置中心，动态路由 | 中大型微服务架构，要求弹性伸缩 |
| Sidecar 模式 | 每个服务旁边挂一个轻量级代理，不集中部署 | 服务网格（Service Mesh）场景，如 Istio |
我个人比较偏向 HA 模式。你想想看，网关一旦挂了，所有服务都不可用。这是典型的「单点故障」——所以要搞多副本，还要做健康检查。
主流产品怎么选？
市面上的产品不少，我简单列几个常见的，给你一个参考：
- Kong：基于 OpenResty，性能好，插件生态丰富。我用它在生产环境撑过日均千万级请求。
- Tyk：开箱即用，管理界面做得很漂亮，适合团队里没有专职网关运维人员的情况。
- Apigee：Google 家的产品，功能最全，但收费不便宜。大企业用得比较多。
- AWS API Gateway：云原生，跟 Lambda、DynamoDB 这些服务集成很顺滑。适合全栈在 AWS 上跑的项目。
- Nginx Plus：老牌劲旅，稳定到你不信。不过配置灵活度没有专门的 API 网关高。
避坑指南：我曾经遇到一个团队，选了 Kong 但没做性能基准测试。上线后才发现，默认配置下 SSL 卸载和自定义插件消耗了太多 CPU，导致网关反而不是瓶颈，成了瓶颈。所以，产品选型一定要做压测。
一个经典的API网关部署逻辑图
下面这张图，是我自己平时画架构图时常用的逻辑结构。它展示了一个典型的 API 网关如何承接客户端请求，然后依次经过认证、限流、路由，最后到达后端服务。
一点思考：安全与效率的平衡
你想想看，网关加了一层，确实多了一次网络跳转，延迟肯定会增加。但换来的呢？是统一的安全管控、可观测性，以及后端服务的简化。这个取舍，值得。
我个人坚持一个原则：安全设计要前置，但不要过度设计。比如，刚开始做的时候，可以只做基本的路由和认证。等业务量上来，再补全限流、熔断、日志审计这些能力。
核心要点：API 网关不是银弹。它是微服务架构中的「基础设施」，不是业务组件。选型、部署、配置都要从实际规模和团队能力出发。