面向微服務架構的云系統負載均衡機制

施凌鵬，朱 征，周俊松，李 鑫，李 靜

（1.國網上海市電力公司 信息通信公司，上海 200072；2.國網上海市電力公司 電力科學研究院，上海 200437；3.南京航空航天大學 計算機科學與技術學院，南京 210023）

0 概述

單體架構應用在面臨當前互聯網環境的快速迭代和用戶需求的迅猛變化情形時，開發成本與運維成本大幅上升，因此，越來越多的應用采用微服務的架構。微服務架構（Microservices Architecure，MSA）是面向服務架構（Service-Oriented Architecure，SOA）的一種變體［1］，是將一個大型的復雜軟件應用拆分為多個松耦合的微服務，集群調度和擴容的粒度降低到微服務實例級別，能夠降低開發、部署和擴縮容的成本［2］。

在降低服務粒度的同時，服務治理將面臨更大的挑戰。請求通常需要通過若干個與之相關的微服務的處理才能夠將正確預期的結果返回給用戶。而在復雜微服務框架下如何治理請求以及優化請求的處理時延是本文研究的目標。

本文通過負載均衡與加入微服務鏈感知的方法降低微服務架構中服務請求的時延，并提出基于微服務鏈感知的負載均衡算法。闡述微服務架構部署場景，繪制云數據中心的架構拓撲圖，并給出微服務實例、微服務鏈和主機描述及用戶請求延遲的衡量標準，以減少微服務鏈在數據中心網絡中的通信成本。最后基于形式化的模型，根據Python 編寫模擬實驗，并設置多組接近于真實環境的不同實驗。

1 相關工作

微服務概念是由LEWIS 等于2014 年定義的，它是一種架構風格［3］和SOA 的具體實現［4］，主要思想是將傳統單體應用根據業務邏輯和其功能拆分成一系列可以被獨立設計、開發、部署、運維的軟件服務單元，并且在遵守服務邊界的前提下，各個微服務能夠彼此相互配合與協作來實現整個系統的價值［5］。

MSA 是指根據整個應用系統的業務需求，通過預先劃定服務邊界、定義微服務進行服務組合而形成的企業級分布式應用體系架構［6］。文獻［7-8］研究傳統云計算架構中的任務調度與負載均衡問題，而針對微服務的治理未進一步擴展。文獻［9］研究基于服務網格的微服務治理方案，但沒有涉及對服務鏈治理問題。

文獻［10-11］對容器運行時的系統進行了基于事件的性能分析，提出在以容器為基礎的微服務系統中，負載均衡對微服務具有顯著影響。文獻［12］通過沙盒化微服務構建性能模型，合理地為不同服務配置容量，從另一種角度對負載問題提出了可行的解決方案。文獻［13］提出基于消息隊列的面向鏈的負載均衡算法，將HTTP 與消息隊列結合使用，但在微服務系統中會導致額外的操作復雜度，增加開銷。

本文在上述研究的基礎上，針對微服務鏈調用中存在共享微服務競爭的問題，從負載均衡的角度入手分析云化微服務架構下的特點，提出微服務鏈感知的請求負載均衡算法，并通過模擬實驗從微服務鏈上的平均請求延遲和主機請求負載均衡的角度對算法進行有效評估。

2 微服務鏈感知的請求負載均衡算法

本節從微服務鏈式調用的場景出發，通過預先對請求對應的微服務鏈進行建模分析，獲取最優的服務執行路徑，實現對負載配置和請求延遲的綜合優化。

2.1 應用場景描述

2.1.1 數據中心網絡

本文從實際場景出發，對云數據中心的微服務通信組合問題展開研究。數據中心網絡拓撲結構如圖1 所示。

圖1 數據中心網絡拓撲結構Fig.1 Structure of data center network topology

微服務以容器的方式進行部署并運行在主機上，同一主機可同時部署多個微服務實例，因此將主機Hi描述為一個微服務實例的子集，即Hi?I。微服務實例與主機之間的關系如式（1）所示：

2.1.2 微服務鏈

微服務鏈是微服務的有序集合，為本文微服務通信組合的主要研究對象，以符號Ci表示，i為該微服務鏈的唯一標識。

