李海創(chuàng)，丁岳偉，高 華

(上海理工大學(xué) 光電信息工程學(xué)院, 上海200093)

基于網(wǎng)絡(luò)動(dòng)態(tài)調(diào)整的應(yīng)用滾動(dòng)更新的優(yōu)化

李海創(chuàng)，丁岳偉，高 華

(上海理工大學(xué) 光電信息工程學(xué)院, 上海200093)

為保證云計(jì)算服務(wù)的持續(xù)運(yùn)行，云計(jì)算平臺(tái)需要支持動(dòng)態(tài)更新技術(shù)。針對(duì)過去主流的動(dòng)態(tài)更新技術(shù)如滾動(dòng)更新存在多版本混合的問題，文中提出了基于網(wǎng)絡(luò)動(dòng)態(tài)調(diào)整的優(yōu)化方案。通過將更新后的服務(wù)實(shí)例與待更新的服務(wù)實(shí)例在網(wǎng)絡(luò)上隔離，使舊版本服務(wù)無法訪問有兼容性問題的新版本服務(wù)，從而解決了多版本混合問題，并且在Docker Swarm的基礎(chǔ)上設(shè)計(jì)并實(shí)現(xiàn)了原型系統(tǒng)，通過實(shí)驗(yàn)驗(yàn)證了該方案的有效性。

動(dòng)態(tài)更新；Docker Swarm；多版本混合問題；云服務(wù)可用性

AbstractWith the development of cloud computing services, more and more applications through the clo-ud platform to provide their services. In order to ensure the continuous operation of these services, cloud com-puting platform needs to support dynamic updating technology. In the past, popular dynamic updating technolog such as rolling updating has mixed version problem. in order to solve this problem, we have proposed a dyn-amically adjusting network strategy. The mixed version problem is solved by isolating the updated service insta-nce from the service instance to be updated on the network, so that the old version service can not access the new version service with the compatibility problem. We design and implement the prototype system on the ba-sis of Docker Swarm, and verify the effectiveness of the scheme through experiments.

Keywordsdynamic updating;Docker Swarm;mixed version problem;cloud service availability

隨著云計(jì)算服務(wù)的發(fā)展，越來越多的商業(yè)應(yīng)用通過云平臺(tái)來提供它們的服務(wù)。據(jù)統(tǒng)計(jì)，一些流行的云服務(wù)，例如Facebook、Google Docs和Wikip-edia，平均每隔7～135天就會(huì)發(fā)布新版本[1]。采用動(dòng)態(tài)更新的技術(shù)可以保證這些云服務(wù)在更新過程的可用性，在PaaS平臺(tái)下已有很多這方面的研究。而最近隨著以Docker為代表的容器技術(shù)的發(fā)展，CaaS(Container as a Service)和與之關(guān)聯(lián)的微服務(wù)架構(gòu)被越來越多的開發(fā)者所推崇。CaaS和微服務(wù)架構(gòu)同樣面臨著動(dòng)態(tài)更新問題的考驗(yàn)[2-5]，本文針對(duì)該問題創(chuàng)新性地提出一種基于網(wǎng)絡(luò)動(dòng)態(tài)調(diào)整的策略，來解決滾動(dòng)更新(動(dòng)態(tài)更新中一種主流的方法)中系統(tǒng)一致性的問題，同時(shí)提供了Compose[6]翻譯引擎來幫助微服務(wù)架構(gòu)的應(yīng)用能以一個(gè)整體在Docker Swarm[5]下進(jìn)行滾動(dòng)更新。

1 相關(guān)工作

隨著以Docker為代表的容器技術(shù)的發(fā)展，越來越多的應(yīng)用采用微服務(wù)架構(gòu)范式在CaaS平臺(tái)上部署。微服務(wù)架構(gòu)將應(yīng)用拆分為一套小且互相關(guān)聯(lián)的服務(wù)，每個(gè)微服務(wù)都是一個(gè)微型應(yīng)用，有著自己六邊形架構(gòu)，包括商業(yè)邏輯和各種接口[7-8]。圖1為典型的采用微服務(wù)架構(gòu)范式的應(yīng)用[3]。當(dāng)更新一個(gè)應(yīng)用，往往需要更新一個(gè)或多個(gè)微服務(wù)，由于服務(wù)間緊密的關(guān)聯(lián)性，如何保證更新過程中的系統(tǒng)一致性是研究重點(diǎn)[9]。

圖1 采用微服務(wù)架構(gòu)范式的應(yīng)用

