1. 课程导论：为什么需要基于业务优先级的API限流？核心概念与课程目标
1.1 从“一刀切”到“精细化”：限流策略的演进
在微服务与AI模型API广泛部署的今天，流量洪峰是常态。传统的“一刀切”限流策略（如对所有请求统一设置QPS阈值）虽然简单，却带来了严重的业务副作用：
- 关键业务被误伤：支付、下单等高价值流量与日志收集、数据清洗等低优流量共享同一配额，一旦触发限流，核心交易可能被拒绝。
- 资源利用率低下：为了保障核心业务，往往设置较高的全局阈值，导致非核心流量在低峰期浪费算力，高峰期又挤占核心资源。
- 缺乏弹性与公平性：无法根据业务等级动态调整配额，导致付费客户与免费用户享受同等服务质量，商业价值无法体现。
基于业务优先级的API限流正是为了解决上述痛点而生。它允许系统根据请求的业务等级（如VIP、普通、免费）分配不同的流量配额与降级策略，实现“保核心、舍边缘”的精细化流量治理。
核心洞察： 限流不是目的，而是手段。基于优先级的限流确保在资源有限时，系统始终优先服务对业务价值最高的请求。
1.2 核心概念速览
在深入架构之前，我们需要统一以下关键术语的定义：
| 概念 | 定义 | 示例 |
|---|---|---|
| 业务优先级 | 根据业务价值或SLA等级对请求进行的分类标记 | P0（核心交易）、P1（用户查询）、P2（后台分析） |
| 配额池 | 为特定优先级分配的独立或共享的流量额度 | P0池：1000 QPS；P1池：500 QPS |
| 降级策略 | 当配额耗尽时，对不同优先级请求采取的不同处理方式 | P0请求排队等待，P2请求直接拒绝 |
| 优先级抢占 | 高优先级请求在资源紧张时，可借用或抢占低优先级配额 | P0池满时，可借用P2池的剩余配额 |
| 令牌桶/漏桶 | 经典的限流算法，在本课程中将被扩展为支持多优先级 | 每个优先级拥有独立的令牌桶 |
1.3 为什么需要优先级限流？—— 三大业务驱动力
- 保障核心收入与SLA：付费API或核心交易链路必须获得最高保障。优先级限流确保在流量突发时，付费用户的请求成功率远高于免费用户，避免收入损失。
- 提升资源利用率与成本控制：通过动态配额分配，允许低优先级任务在空闲时“填满”算力，在繁忙时被“挤走”，实现算力资源的“削峰填谷”，降低硬件成本。
- 实现多租户隔离与公平调度：在SaaS平台或模型市场中，不同租户（客户）购买不同等级的服务。优先级限流是实现租户级QoS（服务质量）隔离的基础技术。
思考： 如果你的AI模型API同时服务于内部实时推理和外部批量任务，哪种场景应该获得更高的优先级？为什么？
1.4 系统架构概览：优先级限流的核心位置
下图展示了基于业务优先级的限流模块在API网关中的典型位置。请求在进入后端模型服务之前，先经过优先级识别与限流决策。
1.5 课程目标与学习路径
通过本教程，你将掌握以下核心能力：
- 设计能力：能够设计支持多优先级的多级限流架构，包括配额池划分、优先级继承与抢占策略。
- 实现能力：基于主流限流算法（令牌桶、滑动窗口）实现优先级感知的限流中间件。
- 部署能力：在API网关（如Kong、Envoy）或应用层集成优先级限流逻辑。
- 调优能力：通过监控指标（如各优先级拒绝率、配额利用率）持续优化限流参数。
前置要求： 本课程假设你已熟悉基本的限流概念（令牌桶、漏桶、固定窗口）以及至少一种后端开发语言（Python/Go/Java）。如果你对基础限流算法尚不熟悉，建议先快速复习相关概念。