通常來說，負載均衡的職責是將網絡請求或者其他形式的負載“均攤”到不同的機器上，避免集羣中部分服務器壓力過大，而另一些服務器比較空閒的情況，讓每臺服務器獲取到適合自己處理能力的負載。在爲高負載服務器分流的同時，還可以避免資源浪費，一舉兩得。
負載均衡可分爲軟件負載均衡和硬件負載均衡，其中軟件負載均衡比較常見，比如Nginx，它會對接受請求進行分配，避免少數服務提供者負載過大而導致的部分請求超時。因此將負載均衡到每個服務提供者上，是非常必要的。
在分佈式的微服務系統中，多臺服務器同時提供一個服務，並統一到服務配置中心，消費者通過查詢服務配置中心，獲取服務到地址列表，需要選取其中一臺來發起RPC遠程調用。如何選擇則取決於具體的負載均衡算法，對應於不同的場景選擇不盡相同。負載均衡算法的種類有很多種，常見的負載均衡算法包括輪詢法、隨機法、源地址哈希法、加權輪詢法、加權隨機法、最小連接法、Latency-Aware等，需根據具體的應用場景選取對應的算法。
本文將圍繞愛奇藝內容理解業務對TFServing服務調用的幾個問題，以及應對這些問題的解決思路和方案進行介紹。
01
背景介紹
愛奇藝內容理解業務大多使用深度學習模型，而模型的在線服務依賴於愛奇藝深度學習推理平臺。通常，推理平臺使用gRPC作爲服務框架，部署在QAE平臺上，使用QLB四層(以下簡稱QLB-4)作爲負載均衡方案。理論上一個VIP對應多臺後端服務器，通過QLB-4自身的負載均衡策略，可以實現有效的服務器負載均衡訪問，但是在大量的深度學習模型在線服務調用過程中，我們發現有以下幾類問題：
QLB-4未能實現真正的負載均衡，流量未被均勻分配，存在部分服務器訪問量明顯過多問題。
當有新的服務端實例時(包括重啓和新增場景)，客戶端流量不能分配到新的服務端實例上，需要重啓客戶端，流量纔會重新分配到新的服務端實例。
當客戶端數量小於服務端數量時，一定會有部分服務端一直沒有接收到客戶端請求。
02
基於QLB-4的TFServing服務調用一
些問題的實驗復現
本次實驗將gRPC 客戶端和服務端均部署在QAE上，服務端入口網絡流量這一指標能直接體現服務端請求接收情況，因此選用服務端入口網絡流量作爲觀測指標。以下實驗圖x軸爲時間軸，y軸爲當前時間段網絡流量的平均值，具體實驗如下：
問題1：QLB-4未能實現真正的負載均衡，流量未被均勻分配，存在部分服務器訪問量明顯過多問題。
實驗機器數量配置如下表：
圖(a) 使用QLB-4 的gRPC 客戶端在服務端的流量分佈情況
圖(a)中，兩個服務端實例接收到的流量大概爲2:1，說明是有兩個客戶端請求流向了同一個服務端。
問題2： 當有新的服務端實例時，客戶端流量不能分配到新的服務端實例上。
實驗機器數量配置如下表：
圖(b) 使用QLB-4 的gRPC 客戶端在新增服務端的流量分佈情況
圖(b)中，新增的服務器實例C啓動後，並沒有客戶端流量打向新增節點C；
問題3：當客戶端數量小於服務端數量時，一定會有部分服務端一直沒有接收到客戶端請求。
實驗機器數量配置如下表：
圖(c) 使用QLB-4 的gRPC 調用在服務器數大於客戶端數情況下流量分佈情況
從圖(c)中可以看出，在服務器數大於客戶端數的情況下，服務器C一直沒有流量進入。
03
問題原因分析
QLB-4是工作在OSI第四層(TCP)的負載均衡器，主要工作流程如下圖(一)所示：客戶端通過VIP(VirtualIP Addres)訪問網絡服務，請求報文到達調度器，調度器根據連接調度算法從一組真實服務器中選出一臺服務器，將報文發送給選出的服務器。同時，調度器在連接Hash路由表中記錄這個連接，當這個連接的下一個報文到達時，從連接Hash路由表中可以得到原選定服務器的地址和端口，用同樣的方式將報文傳給原選定的服務器。整體流程如下圖1所示：
圖1.QLB-4 負載均衡原理圖
對於問題1，由於初次調用路由表會作記錄，就相當於調度器會爲每個客戶端連接分配一臺固定的服務器，未能實現實時的請求動態路由轉發，進而不能實現真正的負載均衡調用；
對於問題2，當新的服務端實例啓動時，雖然QLB-4會增加，但由於客戶端連接在Hash 路由表中沒有改變，報文到達QLB-4後，還是會被轉發到原選定的服務器。當客戶端重啓後，TCP連接重新建立，調度器會爲客戶端重新選擇服務器，此時新的服務器實例有可能被調度器選擇，將報文轉發到新的服務實例。如果一定要實現新的服務端調用，爲此就需要重啓客戶端，帶來極大的上線運維問題；
對於問題3，如果服務器數量多於客戶端，由於一個客戶端只會對應固定的一臺服務器，就一定會存在服務端沒有被調度器選中的情況，即使按照每個客戶端都由不同的服務器來提供服務計算，也會有大於客戶端數量的服務器資源浪費，而GPU資源本身就比較昂貴，所以浪費成本會比較大。
04
解決方案
解決方案一：基於QLB-4的負載均衡優化
QLB-4負載均衡的主要問題是在於Hash 路由表中緩存記錄的時效性和全面性，QLB-4負載均衡中Hash 路由表的存在主要是爲了快速查找後端服務器，但是由於在服務器發生變化時未能及時更新，進而引起了上述的一些問題。故基於Hash 路由表的改進點如下:
1. 在服務器發生變化時清空Hash 路由表，再重建，可以解決Hash 路由表中緩存記錄的全面性問題；
2. 對Hash 路由表中緩存記錄設置過期時間，這樣在某一個時間點來看，可能還有負載不均衡問題，但可以實現全局性的負載均衡。
QLB-4負載均衡的所有問題基本都來自於Hash 路由表，故亦可以考慮去掉Hash 路由表的方案，即進行實時的負載均衡調度，但是效率上會比Hash 路由表有所下降，不適合高併發場景。
解決方案二：客戶端負載均衡
使用客戶端負載均衡策略，基於公司服務註冊中心，客戶端負載均衡工作方式是將服務列表清單存儲在本地，通過定時任務刷新本地緩存，然後對服務列表進行輪詢的方式達到負載均衡的作用，與QLB-4相比的優點主要有：
1. 客戶端負載均衡是基於請求端做的負載均衡，能夠均勻地將流量分配到各個服務端；
2. 客戶端負載均衡中客戶端與服務端是直連方式，比QLB-4要少一跳，能有效減少網絡轉發耗時對RPC的影響。實現客戶端負載均衡的重點是如何自動的獲取服務列表並保證服務列表的有效性，結合公司Skywalker微服務框架，我們引入Consul組件作爲客戶端負載均衡的服務發現引擎，原理如下圖2所示：
圖2.客戶端負載均衡原理圖
整體工作原理詳細描述：
1、 基於gRPC 的TFServing服務端實例啓動，首先會向 ConsulAgent 註冊實例，ConsulAgent 定時向服務進行健康檢查。這一步Skywalker已經實現，我們只需要簡單的配置就能實現將服務註冊到相應的數據中心。在同一個數據中心下，ConsulAgent 之間的數據是共享的，因此我們只需要部署一個ConsulAgent加入對應的數據中心，就能方便的查詢相關TFServing服務的健康節點信息。
2、 gRPC 客戶端向Consul Agent 發送請求，通過服務名獲取相關服務的節點信息。爲了維護客戶端服務列表的有效性，我們需要定時向Consul 發送請求信息，及時獲取最新的服務列表。特別注意的是，如果在定時請求服務列表的間隙，服務端某個實例變得不可用，這種情況下，我們通過gRPC客戶端重試機制來解決，客戶端重試的時候會爲此次請求輪詢地選擇下一服務節點發送RPC，避免此次請求失敗。
3、 客戶端負載均衡器爲服務列表創建Channel連接池，裏面包含和每一個TFServing服務器的連接通道。
4、客戶端調用時負載均衡器會根據具體的負載均衡算法選擇一個TFServing服務器Channel連接。
5、客戶端通過該Channel連接向選擇的服務器發送gRPC請求，若成功，則結束；若失敗，則重試最大次數至成功。
方案對比：方案一依賴於QLB-4的改進和實現，由公司中間件平臺主要負責，考慮到其他業務場景的限制，最終我們選擇了方案二，在客戶端實現負載均衡，不僅實現了功能，還提升了調用效率。
05
總結
最終的解決方案上線後，線上的TFServing服務調用穩定，不再出現負載不均和上下線服務無法發現和調用問題。不僅解決了之前服務發佈後，客戶端需要重啓的運維難題，降低了運維成本，而且實現了服務器的合理調度，避免了公司昂貴的GPU資源的浪費，降低了整體的硬件成本。
關注我們，更多精彩內容陪伴你！
本文分享自微信公衆號 - 愛奇藝技術產品團隊（iQIYI-TP）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。