前提

明確應用系統所需負載均衡的類型（4層或7層），是負載均衡選型的前提。

• 如應用系統需要4層負載均衡，需選擇NLB或CLB。

• 如應用系統需要7層負載均衡，需選擇ALB或CLB。

性能關鍵點

明確應用系統對于負載均衡的性能需求，從而針對性進行負載均衡選型。

• 承載力維度

  • 對于4層負載均衡，如應用系統對新建連接數、并發連接數的性能上限及彈性能力具有較高要求，建議選擇NLB。

  • 對于7層負載均衡，如應用系統對每秒請求數QPS的性能上限及彈性能力具有較高要求，建議選擇ALB。

  • 如對負載均衡的4層或7層的性能上限無較高要求，可考慮選擇CLB。

• 功能支持維度

  • 對于4層負載均衡，如應用系統對4層TCPSSL卸載、洪峰限速、云原生集成等功能具有較高要求，建議選擇NLB。

  • 對于7層負載均衡，如應用系統對7層路由、云原生Ingress網關等功能具有較高要求，建議選擇ALB。

  • 如對負載均衡的4層或7層的功能特性無較高要求，可考慮選擇CLB。

穩定關鍵點

ALB、NLB、CLB的容災架構和機制有所不同，您需要先明確應用系統對于負載均衡的容災需求，從而針對性地進行負載均衡選型。

• 多可用區多活模式

  ALB和NLB均支持多可用區部署。在應用系統所在的地域支持2個及以上可用區的情況下，為了保障業務的高可用性，建議至少選擇兩個可用區進行部署。其工作原理主要通過域名對外提供服務，域名會進行CNAME解析，指向NLB和ALB的域名，然后將業務流量調度至所選可用區內的ALB和NLB實例的VIP（虛擬IP）。當某個可用區出現故障或不可用時，該可用區可被置于DNS摘除狀態，從而實現容災逃逸。這種機制確保了在單個可用區發生故障時，流量可以自動切換到其他可用區，保證業務的連續性和高可用性。

• 雙可用區主備模式

  CLB已在大部分地域支持多可用區類型的實例，此類型實例會部署在兩個可用區，默認啟用主可用區。當主可用區出現故障或不可用時，CLB有能力在短時間內（約30秒）切換到備可用區并恢復服務。當主可用區恢復時，CLB會自動切換回主可用區。

  說明

  CLB的主備可用區是可用區級別的容災。只有當主可用區整體不可用時，如機房整體斷電或者機房出口光纜中斷等，CLB才會切換到備可用區。而并非某個實例出現故障，就切換到備可用區。

通過上述描述可以看出，相較于CLB的容災架構和機制，NLB和ALB采用的多可用區多活模式提供了更大的容災范圍。具體來說，單個負載均衡實例可以部署在2個及以上的可用區內，顯著提升了系統的高可用性和故障恢復能力。此外，這種模式還具備更強的故障逃逸能力，您可以自主操作，將異常可用區的DNS記錄摘除，從而快速響應和處理故障。因此，您可以根據應用系統對穩定性和可用性的要求，選擇合適的負載均衡產品。對于高可用性要求較高的系統，NLB和ALB的多可用區多活模式無疑是更優的選擇。

彈性關鍵點

對于用戶而言，彈性的直接價值，是在業務波峰時能夠及時獲取相應的承載力，并僅需按實際使用量付費，避免資源預置所造成的成本浪費。因此，根據前序章節的介紹：

• 如應用系統計劃選用ALB或NLB，那么此兩款負載均衡產品在具備高性能上限的情況下，采用按使用量計費模式，滿足按需使用&按量付費的彈性要求。

• 如應用系統計劃選用CLB，CLB支持“按規格計費”和“按使用量計費”兩種計費模式，采用按使用量計費模式，便可滿足按需使用&按量付費的彈性要求。

安全關鍵點

ALB、NLB、CLB的安全能力有所不同，明確應用系統對于負載均衡的安全需求，從而針對性地進行負載均衡選型。

