Amazon Elastic Load Balancing 負載均衡高可用架構:給你的服務器配一個頂級的「流量交警」

在互聯網世界裡,最讓架構師和老闆睡不著覺的,莫過於兩件事:

一是突如其來的流量暴增把服務器衝垮,二是某台服務器突然「宕機」導致全站癱瘓。

如果把你的後端服務器集群比作一家銀行的櫃員,當只有一兩個客戶時,大家相安無事。 但當雙十一、黑五或者突發新聞來臨,成千上萬的客戶瞬間湧入,單靠一個櫃員不僅會排起長隊(網站卡頓),櫃員甚至會因為過勞而直接崩潰(服務器宕機)。

怎麼破? 你需要一個精明能幹的「大堂經理」來維持秩序,把客戶均勻地分配到各個空閒的窗口。 在亞馬遜雲科技(AWS)的生態裡,這個角色就是

ELB(Elastic Load Balancing,彈性負載均衡)

。

今天,我們不用晦澀的 PPT 術語,而是用純粹的實戰派視角,深度拆解如何利用 ELB 搭建一套堅不可摧的「高可用負載均衡架構」。

一、 核心選型:三大 ELB 家族成員,你該挑哪一個?

AWS 的 ELB 並不是一個單一的產品,而是針對不同的業務場景,派生出了三個主要方向。 選錯型號,就像是用跑車去拉貨,或者用卡車去賽跑,既浪費錢又達不到效果。

1. ALB (Application Load Balancer) -- 應用負載均衡器

定位:專注於 HTTP/HTTPS 流量(也就是網絡七層協議中的應用層)。

絕活:高級路由功能。 它能看懂請求的內容。 比如,用戶訪問 example.com/api,ALB 可以把请求转给 API 服务器集群;用户访问 example.com/images,它又可以把请求转给图片服务器集群。 它還支持基於域名(Host)、header 甚至查詢字符串來分發流量。

適用場景:絕大多數的 Web 應用、微服務架構、容器化應用(ECS/EKS)。

2. NLB (Network Load Balancer) -- 網絡負載均衡器

定位:專注於 TCP/UDP/TLS 流量(網絡四層協議中的傳輸層)。

絕活:極致的性能與超低延遲。 NLB 能夠處理每秒數以百萬計的突發請求。 更厲害的是,它支持靜態 IP 地址。 每個可用區都可以綁定一個固定的彈性 IP,這對於需要做防火牆白名單的企業級對接來說,簡直是剛需。

適用場景:遊戲服務器、高頻金融交易系統、物聯網(IoT)數據接收端。

3. GLB (Gateway Load Balancer)

-- 網關負載均衡器

定位:專門用來管理第三方虛擬安全設備的(如防火牆、入侵檢測系統)。

適用場景:大廠用來做全站流量的安全審計和清洗。 通常中小型業務很少直接用到它。

二、 高可用架構設計:ELB 是如何實現「故障自癒」的?

很多新手會有個疑問:「我把流量都交給了 ELB,那萬一 ELB 自己掛了怎麼辦? 它不就成了單點故障(Single Point of Failure)了嗎?」

AWS 早就考慮到了這一點。 ELB 名字里的

Elastic(彈性)

包含兩層含義:

容量的彈性

和

架構的彈性

。

1. 跨可用區(Multi-AZ)高可用

在設計 ELB 架構時,最核心的原則就是

絕不把雞蛋放在一個籃子裡

。

AWS 的每個地理區域(Region)都包含多個彼此獨立的可用區(Availability Zone,簡稱 AZ)。 每個 AZ 都有獨立的電力、網絡和散熱系統。

當你創建 ELB 時,系統會強制要求你選擇至少兩個可用區。 實際上,ELB 會自動在每一個你選中的可用區里,各部署一個負載均衡的「節點(Node)」。

當用戶發起請求時,DNS 會把流量輪詢分發到這些不同的可用區節點上。

如果 A 可用區遭遇暴雨斷電徹底癱瘓,ELB 頂層的 DNS 解析會自動把流量切走,全部灌入 B 可用區的節點。 整個過程對用戶來說完全無感知。

2. 健康檢查(Health Check):精準剔除「害群之馬」

ELB 能夠保持高可用的另一大殺手鐧是

健康檢查

。

你必須為 ELB 配置一個規則,比如:

每隔 10 秒,向後端伺服器的 /health 路徑發送一個 HTTP 請求。 如果連續 3 次返回 200 OK,說明服務器活著;如果連續 2 次沒有回應,就判定該服務器「生病」了。

一旦某台服務器被判定為不健康,ELB 會立刻將其

拉黑

