機房著火都不怕? 大白話盤透阿里雲負載均衡 SLB 的抗災級高可用

在聊高可用架構的時候，很多兄弟有個誤區，覺得：「我後端伺服器搞了 10 台，資料庫也搞了主備，我的架構就穩如泰山了。」

但你有沒有想過，這 10 台伺服器前面的

那個「帶路黨」——負載平衡（SLB）如果掛了怎麼辦？ 不論你後端的 ECS 有多強悍，用戶流量連門都進不來，整個系統瞬間癱瘓。 這就是典型的單點故障（SPOF）

。

作為全網流量的「總閘門」，阿里雲的負載均衡 SLB（現在細分為傳統型 CLB 和應用型 ALB）到底是怎麼做到即便機房著火、骨幹網斷開，依然能穩如泰山地轉發流量的？ 今天我們不扯那些虛的，直接拉開引擎蓋，看看它的高可用底盤。

一、 第一層保命護甲：跨可用區（Zone）的「備胎」機制

如果你在阿里雲後台購買 SLB，細心一點就會發現，系統一定會讓你選擇兩樣東西：

主可用區（Primary Zone）

和

備用可用區（Backup Zone）

。 比如：主選北京可用區 A，備選北京可用區 B。

這就是 SLB 最基礎、也最核心的跨機房高可用架構。

平時狀態（主備分明）：SLB 在底層機房中為您啟動了至少兩套硬體或虛擬機實例。平時所有的流量，都 100% 走主可用區 A 的 SLB 實例。備可用區 B 的實例處於「熱備」狀態，就像汽車的備胎，一邊跟著轉動，一邊默默注視著。

極端狀態（秒級切換）：假設北京可用區 A 的機房突然斷電，或者光纜被挖斷。阿里雲的底層健康檢查系統會在 2-5 秒內做出反應，將域名的虛擬 IP（VIP）直接漂移到備用可用區 B 的 SLB 實例上。

用戶感知：用戶的網路請求可能會因為斷線重連而短暫中斷，但很快就能恢復正常訪問。你不需要修改任何 DNS 解析，也不需要手動去後台點擊切換，底層完全自動化。

二、 第二層降維打擊：超大規模集群與 Anycast 的無縫容災

「如果某個地區的兩個可用區同時故障了呢？」 （雖然概率極低，但技術抬槓是運維的優良傳統）。

這時候，就要看 SLB 頂層的集群設計了。 阿里雲的 SLB 并不是單台伺服器在作戰，它的背後是一個龐大的

LVS（四層）+ Tengine（七層）

物理集群。

在四層負載均衡（CLB）中，阿里雲採用了

任播 BGP（任意播）

技術:

阿里雲在骨幹網上，讓全球多個核心機房同時宣告同一個 SLB

的公網 IP 地址。

用戶的流量在進入阿里雲網絡的那一刻,是由運營商的 BGP 路由器根據網絡大路的「擁堵情況」,自動分配到最近、最健康的 SLB 集群中。

如果其中一個機房的 SLB 群集整體出現故障，BGP 路由協定會在幾秒鐘內自動將流量「繞道」傳送到另一個城市的 SLB 群集。這種「多活」架構，已經超越了單地域的限制。

三、 第三層微觀防線：SLB 對後端 ECS 的「生死點名」

SLB 自身高可用還不夠,它還必須保證它分發過去的服務器也是活的。 這就涉及到了

健康檢查(Health Check)

。

很多新手配置健康檢查很隨意,結果導致了「雪崩效應」。 SLB 的健康檢查是這樣幫你保命的：

四層(TCP)點名: SLB 就像一個無情的打卡機,每隔幾秒鐘就去握手一下你後端 ECS 的端口(比如 80 端口)。 如果握手成功,說明你活著;如果連續 3 次握手失敗,SLB 會在毫秒級內把你踢出隊列。 新來的流量絕對不分給你。

七層(HTTP)深度體檢: 很多時候端口是通的,但後端代碼卡死了(比如拋出 500 錯誤)。這時候 SLB 會模擬瀏覽器去訪問你指定的 URL(比如 /health.html)。如果返回的狀態碼不是 2xx 或 3xx，就直接將這台伺服器拉黑。

故障自癒: 一旦你的那台 ECS 重啟好了,代碼恢復正常,SLB 重新體檢通過後,又會自動把它拉回隊列繼續幹活。 整個過程零人工干預。

四、 實戰避坑指南：怎麼才能不暴殄天物？

阿里雲將 SLB 的高可用性發揮到了極致，但如果你在配置時犯了低級錯誤，這套高可用機制便形同虛設。請務必記住以下三條鐵律：

1. 後端 ECS 必須跨可用區部署

這是最常見的錯誤！ 很多人買了跨可用區的 SLB(主區 A,備區 B),但為了圖方便,把後端的 4 台 ECS 全買在了可用區 A。

結果一旦可用區 A 斷電,SLB 確實成功切換到了備區 B,但備區 B 的 SLB 往後一看--空空如也,一台伺服器都沒有。 高可用直接破功。

正確姿勢: SLB 跨 A/B 區,後端的 ECS 也要均勻分布在 A/B 區。

2. 必須開啟「會話保持(Session Stickiness)」嗎?

如果你的業務需要用戶登錄（狀態保存在伺服器記憶體中），開啟會話保持功能能讓同一個用戶的請求始終被轉發到同一台 ECS。

但是！ 如果某台 EC

S 掛了,這個用戶的會話必然會斷掉。 為了真正的高可用,

強烈建議把 Session 剝離出來,統一放到 Redis 緩存(如阿里雲 Redis 版)里

,讓後端的 ECS 變成「無狀態」的。 這樣任何一台 ECS 暴斃,SLB 都可以把流量無縫切給其他服務器,用戶完全無感。

3. 合理設置 TTL 和健康檢查閾值

健康檢查的間隔不要設得太長(比如 10 秒檢查一次,連續 5 次失敗才確認,那意味著服務器掛了近一分鐘 SLB 才會發現,這一分鐘內會有大量用戶報錯);但也不要設得太激進(比如 1 秒檢查一次),否則在高並發時,健康檢查本身的流量就會把你的服務器壓垮。

黃金推薦: 響應超時 3 秒,檢查間隔 2-3 秒,不健康閾值 3 次,健康閾值 2 次。

總結

阿里雲 SLB 的高可用,是一套從

全球 BGP 路由、到跨機房主備硬件、再到後端伺服器秒級健康檢查

的立體防禦體系。

對於運維和架構師來說,SLB 是整個系統中性價比最高的組件。 你不需要去研究複雜的 Keepalived 怎麼配、虛擬 IP 怎麼漂移、LVS 集群怎麼維護,一個月花點小錢,就能直接享受到大廠頂級架構師調教出來的抗災級網關。 把專業的事交給 SLB,你唯一需要做的,就是把後端的服務器老老實實分在不同的機房里。