📚 课程目录第3章 API网关核心概念与性能指标

第3章：API网关核心概念与性能指标

本章深入解析API网关的四大核心性能指标：QPS（每秒查询数）、延迟（Latency）、吞吐量（Throughput）、连接数（Connections）。理解每个指标的定义、计算方式及相互关系，是进行性能调优的基础。面试中，面试官常通过组合提问考察你对指标本质的理解和调优逻辑。

核心指标速查表

指标	定义	常用计算	典型单位	调优方向
QPS	每秒请求处理数	总请求数 / 时间（秒）	req/s	限流、扩容、缓存
延迟	请求到响应的时间	平均/TP99/TP99.9	ms	减少串行、缓存、连接池
吞吐量	单位时间处理的数据量	处理字节数 / 时间	bps / MB/s	压缩、带宽提升、减少包体
连接数	同时维持的连接数	活跃连接 + 等待连接	个	连接复用、池化、超时设置

图1：API网关性能指标回答框架——面试时先定位指标定义，再分析关联关系，最后给出调优措施。

面试问题：请解释QPS和延迟之间的关系，它们如何影响API网关的整体性能？

📌 考察点

是否理解QPS与延迟的反比关系
是否能区分“吞吐量”与“延迟”的权衡
是否知道导致延迟升高的常见原因（如排队、锁竞争）

📐 回答框架

1. 定义：QPS是单位时间的请求数，延迟是单个请求的响应时间。
2. 关联：在小流量时延迟恒定，当QPS接近瓶颈时，延迟会急剧增加（排队效应）。
3. 调优思路：缓存减少延迟 → 释放处理能力 → 提升QPS；或扩容增加处理单元 → 降低排队延迟。

🔍 示例回答

QPS与延迟存在“非线性反比关系”。当系统利用率超过80%时，延迟会呈指数增长。我们曾通过增加二级缓存将TP99延迟从200ms降到50ms，同时QPS提升了约40%。关键是在延迟与QPS之间找到性价比平衡点。

❓ 可能追问

为什么延迟在QPS高时会突增？请分析排队的数学模型。
如果延迟很低但QPS上不去，可能是什么原因？
你如何设置网关的限流阈值？参考QPS还是延迟？

⚠️ 避坑提醒：切忌只强调QPS而忽视延迟，面试官会追问“如果QPS很高但延迟也很高，算不算好？”——必须说明延迟是用户体验的关键指标，两者需要联合评估。

面试问题：如何评估API网关的吞吐量？你会用什么工具和方法来调优？

📌 考察点

吞吐量的计算方式（字节/时间）
是否了解吞吐量与QPS、包体大小的关系
实际调优手段（压缩、协议优化、传输层调优）

📐 回答框架

1. 评估指标：吞吐量 = 总传输字节 / 时间，常用单位 Mbps 或 MB/s。
2. 评估工具：wrk、JMeter、locust 加 - 跟踪吞吐量。
3. 调优手段：启用 gzip 压缩、使用 HTTP/2 多路复用、优化客户端与网关间的连接复用、调整内核 TCP 缓冲区。

🔍 示例回答

我们使用 wrk 进行压测，发现响应体平均约 50KB 时吞吐量仅 200MB/s。通过开启 Brotli 压缩和调整 TCP 拥塞控制算法为 BBR，吞吐量提升至 800MB/s。核心是减少实际传输字节和优化链路拥塞。

❓ 可能追问

压缩会带来额外的延迟，你怎么平衡？
吞吐量瓶颈在网关本身还是网络链路？如何判断？
如果客户端带宽有限，调优网关吞吐量是否有意义？

⚠️ 避坑提醒：不要只谈“提升带宽”这种笼统方案。具体到压缩算法、连接复用策略、内核参数调整才是给面试官的加分项。

面试问题：连接数过高会导致哪些问题？你在实际项目中如何控制API网关的连接数？

📌 考察点

是否理解连接数对内存、CPU、文件描述符的影响
对连接池、连接复用的掌握程度
能否讲清楚连接数与QPS、延迟的三角关系

📐 回答框架

1. 问题：高连接数 → 内存占用增大、文件描述符耗尽、上下文切换开销暴增 → 延迟升高、QPS下降。
2. 控制策略：a. 设置最大连接数限制（基于机器资源）。b. 启用连接池（长连接复用）。c. 调整 keep‑alive 超时时间。d. 使用限流降级保护后端。

🔍 示例回答

曾遇到网关连接数峰值达 2 万，内存占用超过 4GB 导致 GC 加剧。我们做了三件事：连接池上限设为 2000、keep‑alive 从 60s 降到 10s、客户端改用 HTTP/2 多路复用。最终连接数降到 2000 左右，延迟降低 30%。

❓ 可能追问

如果连接数限制太低导致正常请求被拒，你怎么解决？
长连接与短连接各自适用场景是什么？
连接数过高时你是优先扩容还是优化配置？依据是什么？

⚠️ 避坑提醒：不要只谈理论概念，面试官希望听到具体数字和决策逻辑。例如“我们曾将 maxConnections 从 5000 降为 2000，配合连接池复用，效果显著”。

📂 项目案例模板

项目名称	XX电商大促API网关性能调优
业务背景	大促期间流量峰值达平时 10 倍，用户反馈页面加载缓慢，后端服务频繁超时。
规模指标	峰值 QPS 10 万，平均延迟 500ms（TP99 2s），连接数 1.5 万，入口带宽 2Gbps
技术栈	Kong（网关）、Nginx + Lua、Redis 缓存、Prometheus + Grafana、Kubernetes
核心难点	现有网关节点资源不足；延迟抖动导致上游熔断；连接数快速上涨造成 OOM 风险
面试高频追问	为什么平均延迟 500ms 但 TP99 是 2s？说明什么问题？你如何确定限流阈值是基于 QPS 还是基于连接数？调优后效果如何衡量？用了哪些指标做对比？如果后端无法扩容，你怎么在网关层做降级？
可迁移回答话术	“我们采用‘先削峰后填谷’的策略：前端限流 + 后端连接池复用 + 缓存热点数据。具体做了三个动作：①将长连接超时从 60s 降到 15s，连接数降低 40%；②对商品详情接口增加本地缓存，TP99 从 2s 降到 150ms；③设置基于 QPS 的滑动窗口限流，拒绝超量请求并返回友好提示。最终在相同资源下 QPS 提升 3 倍，延迟下降 80%。”