• 關于七層負載均衡：Web攻擊防護能力

  如應用系統具有Web攻擊防護需求，優先推薦采用ALB。ALB WAF增強版支持阿里云WAF3.0服務化接入。

  WAF3.0的服務化接入，是指通過SDK模塊化的方式集成在ALB中，并通過SDK提取流量并進行檢測和防護。該集成方式對應用系統有如下兩方面幫助：

  • 轉發方面：WAF不參與流量轉發，可避免因額外引入一層轉發而帶來各種兼容性和穩定性問題，并降低訪問延遲。

  • 部署方面：無需修改DNS、配置證書、端口、回源算法等復雜的WAF接入轉發配置，簡化部署流程。

• 關于四層負載均衡：傳輸層加密

  如果應用系統需使用四層負載均衡，且具有TCPSSL加密要求，推薦選擇NLB。

  NLB支持配置TCP SSL監聽，實現TCP SSL卸載，將加密流量解析為明文流量后分發至后端服務器，從而使后端服務器的配置得以簡化、工作負載得以降低，繼而提高業務處理效率。

性能關鍵點

• 實例處理性能

  對于ALB或NLB，實例具有較高的性能上限以及較強的彈性能力。但如果應用系統需承載可預知的突發流量（如大促活動等），建議提前與阿里云商務經理聯系，以便評估檢查相關實例對突發流量的承載能力和彈性能力。

  對于CLB，無論使用按規格計費模式或按使用量計費模式，單實例可提供的最大處理能力同S3.large規格（最大連接數1,000,000、新建連接數100,000、每秒查詢數50,000）。建議根據應用系統的流量模型和規模，選擇適合的計費模式、實例規格以及實例數量。

• 公網帶寬性能

  對于公網類型的ALB或NLB，通過彈性公網IP（EIP）提供公網能力。

  • 如果應用系統的流量模型較平穩，共享帶寬可考慮選擇“按帶寬計費模式”，設定業務所需的帶寬峰值。

  • 如果應用系統的流量模型峰谷效應明顯，共享帶寬可考慮選擇“按主流量計費模式”（即在一個計費周期內，取共享帶寬實例的入方向和出方向中流量較大的為主流量，對主流量進行計費），并設定業務所需的帶寬峰值。

  說明

  按流量計費的EIP，帶寬峰值上限為200Mbps。因此，為保障應用系統獲得足夠的帶寬保障，建議搭配使用共享帶寬產品。

  對于CLB，既可通過“私網類型CLB+EIP”的方式提供公網能力，也可直接使用“公網類型CLB”。但出于多個負載均衡實例的帶寬復用性以及IP地址的獨立保有性這兩方面考慮，更為推薦“私網類型CLB+EIP”的方式，并搭配使用共享帶寬產品。

穩定關鍵點

• 實例的可用區規劃

  • 如果使用ALB，至少選擇2個可用區，ALB的可用區盡量與后端服務器的可用區保持一致。但ALB不支持“關閉跨AZ轉發”，即ALB的各VIP接收到客戶端的訪問流量時，會將流量轉發至所有可用區的后端服務器（即不局限于該VIP所屬可用區）。

  • 如果使用NLB，至少選擇2個可用區，NLB的可用區盡量與后端服務器的可用區保持一致。且可考慮“關閉跨AZ轉發”，使NLB各VIP接收到客戶端的訪問流量時，僅將流量轉發至同可用區的后端服務器，從而規避跨AZ轉發。

  • 如果使用CLB，CLB的主可用區盡量與后端服務器的可用區保持一致，從而規避跨AZ轉發。

• 后端服務器的健康檢查

  建議開啟負載均衡的健康檢查功能，從而判斷后端服務器的業務可用性。當某臺后端服務器健康檢查出現異常時，負載均衡會自動將新的請求分發到其他健康檢查正常的后端服務器上；而當該后端服務器恢復正常運行時，負載均衡會將其自動恢復到負載均衡服務中進行流量轉發。健康檢查機制提高了業務整體可用性，避免了局部后端服務器異常對總體服務的影響，是保證業務高可用的關鍵要素。ALB、NLB、CLB的健康檢查協議類型均支持TCP和HTTP。

