一種Dubbo監(jiān)控中心的彈性負載均衡方案

曹 郁 朱志祥

（1.西安郵電大學 西安 710061）（2.陜西省信息化工程研究院 西安 710061）

1 引言

隨著互聯(lián)網的迅速發(fā)展，涌現(xiàn)出越來越多的應用和服務，這些服務導致用戶數(shù)量激增及網絡上的流量爆炸式膨脹，由此出現(xiàn)的分布式服務架構和虛擬化技術受到人們的廣泛關注。Dubbo是一種開源的分布式服務框架，是阿里巴巴SOA服務化治理的核心框架，提供透明的RPC遠程方法調用。Docker是一種輕量的虛擬化技術，具有易用性、隔離性和秒級啟動等特性，它創(chuàng)建簡便、構建快速并且可在任意平臺運行，這種兼容性使得用戶可以在不同平臺間遷移應用。基于Docker容器的Dubbo系統(tǒng)，實現(xiàn)了應用的自動化部署和擴展管理，提高了硬件資源利用率。

一般情況下，服務所承載的負載是相對平穩(wěn)的，但在一些特殊的場景里，如淘寶雙十一、新品網上限量發(fā)售等活動中，短時間內成千上萬的用戶向服務發(fā)出大量的請求。這些請求在給服務提供者帶來巨大利益的同時也會帶來很大的工作負載。若無法及時應對，將會導致服務癱瘓，進而無法響應用戶請求和繼續(xù)提供服務。

在面對高并發(fā)的請求負載時，Dubbo框架本身帶有四種負載均衡策略。但在部署到Docker容器的環(huán)境中，只能對已有的Dubbo容器節(jié)點進行負載均衡，一旦請求量超過所有容器節(jié)點的承載量，Dubbo服務仍將面臨奔潰的危險［1］。針對這一問題，本文提出對Dubbo監(jiān)控中心的改造，根據制定的彈性負載均衡策略，在突發(fā)式工作負載下，橫向彈性伸縮，利用Docker容器秒級啟動和快速部署的優(yōu)點，迅速應對請求量的激增，保證Dubbo服務的正常運行［2］。

2 系統(tǒng)架構設計

系統(tǒng)將Dubbo中的服務提供者Provider，服務消費者Consumer，注冊中心Zookepper和監(jiān)控中心Monitor分別放在不同的容器集群中，通過節(jié)點之間的調用關系將容器連接起來。

Dubbo與Docker結合的架構如圖1所示。

圖1 Dubbo與Docker結合的架構

在提供的應用中Provider Cluster Node需在Zookepper注冊中心注冊服務，將自己所能提供的服務地址暴露到注冊中心，在消費者調用時提供服務；Zookepper是應用的注冊中心，節(jié)點都處在同一級別，并會自動推舉一個Leader，如果其中一臺宕機，則舍棄這個節(jié)點，若Leader宕機，則重新選擇Leader；Consumer Cluster Node在注冊中心查閱到自己所需服務，它只需關注和Zookepper的通信并對自己所需服務向提供者發(fā)起請求，請求通過采用Nginx作為高性能的HTTP和反向代理服務器為向提供者分發(fā)請求；在整個調用過程中Monitor負責管理監(jiān)控連接到Zookepper注冊中心的提供者和消費者，同時記錄消費者和提供者的調用過程和系統(tǒng)運行情況［3］。

Dubbo框架中包含四種負載均衡策略，分別是隨機策略、輪詢策略、最少活躍調用數(shù)策略和一致性Hash策略。隨機策略是按照權重設置隨機概率，使用權比較均勻，有利于動態(tài)調整提供者權重；輪詢策略是按照公約后的權重設置輪詢比率，存在慢的提供者累計請求問題；最少活躍調用數(shù)是指調用前后技術差大的提供者收到更少的請求；一致性Hash策略是將相同參數(shù)的請求發(fā)到同一提供者，當其中一臺提供者無法提供服務時，原本發(fā)往的請求基于虛擬節(jié)點，分攤到其他節(jié)點，從而不會引起巨大變動。

通過對Dubbo所提供的負載均衡策略的分析與研究可以發(fā)現(xiàn)，在一般訪問量的情況下，Dubbo可以利用策略將來自網絡的服務消費者的請求負載均衡到服務提供者的各個Docker容器，保證了容器正常平穩(wěn)的運行［4］。但是當一些特定場景出現(xiàn)時，伴隨著服務消費者請求的大量激增，負載到容器上的請求也會迅速增加，同時容器的性能指標CPU使用率和內存使用率也會隨即上升。若不能及時處理，就會影響到容器的正常運行?；谏鲜鏊岬降膯栴}，引出以下對監(jiān)控中心的改造和彈性負載均衡算法［5］。

