服务端程序存在的意义就是处理流量。没有流量调度的服务端，就像没有红绿灯的十字路口——请求无序涌入，后端无差别崩溃。
许式伟强调，流量调度的本质是对不确定需求的确定性管理：当千万级请求同时到达时，如何让每一份计算资源都被高效利用？如何让每一个用户都获得合理的响应？这不是简单的"分发"，而是一个涉及路由策略、负载均衡、限流熔断、灰度发布的系统性工程。
流量从客户端到服务端，依次经过四个层次的调度：
负载均衡的核心问题是：将请求分配给哪个后端实例？ 不同的算法适用于不同的场景。
| 算法 | 原理 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| 轮询（Round Robin） | 依次分配 | 实现简单，绝对公平 | 不考虑后端差异 | 后端实例同构 |
| 加权轮询 | 按权重比例分配 | 支持异构实例 | 权重配置静态 | 实例性能不均 |
| 最少连接 | 选当前连接数最少的 | 动态感知负载 | 计算开销略高 | 长连接/请求耗时不均 |
| 一致性哈希 | 对请求特征哈希映射 | 会话保持，扩缩容影响小 | 热点倾斜风险 | 需要会话亲和 |
| 随机 | 随机选择 | 零状态，实现极简 | 大数定律才趋均衡 | 极简场景/内部调用 |
一致性哈希是服务端流量调度中最精巧的算法之一，它解决了**"扩缩容时尽量少迁移请求"**的问题。
关键特性：
Trade-off：一致性哈希以 O(log N) 的查找复杂度换取了最小化的请求迁移，但在极端热点场景下仍需结合热点打散策略。
限流（Rate Limiting）：
熔断（Circuit Breaking）：
降级（Degradation）：
超时（Timeout）：
| 维度 | 四层（L4） | 七层（L7） |
|---|---|---|
| 工作层 | 传输层（TCP/UDP） | 应用层（HTTP/gRPC） |
| 路由依据 | IP + 端口 | URL、Header、Cookie 等 |
| 性能 | 高（内核态转发） | 相对低（用户态解析） |
| 灵活性 | 低 | 高（可做内容路由） |
| 典型实现 | LVS、DPVS | Nginx、Envoy、HAProxy |
许式伟的观点是：四层做入口分流，七层做业务路由，两者配合使用，各取所长。
| Trade-off | 一端 | 另一端 | 决策依据 |
|---|---|---|---|
| 公平性 vs 亲和性 | 轮询/随机 | 一致性哈希 | 是否需要会话保持 |
| 性能 vs 灵活性 | 四层 LB | 七层 LB | 简单转发 vs 内容路由 |
| 保护 vs 可用 | 严格限流 | 弹性放行 | 系统容量余量 |
| 一致性 vs 延迟 | 同步校验 | 异步放行 | 风控等级 |
| 全局 vs 局部 | 集中式调度 | 分布式自治 | 规模与复杂度 |
只设一个全局限流阈值，而不区分核心与非核心接口，导致低频核心接口被高频非核心接口挤占资源。
正确做法：按接口重要性分级限流——核心接口独立限流池，非核心接口共享限流池。
3 个物理节点直接映射哈希环，数据倾斜严重，某个节点可能承担 50%+ 的流量。
正确做法：每个物理节点映射 100-200 个虚拟节点，使流量分布趋近均匀。
灰度发布是流量调度在发布场景的应用：通过精确控制流量比例，实现从 1% → 10% → 50% → 100% 的渐进式上线，将故障影响范围控制在最小。
相关章节：34丨服务端开发的宏观视角 建立了三层模型框架；36丨业务状态与存储中间件 将深入流量到达后端后的状态管理