一、SLB概念

負載均衡（Server Load Balancer）是將訪問流量根據轉發策略分發到后端多臺云服務器（Elastic Compute Service，簡稱 ECS）的流量分發控制服務。?
負載均衡服務通過設置虛擬服務地址，將位于同一地域的多臺ECS實例虛擬成一個高性能、高可用的應用服務池；再根據應用指定的方式，將來自客戶端的網絡請求分發到云服務器池中。負載均衡服務是ECS面向多機方案的一個配套服務，需要同ECS結合使用。?
負載均衡服務會檢查云服務器池中ECS實例的健康狀態，自動隔離異常狀態的ECS實例，從而解決了單臺ECS實例的單點問題，提高了應用的整體服務能力。在標準的負載均衡功能之外，負載均衡服務還具備TCP與HTTP抗DDoS攻擊的特性，增強了應用服務的防護能力。?
組成部分?
負載均衡服務由負載均衡實例、監聽和后端服務器三個部分組成。?
負載均衡實例 （Server Load Balancer Instance）?
如果您想使用負載均衡服務，必須先創建一個負載均衡實例。一個負載均衡實例可以添加多個監聽和后端服務器。?
監聽 （Listener）?
在使用負載均衡服務前，您必須為負載均衡實例添加一個監聽，指定監聽規則和轉發策略，并配置健康檢查。?
針對不同的需求，您可以單獨配置四層（TCP/UDP）或七層（HTTP/HTTPS）監聽。?
后端服務器（Backend Server）?
一組接收前端請求的ECS實例。您可以單獨添加ECS實例到服務器池，也可以通過虛擬服務器組或主備服務器組來批量添加和管理。?
默認后端服務器是在實例維度上維護的，即負載均衡實例下的所有監聽都只能夠將請求轉發到相同ECS實例的相同端口上。虛擬服務器組功能實現了監聽維度的轉發。您可以針對不同的監聽創建不同的虛擬服務器組，即負載均衡實例中的不同監聽可以將請求轉發到不同端口的后端服務器上。?
此外，七層負載均衡服務支持域名、URL轉發策略，可以將來自不同域名或者URL的請求轉發給不同的后端服務器處理。?

二、使用限制

2.1 在 4 層（TCP 協議）服務中，不支持添加進后端云服務器池的 ECS 既作為 Real Server，又作為客戶端向所在的 SLB 實例發送請求。因為，返回的數據包只在云服務器內部轉發，不經過負載均衡，所以通過配置在 SLB 后端的 ECS 去訪問其 VIP 是不通的。?
2.2 僅支持 TCP/UDP（4 層） 和 HTTP/HTTPS（7 層） 這 4 種協議。?
2.3 后端服務器僅支持 ECS，不支持第三方云服務器。?
2.4 僅支持輪詢（RR）、加權輪詢（WRR）和最小加權連接數（WLC）這 3 中調度算法。?
2.5 不支持 7 層 SSL Session 超時時間的調整。當前全局統一為 300s。?
2.6 不支持 7 層 HTTP Keep-alive 超時時間的調整。當前配置為 15s。?
說明：如果客戶端訪問 SLB HTTP 監聽時使用長連接, 那么這條連接最長的空閑時間為 15 秒, 即如果超過 15 秒沒有發送任何 HTTP 請求, 這條連接將會被 SLB 主動斷開。如果您的業務可能會出現超過 15 秒的空閑, 需要從業務層面檢測連接的斷開并重新發起連接。?
2.7 不支持轉發超時時間的調整：?
當前配置： TCP 900s，UDP 300s，HTTP 60s，HTTPS 60s?
上述配置是指 SLB 服務端從后端接收數據并進行轉發的超時時間，并非健康檢查超時時間間隔。如果超時，通常會向客戶端返回 504 錯誤碼。?
2.8 金融云 SLB 基于安全性考慮，僅允許開放特定的端口：80，443，2800-3300，6000-10000，13000-14000

三、SLB使用誤區

3.1 SLB后端只添加一臺ECS

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

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

用戶通過 SLB 訪問業務出現異常。但 hosts 綁定后端 ECS 的公網 IP 能正常訪問。用戶據此推斷后端業務是正常的，是 SLB 服務端出現異常導致業務訪問異常。?
其實，由于負載均衡的數據轉發和健康檢查都是通過內網進行的。所以，從后端 ECS 的公網 IP 進行對比訪問測試，并沒有可比性，并不能反應真實訪問情況。?
建議：出現異常時，在后端 ECS 之間，通過內網 IP 做對比訪問測試。

3.3 SLB 的 VIP 能 ping 通就說明配置是正常的

