亞馬遜雲國際站高可用架構設計:跨可用區(AZ)容災與ELB負載均衡

在雲計算時代,「高可用(High Availability, HA)」幾乎是被各類架構師掛在嘴邊的詞。 很多人認為,只要把系統搬上亞馬遜雲(AWS),買了EC2,配了負載均衡,高可用就自然實現了。

然而,真實的生產環境往往會給這種盲目樂觀一記響亮的耳光。

當某個AWS可用區(Available Zone, AZ)因為底層光纜被挖斷、電力故障或軟件定義網絡(SDN)異常而陷入癱瘓時,你的服務是會自動無縫切換,還是跟著一起宕機、客服電話被打爆?

真正的

高可用架構不是買出來的,而是設計出來的

。 本文將徹底拋棄複雜的PPT黑話,用最通俗易懂的「大白話」,帶你拆解亞馬遜雲國際站上最核心的兩個高可用命題:

跨可用區(Cross-AZ)容災

與

ELB負載均衡

。

一、 重新定義「高可用」:Region與AZ的底層真相

在動筆設計架構之前,我們必須先認清AWS的底層物理基礎設施。 這是所有高可用設計的地基。

區域(Region): 地理上完全隔離的區域(比如東京、弗吉尼亞、愛爾蘭)。 區域之間距離極遠,除非發生地緣政治級別的災難,否則一個區域停電絕不影響另一個。

可用區(AZ): 一個區域內包含多個可用區。 請記住:一個AZ並不等於一個數據中心(Data Center)。 一個AZ可能由數個彼此靠近、但電力和網絡完全獨立的數據中心群組成。

💡核心痛點:為什麼單AZ架構必死? 很多出海企業為了省錢,把Web服務器、數據庫全部丟在同一個AZ(比如 ap-northeast-1a)。 這就相當於把所有的雞蛋放在了一個雖然號稱「防彈」但依然可能漏雨的籃子裡。 一旦該AZ發生骨幹網故障,你的業務就會瞬間失聯。

因此,跨AZ(Multi-AZ)架構不是一種「高級選項」,而是生產環境的

硬性底線

。

二、 流量的交警:ELB(彈性負載均衡)的正確打開方式

要實現跨AZ容災,第一步必須有一個「流量交警」,把來自全球用戶的請求均勻、聰明地分發到不同可用區的服務器上。 在AWS中,這個角色由

ELB(Elastic Load Balancing)

擔任。

AWS提供了多種負載均衡器,但在現代Web架構中,我們主要聚焦於

ALB(Application Load Balancer)

和

NLB(Network Load Balancer)

。

1. ALB vs NLB:別選

錯了武器

特性

ALB (應用負載均衡器)

NLB (網絡負載均衡器)

工作OSI層級

第7層(應用層:HTTP/HTTPS)

第4層(傳輸層:TCP/UDP/TLS)

核心優勢

聰明。 能識別URL路徑、Cookie、HTTP Header進行高級路由。 支持SSL證書卸載。

極快。 超低延遲,能夠處理每秒數千萬級的並發請求,支持固定IP。

適用場景

絕大多數Web應用、微服務API、電商網站。

遊戲網關、物聯網(IoT)接收端、非HTTP協議的原始TCP服務。

對於絕大多數出海企業,

ALB

是最推薦的選擇。

2. 跨可用區負載均衡(Cross-Zone Load Balancing)

這是ELB設計中最容易讓人踩坑的地方。

默認情況下,ALB的跨可用區負載均衡是

開啟

的,而NLB默認是

關閉

的。 這有什麼區別?

關閉狀態下: 如果DNS把流量50%分配給AZ-A的負載均衡節點,50%分配給AZ-B的負載均衡節點。 即便AZ-A裡只有1台服務器,AZ-B裡有4台服務器,AZ-A的那台服務器也會頂著50%的流量活活累死。

開啟狀態下: 無論流量先到達哪個AZ的負載均衡節點,ELB都會把請求平均分配給背後所有AZ里的所有後端實例。

結論：

除非你有極度苛刻的延遲要求(微秒級),否則

強烈建議保持跨可用區負載均衡開啟

,確保後端壓力絕對平均。

三、 跨AZ容災的鐵三角:計算、網絡與存儲

有了ELB這個交警還不夠,後端的車道(計算)、路網(網絡)和倉庫(存儲)必須也具備跨AZ的能力,才能在某個AZ暴斃時實現「無感切換」。

1. 計算層:Auto Scaling(自動擴展組)是唯一的正確姿勢

永遠不要手動去創建兩台機器放兩個AZ。 你應該使用

AWS Auto Scaling Group (ASG)

。

你只需要配置一個啟動模板(Launch Template),告訴ASG:「我最少需要2台機器,最多需要10台,請幫我部署在

Ap-northeast-1a

和

Ap-northeast-1b

這兩個AZ中。」

健康檢查機制(Health Check): 別讓ELB只檢查EC2是不是開著的(Ping)。 要配置ELB去請求你代碼里的一個特定接口(如 /health)。 如果這個接口返回500,或者數據庫連接失敗,ELB會立

刻判定該實例「不健康」,停止向其發送流量。

自癒能力: 一旦某個AZ掛了,該AZ內的機器全部失聯,ASG會立刻觸發報警,在另外一個健康的AZ中自動開出新機器補上缺口。

2. 網絡層:子網(Subnet)與路由的黃金法則

在私有網絡(VPC)的設計上,很多人會犯結構混亂的錯誤。 一個標準的高可用網絡架構應該遵循「成對出現、絕對隔離」的原則。

公有子網(Public Subnet): 放置Internet Gateway、ELB以及NAT網關。 每個AZ各配一個。

