負載均衡（Server Load Balancer，下文簡稱 SLB）的引入，可以降低單臺云服務器 ECS（下文簡稱 ECS）出現異常時對業務的沖擊，提升業務的可用性。同時，結合彈性伸縮服務，通過動態調整后端服務器，可以快速對業務進行彈性調整（擴容或縮容），以快速應對業務的發展。

本文，會先對 SLB 的使用限制和常見誤區進行說明，然后介紹 SLB 的使用最佳實踐。

SLB 基礎原理

在開始使用 SLB 之前，建議您務必閱讀如下文章，了解 SLB 的相關基礎原理：

• 負載均衡健康檢查原理淺析
• 負載均衡網絡流量路徑說明

SLB 使用限制

在使用 SLB 進行業務部署之前，請您務必了解 SLB 的相關使用限制，以免對后續使用造成困擾或對業務造成影響。

產品與業務規格限制

SLB 的相關資源或功能存在限制，部分可以通過提交工單申請調整。部分則沒有例外，無法調整。詳細說明，可以參閱?SLB 使用限制。

另外，后續阿里云會推出性能保障型實例，對實例性能提供保障，用戶可配置和查詢其具體的性能指標，并可查看其實時運行數據。相關說明可以參閱?產品文檔。

技術限制

SLB 在技術層面還在逐步增強和完善，截止本文發稿，還存在如下技術限制：

• 在 4 層（TCP 協議）服務中，不支持添加進后端云服務器池的 ECS 既作為 Real Server，又作為客戶端向所在的 SLB 實例發送請求。因為，返回的數據包只在云服務器內部轉發，不經過負載均衡，所以通過配置在 SLB 后端的 ECS 去訪問其 VIP 是不通的。
• 僅支持 TCP/UDP（4 層） 和 HTTP/HTTPS（7 層） 這 4 種協議。
• 后端服務器僅支持 ECS，不支持第三方云服務器。
• 僅支持輪詢（RR）、加權輪詢（WRR）和最小加權連接數（WLC）這 3 中調度算法。
• 不支持 7 層 SSL Session 超時時間的調整。當前全局統一為 300s。

• 不支持 7 層 HTTP Keep-alive 超時時間的調整。當前配置為 15s。

  • 說明：如果客戶端訪問 SLB HTTP 監聽時使用長連接, 那么這條連接最長的空閑時間為 15 秒, 即如果超過 15 秒沒有發送任何 HTTP 請求, 這條連接將會被 SLB 主動斷開。如果您的業務可能會出現超過 15 秒的空閑, 需要從業務層面檢測連接的斷開并重新發起連接。

• 不支持轉發超時時間的調整：

  • 當前配置： TCP 900s，UDP 300s，HTTP 60s，HTTPS 60s
  • 上述配置是指 SLB 服務端從后端接收數據并進行轉發的超時時間，并非健康檢查超時時間間隔。如果超時，通常會向客戶端返回 504 錯誤碼。
• 金融云 SLB 基于安全性考慮，僅允許開放特定的端口：80，443，2800-3300，6000-10000，13000-14000

SLB 常見誤區

從歷史案例看，用戶在 SLB 的規劃和使用過程中有很多常見誤區。接下來逐一說明。

誤區：SLB 后端只需添加一臺 ECS ，確保鏈路能跑通即可

用戶在 SLB 后端只添加一臺服務器時，雖然鏈路能跑通，客戶端也能正常訪問。但卻失去了 SLB 消除 ECS 單點的基本能力。如果這臺僅有的 ECS 出現異常，那邊整個業務訪問也會出現異常。

建議：至少在 SLB 后端加入兩臺以上 ECS。以便單一服務器出現異常時，業務還能持續正常訪問。

誤區：后端 ECS 能正常訪問，但 SLB 無法訪問，則說明 SLB 出現了異常

用戶通過 SLB 訪問業務出現異常。但 hosts 綁定后端 ECS 的公網 IP 能正常訪問。用戶據此推斷后端業務是正常的，是 SLB 服務端出現異常導致業務訪問異常。

