负载平衡和故障切换

负载平衡和故障转移

1）目标和术语

平衡将流量分布在实例/区域/区域之间，以实现性能和可持续性。
Failover-受控故障切换。
RTO/RPO：恢复时间目标和有效数据丢失。
SLO：目标可用性/潜伏率；作为自动操纵和回滚的"门户"。

2）平衡图层

2.1 L4 (TCP/UDP)

优点：性能,简单,TLS passthrough。缺点：不了解路线/cookie。
示例：NLB/GLB，HAProxy/Envoy L4，IPVS。

2.2 L7 (HTTP/gRPC)

优点：路由/头部，金丝雀重量，粘性。缺点：CPU/潜伏期更贵。
例如：NGINX/HAProxy/Envoy/Cloud ALB/API网关。

2.3全球一级

DNS/GSLB：健康检查+地理/加权响应。
Anycast/BGP：全球一个IP，最近的公告点。
CDN/Edge：外围的kesh/feylover。

3）分布算法

Round-robin/weighted是基本的。
Least connections/latency-用于"重"查询。
自我锁定-在没有中心会话的情况下按键（用户/tenant）粘合。
基于Hash的本地性-用于缓存和静态服务。

4）会议和粘性（粘性）

Cookie-sticky： L7 LB设置Cookie以返回实例。
Src-IP粘性：在L4上，在NAT/CGNAT下更糟。
Consistent hashing：更适合水平缓存/聊天。
Aim：在可能的情况下,使服务保持静止,否则,退出状态（Redis/DB中的会话）以简化故障传递。

5）可靠性： 健康检查和退出轮换

Active checks： HTTP 200/深入的业务路径样本（例如,'/healthz/withdraw'与依赖项）。
Passive （Outlier detection）：在5xx/taymauts处弹出后端。
Warm-up：平稳地启用新实例（慢启动）。
Graceful drain：从池中删除→等待查询完成。

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6）故障管理： 时间/回归/电路断裂

时间：比客户时间短；设置每条路线。
Retries：1-2具有抖动和幂等性；禁止在没有相同能力钥匙的情况下进行开机自检。
电路破解：限制同时查询/错误；"半开放"恢复。
Budgets：retrais 限制/Burst合并，以免安排自制DDOS。

7）Kubernetes模式

ClusterIP/NodePort/LoadBalancer/Ingress是基本原语。
Readiness/Liveness：流量仅限于成品。
PodDisruptionBudget：不允许同时下降N副本。
HPA/VPA：根据CPU/RED度量进行缩放，与LB结合。
ServiceTopology/Topology Aware Hints：跨区域的位置。
Service type=LoadBalancer （zonal）：每个AZ中至少有2个副本。

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8）跨区域交通和跨区域交通

Multi-AZ（区域内）：均匀分配（zonal LB）,存储-同步复制。

Multi-region:

Active-Active：两个区域都为流量服务；更复杂-需要数据复制、一致性和跨地理位置的路由。
Active-Passive：主要地区服务,储备为"热/热/冷"。更简单、更快地切换,但高于RPO。

• Geo-DNS（最近的区域）。
• 加权的DNS（金丝雀/重新分配）。
• 基于Latency（RTT测量）。
• Failover=通过健康/可用性信号（来自多个vantage点的probes）。

9）数据和故障处理

缓存/状态：如果可能的话-本地区域；Active-Active-CRDT/一致性哈希。

• 同步复制=低RPO，高于潜伏期。
• 异步=低于潜伏期，但RPO> 0。
• 队列：镜像/多面体拓扑；事件重复数据消除。
• 设计操作和重置力学的等效性。

10）外围： DNS/Anycast/BGP/CDN

DNS：短的TTL（30-60 s）+网络外的健康检查。
Anycast：具有单个IP的多个ROR-最接近的接收流量,路由级别的收发器。

CDN/Edge： 用于保护的缓存和"网关"，在起源下降时提供静态/媒体服务；origin-shield + пер-POP health.

11）示例配置

HAProxy L7:

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

NGINX sticky по cookie:

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Envoy retry/timeout (route):

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12）自动故障切换： 信号和网关

TE-SLI：5xx-rate，p95/p99，aturation，TLS handshakes，TCP resets。
业务SLI：存款/付款成功，PSP没有支付错误。
门：当超出阈值时-关闭区域/实例,提高稳定池的重量,切换GSLB。
运行手册：分步切换和返回（rollback）语句。

13）测试和检查（混沌和游戏日）

混沌测试：禁用AZ/区域，DB/缓存降解，packet-loss模拟。
游戏日：涉及呼叫团队的训练狂欢者。
诊断：从外围到后端的跟踪，发行注释映射和度量。

14）安全和合规性

LB↔servisy之间的mTLS，外围的WAF/Rate极限。
故障/分段区域：blast-radius隔离。
政策：禁止单点故障（SPOF），要求"最低限度N 复制品/AZ"。

15）反模式

一个LB/一个区域，用于所有散装交通（SPOF）。
缺乏深度检查'/healthz'（绿色-但DB/队列不可用）。
无止境的回避→交易/付款双打。
大量NAT的IP粘滞→不平衡。
具有高TTL（开关前时钟）的DNS收件人。
在空白时没有灰色drain-断开查询。

16）实施清单（0-45天）

0-10天

根据AZ ≥2分解实例；启用readiness/liveness, health-checks。
配置L7-timeouts/retries （1次尝试）、outlier检测。
启用graceful drain和slow-start。

11-25天

引入GSLB （geo/weighted）或Anycast作为周长。
金丝雀重量/路线政策；sticky通过cookie/consistent hash。
用于自动取款机的SLO门（p95/5xx+Business SLI）。

26-45天

区域DR：具有翻译测试的主动-主动或主动-被动。
AZ/区域关闭的混沌日，RTO/RPO报告。
自动运行手册"和（pause/shift/rollback脚本）。

17）成熟度量

Multi-AZ覆盖率≥ 99％的关键路径。
DNS/GSLB/Anycast已用于公共终端。
一个AZ下降时的MTTR <5分钟（p95）。
用于目标≤关键数据的RPO（例如，≤ 30秒）。
季刊游戏日和成功的定期收件人。

18）结论

稳健的平衡和故障切换是一种分层体系结构：局部L7策略（计时器/retries/CB，健康检查），适当的粘合和哈希，跨区域稳定性，以及外围的GSLB/DNS/Anycast。添加SLO门、等效性、粗糙排版和常规混沌测试-并且任何节点、区域甚至区域的丢失都将成为具有可预测RTO/RPO的受控事件。