現(xiàn)在的主流CaaS平臺(tái)，如Kubernetes和Docker Swarm，都采用了滾動(dòng)更新的方式來實(shí)現(xiàn)動(dòng)態(tài)更新[10]，通過逐步更新云服務(wù)中的部分實(shí)例，任何時(shí)刻總有實(shí)例能對(duì)外提供服務(wù)，但會(huì)引入多版本混合的問題。除了滾動(dòng)更新，另一種在過去被廣泛接受的動(dòng)態(tài)更新方法是隔離更新[11]，將服務(wù)所有實(shí)例分為兩部分，當(dāng)其中一部分更新時(shí)，另一部分對(duì)外提供服務(wù)，該方法不會(huì)引入多版本混合的問題，但其在可用性上遠(yuǎn)不如滾動(dòng)更新。

結(jié)合滾動(dòng)更新和隔離更新的優(yōu)勢(shì)，一種基于延遲切換的滾動(dòng)更新的方法被提出[1]。該方法主要有以下幾個(gè)步驟：

(1)選擇服務(wù)中的一個(gè)實(shí)例，使負(fù)載均衡器不轉(zhuǎn)發(fā)任何請(qǐng)求到該實(shí)例上；

(2)離線更新選中的實(shí)例，并使服務(wù)的奇遇實(shí)例對(duì)外提供服務(wù)；

(3)選擇服務(wù)中另一個(gè)實(shí)例，重復(fù)步驟(1)和步驟(2)，直至有1/2的實(shí)例完成更新；

(4)跳針負(fù)載均衡器，使更新完成的實(shí)例對(duì)外提供服務(wù)；

(5)重復(fù)步驟(1)、步驟(2)，完成剩余1/2實(shí)例的更新后，調(diào)整負(fù)載均衡器，使所有實(shí)例對(duì)外提供服務(wù)。

該方法結(jié)合了滾動(dòng)更新和隔離更新，在僅更新一個(gè)微服務(wù)的情況下，能解決多版本混合問題得，并保證了足夠的可用性。然而當(dāng)多個(gè)微服務(wù)需要更新，且服務(wù)間彼此存在關(guān)聯(lián)時(shí)，采用延遲切換的滾動(dòng)更新不能解決多版本混合的問題，且也無法保證系統(tǒng)的可用性。如圖1中的Driver Management和Payments同時(shí)需要更新，且Payments不能保證向后兼容性。當(dāng)Payments更新完成時(shí)，如果Driver Management還處在步驟(3)，就會(huì)導(dǎo)致兼容性問題。盡管這不是典型的多版本混合問題，卻產(chǎn)生了一樣的結(jié)果。

為了解決上面的問題，提出一種基于動(dòng)態(tài)更新網(wǎng)絡(luò)的滾動(dòng)更新方法。利用Docker對(duì)容器網(wǎng)絡(luò)做調(diào)整，從而使新舊版本處在不同的網(wǎng)絡(luò)中，徹底解決多版本混合的問題。

2 動(dòng)態(tài)更新網(wǎng)絡(luò)策略

2.1 方法描述

為了解決滾動(dòng)更新中的多版本混合問題，提出了動(dòng)態(tài)更新網(wǎng)絡(luò)策略(Dynamically Adjusting Net-work Strategy, DANS)。在微服務(wù)架構(gòu)中，假設(shè)每次更新升級(jí)都能保證系統(tǒng)的可用性，則當(dāng)服務(wù)A需要更新，且服務(wù)A存在版本兼容問題時(shí)，必然有至少1個(gè)服務(wù)需要同時(shí)更新來保證系統(tǒng)可用性。建立在以上假設(shè)上，DANS通過動(dòng)態(tài)調(diào)整更新中服務(wù)實(shí)例的網(wǎng)絡(luò)，使存在版本兼容問題的服務(wù)實(shí)例集處在同一網(wǎng)絡(luò)下，舊版本的服務(wù)無法訪問新版本服務(wù)，以此來解決多版本混合問題。