3 監(jiān)控中心的改造

原始的Dubbo監(jiān)控中心Monitor負責統(tǒng)計各服務調用次數(shù)，調用時間等，統(tǒng)計先在內存匯總后以固定時間間隔發(fā)送到監(jiān)控中心服務器，并以報表展示，為服務的監(jiān)控運維采集數(shù)據。本系統(tǒng)在現(xiàn)有的監(jiān)控模塊的基礎上，增加了報警模塊和伸縮模塊。它們的交互關系如圖2。

圖2 監(jiān)控中心時序圖

由監(jiān)控模塊對系統(tǒng)進行實時監(jiān)控服務的調用次數(shù)，并將采集的數(shù)據發(fā)送到報警模塊。報警模塊參照所設計的彈性負載均衡策略，將調用次數(shù)與所設定的閾值進行比較，根據比較結果進行判斷是否需要進行伸縮調整。當報警模塊確定所要進行的操作后，發(fā)送指令到伸縮模塊，最終由伸縮模塊完成Docker容器的啟動、部署或停止［6］。

1）監(jiān)控模塊

監(jiān)控模塊實時監(jiān)控服務提供者所提供服務的調用次數(shù)，同時也會監(jiān)控到調用服務的成功次數(shù)和失敗次數(shù)，以及Dubbo在運行過程中系統(tǒng)狀態(tài)，管理員通過監(jiān)控中心的數(shù)據更好地管理系統(tǒng)。

監(jiān)控模塊還集成了Docker Swarm Mode。Docker Swarm Mode是Docker原生的集群管理工具，它創(chuàng)建并初始化API監(jiān)聽服務模塊［12］。注冊、發(fā)現(xiàn)以及調度模塊在容器中獨立運行，負責監(jiān)聽端口或者連接到其他主機的端口，不需要編寫容器植入性代碼就可以實現(xiàn)服務、注冊、調度集群，以及分布式的終端部署集成［7］。在監(jiān)控調用次數(shù)的同時還可以查看Docker容器的運行和使用情況，觀測到每個容器的CPU使用率、內存和網絡情況，這樣對于Dubbo管理員對系統(tǒng)日常維護提供了更加直觀的數(shù)據。同時也可以在彈性負載均衡時提供更可靠的保障［8］。

由于容器的性能時時刻刻都在發(fā)生變化，過于頻繁的采樣會給系統(tǒng)帶來計算負擔，所以需要采用區(qū)間采樣。監(jiān)控中心每隔一個固定時間間隔采集一次數(shù)據，再將數(shù)據發(fā)送給報警模塊［9］。

2）報警模塊

報警模塊的主要任務是將監(jiān)控中心傳來的數(shù)據進行分析，在滿足伸縮的情況下，觸發(fā)伸縮模塊的擴展操作或者收縮操作。

報警模塊不斷等待傳過來的調用次數(shù)數(shù)值，當接收到數(shù)據時，就把數(shù)據與所設定的閾值進行比較。若超過閾值，則按照相應的算法，會觸發(fā)相應的伸縮機制。伸縮擴展時首先計算出所需擴展容器的數(shù)量，然后確定是為服務提供者集群節(jié)點增加相應數(shù)量的容器個數(shù)。最后將所確定的伸縮對象和伸縮數(shù)量作為伸縮方案，發(fā)送給伸縮模塊［10］。

3）伸縮模塊

伸縮模塊一直處于等待伸縮方案狀態(tài)，當方案到達時，就會按照其中的伸縮對象和伸縮數(shù)量進行調整。每次操作完成后就會重新更新容器數(shù)量，并進入冷卻狀態(tài)，以免造成系統(tǒng)“抖動”，且伸縮的整個過程不能被中斷。

首先判斷是否是伸縮指令，若不是，則繼續(xù)等待；若是則判斷是否是伸縮擴展指令，若不是就進入冷卻狀態(tài)，若是，則根據方案中的伸縮對象進行擴展操作，即對服務提供者的Docker容器增加相應的容器數(shù)量，待伸縮擴展完成后進入冷卻狀態(tài)。最后判斷指令是否結束，若無繼續(xù)操作的指令，伸縮模塊任務結束。

4 彈性負載均衡算法

