设计一个高并发的API网关，用于360安全产品的用户请求，需要支持限流、熔断、降级，并能够根据业务模块路由请求。请详细说明限流策略（如令牌桶/漏桶）、熔断的触发条件、降级逻辑，以及如何监控和调整这些参数。

1) 【一句话结论】
设计高并发API网关需以**限流（令牌桶控制突发流量）、熔断（故障时断开连接防故障扩散）、降级（熔断后的兜底操作）**为核心，结合服务注册与发现的动态路由（负载均衡），并通过实时监控指标（QPS、错误率、响应时间）动态调整参数，平衡系统性能与可用性，确保360安全产品用户请求的稳定。

2) 【原理/概念讲解】
老师口吻解释关键概念：

• 限流（Token Bucket）：控制请求速率，防止服务过载。桶有固定容量（如100个令牌），每秒生成固定速率的令牌（如100个/秒），请求来时消耗令牌，若桶空则拒绝（类比“城市限号”，每天发固定数量的“令牌”，超过则无法进入，允许一定突发流量，但总量有限）。采用滑动时间窗口优化：针对突发请求，1秒内统计令牌消耗，避免固定窗口的累积误差，更适应短时间流量波动。
• 熔断（Circuit Breaker）：服务降级机制，当下游服务故障时，上游服务自动断开连接，防止故障扩散。触发条件：下游服务错误率超过阈值（如5分钟内错误率>50%）、超时次数超过阈值（如5分钟内超时>20次）、响应时间超过阈值（如>2秒）。状态管理：包含“关闭（正常）、打开（故障）、半开（试错）”状态，半开状态下逐步恢复服务（如每秒允许1%的请求尝试，若成功则逐步增加比例，失败则继续关闭）。
• 降级（Fallback）：熔断触发后的具体操作，如返回缓存数据或默认提示。逻辑：当熔断器打开时，调用降级方法，避免用户等待或错误，保证核心功能可用。

3) 【对比与适用场景】

• 限流策略对比（令牌桶 vs 漏桶）
  | 策略 | 定义 | 特性 | 使用场景 | 注意点 | |---|---|---|---|---| | 令牌桶 | 桶有容量，每秒生成固定令牌，请求消耗令牌 | 允许一定突发流量，平滑流量 | 需要控制突发流量（如用户登录、支付） | 需预计算令牌生成速率，避免频繁计算 | | 漏桶 | 请求按速率流入桶，桶按固定速率流出 | 严格按速率处理请求，不允许突发 | 需要严格限制流量（如视频流、实时数据） | 可能导致请求积压，适合低延迟场景 |
• 熔断与降级对比
  | 特性 | 熔断 | 降级 | |---|---|---| | 定义 | 服务故障时自动断开连接，防止故障扩散 | 熔断触发后的具体操作（如返回默认数据） | | 触发条件 | 下游错误率/超时/响应时间超过阈值 | 熔断触发后执行 | | 目的 | 防止故障传播 | 提供可用性，避免用户等待或错误 |

4) 【示例】
伪代码展示流程：

request = 获取用户请求
# 1. 路由（服务注册与发现 + 负载均衡）
service = 路由器.route(request.path, request.module)  # 根据请求路径（如 /api/security/check）和业务模块（security）从服务注册中心（如Nacos/Eureka）获取服务列表，用轮询/加权轮询分配服务（如security-service）
# 2. 限流
isAllowed = 限流器.check(request)  # 令牌桶策略，滑动时间窗口计算当前时间令牌数量
if not isAllowed: return 429 Too Many Requests
# 3. 熔断
isCircuitOpen = 熔断器.isOpen()  # 检查状态
if isCircuitOpen: return 503 Service Unavailable
# 4. 降级（熔断时执行）
if isCircuitOpen:
    return 降级逻辑（如返回缓存的安全检查结果或默认提示）
else:
    result = service.checkSecurity(request)  # 调用下游服务
    return result
# 5. 监控
记录请求时间、状态、限流/熔断/降级事件，指标（QPS、错误率、响应时间）用于调整参数

5) 【面试口播版答案】
面试官您好，设计高并发API网关时，核心是通过限流（控制突发流量）、熔断（故障时断开连接防扩散）、降级（熔断后的兜底操作）结合动态路由（服务注册+负载均衡）和实时监控，确保360安全产品用户请求的稳定。限流采用令牌桶策略，桶容量100，每秒生成100令牌，请求来时消耗令牌，超过则返回429；熔断触发条件是下游错误率>50%或超时>20次，此时熔断器打开，直接返回503；降级逻辑是在熔断时返回缓存的安全检查结果。路由根据请求路径和业务模块（如安全、支付）动态分配服务；监控记录QPS、错误率等指标，动态调整限流速率（如QPS过高时降低令牌生成速率，系统空闲时提高速率）和熔断阈值（如错误率下降时逐步降低熔断阈值），确保系统在高并发下稳定。

6) 【追问清单】

• 问：限流参数（如令牌生成速率、桶容量）如何动态调整？
  回答要点：通过监控QPS和响应时间，当QPS超过阈值时降低令牌生成速率（如指数退避，初始速率0.9倍，失败后逐步降低），系统空闲时提高速率（如1.1倍），保持服务可用性。
• 问：熔断的阈值（如错误率、超时次数）如何设置？
  回答要点：基于历史数据，核心服务阈值更低（如错误率>50%触发），次要服务阈值更高（如错误率>70%触发），避免正常波动触发熔断，同时确保故障时及时响应。
• 问：降级逻辑如何设计，是否会影响用户体验？
  回答要点：降级时返回缓存的安全检查结果或默认提示（如“安全检查中，请稍后重试”），避免用户等待，同时记录降级事件，后续恢复服务时更新数据，不影响核心功能。
• 问：如何处理限流和熔断的冲突（如限流通过但熔断开放）？
  回答要点：优先执行熔断逻辑，因为熔断是更严重的故障（服务不可用），限流是流量控制，熔断后直接返回503，避免无效请求，确保系统资源不被浪费。

7) 【常见坑/雷区】

• 限流策略选择不当：用漏桶处理需要突发流量的场景（如用户登录），导致请求积压，影响用户体验。
• 熔断阈值设置不合理：阈值过高（正常波动触发熔断，如错误率50%但实际正常），或过低（故障未及时处理，如错误率45%就触发，但实际是临时波动），影响服务可用性。
• 降级逻辑覆盖不全：只降级部分功能（如非核心的安全检查），导致用户仍能访问核心功能，但非核心功能不可用，影响整体体验。
• 路由逻辑错误：导致请求路由到错误的服务（如安全请求路由到支付服务），引发错误或安全风险。
• 监控参数调整不及时：未根据实时数据调整限流和熔断参数，导致系统过载（如限流速率过高，导致用户请求被拒绝）或服务不可用（如熔断阈值过低，频繁触发熔断）。