掌握輕量級開源 Web云服務器Tengine負載均衡算法的方法和步驟

下文給大家帶來掌握輕量級開源 Web云服務器Tengine負載均衡算法的方法和步驟，希望能夠給大家在實際運用中帶來一定的幫助，負載均衡涉及的東西比較多，理論也不多，網上有很多書籍，今天我們就用億速云在行業內累計的經驗來做一個解答。以阿里巴巴為例。                                                           

在阿里七層流量入口接入層（Application Gateway）場景下， Nginx 官方的Smooth Weighted Round-Robin（ SWRR ）負載均衡算法已經無法再完美施展它的技能。 Tengine 通過實現新的負載均衡算法Virtual Node Smooth Weighted Round-Robin（VNSWRR ）不僅優雅的解決了 SWRR 算法的缺陷，而且QPS處理能力相對于 Nginx 官方的 SWRR 算法提升了60%左右。

問題
接入層 Tengine 通過自研的動態 upstream 模塊實現動態服務發現，即運行時動態感知后端應用機器擴縮容、權重調整和健康檢查等信息。同時該功能可以做很多事情，比如用戶可通過調整后端應用某臺機器的權重從而達到線上真實引流壓測目的。然而，這些操作在 Nginx 原生 SWRR 算法下卻可能引起不可逆轉的血案。
在接入層（Application Gateway）場景下， Nginx 的負載均衡算法 SWRR 會導致權重被調高機器的QPS瞬間暴漲，如上圖App2-host-A機器當權重調整為2時，某一時刻流量會集中轉發到該機器；
Nginx 的 SWRR 算法的處理時間復雜度是O(N)，在大規模后端場景下 Nginx 的處理能力將線性下降；
綜上所述，對接入層 Tengine 的負載均衡轉發策略的改造及性能優化已迫在眉睫。
原生 SWRR 算法分析
在介紹案列之前，我們先簡單介紹下 Nginx 的負載均衡算法 SWRR 轉發策略及特點：
SWRR 算法全稱是Smooth Weighted Round-Robin Balancing，顧名思義該算法相比于其它加權輪詢（WRR）算法多一個smooth（平滑）的特性。
下面我們就一個簡單的列子來描述下該算法：
假設有3臺機器A、B、C權重分別為5、1、1，其中數組s代表機器列表、n代表機器數量，每個機器的cw初始化為0、ew初始化為機器權重、tw代表本輪選擇中所有機器的ew之和、best表示本輪被選中的機器。簡單的描述就是每次選擇機器列表中cw值最大的機器，被選中機器的cw將會減去tw，從而降低下次被選中的機會，簡單的偽代碼描述如下：
best = NULL;
tw = 0;
for(i = random() % n; i != i || falg; i = (i + 1) % n) {
flag = 0;
s[i].cw += s[i].ew;
tw += s[i].ew;
if (best == NULL || s[i].cw > best->cw) {
best = &s[i];
}
}
best->cw -= tw;
return best;
請求編號 選擇前的權重值 被選中的server 選擇后的權重值

