高可用的度量：可用性 SLA
高可用（High Availability，HA）的本质是减少停机时间。行业用「几个9」来量化可用性目标：
| SLA | 年停机时间 | 月停机时间 | 典型系统 |
|---|---|---|---|
| 99%（2个9） | 87.6 小时 | 7.3 小时 | 内部工具 |
| 99.9%（3个9） | 8.76 小时 | 43.8 分钟 | 大多数 SaaS |
| 99.99%（4个9） | 52.6 分钟 | 4.4 分钟 | AWS、Stripe |
| 99.999%（5个9） | 5.26 分钟 | 26 秒 | 电信核心网络 |
⚠ SLA 是乘法问题
如果你的系统依赖两个各 99.9% 的服务，整体可用性是 99.9% × 99.9% = 99.8%。依赖链越长，整体可用性越低。这也是为什么要做熔断降级——保护整体不被局部拖垮。
DNS 负载均衡
最简单的负载均衡：让 DNS 返回多个 IP 地址，客户端随机选择一个连接。
DNS 轮询（Round Robin DNS）：
client$ nslookup api.example.com
Server: 8.8.8.8
Address: api.example.com
→ 1.2.3.4 (Server A)
→ 1.2.3.5 (Server B)
→ 1.2.3.6 (Server C)
客户端每次 DNS 查询可能得到不同顺序的 IP
TTL 期间内，客户端会缓存并一直使用同一 IP
优点：
+ 无需额外硬件/软件
+ 天然的地理分发（按地区返回最近 IP）
+ 实现简单，运维成本低
缺点：
- 无法做健康检查（不知道某个 IP 是否宕机）
- DNS 缓存（TTL）导致故障切换慢（几分钟到几小时）
- 无法感知服务器负载，无法智能调度
- 客户端行为不可控（有些客户端永远选第一个 IP）
L4 与 L7 负载均衡
负载均衡器工作在网络协议栈的不同层次，能力和开销各不相同：
OSI 模型与负载均衡层次：
Layer 7 │ Application │ HTTP/HTTPS/gRPC │ 能读取请求内容，按 URL/Header 路由
Layer 6 │ Presentation │ TLS/SSL │
Layer 5 │ Session │ │
Layer 4 │ Transport │ TCP/UDP │ 只看 IP + 端口，高性能
Layer 3 │ Network │ IP │
Layer 2 │ Data Link │ Ethernet │
Layer 1 │ Physical │ │
| 特性 | L4 负载均衡 | L7 负载均衡 |
|---|---|---|
| 工作层 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS） |
| 路由依据 | IP 地址 + 端口号 | URL 路径、HTTP Header、Cookie、请求内容 |
| 性能 | 极高（内核态处理） | 较高（用户态，但现代硬件影响不大） |
| SSL 终止 | 透传（不解密） | 可在 LB 处终止 SSL，节省后端开销 |
| 典型工具 | LVS、HAProxy（TCP 模式）、AWS NLB | Nginx、HAProxy（HTTP 模式）、AWS ALB、Envoy |
| 典型场景 | 数据库、游戏服务器、视频流 | Web 服务、API 网关、微服务路由 |
L7 负载均衡的强大路由能力
L7 负载均衡路由示例（Nginx 配置逻辑）：
请求 GET /api/users/123
│
└─▶ L7 LB 解析 HTTP 请求
├── 路径以 /api/ 开头 → 转发到 API Server 集群
├── 路径以 /static/ 开头 → 转发到静态资源服务器
├── 路径以 /ws/ 开头 → 转发到 WebSocket 服务器
└── Header 含 X-Beta: true → 转发到灰度服务器
灰度发布（Canary Deployment）：
┌─────────────────────────────────┐
│ L7 Load Balancer │
└──────┬────────────────┬─────────┘
│ 95% │ 5%
┌────▼────┐ ┌────▼────┐
│ Prod │ │ Canary │
│ v1.0 │ │ v2.0 │
└─────────┘ └─────────┘
负载均衡算法
轮询（Round Robin）
请求序列： R1 R2 R3 R4 R5 R6 R7 R8
分配到服务器： A B C A B C A B
简单平均分配，适合同质化服务器（配置相同）
问题：不考虑服务器当前负载和请求处理时间
加权轮询（Weighted Round Robin）
Server A：权重 3（高配，16核）
Server B：权重 2（中配，8核）
Server C：权重 1（低配，4核）
分配：A A A B B C A A A B B C ...
每6个请求：A处理3个，B处理2个，C处理1个
适合：服务器配置不同的混合集群
最少连接（Least Connections）
新请求到达时，选择当前活跃连接数最少的服务器：
Server A：当前 52 个活跃连接
Server B：当前 31 个活跃连接 ◀── 新请求分配到这里
Server C：当前 48 个活跃连接
适合：请求处理时间差异大的场景（如混合简单查询和复杂报表）
实现：LB 需要维护每台服务器的连接计数
IP 哈希（IP Hash）
Hash(client_ip) % server_count → 固定路由到某台服务器
1.2.3.4 → Hash → 0 → Server A
5.6.7.8 → Hash → 1 → Server B
9.0.1.2 → Hash → 2 → Server C
优点：同一客户端永远路由到同一服务器（实现软性粘性会话）
缺点：服务器增减时，哈希结果变化，大量用户被重新映射
改进：一致性哈希（Consistent Hashing）
只有 1/N 的请求在节点增减时受影响（见第5章）
健康检查（Health Check）
健康检查是负载均衡器的核心能力。通过定期探测后端服务器，自动剔除故障节点，并在恢复后自动加入。
主动健康检查（Active）
- LB 定期主动发送探测请求
- TCP：尝试建立连接，成功即健康
- HTTP：GET /health，检查状态码
- 可以检查应用逻辑（如 DB 连接是否正常）
- 延迟感知故障（探测间隔内无感知）
被动健康检查（Passive）
- 监控真实请求的响应
- 连续 N 次失败 → 标记为不健康
- 零额外探测开销
- 实际用户会承受一部分失败请求
- 通常与主动检查配合使用
健康检查与故障切换流程：
LB 每 10 秒探测一次各服务器
正常状态：
Server A ● 健康 Server B ● 健康 Server C ● 健康
流量分配：A:33% B:33% C:33%
Server B 故障（返回 500 或连接超时）：
检查 1 → 失败 (1/3)
检查 2 → 失败 (2/3)
检查 3 → 失败 (3/3) → 标记 B 为不健康，从池中移除
流量分配：A:50% C:50% （自动切换，约 30 秒内完成）
Server B 恢复：
检查 1 → 成功 (1/2)
检查 2 → 成功 (2/2) → 重新加入池
流量分配：A:33% B:33% C:33%
Nginx / HAProxy vs 云负载均衡
| 方案 | 代表产品 | 优势 | 劣势 |
|---|---|---|---|
| 软件 LB | Nginx、HAProxy、Envoy | 高度可定制、可编程、成本低 | 需要自己运维 LB，LB 本身也是单点 |
| 云托管 LB | AWS ALB/NLB、GCP GLB、阿里云 SLB | 全托管、自动扩缩、开箱即用的 HA | 成本较高、厂商锁定、定制化受限 |
| 硬件 LB | F5 BIG-IP、Citrix ADC | 极致性能、硬件加速 SSL | 价格昂贵（数十万）、扩展困难 |
Anycast：全球流量调度
Anycast 是一种网络路由技术：多个地理位置分散的服务器使用同一个 IP 地址，网络层自动将用户流量路由到最近的节点。
Anycast 全球加速示意：
IP: 104.16.0.0 (同一个 IP)
│
┌─────────┼─────────┬─────────────┐
│ │ │ │
┌───▼───┐ ┌──▼──┐ ┌───▼───┐ ┌────▼────┐
│ PoP │ │ PoP │ │ PoP │ │ PoP │
│ 北美 │ │欧洲 │ │ 亚洲 │ │ 南美洲 │
└───────┘ └─────┘ └───────┘ └─────────┘
用户在东京 → BGP 路由 → 亚洲节点（就近）
用户在纽约 → BGP 路由 → 北美节点（就近）
Cloudflare 的 Anycast 网络：
- 200+ 个 PoP（接入点）
- 全球用户延迟 < 20ms
- 天然 DDoS 吸收（攻击流量被分散到全球节点）
▶ 面试要点
- 负载均衡本身也会成为单点。解决方案：主备热切换（Active-Standby）+ VIP（Virtual IP）漂移，或使用云 LB（本身已是分布式）。
- L4 和 L7 的本质区别：L4 不解析应用协议，速度快但功能简单；L7 能看到请求内容，可以做精细路由但需要更多计算资源。
- 大公司（如 Cloudflare、AWS）在 L4 之前还有 Anycast 做全球流量调度，L4 做数据中心内部调度，L7 做应用层路由——三层叠加。