用戶請求Ri由特定微服務鏈提供響應，i是用戶請求的唯一標識。用戶請求將唯一對應一個微服務鏈，式（2）描述了該映射關系：

圖2 所示為用戶請求由一個基本的微服務鏈對應的過程。其中，箭頭代表數據傳輸的方向，箭頭上的符號DA代表微服務，MA代表傳送給微服務，MB代表請求的數據大小，DB、DC、DD以此類推，在服務鏈式調用的場景下，服務間的傳輸時延同樣會對服務性能產生較大影響，因此通過DA計算傳輸時延，并以此作為鏈路權重。

圖2 微服務鏈簡單拓撲Fig.2 Simplified topology of microservice chain

微服務鏈可以表示如下：

其中：Mi表示微服務實例對象，i為唯一性標識。

2.1.3 微服務與微服務實例

微服務鏈與微服務實例之間存在多對多的關系，通過式（4）描述微服務與微服務鏈聯系：

2.2 系統模型

復雜網絡中頻繁多次的請求是造成服務時延增加的主要原因［11］，本文將負載均衡問題拓展為微服務環境下服務通信組合調用問題，以微服務鏈為研究對象，尋求服務鏈式組合情況下的性能優化策略。

本節將影響微服務環境中負載配置和請求響應效率的關鍵因素予以形式化處理（見表1），并基于此構建面向微服務鏈的請求響應模型。

表1 參數的形式化描述Table 1 Formalized description of the parameters

為簡化抽象系統，本文重點研究微服務環境下的服務請求問題［14］，設定微服務實例所獲資源相同，且主機環境同構，并將主機任務（即微服務實例運行的任務）串行化。

所有發向負載均衡器的請求由一個特定隊列接收，并對隊列中的請求分別構建微服務通信組合模型，通過代價函數遍歷組合實例得到代價最小的實例組合［15］，該組合在一段時間內具有有效性。

2.3 衡量指標

衡量指標是結果分析中的重要因素，針對云系統下的微服務架構環境，本文選取微服務鏈上的平均請求延遲和主機負載作為衡量指標［16］。

微服務鏈上的平均請求延遲計算方法如式（5）所示：

其中：li是單個請求的延遲時間［17-18］，如式（6）所示，主要由等待執行時間和請求數據傳輸時間組成：

其中：h（k）為k實例所在的主機；Q（x）為所有在主機x隊列中的請求；i（r）為獲取請求r所在的實例。

除等待時間外，數據傳輸時間對請求響應的性能同樣也有顯著影響，因此為傳輸鏈路設置權重如式（9）所示：

傳輸速度使用2 個微服務實例之間的距離進行衡量，如式（10）所示：

綜上，可計算出每個微服務鏈上的平均請求延遲。平均請求延遲代表整個微服務架構中服務質量方面的性能，若微服務鏈上的平均請求延遲越小，則證明該架構的服務質量越高。

2.4 算法設計

微服務鏈感知的請求負載均衡算法如算法1所示。

算法1微服務鏈感知的請求負載均衡算法

輸入用戶請求集合R

輸出請求微服務實例的順序

算法1 首先接收到用戶的請求，通過用戶請求內容分析出功能所屬的微服務鏈，根據微服務鏈確定該鏈上的微服務類型以及它們的依賴關系；再借助微服務鏈中的數據傳輸信息，分析出首要解決的微服務通信組合，并使用代價函數對其組合中的實例進行遍歷計算，尋找出所得代價最小的實例組合，使用該實例組合對該請求的微服務實例順序進行更新；然后繼續去尋找需要優化的微服務通信組合。重復上述過程，直到所有微服務都選中了實例，最終將接受請求并將微服務實例請求順序與請求本身一并轉發，完成對該請求的負載均衡。

為簡化分析算法的時間復雜度，假定請求對應的微服務鏈中微服務集與數據集數目均為n，數據集DSSet 預先排序降低之后的時間開銷，算法的時間復雜度主要由排序算法和while 循環的時間開銷共同決定，因此總的時間復雜度為O（nlbn）。

3 仿真實驗結果與性能分析

