一、背景簡介

1.1、現狀

?實際生產環境中，復雜業務系統對分布式服務集群架構的依賴。

?服務集群異質化節點的容器化部署，機器性能超賣現象不可避免、性能不均情況時有發生。

?服務集群各硬件組件出錯率不可避免[1]，上層業務相關的應用軟件系統需考慮容錯設計。

?大促流量分布變化難以準確預見，系統服務穩定性與機器資源成本之間需進行妥善權衡。

1.2、問題

?集群內負載不均，整體資源利用率低。

?單節點過載容易觸發集群整體擴容。

?節點偶發硬件（CPU、網卡、內存等）異常影響業務服務整體可用率。

?大促等分布多變的線上流量容易導致集群服務穩定性問題。

1.3、需求

設計合理的負載均衡策略（LB）來提高服務集群的資源利用率和服務穩定性，以有效應對大促復雜多變的流量對系統服務的沖擊。

二、理論基礎

2.1、通用負載均衡問題

負載均衡是提高系統資源利用率和并行計算性能的一個關鍵技術，可分為靜態和動態兩類。如果負載可以在運行之前確定并事先將負載劃分，則屬于靜態負載均衡問題；若只能在運行時測量負載并動態確定負載劃分，則屬于動態負載均衡（DLB）問題。

對于給定的一個包含計算和通訊的任務集合，以及一組通過一定拓撲連接起來的計算機，求解任務到計算機的一個映射，使得求解該問題的時間最小，這就是負載均衡的目標[2]。

2.2、負載均衡策略匯總

2.2.1、分布式策略

實現分布式的負載均衡可有多種策略，其中一個基本策略就是近鄰法。在該策略中，每個處理器和相鄰處理器交換負載，實現和相鄰處理器間的負載均衡，并經過多次迭代達到全局負載均衡。它主要包括擴散法、維交換法（DEM）和梯度法（GM）。

2.2.2、集中式策略

在集中式策略中，每個處理器的計算負載和通訊發送到一個指定的處理器，該處理器負責收集、處理全局的負載信息，并做出全局的負載均衡決策。

2.2.3、混合/層次策略

為了最小化負載均衡開銷，一些負載均衡方法重在研究如何根據層次拓撲結構來構建一個層次樹的問題。利用層次樹進行多級負載均衡，根據層次化的網絡結構將處理器劃分為多個組（均衡域），由這些均衡域組織成一個層次結構。在層次結構中的每一層，相鄰的域間進行負載均衡，并且從底層至上層，在每層執行相同的域間負載均衡過程，最后在根節點完成全局的負載均衡。

2.3、負載均衡算法層級

2.3.1、系統級負載均衡

?DNS負載均衡

DNS負載均衡是一種使用DNS（域名系統）來分散到達特定網站的流量的方法。基本上，它是通過將一個域名解析到多個IP地址來實現的。當用戶試圖接入這個域名時，DNS服務器會根據一定的策略選擇一個IP地址返回給用戶，以此來實現網絡流量的均衡分配。

?Nginx負載均衡

Nginx是一種高效的Web服務器/反向代理服務器，它也可以作為一個負載均衡器使用。在負載均衡配置中，Nginx可以將接收到的請求分發到多個后端服務器上，從而提高響應速度和系統的可靠性。Nginx是負載均衡比較常用的方案。

?LVS/F5+Nginx

Nginx一般用于七層負載均衡，其吞吐量是有一定限制的，如果網站的請求量非常高，還是存在性能問題。為了提升整體吞吐量，會在DNS和Nginx之間引入接入層，如使用LVS（軟件負載均衡器)、F5（硬件負載均衡器）可以做四層負載均衡，即首先DNS解析到LVS/F5，然后LVS/F5轉發給Nginx，再由Nginx轉發給后端真實服務器。

2.3.2、應用級負載均衡

?Ribbon負載均衡

Ribbon是一個開源的、基于HTTP和TCP的客戶端負載均衡工具，它提供了一個簡單的、基于配置的負載均衡策略，其通過在客戶端上運行來選擇最佳的服務器。Ribbon提供了多種負載均衡策略，如隨機、輪詢、最少活躍調用等，可以根據實際需求選擇合適的策略。當客戶端連接到服務器后，Ribbon會根據服務器的響應速度、負載情況等因素進行評估，并動態調整選擇的服務器。這種方式可以實現更靈活的負載均衡，提高系統的可用性和性能。

?Dubbo負載均衡

