在360的服务端系统中，如何设计一个高并发的API网关？请描述其核心组件和负载均衡策略，并说明如何处理安全防护（如DDoS、SQL注入）。
360服务端开发工程师-Golang难度：中等
答案
1) 【一句话结论】设计360高并发API网关的核心是构建分层架构（Nginx L7反向代理+Golang微服务），通过服务发现动态管理后端服务实例，负载均衡采用加权轮询并配合健康检查，结合黑洞路由/流量清洗防DDoS，参数化查询+数据库审计防SQL注入，实现高可用、可扩展的安全请求分发。
2) 【原理/概念讲解】API网关作为系统入口，需处理请求路由、协议转换、安全校验与流量控制。核心组件及原理：
- 服务发现：如Consul或Zookeeper，后端服务实例主动注册位置，网关动态获取实例列表。当实例新增/故障时，负载均衡器自动更新，提升扩展性（类比“服务目录”，服务实例主动上报位置，网关动态获取）。
- 健康检查：定期（如每秒1次）向后端服务发送HTTP GET请求（/healthcheck），要求响应200 OK（超时或错误则标记为不健康，后续请求不发送，故障实例后续重新检查）。
- 负载均衡：根据算法分发请求，如加权轮询（性能高的实例权重高）、最少连接（优化连接资源）。
- 安全防护：
- DDoS：黑洞路由（异常流量引导至黑洞IP）、流量清洗中心（过滤高频/异常包）。
- SQL注入：Golang通过database/sql包的Prepare语句（预编译SQL，参数化查询），输入白名单过滤（仅允许数字/字母，或正则校验），结合数据库审计（记录SQL语句，异常时告警）。
3) 【对比与适用场景】
| 负载均衡策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 加权轮询 | 根据后端服务权重（CPU/内存利用率）分发请求 | 考虑服务能力，性能高的实例承担更多请求 | 后端性能差异大（如不同版本服务） | 需动态调整权重（如通过监控指标） |
| 最少连接 | 选择当前连接数最少的服务实例 | 优化连接资源，减少长连接阻塞 | 连接密集场景（如WebSocket长连接） | 需维护连接状态，复杂度较高 |
| IP哈希 | 根据客户端IP哈希结果分配服务 | 长期绑定，保持会话一致性 | 会话保持（如用户登录后固定服务） | 客户端IP变化导致会话断开，需配合会话同步 |
4) 【示例】
Nginx配置（加权轮询+健康检查）：
http {
upstream backend_services {
server 192.168.1.1:8080 weight=3 max_fails=3 fail_timeout=10s;
server 192.168.1.2:8080 weight=2 max_fails=3 fail_timeout=10s;
server 192.168.1.3:8080 weight=1 max_fails=3 fail_timeout=10s;
}
server {
listen 443 ssl http2;
server_name api.360.com;
location /healthcheck {
return 200;
}
location / {
proxy_pass http://backend_services;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
limit_rate 100k; # 限速防DDoS
auth_request /auth; # 认证
}
}
}
Golang服务发现（Consul示例）：
// 伪代码：服务发现客户端
client, _ := consulapi.NewClient(consulapi.DefaultConfig())
service := client.Health().Service("user-service", "", nil)
for _, entry := range service {
backendAddr := fmt.Sprintf("%s:%d", entry.Service.Address, entry.Service.Port)
// 添加到负载均衡器
lb.Add(backendAddr, entry.Service.ServiceName)
}
5) 【面试口播版答案】（约90秒）
面试官您好，设计360高并发API网关时，核心是构建分层架构，以Nginx作为L7反向代理处理协议转换（如HTTP/2、WebSocket）和路由，Golang微服务处理业务逻辑。首先，通过Consul服务发现动态管理后端服务实例，当实例新增或故障时自动更新负载均衡器，提升扩展性。负载均衡采用加权轮询，根据后端服务CPU/内存利用率动态调整权重，比如性能高的实例权重更高。健康检查每秒向服务发送/healthcheck请求，要求200 OK，超时或错误则标记为不健康，后续请求不发送。安全防护方面，DDoS通过黑洞路由将异常流量引导至黑洞IP，流量清洗中心过滤高频或异常包；SQL注入通过Golang的Prepare语句实现参数化查询，输入白名单过滤（仅允许数字/字母），并配合数据库审计记录SQL语句，异常时告警。整体架构解耦前端请求与后端服务，实现高并发下的安全、可扩展请求分发。
6) 【追问清单】
- 问：服务发现如何处理故障转移？比如后端服务实例宕机后，如何快速恢复？
回答要点：健康检查标记故障实例后，后续请求不发送，故障实例后续重新检查（如每秒1次），若恢复则重新加入负载均衡器。 - 问：负载均衡算法如何动态调整？比如加权轮询的权重如何根据实时指标更新？
回答要点：通过监控后端服务的CPU、内存、QPS等指标，动态计算权重（如高负载实例权重降低，低负载实例权重提高），实现负载均衡的动态优化。 - 问：安全防护中，如何应对0-day新型SQL注入攻击？
回答要点：结合WAF的规则更新（如实时更新SQL注入特征库），以及输入验证的动态白名单（如正则校验，允许的字符范围），同时监控异常SQL行为，触发告警或阻断。 - 问：API网关的扩展性如何？比如增加后端服务实例时，是否需要重启网关？
回答要点：负载均衡器支持动态添加后端节点，权重自动调整，无需重启网关，实现水平扩展，提升系统伸缩性。
7) 【常见坑/雷区】
- 坑1：服务发现未考虑故障转移，导致故障实例未被及时剔除，影响可用性。
- 坑2：健康检查频率设置不当，如过低导致故障实例未被及时检测，过高增加网络开销。
- 坑3：安全防护措施单一，仅依赖API网关，未与后端服务协同，导致后端仍受攻击。
- 坑4：负载均衡算法选择不当，如简单轮询导致后端服务负载不均，性能下降。
- 坑5：限流策略设置不合理，如过严导致正常请求被拒绝，过松无法防攻击。