其實，由于負載均衡的數據轉發和健康檢查都是通過內網進行的。所以，從后端 ECS 的公網 IP 進行對比訪問測試，并沒有可比性，并不能反應真實訪問情況。

建議：出現異常時，在后端 ECS 之間，通過內網 IP 做對比訪問測試。

誤區： SLB 的 VIP 能 ping 通就說明配置是正常的

用戶通過 ping SLB 的 VIP 地址來判斷 SLB 服務的有效性。

其實，這種測試非常不可靠。因為 ping 響應是由 SLB 服務端直接完成的，與后端 ECS 無關。所以，正常情況下：

• 只要配置了任意監聽，即便相應監聽處于異常狀態，SLB VIP ping 也是正常的。
• 相反，如果 SLB 沒有配置任何監聽，其 VIP 是 ping 不通的。

建議：對于 4 層服務，通過 telnet 監聽端口進行業務可用性測試；對于 7 層服務，通過實際的業務訪問進行可用性測試。

誤區：已經調整了健康檢查間隔，結果還會出現訪問超時

用戶反饋已經調大了健康檢查的最大間隔時間，但客戶端訪還是由于訪問超時收到 504 錯誤。

其實，雖然健康檢查及業務轉發都是由 SLB 服務端相同的服務器承載，但卻是完全不同維度的處理邏輯。來自客戶端的請求，經由 SLB 轉發給后端 ECS 后，SLB 服務端會有接收數據的超時窗口。而另一方面，SLB 服務端持續的對后端 ECS 根據檢查間隔配置進行健康檢查。這兩者之間沒有直接關系，唯一的影響是在后端 ECS 健康檢查失敗后，SLB 不會再對其進行數據轉發。

建議：客戶端訪問超時時，結合業務與 SLB 默認超時時間進行比對分析；健康檢查超時時，結合健康檢查與業務超時時間進行比對分析。

誤區：從后端日志看，健康檢查間隔與監聽配置的間隔時間不一致

用戶反饋通過 SLB 后端 ECS 的業務日志進行統計分析，發現健康檢查的間隔非常短，與之前在創建監聽時配置的健康檢查間隔時間不一致。

這個問題在文檔?負載均衡健康檢查原理淺析?有相關說明：LVS 集群內所有節點，都會獨立、并行的遵循該屬性去對后端 ECS 進行定期健康檢查。由于各 LVS 節點的檢查時間并不同步，所以，如果從后端某一 ECS 上進行單獨統計，會發現來自負載均衡的健康檢查請求在時間上并不會遵循上述時間間隔。

建議：如果健康檢查頻率過高對業務造成影響，可以參閱知識點?健康檢查導致大量日志的處理?進行處理。

誤區：大量健康檢查形成 DDoS 攻擊，導致服務器性能下降

用戶認為 SLB 服務端使用上百臺機器進行健康檢查，大量健康檢查請求會形成 DDoS 攻擊，造成后端 ECS 性能降低。

實際上，無論何種模式的健康檢查，其規模均不足以達到類似于 DDoS 攻擊的量級：SLB 集群會利用多臺機器（假定為 M 個，個位數級別），對后端 ECS 的每個服務監聽端口 （假定為 N 個） ，按照配置的健康檢查間隔（假定為 O 秒，一般建議最少 2 秒）進行健康檢查。以 TCP 協議健康檢查為例，那么每秒由健康檢查產生的 TCP 連接建立數為：M*N/O。

從該公式可以看出，M 和 N 都是固定的，而且值很小。所以，最終健康檢查帶來的每秒 TCP 并發請求數，主要取決于創建的監聽端口數量。所以，除非有巨量的監聽端口，否則由健康檢查產生的連接請求，根本無法達到 SYN Flood 的攻擊級別，實際對后端 ECS 的網絡壓力也極低。

