負載平衡和故障切換

負載平衡和故障轉移

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的受控事件。