基于閾值的伸縮方案可實現(xiàn)對系統(tǒng)工作負載的動態(tài)適應，但關鍵問題是如何設定適當?shù)纳炜s規(guī)則和系統(tǒng)性能指標。本方案采用服務的調用次數(shù)作為性能指標進行彈性伸縮。系統(tǒng)的工作負載主要來自服務消費者的請求，而這些請求在系統(tǒng)中的直接體現(xiàn)就是監(jiān)控中心所監(jiān)測到的調用次數(shù)。所以選擇服務的調用次數(shù)作為算法的指標可以更好地體現(xiàn)彈性負載均衡的特點。

高并發(fā)的服務消費者的請求進入系統(tǒng)的時候，直觀和迅速地反映到系統(tǒng)的監(jiān)控中心。監(jiān)控中心會立即將系統(tǒng)的服務調用次數(shù)統(tǒng)計出來，而請求會通過Dubbo所提供的策略負載均衡到各個服務提供者的Docker容器節(jié)點［11］。突發(fā)式的工作負載所帶來的就是容器的CPU使用率和內存使用率急劇上升。每個容器都有自己所能提供的工作上限，當容器的使用率達到一定的數(shù)值時，若不能及時處理，就會面臨宕機的危險［12］。

首先設定閾值K，K是定值，調用次數(shù)Ki超過K時，報警模塊就要制定伸縮方案。若在t1時刻，Ki第一次超過K時，報警模塊就記錄此刻的調用次數(shù)。在t2時刻監(jiān)控中心發(fā)送的調用次數(shù)再次超過K值時，報警模塊就觸發(fā)伸縮機制。即滿足

當x≥0時，則啟動伸縮模塊進行容器的擴容。統(tǒng)計從t1時刻到t2時刻所有的并發(fā)量是為了防止突發(fā)的工作負載只是短暫的，不會對系統(tǒng)造成影響，并且迅速恢復到系統(tǒng)可承載的請求量。監(jiān)控中心在t1至t2時間段內，若所監(jiān)測到的調用次數(shù)始終處于高于閾值的狀態(tài)，則再去調用報警模塊制定伸縮方案，使伸縮模塊完成彈性負載均衡過程。這種策略能夠更加及時有效地應對高并發(fā)的負載，減少資源的浪費。

容器收縮時不能一次全部釋放，而是要逐步釋放，并在釋放的過程中需保證監(jiān)控中心監(jiān)測到的調用次數(shù)總是小于閾值。這樣處理的好處就是避免因釋放過多資源而導致系統(tǒng)損失大量性能，且在釋放的時間段內，一旦調用次數(shù)高于閾值，可立即啟動還未釋放的容器。Docker具有快速部署，秒級啟動等優(yōu)點，可以迅速分擔工作負載［13］。每次釋放完容器后都會有一個短暫的冷卻時間，時間的設定只需按照經驗取即可［14］。

5 實驗驗證

1）創(chuàng)建系統(tǒng)運行環(huán)境

實驗采用Dockerfile制作所需的鏡像，使用容器編排工具docker-compose一鍵式構建基于dock?er容器的Dubbo實驗環(huán)境。

圖3 基于Docker的Dubbo系統(tǒng)

2）模擬用戶發(fā)送請求

系統(tǒng)監(jiān)控中心設定監(jiān)控時間為30s，設定用戶調用次數(shù)的閾值是600。實驗采用webbench進行壓力測試，-c表示調用次數(shù)，-t為請求響應時間，URL為請求響應地址。

如圖4模擬用戶請求為600次，即調用次數(shù)是600：

圖4 模擬用戶請求

3）結果分析

圖5 不同時間段的請求次數(shù)折線圖

圖6 容器數(shù)量變化折線圖

由圖5可知，在120s時，調用次數(shù)達到閾值600次，并在150s時持續(xù)增長至1000次，此時調用報警模塊調用彈性負載均衡算法，x=30*1000-30*600=12000＞0，所以調用伸縮模塊進行擴容操作。

圖6顯示，在180s時容器擴容，由原來的4個容器擴至6個，并在240s時，請求量低于閾值時，容器減少到5個，從而體現(xiàn)容器遞增步長擴容，固定步長縮容的特點。

6 結語

監(jiān)控中心能夠監(jiān)控服務的調用次數(shù)，并將次數(shù)傳送到報警模塊，報警模塊通過數(shù)據與閾值的比較結果，根據彈性負載均衡算法判斷是否觸發(fā)伸縮模塊，從而實現(xiàn)系統(tǒng)的彈性負載均衡。

將Dubbo框架部署到Docker容器中節(jié)約了系統(tǒng)資源，避免了當應用越來越大時所帶來啟動時間的延長和持續(xù)部署的難度。同時在監(jiān)控中心部分增加了彈性負載均衡策略，使得系統(tǒng)更加快速高效地應對高并發(fā)的用戶請求。