• 監聽的限速設置

  為防止非預期的洪峰流量超過后端服務器的承載力并導致“雪崩效應”，可以考慮使用負載均衡的監聽級限速功能。在洪峰流量出現時，此功能可以確保后端服務器在其承載能力范圍內處理請求。

  • ALB的每秒請求數（QPS）限速

    對于ALB的目標監聽，可設置“總QPS限速”或“客戶端顆粒度QPS限速”（基于客戶端源IP），這兩種限速方式可以單獨或同時配置。

  • NLB的新建連接數（CPS）限速

    對于NLB的目標監聽，可以設置在每個可用區（VIP）每秒可接受的新建連接數上限。

安全關鍵點

• 黑白名單的訪問控制

  ALB和NLB均支持加入安全組，可通過ALB加入安全組或NLB加入安全組實現基于白名單或黑名單的訪問控制。

  CLB提供監聽級別的訪問控制。您可以針對不同的監聽設置訪問白名單或黑名單：

  • 開啟白名單：僅轉發來自所選訪問控制策略組中設置的IP地址或地址段的請求，白名單適用于應用只允許特定IP訪問的場景。

  • 開啟黑名單：來自所選訪問控制策略組中設置的IP地址或地址段的所有請求都不會轉發，黑名單適用于應用只限制某些特定IP訪問的場景。

• TLS策略的自定義

  • 對于七層負載均衡，針對HTTPS場景，ALB預置了部分常用的TLS安全策略以滿足加密需求，您可根據安全需求選擇合適的TLS安全策略，或者配置自定義TLS安全策略，從而保證應用系統的安全性。

  • 對于四層負載均衡，針對TCPSSL場景，NLB預置了部分常用的TLS安全策略以滿足加密需求，您可根據安全需求選擇合適的TLS安全策略，或者配置自定義TLS安全策略，從而保證應用系統的安全性。

  說明

  CLB不支持自定義TLS安全策略。

• 雙向認證

  在HTTPS場景下，ALB（標準版和WAF增強版）、NLB以及CLB均支持雙向認證，能夠滿足應用系統的安全認證要求。而在TCPSSL場景中，NLB具備雙向認證能力，確保了高安全性的通信需求。具體操作可參考：使用ALB部署HTTPS業務（雙向認證）、通過NLB實現TCPSSL卸載（雙向認證）、使用CLB部署HTTPS業務（雙向認證）。

可觀測關鍵點

• 監控

  當應用系統遇到請求超時、流量限速等網絡連接問題，或需了解負載均衡的工作負載等數據，可查看負載均衡所提供的監控項指標。具體操作可參考：NLB監控項說明、ALB監控項說明、CLB監控項說明。

• 日志

  負載均衡可提供操作日志和訪問日志功能。具體操作可參考：ALB日志、NLB日志、CLB訪問日志、CLB操作日志。

  • 操作日志：可以監控并記錄賬號對負載均衡產品的使用行為。

  • 訪問日志：收集了所有發送到7層負載均衡的請求的詳細信息（包括請求時間、客戶端IP地址、延遲、請求路徑和服務器響應等），可通過訪問日志分析客戶端行為、了解客戶端地域分布以及進行問題排查。

• 網絡智能服務

  除使用NLB、ALB、CLB自身所提供的監控日志能力外，建議考慮開啟網絡智能服務，進一步提升應用交付網絡的可觀測性。

4層負載均衡

設計關鍵點回顧與提煉：

• 穩定關鍵點

  • 至少選擇2個或2個以上的可用區創建NLB，且盡量與后端服務器所在可用區保持一致。

  • NLB可考慮“關閉跨AZ轉發”。

  • 按需評估是否開啟新建連接限速，從而預防非預期的洪峰流量造成“雪崩效應”。

  • 針對后端服務器組，啟用健康檢查。