Dubbo是一種高性能的分布式服務框架，它提供了一套完整的服務治理解決方案。其中，負載均衡是Dubbo框架的重要特性之一，它可以幫助我們實現服務調用的負載均衡，提高系統的性能和可靠性。通過配置文件或編程方式，我們可以基于Dubbo框架在多個服務提供者之間靈活地進行請求分發，以實現請求的負載均衡。具體地，其提供了多種負載均衡策略，包括隨機、輪詢、最少活躍調用等。

三、方案實踐

3.1、模型系統負載均衡策略演進歷程

圖3-1. 在線模型系統服務常見架構

3.1.1、常見負載均衡策略

?靜態負載均衡技術

?輪詢（Round Robin）、隨機（Random）等；

?處理策略簡單、時效性高，但依賴集群節點同質化假設。

?動態負載均衡技術

?最小鏈接數（Least Connections）、最低時延（Locality Aware）等；

?基于節點相關狀態信息反饋，實時調整分流策略，進而達到期望指標的均衡。

3.1.2、演進一：LB策略適配服務集群業務特點

?在線特征服務集群

?在線廣告業務場景：User & Sku數量龐大、特征類型豐富。

?集群Cache機制保證特征處理時效性，并降低相關依賴服務（如：SKU服務集群）請求壓力。

?LB策略需保證一定的Cache命中率：基于用戶PIN的一致性Hash策略[3]。

?模型預估服務集群

?在線推理過程對請求之間透明，常規隨機Random策略即可。

3.1.3、演進二：LB策略引入“可用率”目標，增強服務穩定性

?問題現象

?集群單節點異常，個別異常節點可用率影響集群整體可用率。

?線上突發流量變化，影響服務穩定性，甚至導致服務不可用，服務集群缺乏自動防護。

?策略升級

?靜態策略 → 動態策略：引入集群節點實時可用率統計指標。

?服務可用率指標直接控制節點流量分配、請求降級/恢復：（1）可用率低于集群平均可用率閾值節點減少分流比例；（2）集群平均可用率低于閾值，開啟降級防護，并周期性嘗試降級恢復。

3.1.4、演進三：LB策略添加“異構硬件利用率”（CPU/GPU）目標，提高資源利用率

?問題現象

?集群異質化節點部署，各節點資源利用不均。

?集群木桶效應嚴重，個別節點性能受限觸發集群整體擴容。

?策略升級

?單目標策略 → 多目標分級策略：進一步添加集群節點CPU/GPU資源利用統計指標。

?服務可用率指標為主，CPU/GPU資源利用率指標為輔。在服務可用率滿足的條件下，進一步調節流量分配比例，實現集群CPU/GPU資源利用率的最大化。

3.1.5、演進四：LB實現框架統一，支撐廣告系統全鏈路算力的最優調度

?問題現象

?模型系統內部各模塊LB框架各異，維護開發成本較高。

?模型系統內、外服務之間的不同LB框架無法復用，阻礙廣告系統全鏈路算力的最優化實現。

?策略升級

?模塊化重構LB策略相關邏輯實現，并統一LB框架，進而打通模型系統內、外服務之間的算力孤島。

3.1.6、總結

?生產環境復雜多變，進而要求LB策略的設計對系統影響穩定且結果可預見。

?業務服務指標和集群性能指標之間相互影響，單目標均衡策略無法兩者兼顧。

?多目標均衡策略必然引入成倍的決策復雜度：k（均衡目標數）* n（C端集群）*m（S端集群）。

?多目標均衡分級：不同目標間相互耦合，難以兼顧！總需要有一個主目標作為兜底。

?均衡目標與均衡策略之間的適配&兼容：（1）多目標（CPU+可用率）、多負載均衡策略（Random、ConsistentHash）適配簡單；（2）新LB策略對舊LB均衡策略的兼容性（CPU均衡對一致性Hash原則的兼容性）。

3.2、“服務可用率+資源利用率”雙目標聯合均衡LB策略

該策略以服務可以率目標為兜底，基于待優化資源利用率目標的期望取值，將任意時刻整個集群的所有節點劃分為 “負反饋列表（refuse list）” 和 “正反饋列表（accept list）” 兩部分，且節點實際取值與期望取值之間的數值差異表征了當前節點在該優化目標上的“均衡度”。同時，負反饋列表中的節點采用減少分流比例策略，正反饋列表中的節點則增加分流比例，而分流策略的具體變化比例由當前節點的均衡度來決定。