私有子網(Private Subnet): 放置真實的EC2應用服務器。 這些機器不需要公網IP,絕對不能直接暴露給互聯網。 每個AZ各配一個。

高可用NAT網關陷阱: 很多團隊為了省錢,在整個VPC裡只建了一個NAT網關放在AZ-A,讓AZ-B的私有EC2也跨AZ繞過來上網。 一旦AZ-A掛了,AZ-B的服務器雖然活著,但也因為無法上網(無法訪問外部API、無法下載依賴)而廢掉。 正確的做法:每個AZ各自擁有獨立的NAT網關。

3. 存儲與數據庫層:告別單點,擁抱Multi-AZ

計算節點是無狀態的(Stateless),死掉可以隨時重開。 但

數據是有狀態的,數據絕不能丟。

關係型數據庫(RDS / Aurora):強烈開啟 Multi-AZ 部署。 AWS會自動在另一個AZ創建一個完全同步的備用(Standby)實例。 當主庫所在的AZ發生故障時,RDS會自動進行DNS漂移,在幾s到幾十s內把備用庫提升為主庫,你的應用代碼甚至不需要修改連接字符串(Endpoint)。

文件存儲(EFS vs EBS):EBS(雲硬盤): 它是綁定在特定AZ的。 這意味著AZ-A的EC2掛了,你無法直接把它的EBS掛載到AZ-B的EC2上。 EFS(彈性文件系統): 原生支持跨AZ。 多個AZ的EC2可以同時讀寫同一個EFS。 如果你的業務需要共享文件存儲(比如Wordpress的圖片上傳目錄),請毫不猶豫地選擇EFS。

四、 終極實戰:一個標準的多AZ高可用架構演練

為了讓你有更直觀的感受,我們來模擬一個標準的用戶請求是如何在AWS跨AZ高可用架構中流轉的。

場景:用戶訪問一個電商網站 [https: //example.com ]

域名解析: 用戶發起請求,AWS Route 53(智能DNS)解析該域名。 由於配置

了延遲或輪詢策略,route 53將流量指向部署在公有子網的 ALB。

流量分發: ALB接收到HTTPS請求,在本地完成SSL證書解密(卸載壓力),然後根據跨可用區負載均衡策略,將請求轉發給位於AZ-A或AZ-B私有子網中的 EC2實例。

業務處理與數據讀寫: EC2上的應用處理業務。 如果需要讀寫數據庫,它會連接到 RDS 主庫(位於AZ-A)。 此時,RDS會自動將數據同步複製到 RDS 備庫(位於AZ-B)。

災難發生(模擬AZ-A徹底斷網):ELB反應: ALB發現AZ-A內的EC2實例心跳停止,或者健康檢查連續失敗,立刻將AZ-A從轉發列表中剔除。 100%的流量被瞬間導入AZ-B的EC2。 RDS自癒: AWS監控到RDS主庫失聯,自動啟動故障轉移(Failover)。 AZ-B的備用庫在30秒內升級為新主庫,route 53自動更新RDS的內部Endpoint。 AZ-B的EC2短暫報錯後恢復正常讀寫。 ASG擴容: auto Scaling Group發現當前存活的機器數量少於設定的最小期望值,立刻在健康的AZ-B中彈出一台全新的EC2,並自動註冊到ALB背後。

結果:

整個過程中,除了極少數在切換瞬間發起請求的用戶可能會遇到一次重試(502/504),99%的用戶完全感知不到後台經歷了一場「生死時速」的機房級災難。

五、 避坑指南:架構師常犯的三個致命錯誤

在實際落地這套架構時,根據大量的翻車案例,我總結了以下三個最容易被忽略的暗礁:

1. 跨AZ傳輸費用(Cross-AZ Data Transfer Costs)

AWS的入站流量(從互聯網進來)是免費的,但在同一個Region內,

流量跨越不同的AZ傳輸是要收費的

(通常是 $0.01/GB)。

如果你的微服務拆得太碎,服務A(AZ-A)頻繁通過RPC調用服務B(AZ-B),到了月底,你會收到一張極其恐怖的網絡帳單。

優化方案:盡量讓流量在同一個AZ內完成內網閉環,只有在容災切換時才跨AZ。

2. 數據庫「腦裂」與同步延遲

雖然RDS Multi-AZ是同步複製,性能非常好,但如果你們是自己搭建的自建數據庫集群(如自己硬核魔改的MySQL MHA),在跨AZ網絡抖動時,極易發生兩個節點都認為自己是主庫的「腦裂」現象,從而導致數據寫亂。

優化方案:專業的事交給專業的工具,生產環境強烈

建議優先使用 RDS 或 Aurora,把底層的分布式一致性問題交給AWS去解決。

3. 忘記測試:紙面上的高可用不是高可用

很多團隊架構設計得很完美,但上線三年從未做過一次容災演練。 結果真的發生故障時,發現代碼里把數據庫IP寫死了、或者安全組(Security Group)忘記放行另一個AZ的網段。

優化方案:定期執行 Chaos Engineering(混沌工程)。 在低峰期,手動去RDS控制台點一下「Failover」,或者故意關掉一個AZ的所有EC2,看看系統能否如預期般自癒。

結語

在雲原生時代,

容災不應該是一件昂貴且繁瑣的體力活,而應該是一種設計直覺。

通過將

ELB的智能分發

、

Auto Scaling的無狀態自癒

以及

RDS的跨AZ同步複製

結合在一起,我們只用了幾項標準的亞馬遜雲國際站服務,就構建出了一個足以抵禦機房級災難的鋼鐵架構。

記住,高可用的最高境界,不是保佑故障永遠不發生;而是當故障如期而至時,你的系統只是輕輕晃動了一下,便繼續在風雨中穩步前行。