用戶通過 ping SLB 的 VIP 地址來判斷 SLB 服務的有效性。?
其實，這種測試非常不可靠。因為 ping 響應是由 SLB 服務端直接完成的，與后端 ECS 無關。所以，正常情況下：?
只要配置了任意監聽，即便相應監聽處于異常狀態，SLB VIP ping 也是正常的。?
相反，如果 SLB 沒有配置任何監聽，其 VIP 是 ping 不通的。?
建議：對于 4 層服務，通過 telnet 監聽端口進行業務可用性測試；?
對于 7 層服務，通過實際的業務訪問進行可用性測試。

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

用戶反饋已經調大了健康檢查的最大間隔時間，但客戶端訪還是由于訪問超時收到 504 錯誤。?
其實，雖然健康檢查及業務轉發都是由 SLB 服務端相同的服務器承載，但卻是完全不同維度的處理邏輯。來自客戶端的請求，經由 SLB 轉發給后端 ECS 后，SLB 服務端會有接收數據的超時窗口。而另一方面，SLB 服務端持續的對后端 ECS 根據檢查間隔配置進行健康檢查。這兩者之間沒有直接關系，唯一的影響是在后端 ECS 健康檢查失敗后，SLB 不會再對其進行數據轉發。?
建議：客戶端訪問超時時，結合業務與 SLB 默認超時時間進行比對分析；健康檢查超時時，結合健康檢查與業務超時時間進行比對分析。

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

用戶反饋通過 SLB 后端 ECS 的業務日志進行統計分析，發現健康檢查的間隔非常短，與之前在創建監聽時配置的健康檢查間隔時間不一致。?
這個問題在文檔 負載均衡健康檢查原理淺析 有相關說明：LVS 集群內所有節點，都會獨立、并行的遵循該屬性去對后端 ECS 進行定期健康檢查。由于各 LVS 節點的檢查時間并不同步，所以，如果從后端某一 ECS 上進行單獨統計，會發現來自負載均衡的健康檢查請求在時間上并不會遵循上述時間間隔。?
建議：如果健康檢查頻率過高對業務造成影響，可以參閱知識點 健康檢查導致大量日志的處理 進行處理。

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

用戶認為 SLB 服務端使用上百臺機器進行健康檢查，大量健康檢查請求會形成 DDoS 攻擊，造成后端 ECS 性能降低。?
實際上，無論何種模式的健康檢查，其規模均不足以達到類似于 DDoS 攻擊的量級：SLB 集群會利用多臺機器（假定為 M 個，個位數級別），對后端 ECS 的每個服務監聽端口 （假定為 N 個） ，按照配置的健康檢查間隔（假定為 O 秒，一般建議最少 2 秒）進行健康檢查。以 TCP 協議健康檢查為例，那么每秒由健康檢查產生的 TCP 連接建立數為：M*N/O。?
從該公式可以看出，M 和 N 都是固定的，而且值很小。所以，最終健康檢查帶來的每秒 TCP 并發請求數，主要取決于創建的監聽端口數量。所以，除非有巨量的監聽端口，否則由健康檢查產生的連接請求，根本無法達到 SYN Flood 的攻擊級別，實際對后端 ECS 的網絡壓力也極低。?
建議： 如果健康檢查頻率過高對業務造成影響，可以參閱知識點 健康檢查導致大量日志的處理 進行處理。

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

這樣配置會導致當后端 ECS 出現異常時，負載均衡需要經過較長時間才能偵測到后端 ECS 出現不可用。尤其是當后端 ECS 間歇性不可用時，由于需要【連續多次】檢測失敗時才會移除異常 ECS。所以，檢查間隔過長，會導致負載均衡集群可能根本無法發現后端 ECS 不可用。?
3.8 移除服務器與權重置零的效果是一樣的?
移除服務器：已經建立的連接會一并中斷，新建連接也不會再轉發到該 ECS。?
權重置零：已經建立的連接不會中斷，直至超時或主動斷開。新連接不會轉到該 ECS。?
建議：在業務調整或服務器維護時，提前將相應服務器的權重置零，直至連接持續衰減至零。操作完成后，再恢復權重配置，以降低對業務的影響。

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

SLB 在創建監聽時可以指定帶寬峰值。但用戶通過單一客戶端進行測試時，發現始終無法達到該峰值。?
由于 SLB 是基于集群方式部署和提供服務的。所以，所有前端請求會被均分到集群內不同的 SLB 服務器上進行轉發。相應的，在監聽上設定的帶寬峰值也會被平分后設定到各服務器。因此，單個連接下載的流量上限公式為：?
單個連接下載峰值=設置的負載均衡總帶寬/(N-1)?
*注：N 為流量轉發分組個數，當前值一般為 4?
假設在控制臺上設置的帶寬峰值為 10Mb，那么單個客戶端可下載的最大流量為： 10/(4-1)≈3.33Mb?
建議：建議在配置單個監聽的帶寬峰值時，根據實際的業務情況并結合上述實現方式設定一個較為合理的值，從而確保業務的正常對外服務不會受到影響和限制。