DANS更新流程上和滾動(dòng)更新一致，即逐步更新服務(wù)中的實(shí)例。假設(shè)待更新的服務(wù)為A和B，每個(gè)服務(wù)有m個(gè)實(shí)例，都屬于同一個(gè)網(wǎng)絡(luò)O(old n-etwork)，分別記為OAi,OBi(0

圖2 DANS更新過程中的狀態(tài)

2.2 優(yōu)勢(shì)分析

(1)

圖3 延遲切換的滾動(dòng)更新和DANS的比較

(2)

從式(1)和式(2)中能證明DANS比延遲切換的滾動(dòng)更新有更高的可用性。

3 原型系統(tǒng)實(shí)現(xiàn)

為了驗(yàn)證DANS方案的有效性，在Docker Swarm上實(shí)現(xiàn)改方案的原型。該原型系統(tǒng)主要由3部分組成：(1)Compose翻譯引擎(Compose Trans-lation)，將Compose翻譯成Docker Service Spec，從而使應(yīng)用能以一個(gè)整體在Docker Swarm中更新；(2)更新管理器(Upgrade Management)，分析應(yīng)用間的關(guān)聯(lián)關(guān)系，為不同服務(wù)附上不同網(wǎng)絡(luò)，并執(zhí)行更新操作；(3)負(fù)載均衡器(Load balance)，由于目前Docker1.12.3還不支持更新Docker Service的網(wǎng)絡(luò)[12-13]，所以簡(jiǎn)易實(shí)現(xiàn)一個(gè)擴(kuò)展的路由器，架構(gòu)圖如圖4所示[14]。

圖4 DANS原型系統(tǒng)架構(gòu)圖

3.1 Compose翻譯引擎

Docker Compose 是用來定義和運(yùn)行多容器應(yīng)用的工具，利用 Compose 文件可以配置相應(yīng)的服務(wù)及服務(wù)間的依賴關(guān)系。然而Docker 1.12之后，引入了全新的Docker Service的概念，通過Compose無法直接創(chuàng)建出Docker Service，且Docker Swarm沒有提供相應(yīng)的Service編排工具。為了解決這一問題，開發(fā)了Compose翻譯引擎，將Compose配置轉(zhuǎn)換成對(duì)應(yīng)的Service Spec。通過Compose翻譯引擎，可以將采用微服務(wù)架構(gòu)范式的應(yīng)用作為一個(gè)整體進(jìn)行更新。

3.2 更新管理器

更新管理器通過分析Compose翻譯引擎翻譯后的Service Specs，將DANS相關(guān)的網(wǎng)絡(luò)配置附在Service Specs上，最后將Service Specs傳至Docker Proxy執(zhí)行更新操作。具體步驟可以分為：

(1)取原Service Specs，與新Service Specs比較，找出實(shí)際需要更新的服務(wù)；

(2)檢查待更新服務(wù)的依賴關(guān)系，如果服務(wù)不被其余待更新服務(wù)所依賴，則為其Service Spec加上原有網(wǎng)絡(luò)和新網(wǎng)絡(luò)的配置；否則只加上新網(wǎng)絡(luò)的配置；

(3)將處理后的Service Specs通過Docker Proxy傳至Docker Engine執(zhí)行更新操作。

3.3 負(fù)載均衡器

由于目前Docker 1.12.3不支持更新Docker Service的網(wǎng)絡(luò)配置，于是采用將原服務(wù)通過滾動(dòng)更新機(jī)制停止，并將新服務(wù)通過滾動(dòng)更新機(jī)制創(chuàng)建的方式，來完成服務(wù)的更新操作，這會(huì)導(dǎo)致無法直接使用Docker提供的負(fù)載均衡機(jī)制。在DANS中，只有不被其他待更新服務(wù)所依賴的服務(wù)才需要額外的負(fù)載均衡器。

4 實(shí)驗(yàn)結(jié)果與分析

4.1 實(shí)驗(yàn)過程

選擇一個(gè)開源的在線投票系統(tǒng)Voting[15]作為實(shí)驗(yàn)應(yīng)用，如圖5所示。實(shí)驗(yàn)環(huán)境如表1所示。

圖5 Voting應(yīng)用的結(jié)構(gòu)圖

參數(shù)值操作系統(tǒng)CentOS7 2Docker版本1 12 3

Voting應(yīng)用原本由5個(gè)服務(wù)組成，為了便于實(shí)驗(yàn)將其中的Redis Queue去除，并為Worker服務(wù)增加接受投票請(qǐng)求的api。首先，擴(kuò)展Worker和Voting App的實(shí)例數(shù)，然后不斷發(fā)起對(duì)Voting App的請(qǐng)求，在訪問過程中更新Voting App和Worker。

4.2 實(shí)驗(yàn)結(jié)果與評(píng)價(jià)

實(shí)驗(yàn)針對(duì)3種更新變化做驗(yàn)證，分別是更改worker api、增加worker api、更改投票候選人。實(shí)驗(yàn)結(jié)果如表2所示。表中數(shù)據(jù)表示當(dāng)某種更新發(fā)生時(shí)，投票和訪問頁面的可用性，用半分比表示。從實(shí)驗(yàn)結(jié)果中可以看到，3種不同的更新變化下，服務(wù)仍能提供極高的可用性，這證明了DANS能解決滾動(dòng)更新過程中的多版本混合問題。

表2 多版本混合問題測(cè)試

最后，通過比較DANS、滾動(dòng)更新和隔離更新在不同服務(wù)實(shí)例數(shù)下的可用性和平均響應(yīng)時(shí)間，實(shí)驗(yàn)結(jié)果如表3所示，在可用性上DANS有著突出的表現(xiàn)；在平均響應(yīng)時(shí)間上，由于引入了應(yīng)用層的負(fù)載均衡，響應(yīng)時(shí)間略低于滾動(dòng)更新[16]。

表3 DANS性能測(cè)試

5 結(jié)束語

本文針對(duì)滾動(dòng)更新中的多版本混合問題，提出基于動(dòng)態(tài)調(diào)整網(wǎng)絡(luò)的優(yōu)化方案，并在Docker Swarm下設(shè)計(jì)并實(shí)現(xiàn)了原型系統(tǒng)。根據(jù)實(shí)驗(yàn)結(jié)果，DANS能有效得解決多版本混合問題，且與普通的滾動(dòng)更新和隔離更新相比有更高的可用性。但由于引入了額外的負(fù)載均衡器，在響應(yīng)時(shí)間上有所降低，之后將緊密跟蹤Docker的發(fā)展，擺脫對(duì)額外負(fù)載均衡器的依賴。

[1] Ouyang X, Ding B, Wang H. Delayed Switch: Cloud service upgrade with low availability and capacity loss[C].Shanghai:IEEE International Conference on Software Engineering and Service Science, IEEE, 2014.

[2] Gramoli V, Bass L, Fekete A, et al. Rollup: non-disruptive rolling upgrade with fast consensus-based dynamic reconfigurations[J]. IEEE Transactions on Parallel & Distributed Systems, 2016, 27(9):2711-2724.

[3] Sun D, Bass L, Fekete A, et al. Quantifying failure risk of version switch for rolling upgrade on clouds[C]. Sydney:IEEE Fourth International Conference on Big Data and Cloud Computing, 2014.

[4] 季莉莉,李燁. 云環(huán)境下基于遷移的虛擬機(jī)集群優(yōu)化算法[J]. 電子科技, 2016, 29(3):117-120.

[5] Fu Min, Zhu Liming, Bass L, et al. R-ecovery for failures in rolling upgrade on clouds[C]. Atlanta:IEEE/IFIP International Conference on Dependable Systems and Networks,2014.

[6] Docker. Docker documents[EB/OL]. (1998-10-04) [2005-04-12] http://docs.docker.com.

[7] Chris Richardson. Introduction to microservic-es[EB/OL]. (2015-5-19) [2016-12-2] https://www.nginx.com/blog/introduction-to-microservices.

[8] Kang H, Le M, Tao S. Container and microservice driven design for cloud infrastructure DevOps[C]. San Francisco:IEEE International Conference on Cloud Engineering (IC2E), 2016.

[9] 張婕,曹春,余東亮. 一種面向 PaaS的實(shí)例級(jí)應(yīng)用動(dòng)態(tài)更新技術(shù)[J]. 計(jì)算機(jī)科學(xué), 2015, 42(12):60-64.

[10] Roush E T. Cluster rolling upgrade using multiple version support [C]. California:IEEE International Conference on Cluster Computing,2001.

[11] Das T,Roush E T,Nandana P. Quantum leap cluster upgrade [C]. New York:Proceedings of the 2nd Bangalore Annual Compute Conference,ACM,2009.

[12] Docker. Docker repository[EB/OL]. (2016-10-27) [2016-12-2] https://github.com/docker/docker.

[13] Docker. Swarmkit repository[EB/OL]. (2016-10-27) [2016-12-2] https://github.com/docker/swarmkit.

[14] Mark Church. Docker reference architecture:designing scalable, portable docker container networks[EB/OL]. (2016-10-18) [2016-12-2] https://success.docker.com/Datacenter/Apply/Docker_Reference_Architecture%253A_Designing_Scalable%252C_Portable_Docker_Container_Networks.

[15] Dao Cloud. Voting application[EB/OL]. (2016-9-7) [2016-12-2] https://github.com/DaoCloud/example-voting-app.

[16] Sun D, Guimarans D, Fekete A, et al. Multi-objective optimisation of rolling upgrade allowing for failures in clouds[C].Tianjin:IEEE 34th Symposium on Reliable Distributed Systems (SRDS), 2015.

The Optimization of Rolling Updating Based on Dynamically Adjusting Network Strategy

LI Haichuang，DING Yuewei，GAO Hua

(School of Optical-Electrical and Computer Engineering, University of Shanghai for Science and Technology, Shanghai 200093,China)

TP393

A

1007-7820(2017)10-066-04

2016- 12- 02

李海創(chuàng)(1992-)，男，碩士研究生。研究方向：動(dòng)態(tài)更新，容器集群。高華(1989-)，女，工程師。研究方向：軟件工程。

10.16180/j.cnki.issn1007-7820.2017.10.018