这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
策略、健康检查与效果验证
负载均衡策略
策略 1：轮询（Round Robin）
设计流程
策略 1：轮询（Round Robin）：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：确认请求入口、上游实例和本次转发的选择依据
- 步骤 3：根据延迟、连接数和健康状态调整转发目标
- 步骤 4：返回上游响应，并记录实例、延迟和错误信息
关注点：实例健康、转发策略、故障摘除和扩容验证。
请求分布：
请求 1 → Server 1
请求 2 → Server 2
请求 3 → Server 3
请求 4 → Server 4
请求 5 → Server 1
...策略 2：最少连接（Least Connections）
设计流程
策略 2：最少连接（Least Connections）：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：选择负载均衡策略
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
优势：
- 将请求分配给当前连接数最少的服务器
- 适合处理时间差异大的场景
策略 3：IP 哈希（IP Hash）
设计流程
策略 3：IP 哈希（IP Hash）：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：选择负载均衡策略
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
优势：
- 同一个 IP 的请求总是分配到同一台服务器
- 适合有状态的服务
- 问题：可能导致负载不均
策略 4：加权轮询（Weighted Round Robin）
设计流程
策略 4：加权轮询（Weighted Round Robin）：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：选择负载均衡策略
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
请求分布：
请求 1 → Server 1
请求 2 → Server 1
请求 3 → Server 1
请求 4 → Server 2
请求 5 → Server 2
请求 6 → Server 3
请求 7 → Server 3
请求 8 → Server 4
...健康检查
Nginx 被动健康检查
设计流程
Nginx 被动健康检查：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：发现故障并自动摘除异常节点
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
参数说明：
max_fails=3：30 秒内失败 3 次，标记为不可用fail_timeout=30s：30 秒后重新尝试连接
主动健康检查（需要第三方模块）
设计流程
主动健康检查（需要第三方模块）：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：确认请求入口、上游实例和本次转发的选择依据
- 步骤 3：根据延迟、连接数和健康状态调整转发目标
- 步骤 4：返回上游响应，并记录实例、延迟和错误信息
关注点：实例健康、转发策略、故障摘除和扩容验证。
会话保持
如果需要会话保持（同一用户的请求总是分配到同一台服务器）：
设计流程
会话保持：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：选择负载均衡策略
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
或者使用 cookie：
设计流程
会话保持：流量配置
- 步骤 1：维护可用后端实例列表
- 步骤 2：把请求转发到健康实例
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
效果验证
上线后，我观察了一周：
性能提升
负载均衡后（4 台服务器）：
- 总 QPS：60
- 每台 QPS：15
- 响应时间：100ms
- 每台 CPU 使用率：40%
可用性提升
单机时代：
- 服务器故障 → 全站不可用
- 恢复时间：重启服务器（5-10 分钟）
负载均衡后：
- 1 台服务器故障 → 其他服务器继续服务
- 影响范围：25% 的用户（如果有 4 台服务器）
- 恢复时间：自动检测并恢复流量（30 秒）监控和告警
设计流程
监控和告警
- 步骤 1：检查健康状态并触发告警
- 步骤 2：采集健康状态并触发告警
- 步骤 3：确认请求入口、上游实例和本次转发的选择依据
- 步骤 4：根据延迟、连接数和健康状态调整转发目标
关注点：实例健康、转发策略、故障摘除和扩容验证。
练习
练习 1
现在有 4 台应用服务器，其中 1 台配置更高，另外 3 台配置相同。你会选择哪种负载均衡策略？上线后至少观察哪些指标？
参考答案 (3 个标签)
负载均衡 策略选择 上线验证
可以先选加权轮询。配置更高的服务器承担更多请求，其余服务器继续分担基础流量。
上线后重点看三类指标：
- 实例负载是否均衡：每台服务器的 QPS、CPU、内存、连接数是否符合权重预期。
- 用户体验是否变好：整体响应时间、P95/P99 延迟、错误率是否下降。
- 故障摘除是否有效：主动或被动健康检查能不能及时发现异常实例，摘除后流量是否自动转移。
如果高配服务器反而成为瓶颈，就要降低它的权重；如果业务请求耗时差异很大，可以再考虑最少连接策略。