建議： 如果健康檢查頻率過高對業務造成影響，可以參閱知識點?健康檢查導致大量日志的處理?進行處理。

誤區：用戶為了降低健康檢查的影響，將健康檢查間隔設置得很長

用戶為了降低健康檢查對業務的影響，將檢查間隔時間設置得很長。

這樣配置會導致當后端 ECS 出現異常時，負載均衡需要經過較長時間才能偵測到后端 ECS 出現不可用。尤其是當后端 ECS 間歇性不可用時，由于需要【連續多次】檢測失敗時才會移除異常 ECS。所以，檢查間隔過長，會導致負載均衡集群可能根本無法發現后端 ECS 不可用。

建議： 如果健康檢查頻率過高對業務造成影響，可以參閱知識點?健康檢查導致大量日志的處理?進行處理。

誤區：移除服務器與權重置零的效果是一樣的

用戶在進行業務調整時，認為直接將服務器從 SLB 后端移除，或將其權重置零即可，兩者效果是一樣的。

其實，兩者有很大區別，相關操作對業務的影響也不一致：

• 移除服務器：已經建立的連接會一并中斷，新建連接也不會再轉發到該 ECS。
• 權重置零：已經建立的連接不會中斷，直至超時或主動斷開。新連接不會轉到該 ECS。

建議：在業務調整或服務器維護時，提前將相應服務器的權重置零，直至連接持續衰減至零。操作完成后，再恢復權重配置，以降低對業務的影響。

誤區：單個連接就能達到監聽配置的帶寬峰值

SLB 在創建監聽時可以指定帶寬峰值。但用戶通過單一客戶端進行測試時，發現始終無法達到該峰值。

由于 SLB 是基于集群方式部署和提供服務的。所以，所有前端請求會被均分到集群內不同的 SLB 服務器上進行轉發。相應的，在監聽上設定的帶寬峰值也會被平分后設定到各服務器。因此，單個連接下載的流量上限公式為：

單個連接下載峰值=設置的負載均衡總帶寬/(N-1) *注：N 為流量轉發分組個數，當前值一般為 4

示例：
假設在控制臺上設置的帶寬峰值為 10Mb，那么單個客戶端可下載的最大流量為：?10/(4-1)≈3.33Mb

建議：建議在配置單個監聽的帶寬峰值時，根據實際的業務情況并結合上述實現方式設定一個較為合理的值，從而確保業務的正常對外服務不會受到影響和限制。

SLB 使用最佳實踐

接下來，結合 SLB 的產品特性與歷史案例，從多個維度闡述使用 SLB 的最佳實踐。

設計業務架構

?

注：內網環境下，不支持多可用區，只看圖例的單邊即可。

SLB 在公網環境下的典型業務架構如上圖所示。基于多可用區特性，當主可用區出現異常時，SLB 會自動將流量切換到備可用區。但在實際的業務架構設計過程中，建議關注如下要點：

• 實例類型與計費方式

  • 如果只用于內部服務分發，則創建私網實例即可。
  • 按流量計費，適用于波峰波谷效應明顯的業務。
  • 按帶寬計費，適用于帶寬較為平穩的業務。

• 區域與多可用區

  • 為了降低延遲，建議選擇離您客戶最近的地域進行 SLB 部署。
  • 并非所有區域都支持多可用區特性（具體支持情況以您在控制臺所見為準），請您結合業務情況選擇合適的可用區。
  • 在配合使用多可用區特性時，后端 ECS 也必須同時在相應的主備可用區部署，才能保障出現異常時，相應可用區有 ECS 能進行業務承載。

配置監聽

?

如上圖所示，SLB 支持創建多種協議監聽，然后按轉發策略，將前端業務請求轉發到后端多種邏輯服務器集。在 SLB 服務配置的各主要步驟中，請關注如下要點。

選擇監聽協議

SLB 支持創建 TCP/UCP/HTTP/HTTPS 這 4 種協議的監聽。您可參考以下表格，根據業務情況選擇適合的協議創建監聽：