3.2.1、雙目標分級反饋

針對在線服務應用場景，往往更關注于服務本身的可用率指標，與之相較的CPU利用率則作為L2級均衡目標，具體地：

?Stage-1：統計當前周期內集群各節點請求的成功數量和失敗數量以計算出單個服務節點的平均可用率；

?Stage-2：通過匯總所有服務節點的平均可用率以獲得集群的平均可用率，并將其作為可用率均衡目標在當前周期內的期望取值；

?Stage-3：基于各節點平均可用率與集群平均可用率之間的差異，確定出各服務節點的均衡度：當前服務節點的可用率已滿足均衡目標，則進一步進行L2級CPU利用率目標均衡；否則，選取下一節點重新進行服務可用率均衡處理。

3.2.2、服務可用率主動防護

?Stage-1：節點選擇，待選擇節點成功率需不低于集群平均成功率。

?Stage-2：成功率更新，雙端隊列固定窗口維護各節點請求RPC狀態，并實時更新集群平均成功率。

?Stage-3：主動防護，周期性統計集群歷史平均成功率，并判斷其變化趨勢：如成功率變差，則觸發主動防護降級；如成功率變好，則逐漸恢復降級防護。

3.2.3、資源利用率（如CPU）漸進式收斂

?Stage-1：集群中所有節點的列表屬性均被初始化為refuse list，同時設置節點分流策略的調整比例

為0;

?Stage-2：收集集群各節點周期性反饋的CPU利用率

，計算出當前集群整體的CPU利用率均值，進而得到CPU利用率均衡目標的期望取值

;

?Stage-3：針對實際迭代場景中不同屬性的集群節點，先根據式 (1)、(2) 獲得節點CPU利用率的實際均衡度

，再通過式 (3)、(4)來完成對應節點分流策略調整比例的迭代更新：

。

3.2.4、收斂域+權重衰減

追求期望指標的絕對均衡，難以兼容與流量分布密切相關的LB策略，如一致性哈希（Consistent Hashing）。

?為

引入容差范圍

，使得均衡目標的收斂從單一基準點擴展為收斂區域。

?定期衰減分流權重，在容差范圍內進一步弱化對一致性Hash原則的影響。

3.2.5、聯合均衡策略特點

?兼顧服務指標（可用率）和性能指標（CPU利用率）。

?漸進收斂，動態調權過程更穩定，且支持收斂域。

四、效果展示

4.1、收斂點

?通過閉環反饋調整邏輯，實現集群平均基準收斂點均衡。

?2022年618期間在模型預估服務集群全量上線，優化整體機器資源利用率10%+。

4.2、收斂域+權重衰減

?CPU使用率 Max/Min Diff 減少 2 倍，服務集群緩存命中率降低控制在2% 以內。

?2022年雙十一期間在模型特征服務集群全量上線，優化整體機器資源利用率15%+。

4.3、異構硬件擴展

不限于CPU利用率的均衡，針對GPU A10、A30異構硬件混合部署的模型預估服務平臺，通過在服務內部增加GPU利用率探針，直接擴展為對GPU硬件利用率的均衡，等效優化機器資源上千核。

4.4、LB框架統一

?LB框架統一后，模型系統內、外服務LB策略完全打通。

?2024年618大促前后模型接入服務模塊完成全量上線，整體CPU資源利用率優化20%+。

五、經驗總結

5.1、穩定調權過程中的異常處理

?權重歸一化，避免權重更新出現發散。

?排除異常節點數據，即使最壞情況下也需保證系統不能差于初始狀態。

?......

5.2、性能極限情況下的主動限流防護

?均衡策略有效的前提：流量變化與均衡目標之間存在相關性！

?節點性能到達極限時，相關性關系可能失效，主動限流防護必不可少。

Reference

1.Wang G, Zhang L, Xu W .What Can We Learn from Four Years of Data Center Hardware Failures[C]//Dependable Systems and Networks.IEEE, 2017.DOI:10.1109/dsn.2017.26.

2.楊際祥,譚國真,王榮生.并行與分布式計算動態負載均衡策略綜述[J].電子學報, 2010, 38(5):9.DOI:CNKI:SUN:DZXU.0.2010-05-023.

3.Mirrokni V , Thorup M , Zadimoghaddam M .Consistent Hashing with Bounded Loads[J]. 2016.DOI:10.48550/arXiv.1608.01350.

4. https://developer.aliyun.com/article/1325514 .

審核編輯 黃宇