• 性能關鍵點

  公網類型NLB，建議搭配使用共享帶寬產品，且根據流量模型，選擇使用“主流量計費”或“按帶寬計費”。

• 安全關鍵點

  根據應用系統的安全管控要求，評估是否將NLB加入安全組。如使用TCPSSL監聽，評估是否自定義TLS策略以及是否啟用雙向認證。

7層負載均衡

設計關鍵點回顧與提煉：

• 穩定關鍵點

  • 至少選擇2個或2個以上的可用區創建ALB，且盡量與后端服務器所在可用區保持一致。

  • 按需評估是否開啟QPS限速，從而預防非預期的洪峰流量造成“雪崩效應”。

  • 針對后端服務器組，啟用健康檢查。

• 性能關鍵點

  公網類型ALB，建議搭配使用共享帶寬產品，且根據流量模型，選擇使用“主流量計費”或“按帶寬計費”。

• 安全關鍵點

  根據應用系統的安全管控要求，評估是否需將ALB加入安全組、評估是否自定義TLS策略以及評估是否啟用雙向認證。

負載均衡選型

應用系統如需借助負載均衡，構建支持IPv6的應用交付網絡，建議綜合考慮“IPv6端到端通信”和“IPv6至IPv4轉換”兩種場景，以確定負載均衡選型。

• 場景1：IPv6端到端通信

  NLB和ALB，均支持掛載IPv6類型的后端服務器，從而將來自客戶端的IPv6訪問請求，以IPv6協議轉發至后端服務器，幫助應用系統實現全鏈路的IPv6通信。而CLB不支持。

  

• 場景2：IPv6至IPv4轉換

  NLB、ALB、CLB，均具備IPv6至IPv4轉換能力，從而將來自客戶端的IPv6訪問請求，以IPv4協議轉發至后端服務器，幫助應用系統簡單快速地具備IPv6訪問能力。

  

綜上，由于NLB和ALB可同時兼顧“IPv6端到端通信”和“IPv6至IPv4轉換”，建議優先選擇NLB或ALB構建IPv6應用交付網絡。

與此同時，NLB和ALB支持雙棧類型實例，即單個實例可同時具備IPv6地址和IPv4地址，從而構建統一的IPv6與IPv4應用交付網絡。而CLB不支持雙棧類型實例，需單獨創建IPv6類型實例和IPv4類型實例，使得IPv4和IPv6應用交付網絡相互獨立。因此選擇NLB或ALB，還可幫助簡化應用交付網絡架構。

負載均衡部署

IPv6應用交付網絡的負載均衡部署階段，同樣需重點關注“穩定、安全、彈性、可觀測、自服務”這5項設計關鍵點。

• IPv6端到端通信

  步驟1: 為NLB或ALB所在VPC開啟IPv6。

  步驟2: 創建“協議版本”為雙棧的NLB或ALB實例。

  步驟3: 如NLB或ALB的IPv6地址需要公網可達，則需在NLB或ALB所在VPC的IPv6網關，為IPv6地址開通公網帶寬。

  步驟4: 創建NLB或ALB的后端服務器組，并開啟IPv6掛載。

• IPv6至IPv4轉換

  • NLB或ALB部署

    步驟1: 為NLB或ALB所在VPC開啟IPv6。

    步驟2: 創建“協議版本”為雙棧的NLB或ALB實例。

    步驟3: 如NLB或ALB的IPv6地址需要公網可達，則需在NLB或ALB所在VPC的IPv6網關，為IPv6地址開通公網帶寬。

    步驟4: 創建NLB或ALB的后端服務器組，無需開啟IPv6掛載。

  • CLB部署

    創建“IP版本”為IPv6的CLB實例，且僅公網CLB實例支持IPv6。隨后完成負載均衡的常規配置即可。