協議類型建議的應用場景特性

TCP	●注重可靠性，對數據準確性要求高，速度可以相對較慢的場景； ●示例：文件傳輸、發送或接收郵件、遠程登錄、無特殊要求的 Web 應用	●面向連接的協議； ●在正式收發數據前，必須和對方建立可靠的連接； ●基于源地址會話保持，在網絡層可直接看到來源地址； ●監聽支持 TCP 和 HTTP 兩種方式進行健康檢查； ●轉發路徑短，所以性能比 7 層更好，數據傳輸速度更快
HTTP	需要對數據內容進行識別的應用，如 Web 應用、小的手機游戲等	●應用層協議，主要解決如何包裝數據； ●基于 Cookie 會話保持；使用 X-Forward-For 獲取源地址； ●監聽只支持 HTTP 方式健康檢查
HTTPS	有更高的安全性需求，需要加密傳輸的應用	●加密傳輸數據，可以阻止未經授權的訪問； ●統一的證書管理服務，用戶可以將證書上傳到負載均衡，解密操作直接在負載均衡上完成
UDP	●關注實時性而相對不注重可靠性的場景； ●示例：視頻聊天、金融實時行情推送	●面向非連接的協議； ●在數據發送前不與對方進行三次握手，直接進行數據包發送，不提供差錯恢復和數據重傳； ●可靠性相對低；數據傳輸快

補充說明

• 并非只要 Web 網站就必須使用 HTTP 協議。大部分沒有特殊 HTTP 要求的 Web 網站，使用 TCP 監聽 80 端口就可以滿足業務需求。
• SLB 集群采用 LVS 和 Tengine 實現。其中 4 層監聽（TCP/UDP）經過 LVS 后直接到達后端服務器，而 7 層監聽（HTTP/HTTPS）經過 LVS 后，還需要再經過 Tengine 轉發，最后達到后端服務器，由于比 4 層多了一個處理環節。因此，7 層監聽的性能相對要差一些。

選擇后端服務器集模式

SLB 后端服務器支持按 3 種邏輯創建服務器集。要點如下：

集合模式配置權重指定服務端口服務器數量限制其它特性

后端服務器	支持	不支持	無限制	創建監聽時的默認映射服務器集
虛擬服務器組	支持	支持	無限制	有更大的靈活性
主備服務器組	支持	支持	2 臺	只能在 TCP/UDP 監聽上使用

建議

• 按業務邏輯創建不同的虛擬服務器組，然后創建相應的監聽與之對應。
• 無論創建何種服務器集合，均結合 SLB 多可用區特性，同時加入位于不同可用區的服務器，以實現跨可用區容災。
• 設置過多轉發規則會增加業務維護的復雜度，建議盡量精簡策略條目。

選擇轉發策略

權重代表相應服務器所承載的業務的相對占比，而非絕對值。當前 SLB 支持 3 種轉發策略，其使用場景及要點如下：

轉發策略算法說明使用要點

加權輪詢（WRR）	按比重輪流分配新增連接。	●根據后端 ECS 規格的不同，配置相應的權重。 ●如果是長連接業務，可能會導致老服務器的連接數持續增加， 而新加入服務器的連接數相對非常低，造成負載不均的假象。
加權最小連接數（WLC）	●在 SLB 服務端，實時統計與后端 ECS 已建立的 ESTABLISHED 狀態連接數，來評估相應服務器的負載情況。 ●按權重比例，將新增連接分配給活動連接數少的服務器，最終盡可能使服務器的已建立連接數與其權重成正例。	當前暫未實現新增服務器的過載保護或緩沖機制。所以，如果業務并發非常高，可能會導致新增服務器連接數陡增，對業務造成影響。建議新增服務器時，逐步調高權重。
輪詢（RR）	按順序逐一分發新增連接。	必須手工確保后端 ECS 的業務承載能力一致。

示例：假設有 100 個新增連接，則在不同的調度算法下，不同服務器的分配連接數示意如下：