模擬實驗根據Python 編寫，通過面向對象的編程范式來對上文的問題模型進行抽象和編寫。當前有很多的云模擬器如CloudSim［19］，但大部分云模擬器都是面向虛擬機模式的，較少有支持容器這種新型的進程隔離“虛擬化”方式，也因為問題模型較為獨特，所以參考文獻［20］采用自定義調度器的方案。

3.1 參數設置

以上文設計的模型為基礎，模擬實驗中的網絡架構與數據中心網絡架構一致，即1 個路由器、2 個交換機、3 臺主機。在該模擬實驗中，模擬的時間片的單位為ms，數據量大小為KB，對于某個微服務而言，其返回數據量范圍為1～100 KB，其實例處理請求的時間范圍為1～10 ms。通過在程序初始化中描述不同的微服務來確定其返回的數據量大小與單一請求處理時長。對于數據中心網絡之間的傳輸鏈路，本文粗略地將其認為是一個定值，也可以理解為是其鏈路的權重。對于同主機的2 個實例，它們之間通信的速率主要受到磁盤吞吐量的限制；對于同機架不同主機的2 個實例，它們之間的通信速率主要受到網卡吞吐量的限制；最后對于不同機架實例之間的通信，速率應該是三者最低的，而且考慮到數據中心骨干網絡的壓力。具體實驗參數如表2 所示。

表2 實驗參數設置Table 2 Parameters setting of experiment

本文主機同構的串行化假設主機性能相同，不需要使用加權輪詢（RR）。因此，輪詢的負載均衡算法成為本文的對比算法。

3.2 微服務鏈上的平均請求延遲評估

本文通過設置不同的微服務鏈、不同的實例放置方法、不同的請求發送機制和不同的負載均衡算法進行多次實驗。

3.2.1 3 條微服務鏈

本文微服務實例放置方式如圖3 所示，設置的3 條微服務鏈如圖4 所示。

圖3 3 條微服務鏈實例放置方式Fig.3 Instances placement way of three microservice chains

圖4 3 條微服務鏈簡化拓撲Fig.4 Simplified topology of three microservice chains

3 條微服務鏈分別為：C1=｛MA，MB，MC，MD｝，C2=｛ME，MF，MG｝，C3=｛MH，MF，MI，MJ｝。

相關的微服務詳細信息如表3 所示。

表3 3 條微服務列表Table 3 List of three microservices

本文使用對3 條微服務鏈輪流請求的請求模式，每2 個時間片（2 ms）向系統中發送1 個服務請求，并通過式（5）計算每個微服務鏈的平均請求延遲，得到如圖5 所示的結果。

圖5 3 條微服務鏈的平均請求延遲Fig.5 Average request latency of three microservice chains

本文提出的負載均衡方法的微服務平均延遲低于輪轉調度的方法（-18.47%，-12.30%，-2.62%），取得了較好的結果。

3.2.2 1 條微服務鏈

除了3 條微服務鏈的情況外，本文還設置了僅有1 條微服務鏈的實驗（C1=｛MA，MB，MC，MD｝），以驗證本文算法在不同頻次請求下的性能，微服務詳細信息如表4 所示。

表4 1 條微服務列表Table 4 List of one microservice

對于1 條微服務鏈的情況，本文設置2 種請求模式來衡量性能，部署模式如圖6 所示。首先向系統發送中等頻次的輪流請求，即每3 個時間片（3 ms）發送1 個請求，并通過式（5）計算微服務鏈的平均請求延遲，得到如圖7 所示的結果。

圖6 1 條微服務實例的放置方式Fig.6 Instances placement way of one microservice chain

圖7 中頻次請求的平均延遲Fig.7 Average latency of medium frequency requests

從圖7 可以看出，本文的方法能夠極大地降低請求延遲，降低幅度達到73.6%。

為測試極端情況的性能（如高并發情景），向系統發送高等頻次的輪流請求，即每2 個時間片（2 ms）發送一個請求，得到如圖8 所示的實驗結果。

圖8 高頻次請求的平均延遲Fig.8 Average latency of high frequency requests