0 {5,1,1} A {-2,1,1}
1 {3,2,2} A {-4,2,2}
2 {1,3,3} B {1,-4,3}
3 {6,-3,4} A {-1,-3,4}
4 {4,-2,5} C {4,-2,-2}
5 {9,-1,-1} A {2,-1,-1}
6 {7,0,0} A {0,0,0}
其 SWRR 算法選擇的順序為：{ A, A, B, A, C, A, A }
而普通WRR算法選擇的順序可能為：{ C, B, A, A, A, A, A }
SWRR 相比于普通的WRR算法特點：平滑、分散 。
調高權重引發的血案
從上面的描述來看， SWRR 算法似乎已經比較完美了，但是在某些場景下還是有一定的缺陷，下面我們就一個真實的案列來看看它都有哪些缺陷：
一天早上，流量調度的同學匆忙的跑到我的工位，當時看他神色是尤為的緊張，心想肯定是出啥問題了。果不其然："為啥我把中心機房某臺機器的權重從1調整為2的時候，接入層 Tengine 并不是按照這個權重比例轉發流量恩？"，當時被調高機器QPS變化趨勢如下圖所示：
注：其中深藍色曲線表示權重被調高機器的QPS變化，淺綠色曲線表示該集群單機的平均QPS。
當時看到這個流量趨勢變化圖的時候也是一臉茫然，不過好在有圖有數據，那就可以先分析一下這個圖的幾個特征數字；由于部分數據敏感，詳細數據分析就不在此處展開。直接描述其現象和原因：
被調高權重的機器當時被分發到的流量基本上是該應用機房總流量的1/2，一段時間后該機器的流量才恢復到預期的權重比例。其原因就是由于接入層 Tengine 對后端機器信息的變化是動態感知熱生效的，而 Nginx 官方的 SWRR 算法策略第一次會選擇當前機器列表中權重最大的機器轉發流量。從而進一步導致已感知到后端機器權重變化的接入層 Tengine 都會將第一個請求轉發到權重被調高的機器上。
大規模下性能驟降
如下是在upstream里面配置2000個后端，在反向代理場景下壓測 Nginx 的函數熱點圖如下所示。其中ngx_http_upstream_get_peer函數CPU消耗占比高達39%，其原因是因為 SWRR 算法的選取機器的時間復雜度為O(N) (其中N代表后端機器數量)，這就相當于每個請求都要執行接近2000次循環才能找到對應本次轉發的后端機器。
? 壓測環境
CPU型號： Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
壓測工具：./wrk -t25 -d5m -c500 http://ip/t2000
Tengine 核心配置：配置2個worker進程，壓力源 --長連接--> Tengine / Nginx --短連接--> 后端
下面我們做個試驗，控制變量是 upstream 里面配置的 server 數量，觀察不同場景下 Nginx 的 QPS 處理能力以及響應時間RT變化情況。從圖中可以發現當后端 upstream 里面的 server 數量每增加500臺則 Nginx 的 QPS 處理能力下降 10% 左右，響應RT增長 1ms 左右。
從上面的分析基本上已經確認是 SWRR 算法存在如上兩個缺陷，下面就開始解決；
改進的 VNSWRR 算法
雖然經典的WRR算法（如隨機數方式實現）可以在時間復雜度上達到 O(1) ，而且也可以避免 SWRR 算法調高權重的選取缺陷。但是在某些場景下（如小流量）可能造成后端的流量不均等問題，尤其是在流量瞬間暴漲的場景下有太多不可確定性。于是就構思是否有一種算法即能擁有 SWRR 算法的平滑、分散特點，又能具備 O(1) 的時間復雜度。所以就有了Virtual Node Smooth Weighted Round-Robin（ VNSWRR ）算法。
此處拿個列子來說明此算法：3臺機器A、B、C權重分別為1、2、3，N代表后端機器數 、TW代表后端機器權重總和。
算法關鍵點
o 虛擬節點初始化順序嚴格按照 SWRR 算法選取，保證初始化列表里的機器能夠分布足夠散列；
o 虛擬節點運行時分批初始化，避免密集型計算集中。每批次虛擬節點使用完后再進行下一批次虛擬節點列表初始化，每次只初始化min(n, max)個虛擬節點；
算法描述
o Tengine 程序啟動或者運行時感知后端機器信息變化時，則構建TW個虛擬節點且第一次只初始化N個節點（注：TW代表后端機器權重之和，N代表后端機器數）；
o 各個進程設置隨機起點輪詢位置，如上圖的Step 1對應的列表其起

看了以上關于掌握輕量級開源 Web云服務器Tengine負載均衡算法的方法和步驟，如果大家還有什么地方需要了解的可以在億速云行業資訊里查找自己感興趣的或者找我們的專業技術工程師解答的，億速云技術工程師在行業內擁有十幾年的經驗了。