,不再向它發送任何新流量,直到它恢復正常。 這成功避免了「因為一台伺服器死機,導致 1/3 的用戶訪問報錯」的慘劇。

三、 實戰演練:手把手搭建一套 ALB Multi-AZ 高可用 Web 架構

接下來,我們以最經典的 ALB 為例,走一遍生產環境的標準配置流程。

第一步:準備後端「目標組(Target Group)」

在配置負載均衡器之前,我們要先告訴它「把流量發給誰」。 在 AW

S 里,這個後端的集合叫做目標組。

打開 EC2 控制台,在左側導航欄找到 Target Groups,點擊 Create target group。

選擇目標類型,通常選擇 Instances(實例),輸入名字。

協議與端口:選擇 HTTP:80(或者你的應用運行的端口)。

Health checks(健康檢查):檢查路徑通常寫你的服務狀態接口,比如 / 或 /status.html。 展開高級設置(Advanced health check settings),把「健康閾值」設為 3,「不健康閾值」設為 2,「超時時間」設為 5 秒,「間隔」設為 10 秒。

點擊 Next,把你在不同可用區(比如 AZ-A 和 AZ-B)啟動的 Web 服務器實例勾選進來,點擊 Create target group。

第二步:創建 Application Load Balancer

在左側導航欄點擊 Load Balancers,點擊 Create load balancer,選擇 Application Load Balancer。

Scheme(方案):選擇 Internet-facing(面向互聯網)。 如果是對內網微服務做負載,才選 Internal。

Network mapping(網絡映射):選擇你的 VPC。 關鍵步驟:勾選至少兩個可用區(例如 us-east-1a 和 us-east-1b),並選擇每個可用區對應的公網子網(Public Subnet)。💡架構避坑指南:ALB 自身必須駐留在公網子網中,這樣它才能拿到公網 IP 接收互聯網流量。 但是！ 你的後端 Web 服務器(EC2)可以、且強烈建議放在**私網子網(Private Subnet)**里。 這樣,外界沒有任何人能直接通過 IP 攻擊你的服務器,所有的安全防護都由前端的 ALB 來扛,架構安全性瞬間拉滿。

第三步:配置安全組(Security Groups)與監聽器

Security groups:為 ALB 關聯一個安全組,必須放通 TCP 80(HTTP)和 TCP 443(HTTPS)端口。

Listeners and routing(監聽器與路由):默認有一條 HTTP:80 的監聽器,在 Forward to(轉發至)下拉菜單中,選擇我們第一步創建的那個「目標組」。 如

果有 SSL 證書,點擊 Add listener,添加一條 HTTPS:443,並配置你的域名證書。

點擊最下方的

Create load balancer

。 大約 2 分鐘後,ALB 狀態變為

活動中

,你將獲得一個長長的 DNS 名稱(例如:

My-alb-123456789.us-east-1.elb.amazonaws.com

）。

四、 高級進階:與 Auto Scaling(彈性伸縮)合體,成就終極高可用

如果你只配了 ELB,當流量真的超過後端伺服器的總承受極限時,網站依然會卡死。 ELB 只是個大堂經理,它沒辦法憑空變出更多的櫃員。

要實現真正的「彈性自由」,你需要把

ELB

和

Auto Scaling(自動彈性伸縮)

綁定在一起。

[用戶請求] -> [ELB] -> [根據流量自動增加/減少 EC2 數量 (Auto Scaling Group)]

當雙十一零點來臨,流量暴增:

CloudWatch 監控發現後端伺服器的平均 CPU 飆升到了 80%。

Auto Scaling 收到信號,立刻自動打包創建 5 台全新的 EC2 服務器。

最奇妙的地方在這裡:新服務器啟動後,auto Scaling 會自動向 ELB 的目標組報到:「報告經理,我是新來的櫃員,已經準備就緒!」

ELB 收到通知,立刻開始把後續的流量分流給這 5 台新服務器,整個過程不需要人工改動任何一行配置或重啟任何設備。

凌晨兩點流量退去,CPU 降下來了,auto Scaling 會自動銷毀這 5 台機器省錢,ELB 也會優雅地斷開連接(Deregistration Delay),確保正在處理的請求正常結束後,再把它們移出集群。

結語

在現代雲原生架構中,amazon ELB 絕對不是一個簡單的「流量轉發器」,它是整個高可用架構的

指揮官

。

它通過跨可用區的節點部署防範了物理級別的災難,通過嚴格的健康檢查隔離了系統內部的故障,又通過與 Auto Scaling 的完美配合賦予了業務無限延展的可能。 搞懂了 ELB 的運行邏輯與配置細節,你就握住了搭建高並發、不宕機現代化網站最核心的那把鑰匙。