從圖8 可以看出，本文方法即使在高負載情況下也有更好的性能。綜合上述實驗結果，在復雜多條微服務鏈的環境中，也就是更接近于真實微服務架構的環境中，該算法能夠有效降低請求延遲。

3.3 主機負載情況評估

由于容器進程隔離的特性，容器能夠與宿主機共享內核和計算資源。基于2.2 節所提的串行化假設，當請求任務在執行時，則能夠利用當前主機所有可用的計算資源。因此，本文只要通過每個主機的請求等待序列，并根據微服務劃分的執行速度權重，就能夠很好地衡量出主機實際的負載情況。

3.3.1 3 條微服務鏈請求模式

對于3 種微服務鏈輪流請求的請求模式，每2 個時間片（2 ms）向系統中發送一個服務請求，并在每個時間片中記錄每個主機的負載值，得到的結果如圖9 所示（彩圖效果見《計算機工程》官網HTML 版，下同）。

圖9 3 條微服務鏈分別請求下的主機負載情況Fig.9 Host load conditions under separate requests of the three microservice chains

從圖9 可以看出，本文方法能夠使主機之間的負載更加均衡，而輪轉調度方法會造成嚴重的負載傾斜。

3.3.2 1 條微服務鏈部署模式

對于1 條微服務鏈的部署模式，首先需要向系統發送中等頻次的請求，即每3 個時間片（3 ms）發送一個請求，然后通過記錄每個時間片上主機的負載值，得到如圖10 所示的1 條微服務鏈中頻次請求下主機負載情況。

圖10 1 條微服務鏈中頻次請求下的主機負載情況Fig.10 Host load conditions under separate requests of one microservice chain

圖10（a）為使用本文算法的主機負載情況，圖10（b）為使用輪轉算法的主機負載情況，可以看到在2 組實驗中本文方法主機之間的負載會更均衡，而輪轉調度方法還是會存在嚴重的負載傾斜。

通過向系統發送高頻次的請求，即每2 個時間片（2 ms）發送1 個請求，得到如圖11 所示的主機負載情況。從圖11 可以看出，在2 組實驗中，本文方法主機之間的負載會更均衡，而輪轉調度方法還是會存在嚴重的負載傾斜。

圖11 1 條微服務鏈高頻次請求下的主機負載情況Fig.11 Host load conditions under single high-frequency request of one microservice chain

3.4 實驗結果

本文通過在4 個3 條微服務鏈和4 個1 條微服務鏈上不同的實驗，根據不同的實例設置方式和請求模式，得到了較為接近真實環境的實驗結果。

在3 條微服務鏈的環境中，使用本文負載均衡策略的實驗在微服務鏈的平均請求延遲上要比對比策略更低，主機的負載情況會比對比算法更加均衡。同時，本文算法在微服務鏈之間相互有交叉（即相關）的情況下表現更加優異，能夠在極大地降低微服務鏈請求平均延遲的同時，保證主機負載的均衡。

在1 條微服務鏈的環境中，當微服務實例較少且擺放方案不均勻時，本文微服務鏈感知的負載均衡策略能夠有效地降低微服務鏈的請求時延，并且在高并發場景下仍有較好的表現，能夠保證在接近于真實微服務架構環境中的復雜微服務鏈下，本文的負載均衡策略可有效降低請求延遲。

在主機負載方面，本文算法能夠取得較為均衡的結果，而輪轉調度方式會經常出現嚴重的負載傾斜。

4 結束語

本文從微服務架構的服務調用與負載均衡出發，結合傳統云計算架構中的負載均衡和任務調度算法，根據微服務賦予云環境下的感知能力，提出微服務鏈感知的請求負載均衡算法。通過降低微服務架構中請求延遲時間平衡主機之間的負載，解決服務鏈調用中存在共享微服務競爭的問題。實驗結果表明，該算法能夠在復雜微服務請求調用鏈下降低請求平均延遲，有效均衡主機的工作負載。隨著容器技術和微服務架構的不斷發展，軟件行業將對微服務治理提出更高的優化目標，由于微服務基于容器運行時的特點，下一步將微服務部署與優化相結合，提出更適用于特定場景的部署方案。