目錄
一、負載均衡
負載均衡是雲計算的基礎組件，是網絡流量的入口，其重要性不言而喻。
什麼是負載均衡呢？
將用戶請求或者說流量通過負載均衡器，按照某種負載均衡算法把流量均勻地分散到後端的多個服務器上，接收到請求的服務器可以獨立的響應請求，以期望的規則分攤到多個操作單元上進行執行，達到負載分擔的目的。並通過它可以實現橫向擴展（scale out），將冗餘的作用發揮爲高可用。
二、負載均衡模型分類
從應用場景上來說，常見的負載均衡模型有全局負載均衡和集羣內負載均衡，從產品形態角度來說，又可以分爲硬件負載均衡和軟件負載均衡。
全局負載均衡一般通過 DNS 實現，通過將一個域名解析到不同 VIP，來實現不同的 Region 調度能力。
硬件負載均衡器常見的有 F5、A10、Array，它們的優缺點都比較明顯，優點是功能強大，有專門的售後服務團隊，性能比較好；缺點是缺少定製的靈活性，維護成本較高。
現在的互聯網更多的思路是通過軟件負載均衡來實現，這樣可以滿足各種定製化需求，常見的軟件負載均衡有 LVS、Nginx、Haproxy。
對於用戶配置的四層監聽，LVS 後面會直接掛載用戶 ECS，七層用戶監聽 ECS 則掛載在 Tengine 上。四層監聽的流量直接由 LVS 轉發到 ECS，而七層監聽的流量會經過 LVS 到 Tenigine 再到用戶 ECS。
每一個 Region 裏都會有多個可用區，達到主備容災目的，每一個集羣裏都有多臺設備，第一是爲了提升性能，第二也是基於容災考慮。
上圖爲高性能負載均衡控制管理概要圖，SLB 產品也有 SDN 概念，轉發和控制是分離的，用戶所有配置通過控制檯先到控制器，通過集中控制器轉換將用戶配置推送到不同設備上，每臺設備上都有 Agent 接收控制器下發的需求。
通過本地轉換成 LVS 和 Tengine 能夠識別的配置，這個過程支持熱配置，不影響用戶轉發，不需要 reload 才能使新配置生效。
三、CDN負載均衡
四、LVS負載均衡
4.1 LVS 支持的三種模式
早期 LVS 支持以下三種模式：DR 模式、TUN 模式、NAT 模式
4.1.1 DR 模式
DR 模式經過 LVS 之後，LVS 會將 MAC 地址更改、封裝 MAC 頭，內層 IP 報文不動。
報文經過 LVS 負載均衡查找到 RS 之後，將源 MAC 頭改成自己的，目的 MAC 改成 RS 地址，MAC 尋址是在二層網絡裏，對網絡部署有一定的限定，在大規模分佈式集羣部署裏，這種模式的靈活性沒有辦法滿足需求。
4.1.2 TUN 模式
TUN 模式走在 LVS 之後，LVS 會在原有報文基礎上封裝 IP 頭，到了後端 RS 之後，RS 需要解開 IP 報文封裝，才能拿到原始報文。
不管是 DR 模式還是 TUN 模式，後端 RS 都可以看到真實客戶源 IP，目的 IP 是自己的 VIP，VIP 在 RS 設備上需要配置，這樣可以直接繞過 LVS 返回給用戶。
TUN 模式問題在於需要在後端 ECS 上配置解封裝模塊，在 Linux 上已經支持這種模塊，但是 Windows 上還沒有提供支持，所以會對用戶系統鏡像選擇有限定。
4.1.3 NAT 模式
NAT 模式用戶訪問的是 VIP，LVS 查找完後會將目的 IP 做 DNAT 轉換，選擇出 RS 地址。
因爲客戶端的 IP 沒變，在回包的時候直接向公網真實客戶端 IP 去路由，NAT 的約束是因爲 LVS 做了 DNAT 轉換，所以回包需要走LVS，把報文頭轉換回去。
由於 ECS 看到的是客戶端真實的源地址，我們需要在用戶 ECS 上配置路由，將到 ECS 的默認路由指向 LVS 上，這對用戶場景也做了限制。
4.2 LVS 基於 Netfilter 的框架實現
Netfilter 是 Linux 提供的網絡開放平臺，基於該平臺可以開發自己的業務功能模塊，早期好多安全廠商都是基於 Netfilter 做一些業務模型實現。
這種模型比較靈活，但通用模型裏更多的是兼容性考慮，路徑會非常長;而且通用模型中沒辦法發揮多核特性，目前 CPU 的發展更多是向橫向擴展。
我們經常見到多路服務器，每路上有多少核，早期通用模型對多核支持並不是特別友善，在多核設計上有些欠缺，導致我們在通用模型上做一些應用開發時的擴展性是有限的，隨着核的數量越來越多，性能不增反降。
五、負載均衡策略是什麼
正如上圖所示的這樣，由一個獨立的統一入口來收斂流量，再做二次分發的過程就是負載均衡，它的本質和分佈式系統一樣，是分治。在軟件系統中爲了避免流量分攤不均，造成局部節點負載過大（如 CPU 吃緊等），所以引入一個獨立的統一入口來做類似的工作。
在軟件系統中的負載均衡的背後是策略在起作用，而策略的背後是由某些算法或者說邏輯來組成的。負載均衡，也有很多算法或者說邏輯在支撐着這些策略，也有靜態和動態之分。
六、常用負載均衡策略圖解
下面來羅列一下日常工作中最常見的 5 種策略。
6.1 輪詢
這是最常用也最簡單策略，平均分配，人人都有、一人一次。大致的代碼如下：
int globalIndex = 0; //注意是全局變量，不是局部變量。
try{
return servers[globalIndex];
} finally {
globalIndex++;
if (globalIndex == 3)
globalIndex = 0;
}
6.2 加權輪詢
在輪詢的基礎上，增加了一個權重的概念。權重是一個泛化後的概念，可以用任意方式來體現，本質上是一個能者多勞思想。
比如，可以根據宿主的性能差異配置不同的權重。大致的代碼如下：
int matchedIndex = -1;
int total = 0;
for (int i = 0; i < servers.Length; i++)
{
servers[i].cur_weight += servers[i].weight;//①每次循環的時候做自增（步長=權重值）
total += servers[i].weight;//②將每個節點的權重值累加到彙總值中
if (matchedIndex == -1 || servers[matchedIndex].cur_weight < servers[i].cur_weight) //③如果 當前節點的自增數 > 當前待返回節點的自增數，則覆蓋。
{
matchedIndex = i;
}
}
servers[matchedIndex].cur_weight -= total;//④被選取的節點減去②的彙總值，以降低下一次被選舉時的初始權重值。
return servers[matchedIndex];
這段代碼的過程如下圖的表格。"()"中的數字就是自增數，即代碼中的 cur_weight。
值得注意的是，加權輪詢本身還有不同的實現方式，雖說最終的比例都是 2：1：2。
但是在請求送達的先後順序上可以有所不同。比如「5-4，3，2-1」和上面的案例相比，最終比例是一樣的，但是效果不同。
「5-4，3，2-1」更容易產生併發問題，導致服務端擁塞，且這個問題隨着權重數字越大越嚴重。
例子：10：5：3 的結果是「18-17-16-15-14-13-12-11-10-9，8-7-6-5-4，3-2-1」
6.3 最少連接數
![在這裏插入圖片描述]()
這是一種根據實時的負載情況，進行動態負載均衡的方式。維護好活動中的連接數量，然後取最小的返回即可。大致的代碼如下：
var matchedServer = servers.orderBy(e => e.active_conns).first();
matchedServer.active_conns += 1;
return matchedServer;
//在連接關閉時還需對active_conns做減1的動作。
6.4 最快響應
這也是一種動態負載均衡策略，它的本質是根據每個節點對過去一段時間內的響應情況來分配，響應越快分配的越多。
具體的運作方式也有很多，上圖的這種可以理解爲，將最近一段時間的請求耗時的平均值記錄下來，結合前面的加權輪詢來處理，所以等價於 2：1：3 的加權輪詢。
**題外話：**一般來說，同機房下的延遲基本沒什麼差異，響應時間的差異主要在服務的處理能力上。
如果在跨地域（例：浙江->上海，還是浙江->北京）的一些請求處理中運用，大多數情況會使用定時「Ping」的方式來獲取延遲情況，因爲是 OSI 的 L3 轉發，數據更乾淨，準確性更高。
6.5 Hash 法
Hash 法的負載均衡與之前的幾種不同在於，它的結果是由客戶端決定的。通過客戶端帶來的某個標識經過一個標準化的散列函數進行打散分攤。上圖中的散列函數運用的是最簡單粗暴的取餘法。
**題外話：**散列函數除了取餘之外，還有諸如變基、摺疊、平方取中法等等，此處不做展開，有興趣的小夥伴可自行查閱資料。
另外，被求餘的參數其實可以是任意的，只要最終轉化成一個整數參與運算即可。
最常用的應該是用來源 IP 地址作爲參數，這樣可以確保相同的客戶端請求儘可能落在同一臺服務器上。
常用負載均衡策略優缺點和適用場景
我們知道，沒有完美的事物，負載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優缺點和適用場景，我稍作了整理，如下。
這些負載均衡算法之所以常用也是因爲簡單，想要更優的效果，必然就需要更高的複雜度。
比如，可以將簡單的策略組合使用、或者通過更多維度的數據採樣來綜合評估、甚至是基於進行數據挖掘後的預測算法來做。
七、用健康探測來保障高可用
不管是什麼樣的策略，難免會遇到機器故障或者程序故障的情況。所以要確保負載均衡能更好的起到效果，還需要結合一些健康探測機制。定時的去探測服務端是不是還能連上，響應是不是超出預期的慢。
如果節點屬於“不可用”的狀態的話，需要將這個節點臨時從待選取列表中移除，以提高可用性。一般常用的健康探測方式有 3 種。
7.1 HTTP 探測
使用 Get/Post 的方式請求服務端的某個固定的 URL，判斷返回的內容是否符合預期。一般使用 HTTP 狀態碼、Response 中的內容來判斷。
7.2 TCP 探測
基於 TCP 的三次握手機制來探測指定的 IP + 端口。最佳實踐可以借鑑阿里雲的 SLB 機制，如下圖：
值得注意的是，爲了儘早釋放連接，在三次握手結束後立馬跟上 RST 來中斷 TCP 連接。
7.3 UDP 探測
可能有部分應用使用的是 UDP 協議。在此協議下可以通過報文來進行探測指定的 IP + 端口。最佳實踐同樣可以借鑑阿里雲的 SLB 機制，如下圖：
結果的判定方式是：在服務端沒有返回任何信息的情況下，默認是正常狀態。否則會返回一個 ICMP 的報錯信息。