曹 郁 朱志祥

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

1 引言

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

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

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

2 系統(tǒng)架構(gòu)設(shè)計(jì)

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

Dubbo與Docker結(jié)合的架構(gòu)如圖1所示。

圖1 Dubbo與Docker結(jié)合的架構(gòu)

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

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

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

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

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

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

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

1）監(jiān)控模塊

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

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

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

2）報(bào)警模塊

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

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

3）伸縮模塊

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

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

4 彈性負(fù)載均衡算法

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

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

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

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

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

5 實(shí)驗(yàn)驗(yàn)證

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

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

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

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

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

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

圖4 模擬用戶請求

3）結(jié)果分析

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

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

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

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

6 結(jié)語

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

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