服務器權重占比加權輪詢加權最小連接數輪詢

A	50	50/ (100+50+50) =25%	將 100*25%=25 個連接分發給服務器 A	實時統計連接數，逐一將新增連接分配給活動連接數最少的服務器。最終使其新增連接數占比大致為 25%	不考慮權重，按順序分發新增連接到服務器 A/B/C
B	100	100/ (100+50+50) =50%	將 100*50%=50 個連接分發給服務器 B	↑ 同上，最終使其新增連接數占比大致為 50%	↑ 同上
C	50	50/ (100+50+50)= 25%	將 100*25%=25 個連接分發給服務器 C	↑ 同上，最終使其新增連接數占比大致為 25%	↑ 同上
D	0	0/ (100+50+50) =0%	服務器下線，不分配任何連接	← 同左	← 同左

配置健康檢查

健康檢查用于實時探測后端 ECS 上的業務可用性，以避免新增連接被分發到異常服務器對業務造成影響。由于是 SLB 依賴的核心服務，所以 4 層協議（TCP/UCP）的健康檢查無法關閉。

在配置健康檢查時，注意如下要點：

• 根據業務情況合理選擇 TCP 或 HTTP 模式健康檢查

  • TCP 模式健康檢查只能檢查端口的可用性，對 7 層 HTTP 狀態無法感知。所以，Web 類 7 層業務建議配置 HTTP 模式健康檢查。
  • TCP 模式健康檢查由于在連接建立后即主動發送 RST 斷開連接，所以可能會導致業務層面認為是非正常中斷，導致產生大量相關聯的錯誤日志。該問題可以參閱?健康檢查導致大量日志的處理?進行處理。
  • 如果使用 HTTP 健康檢查模式，建議合理調整后端日志配置，避免健康檢查 HEAD 請求過多對 IO 性能造成影響。
• 合理配置健康檢查間隔
  根據實際業務需求配置健康檢查間隔，避免因為健康檢查間隔過長導致無法及時發現后端 ECS 出現問題。具體請參考：健康檢查的相關配置，是否有相對合理的推薦值？

• 合理配置檢查端口與檢查 URL

  • 對于 4 層 TCP 協議，由于虛擬服務器組可以由后端 ECS 不同的端口承載業務，因此在配置健康檢查時不要設置檢查端口，而應該"默認使用后端服務器的端口進行健康檢查"。否則可能導致后端 ECS 健康檢查失敗。
  • 對于 7 層 HTTP 協議，使用虛擬服務器組合轉發策略時，確保健康檢查配置策略中的 URL 在后端每臺機器上都可以訪問成功。
  • 使用 HTTP 模式健康檢查時，不要對根目錄進行檢查。建議配置為對某個靜態頁面或文件進行檢查以降低對主頁的沖擊。但是，相應的，這可能會導致誤判：健康檢查 URL 雖然訪問是正常的，但主頁實際上已經出現異常。

• UDP 健康檢查
  當前 UDP 協議健康檢查可能存在服務真實狀態與健康檢查不一致的問題：

  • 如果后端 ECS 服務器是 Linux 服務器，在大并發場景下，由于 Linux 的防 ICMP 攻擊保護機制，會限制服務器發送 ICMP 的速度。此時，即便服務已經出現異常，但由于無法向前端返回 “port XX unreachable” 報錯信息，會導致負載均衡由于沒收到 ICMP 應答進而判定健康檢查成功，最終導致服務真實狀態與健康檢查不一致。
  • 如果相應服務器非正常關機，由于也不會返回 “port XX unreachable” 報錯信息。所以也會導致健康檢查處于"正常"狀態的誤報。

選擇與配置后端 ECS

在后端 ECS 的選擇與配置時，注意如下要點：