3.10 阿里云web應用防火墻（WAF）+SLB回話保持不生效

在流量入口為防護網址添加waf，waf作為反向代理在slb如果配置四層tcp/udp端口監聽，可能存在后端web應用回話保持不生效，七層使用cookie可以解決，但是由于業務可能存在限制必須使用四層端口，此時可以在阿里后臺提交工單申請開啟waf回話保持緩存解決。

四、SLB最佳實踐

4.1 業務架構

SLB 在公網環境下的典型業務架構如上圖所示。基于多可用區特性，當主可用區出現異常時，SLB 會自動將流量切換到備可用區。但在實際的業務架構設計過程中，建議關注如下要點：?
為了降低延遲，建議選擇離您客戶最近的地域進行 SLB 部署。?
并非所有區域都支持多可用區特性（具體支持情況以您在控制臺所見為準），請您結合業務情況選擇合適的可用區。?
在配合使用多可用區特性時，后端 ECS 也必須同時在相應的主備可用區部署，才能保障出現異常時，相應可用區有 ECS 能進行業務承載。

4.2 監聽配置

如上圖所示，SLB 支持創建多種協議監聽，然后按轉發策略，將前端業務請求轉發到后端多種邏輯服務器集。在 SLB 服務配置的各主要步驟中，請關注如下要點。?
選擇監聽協議?
并非只要 Web 網站就必須使用 HTTP 協議。大部分沒有特殊 HTTP 要求的 Web 網站，使用 TCP 監聽 80 端口就可以滿足業務需求。?
SLB 集群采用 LVS 和 Tengine 實現。其中 4 層監聽（TCP/UDP）經過 LVS 后直接到達后端服務器，而 7 層監聽（HTTP/HTTPS）經過 LVS 后，還需要再經過 Tengine 轉發，最后達到后端服務器，由于比 4 層多了一個處理環節。因此，7 層監聽的性能相對要差一些。?
集合模式 配置權重 指定服務端口 服務器數量限制 其它特性?
后端服務器 支持 不支持 無限制 創建監聽時的默認映射服務器集?
虛擬服務器組 支持 支持 無限制 有更大的靈活性?
主備服務器組 支持 支持 2 臺 只能在 TCP/UDP 監聽上使用?
按業務邏輯創建不同的虛擬服務器組，然后創建相應的監聽與之對應。?
無論創建何種服務器集合，均結合 SLB 多可用區特性，同時加入位于不同可用區的服務器，以實現跨可用區容災。?
設置過多轉發規則會增加業務維護的復雜度，建議盡量精簡策略條目。?
選擇轉發策略?
權重代表相應服務器所承載的業務的相對占比，而非絕對值。當前 SLB 支持 3 種轉發策略，其使用場景及要點如下：?
轉發策略 算法說明 使用要點?
加權輪詢（WRR） 按比重輪流分配新增連接 根據后端 ECS 規格的不同，配置相應的權重。如果是長連接業務，可能會導致老服務器的連接數持續增加，而新加入服務器的連接數相對非常低，造成負載不均的假象。?
加權最小連接數（WLC） ●在 SLB 服務端，實時統計與后端 ECS 已建立的 ESTABLISHED 狀態連接數，來評估相應服務器的負載情況。按權重比例，將新增連接分配給活動連接數少的服務器，最終盡可能使服務器的已建立連接數與其權重成正例。 當前暫未實現新增服務器的過載保護或緩沖機制。所以，如果業務并發非常高，可能會導致新增服務器連接數陡增，對業務造成影響。建議新增服務器時，逐步調高權重。?
輪詢（RR） 按順序逐一分發新增連接。 必須手工確保后端 ECS 的業務承載能力一致。

五、建議

? 在同一個服務器集中，同時加入不同可用區的服務器，以實現同城容災?
? 根據服務器規格的差異，配置與之成正比的權重?
? SLB 后端最少配置兩臺以上 ECS，以避免單臺 ECS 出現異常導致整個業務也出現異常?
? 后端 ECS 建議無狀態部署：即只用于計算，而數據調用與存儲后連至后端的 OSS、RDS 等公共服務。這樣可以無需為 ECS 之間的數據同步問題而困擾。?
? 建議基于相同的鏡像或自定義鏡像創建后端 ECS 服務器，以保障配置的一致性。?
? 后端 ECS 歸屬安全組及系統內部防火墻必須對 SLB 服務端地址段進行訪問放行。
————————————————
版權聲明：本文為CSDN博主「faydd3」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/faydd3/article/details/82286258

總結

以上是生活随笔為你收集整理的阿里云SLB最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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