API 网关：统一入口的得与失
2026/8/24大约 2 分钟
亿级规模系统系列 · 阶段 1 · 接入层扩展 · 第 6/49 篇 · 🚧 占位待学
上一篇：《负载均衡：四层与七层、算法与副作用》
下一篇：《线程模型：从 BIO 到 NIO，百万连接的地基》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 1 · 单元 1.3
一、本文要解决的问题
鉴权、限流、日志、灰度……这些能力每个服务都写一遍？入口层收敛到网关是标准答案。但网关自己也会成为瓶颈与单点——它是整个系统最不能挂的组件，怎么保证它挂不了？
二、知识点清单
- 网关的职责清单：路由、鉴权、限流、灰度、日志、协议转换——以及不该放进去的（业务逻辑）
- Spring Cloud Gateway（Filter 链 / 响应式）与 APISIX（etcd + 插件）的模型对比与选型
- 网关集群化：网关自己也要负载均衡（LVS/DNS/keepalived），配置中心热更新
- 网关层限流 vs 服务层限流的分工（为阶段 5 埋线）
- 网关的性能特征：响应式为什么适合 IO 密集的转发场景
三、动手实验（学习时必须真跑）
- 起 Spring Cloud Gateway（或 Docker 起 APISIX），把示例系统的两条路由收敛进来
- 配置一个限流插件（如 100 QPS），wrk 压测验证 429 返回的占比
- 对网关单独做压测，测出它自身的转发 QPS 上限，理解「网关也会成为瓶颈」
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。