• 在同一個服務器集中，同時加入不同可用區的服務器，以實現同城容災
• 根據服務器規格的差異，配置與之成正比的權重
• SLB 后端最少配置兩臺以上 ECS，以避免單臺 ECS 出現異常導致整個業務也出現異常
• 后端 ECS 建議無狀態部署：即只用于計算，而數據調用與存儲后連至后端的 OSS、RDS 等公共服務。這樣可以無需為 ECS 之間的數據同步問題而困擾。
• 建議基于相同的鏡像或自定義鏡像創建后端 ECS 服務器，以保障配置的一致性。
• 后端 ECS 歸屬安全組及系統內部防火墻必須對 SLB 服務端地址段進行訪問放行。

調整后端 ECS 的操作建議

新增后端服務器

在往 SLB 內新增服務器時，注意如下要點：

• 建議新增服務器時，將權重置零，在確保業務正常運行后，再調整權重使其上線。
• 如果業務是長連接，在新增服務器時，建議先將相應監聽的調度算法修改為輪詢模式，然后逐步調高新增服務器的權重，以降低對該新增服務器的過高沖擊。

調整、維護業務和后端服務器

在后端 ECS 服務器的日常調整、維護過程中，注意如下要點：

• 選擇合適的業務窗口，定期對后端 ECS 進行重啟操作（操作前先創建快照進行備份），以便應用系統補丁，并主動觸發、感知系統內部錯誤導致的服務器無法正常啟動等問題。

• 業務更新或系統維護時建議的操作步驟：

  1.將相應 ECS 的權重置零。此時，已建立的連接不受影響，新增連接不會再分發到該服務器。 2.周期性的在系統內通過 netstat/ss 等指令，確保已建立連接逐步自動斷開，衰減置零。如果客戶端有自動重連機制，則根據業務情況也可以忽略本步驟。 3.對服務器進行快照備份。 4.進行業務調整、服務器配置、重啟等操作。 5.操作完畢后，確認業務重新正常上線。然后逐步調高服務器權重，使其重新上線。 6.逐一對服務器集內所有服務器按上述步驟進行維護。

移除服務器

如果確認服務器不再使用，不建議直接移除服務器。而是參閱前述步驟，將相應服務器權重置零。待已建立連接全部正常斷開后，再移除該服務器。

常見問題的排查思路

SLB 在使用過程中的常見問題與排查思路可以參閱下列文檔，本文不再詳述：

• 健康檢查異常的排查思路
• 負載均衡返回 HTTP 500/502/504 錯誤的處理
• 后端 ECS 負載不均衡問題的處理

典型案例

后端 ECS 負載不均

問題場景：
后端 ECS 規格均一致，但其中幾臺服務器的 PPS 一直非常高。而新加入的服務器，相對負載非常低。
業務高峰期，相關服務器健康檢查異常，導致服務器下線，并進一步導致其它服務器負載升高，引發整個 SLB 后端出現雪崩式異常，業務受到嚴重影響。

排查思路：

業務監聽使用 WRR 調度算法，在 SLB 服務端統計，在單位時間內分發到各服務器的連接數是均衡的。

異常服務器上的連接數持續居高不下，嘗試調高 OS 層面的 TCP 連接數限制等配置，無明顯效果。

和客戶交流，結合業務分析，相關連接來源正常，都是正常的業務連接。但業務場景是物聯網的監控數據上報，使用的是長連接。所以除非主動斷開相關連接，否則相關連接會持續堆積。

應對措施：

將負載較低的服務器的權重值調低。

將監聽的調度算法修改為 WLC。

將異常服務器的權重值置零。

將負責較低的服務器的權重值逐步調高。

以上步驟用于將負載逐步轉移到新加入的服務器，并避免對新增服務器及異常服務器的沖擊。

待異常服務器的連接數下降到合理水平后，將其重新上線（重新配置權重）。

由于后端服務器負載總體偏高，導致業務高峰期多臺服務器無法滿足業務需求，出現雪崩式異常。所以，同步建議客戶對 SLB 后端服務器進行擴容。

總結

以上是生活随笔為你收集整理的阿里云负载均衡【SLB】使用实践方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。