当检测请求量从10万/秒增加到100万/秒时，如何通过水平扩展（增加推理节点）和垂直扩展（升级硬件）来应对？请设计负载均衡策略（如Ribbon或Nginx），并说明如何监控系统性能（如使用Prometheus）。
答案
1) 【一句话结论】当检测请求量从10万/秒增至100万/秒时，核心策略是通过水平扩展（增加多组推理节点）与垂直扩展（升级单节点硬件）协同，以Nginx作为入口负载均衡，Ribbon/Consul实现服务间动态负载，结合Prometheus+Grafana全链路监控，同时优化模型推理效率以提升整体吞吐。
2) 【原理/概念讲解】同学们，首先得明确水平扩展和垂直扩展的区别。水平扩展（Horizontal Scaling）就是增加系统的节点数量，比如原来有1个推理服务器，现在增加到10个，每个服务器处理相同量的请求，这样总处理能力就提升了10倍。而垂直扩展（Vertical Scaling）则是升级单台服务器的硬件，比如把CPU从8核升级到16核，内存从32G升级到64G，提升单台服务器的性能。当请求量从10万/秒增加到100万/秒时，单纯靠垂直扩展可能成本高且有限，所以通常采用水平扩展为主，结合垂直扩展优化单节点性能。接下来是负载均衡策略，比如前端用Nginx作为入口负载均衡器，它支持四层（IP+端口）和七层（HTTP头）负载，能根据请求的来源、内容等做智能分发。然后服务间调用用Ribbon（Spring Cloud组件），Ribbon会维护一个服务列表，通过轮询、随机、加权等算法将请求分发到不同的推理节点，实现动态负载均衡。最后是监控系统，用Prometheus收集关键指标，比如每个推理节点的QPS（每秒请求数）、平均响应延迟、CPU使用率、内存使用率等，通过Grafana可视化展示，当指标超过阈值时触发告警，比如QPS超过100万/秒时，或者延迟超过200ms时，及时通知运维团队。
3) 【对比与适用场景】
| 对比项 | 水平扩展 | 垂直扩展 |
|---|---|---|
| 定义 | 增加系统节点数量 | 升级单台服务器的硬件 |
| 优势 | 弹性高，可扩展性强，成本相对低（初期） | 单节点性能提升明显，管理简单 |
| 劣势 | 跨节点数据同步复杂，网络延迟增加 | 成本高（高端硬件），性能提升有限 |
| 适用场景 | 大规模高并发场景（如电商双十一、短视频平台） | 单节点性能瓶颈明显，节点数量少 |
4) 【示例】
架构图描述：请求从客户端发起，首先到达Nginx负载均衡器，Nginx根据配置的轮询算法将请求转发到后端的一个推理节点。推理节点处理请求后返回结果给Nginx，Nginx再返回给客户端。同时，每个推理节点会向Prometheus发送指标数据，比如QPS=10000，延迟=150ms，CPU使用率=70%。Prometheus收集这些数据后，通过Grafana可视化展示，当QPS超过100000时，触发告警。
伪代码示例（Nginx配置）：
upstream inference_nodes {
server 192.168.1.10:8500;
server 192.168.1.11:8500;
server 192.168.1.12:8500;
# 轮询算法
}
server {
listen 80;
server_name inference.360.com;
location / {
proxy_pass http://inference_nodes;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# 会话保持（可选）
proxy_cookie_path / /;
}
}
5) 【面试口播版答案】
面试官您好，当检测请求量从10万/秒增加到100万/秒时，核心思路是通过水平扩展+垂直扩展结合，同时设计合理的负载均衡和监控系统。首先，水平扩展：增加推理节点数量，比如从10个节点增加到100个节点，每个节点处理1万/秒请求，总处理能力达到100万/秒。垂直扩展方面，升级单节点硬件，比如将CPU从8核升级到16核，内存从32G升级到64G，提升单节点处理能力。然后负载均衡策略：前端用Nginx作为入口负载均衡器，采用轮询算法分发请求到后端节点；服务间调用用Ribbon（Spring Cloud组件），结合Consul服务注册中心，实现动态负载均衡。最后监控系统：用Prometheus收集关键指标，比如QPS、延迟、CPU使用率，通过Grafana可视化，当指标超过阈值时触发告警，比如QPS超过100万/秒时，及时扩容或优化模型。
6) 【追问清单】
- Q1：如果水平扩展后，节点间数据同步有延迟，如何解决？
A：使用分布式缓存（如Redis）或消息队列（如Kafka）同步状态，或者采用无状态设计，减少数据同步需求。 - Q2：负载均衡算法选择轮询是否合理？有没有其他算法？
A：轮询适合请求无状态的场景，但如果有节点性能差异，可考虑加权轮询（性能好的节点分配更多请求），或者随机算法（避免热点节点）。 - Q3：垂直扩展的成本如何控制？
A：优先考虑水平扩展，垂直扩展作为补充，比如先增加节点，当节点利用率超过80%时，再考虑升级硬件。 - Q4：监控指标除了QPS和延迟，还需要关注哪些？
A：CPU使用率、内存使用率、模型推理时间、网络带宽等，全面评估系统性能。 - Q5：如果出现节点故障，负载均衡如何处理？
A：Nginx和Ribbon都有故障检测机制，当节点故障时，会自动从服务列表中移除，不再分发请求，保证系统可用性。
7) 【常见坑/雷区】
- 只说水平扩展而忽略垂直扩展，或者只说垂直扩展而忽略水平扩展，导致方案不完整。
- 负载均衡策略选错，比如用Ribbon做前端负载，或者Nginx做服务间调用，混淆两者定位。
- 监控指标不全面，只关注QPS，而忽略延迟、CPU等关键指标，无法全面评估系统性能。
- 没考虑模型优化，比如模型压缩、量化，提升单节点处理能力，减少扩展需求。
- 节点管理混乱，比如没有服务注册中心，节点列表手动维护，导致负载均衡失效。