分布式系統(tǒng)高效升級方法研究

屠雪真 陳小強

摘 要： 隨著移動互聯(lián)網(wǎng)、云計算等技術(shù)的發(fā)展，分布式系統(tǒng)以其易擴展、高可靠、靈活性強等優(yōu)點成為了應(yīng)用軟件系統(tǒng)的首選架構(gòu)。然而大型分布式系統(tǒng)的更新升級存在著過程復雜、時間長、新舊版本共存等問題。從研究分析分布式系統(tǒng)更新升級的特點和關(guān)鍵技術(shù)點出發(fā)，結(jié)合電信大型分布式系統(tǒng)實踐中遇到的問題，提出了一種自動化的升級和數(shù)據(jù)遷移方法，采用邏輯順序號保證數(shù)據(jù)的一致性，采用邏輯機架實施分區(qū)升級，設(shè)計了一種接力賽機制減少升級期間的數(shù)據(jù)遷移量，解決了分布式系統(tǒng)升級耗時長風險大的問題。實驗結(jié)果表明，與現(xiàn)有的升級方式相比，分區(qū)升級方法縮短升級時間50%左右，將對業(yè)務(wù)的影響時長減小到秒級，提升了升級效率，并有效降低了升級風險。

關(guān)鍵詞： 移動互聯(lián)網(wǎng); 云計算; 分布式系統(tǒng); 高可靠; 版本升級

中圖分類號： TP393

文獻標志碼： A

文章編號：1007-757X（2019）06-0042-05

Abstract： With the development of technologies such as mobile Internet and cloud computing， distributed systems have become the preferred architecture for application software systems because of their advantages of easy expansion， high reliability， and flexibility. However， the update and upgrade of large-scale distributed systems have problems such as complicated process， long time， and coexistence of new and old versions. Based on the analysis of the characteristics and key technologies of distributed system upgrade， and combined with the problems encountered in the practice of large-scale distributed telecom systems， in this paper， an automated upgrade and data migration method is proposed. The method uses logical sequence numbers to ensure data consistency， uses logical racks to implement partition upgrades. And a relay race mechanism is designed to reduce the amount of data migration during the upgrade. It solves the problem that the distributed system upgrade takes a long time and has a high risk. The experimental results show that compared with the existing upgrade method， the partition upgrade method shortens the upgrade time by about 50%， reduces the impact on the service to the second level， improves the upgrade efficiency， and effectively reduces the upgrade risk.

Key words： Mobile Internet; Cloud computing; Distributed system; High reliability; Version upgrade

0?引言

隨著移動互聯(lián)網(wǎng)、社交網(wǎng)絡(luò)、云計算等技術(shù)的快速發(fā)展，數(shù)據(jù)量呈爆炸式增長。對于日益增長的海量數(shù)據(jù)處理，許多應(yīng)用面臨著高并發(fā)、低時延、高可用及彈性擴展等挑戰(zhàn)，分布式系統(tǒng)及相關(guān)技術(shù)被廣泛地應(yīng)用于各行各業(yè)的應(yīng)用中。大型的分布式系統(tǒng)通常由幾十到幾百甚至幾千臺服務(wù)節(jié)點組成，構(gòu)建和維護這種大規(guī)模分布式系統(tǒng)往往很復雜[1]。在系統(tǒng)的生命周期內(nèi)，每隔一段時間，系統(tǒng)都需要進行升級以提升性能、修改錯誤或者增加新功能。如何有效地設(shè)計一種升級方案，使得大規(guī)模分布式系統(tǒng)能得到正確的、高效的升級和數(shù)據(jù)遷移，同時能持續(xù)對外提供服務(wù)，是實際過程中不得不面臨的困難和挑戰(zhàn)。

集中式應(yīng)用系統(tǒng)一般由少量幾臺應(yīng)用主機組成，其版本升級可以通過手工方式一對一地進行升級實現(xiàn)。而對于大規(guī)模的分布式應(yīng)用系統(tǒng)，手工的升級方式不僅需要投入大量的人力，升級的質(zhì)量和效果也很難得到保證[2]。因此，需要實現(xiàn)自動化升級方式，還需要確保多種版本按正確的步驟和順序升級更新，并保證數(shù)據(jù)的一致性[3]。

1?相關(guān)工作

分布式系統(tǒng)是其組件分布在聯(lián)網(wǎng)的計算機上，組件之間通過傳遞消息進行通信和動作協(xié)調(diào)的軟件系統(tǒng)[4]。分布式系統(tǒng)的可用性指的是系統(tǒng)不間斷提供服務(wù)的能力，公式定義如下：Availability=f（MTBF，MTTR）。

其中，MTBF（Mean time between Failures）是指系統(tǒng)多長時間壞一次;MTTR（Mean time to recover）是指一旦系統(tǒng)故障恢復服務(wù)所需要的時長。要想提高系統(tǒng)的可用性，要么提高MTBF，要么降低MTTR。而影響MTBF的最大的因素是軟件版本升級，發(fā)布新版本則是MTBF最大的敵人[5]。一是要提高發(fā)布的版本質(zhì)量，另一方面要能做好版本升級的過程控制。自動升級功能是做好版本升級過程控制不可缺少的功能[6]。

現(xiàn)有分布式系統(tǒng)的升級是各個節(jié)點串行進行的，每個節(jié)點的升級過程分成三個階段[7]。

下線階段：節(jié)點收到升級通知，開始遷移數(shù)據(jù)，數(shù)據(jù)遷移完成，本節(jié)點停止服務(wù)。其中最耗時的是主備副本間差異數(shù)據(jù)的遷移。

升級階段：此階段是離線的，主要操作是備份數(shù)據(jù)和配置文件、準備環(huán)境、替換版本等。其中備份數(shù)據(jù)最耗時。

上線階段：節(jié)點從重啟直至能對外正常提供服務(wù)都屬于上線階段。主要操作是重啟進程，數(shù)據(jù)遷移，遷移完成后，開始對外正常服務(wù)。其中最耗時的是數(shù)據(jù)遷移。

由此，現(xiàn)有的分布式系統(tǒng)升級方式依然面臨三個問題。一是升級時間長。大規(guī)模分布式系統(tǒng)節(jié)點眾多，即使每個節(jié)點升級時間控制在分鐘級，整個系統(tǒng)升級耗時累計也會達到數(shù)此小時甚至數(shù)天。二是數(shù)據(jù)遷移量大。每個節(jié)點升級完成后，重新啟動會把原先屬于自己的數(shù)據(jù)全量遷移回來。三是影響對外提供的服務(wù)，系統(tǒng)升級期間，被升級節(jié)點上承載的業(yè)務(wù)受到影響，數(shù)據(jù)遷移可能會影響系統(tǒng)性能，系統(tǒng)也存在升級失敗的風險。很多商用分布式系統(tǒng)對升級的要求是快速精確、成功率高、過程可控，對業(yè)務(wù)影響小，甚至不能中斷對外提供的服務(wù)。

近年來，有很多研究和設(shè)計來解決或改進分布式系統(tǒng)的這些問題和不足。

朱清華等[8]提出基于數(shù)據(jù)庫日志的流式數(shù)據(jù)提取、遷移技術(shù)，通過對數(shù)據(jù)庫日志進行解析，提取增量數(shù)據(jù)，并將這些數(shù)據(jù)直接發(fā)往hadoop集群，降低了數(shù)據(jù)遷移的開銷。但是該研究僅限于hadoop集群中的特定數(shù)據(jù)系統(tǒng)，且沒有經(jīng)過商用的驗證。

黃禮駿等[9]提出了一種能使分布式系統(tǒng)在多種版本共存的環(huán)境下正確地進行升級的方案，通過zookeeper[10]生成分布式全局鎖，協(xié)調(diào)節(jié)點升級過程，實現(xiàn)了跨數(shù)據(jù)中心的分布式環(huán)境的升級。該研究側(cè)重于升級全過程協(xié)調(diào)，版本升級和數(shù)據(jù)遷移兩個階段是串行，每個階段內(nèi)部節(jié)點也是串行的，時間過程耗時比較長，同時也沒有解決數(shù)據(jù)遷移量大的問題。

武奇等[11]提出的動態(tài)數(shù)據(jù)遷移算法，是一種啟發(fā)式的數(shù)據(jù)遷移機制，將節(jié)點上訪問量高的數(shù)據(jù)遷移到其他節(jié)點。該算法針對的是運行過程中數(shù)據(jù)在節(jié)點間分布不均衡的問題。本研究針對升級時節(jié)點上已有數(shù)據(jù)的遷移，針對的場景是不同的。

以上研究都局限在分布式系統(tǒng)部分問題的改進和提升，存在適用場景的局限。

2?分區(qū)升級方案

通過分布式系統(tǒng)架構(gòu)和升級機制的研究分析可知，上述問題的產(chǎn)生，一是因為分布式系統(tǒng)的集群層次結(jié)構(gòu)過于簡單，只有集群和集群下節(jié)點兩層，要解決這個問題，就應(yīng)該改變現(xiàn)有的分布式系統(tǒng)集群層次結(jié)構(gòu)，重新設(shè)計節(jié)點的組織方法，使得升級期間不中斷對外的服務(wù)提供。二是需要遷移的數(shù)據(jù)量大，遷移時間長，遷移過程控制不精細。要解決這個問題，可以記錄節(jié)點升級前的數(shù)據(jù)狀態(tài)，升級完成后重啟時，先加載本地數(shù)據(jù)，然后再向其它節(jié)點獲取升級期間更新的數(shù)據(jù)，最后形成最新的完整數(shù)據(jù)集。

綜合以上分析，本文提出了一種自動化的分區(qū)升級方案，采用邏輯機架進行并行批量升級，采用接力賽機制減少升級過程中遷移的數(shù)據(jù)量，使用邏輯順序號LSN（Logic Sequence Number）保證分布的數(shù)據(jù)一致性，較優(yōu)的解決了以上的典型問題。提升了分布式系統(tǒng)的升級效率。

本系統(tǒng)由版本發(fā)布主機和應(yīng)用集群組成，如圖1所示。

完整的自動升級過程分為上傳應(yīng)用程序和自動升級應(yīng)用程序。上傳程序主要用來在服務(wù)器上傳即將升級的文件?？蛻舳俗詣觽蓽y版本號，當服務(wù)器端記錄的版本號比本地客戶端記錄的版本號大時，將從服務(wù)端下載最新的程序，開始升級并保持版本同步[12]。

發(fā)布主機是核心的升級管理器，負責自動升級過程的控制和升級結(jié)果的跟蹤，對應(yīng)用系統(tǒng)版本進行管理，包含版本發(fā)布、版本回退等，并對各節(jié)點版本更新情況進行跟蹤。發(fā)布過程需要保證版本發(fā)布的事務(wù)一致性，即一個版本更新包涉及的文件發(fā)布，需要保證都成功或失敗時能進行回滾操作。

應(yīng)用集群節(jié)點實施版本的自動升級，負責本節(jié)點版本更新以及更新結(jié)果的反饋。各節(jié)點應(yīng)保留本地數(shù)據(jù)備份、當前版本文件以及要升級的目標版本文庫。分布式系統(tǒng)都是分層次的，上層依賴于下層，所以每個節(jié)點的升級是按先下后上的層次順序，并作為一個事務(wù)來執(zhí)行的。

不同于傳統(tǒng)分布式系統(tǒng)簡單的層次結(jié)構(gòu)，本方案設(shè)計了一種集群-機架-節(jié)點的三級架構(gòu)，在集群和節(jié)點之間，增加一個邏輯機架層。集群的每個節(jié)點都歸屬一個邏輯機架。

確定集群邏輯機架的數(shù)量是個必須精心設(shè)計的問題，需要考慮兩方面的因素：

1） 當任一邏輯機架升級時，都能正常對外服務(wù)，因此其他任一機架上必須有全部的數(shù)據(jù);

2） 在保障分布式系統(tǒng)中數(shù)據(jù)的可靠性的同時，綜合考慮對網(wǎng)絡(luò)、內(nèi)存、磁盤I/O的資源需求和壓力，業(yè)界最常采用二副本或三副本。

因此，設(shè)計集群邏輯機架的數(shù)量等于副本數(shù)量，即一般為二或者三機架。為進一步說明集群邏輯機架的數(shù)量為什么要等于副本數(shù)量，假設(shè)集群有6個節(jié)點，有數(shù)據(jù)A，B，C，數(shù)據(jù)有2個副本，數(shù)據(jù)分布如圖2所示。

圖中線段連接數(shù)據(jù)的兩個副本，箭頭方向指示數(shù)據(jù)同步的方向。

機架分成兩個，節(jié)點1，2，3屬于機架1，節(jié)點4，5，6屬于機架2。

數(shù)據(jù)A的主副本，在機架A的節(jié)點1上，另一個副本在機架B的節(jié)點4上。

數(shù)據(jù)B的主副本，在機架B的節(jié)點5上，另一個副本在機架A的節(jié)點2上。

數(shù)據(jù)C的主副本，在機架A的節(jié)點3上，另一個副本在機架B的節(jié)點6上。

可以看出，機架1和機架2都有全量的數(shù)據(jù)A，B，C。

集群升級時以邏輯機架為單元進行的。以圖2為例說明集群的升級過程：

1） 發(fā)布主機發(fā)布指令升級機架A，機架A三個節(jié)點數(shù)據(jù)遷移到機架B上的節(jié)點。

2） 數(shù)據(jù)遷移完畢，機架A的三個節(jié)點下線，更換版本并重新啟動。機架A三個節(jié)點下線期間，機架B上因為存儲了全部數(shù)據(jù)，能正常對外服務(wù)，因此對業(yè)務(wù)是無影響的。

3） 機架A重啟成功，數(shù)據(jù)從機架B節(jié)點遷移回機架A。機架A上三個節(jié)點重啟升級等操作是并行的，因此無論歸屬機架的節(jié)點數(shù)量是多少，重啟升級時間和一個節(jié)點大致相等。

4） 數(shù)據(jù)遷移完畢，機架A升級成功并接管服務(wù)，機架B依次升級。雖然從機架的角度看，仍然是按照機架串行升級的，但是從節(jié)點來看是批量的并行升級。

假設(shè)數(shù)據(jù)是N個副本，對應(yīng)N個機架，節(jié)點有M個，每個節(jié)點升級時間為T，升級時間計算和比對：

1） 以邏輯機架為單元升級時，升級時間為機架數(shù)*單個節(jié)點升級時間= N*T， 升級時間與集群內(nèi)節(jié)點個數(shù)無關(guān)。

2） 節(jié)點單獨升級時，整個升級時間為節(jié)點數(shù)*單個節(jié)點升級時間= M*T， 升級時間與集群內(nèi)節(jié)點個數(shù)成正比。

可見，以邏輯機架為單元升級時間為2T，以節(jié)點單獨升級時間為6T，節(jié)省2/3的時間。

2.1?接力賽機制的升級流程

為減少升級期間對業(yè)務(wù)的影響，數(shù)據(jù)遷移時設(shè)計了一種接力賽機制。將被升級節(jié)點上的數(shù)據(jù)分成兩部分進行遷移，兩部分數(shù)據(jù)的大小可配置，配置原則是一部分數(shù)據(jù)為閥值大小，另一部分為其余的數(shù)據(jù)。為減少對業(yè)務(wù)影響，閥值不可配置過大。為了簡化配置，只需進行閥值大小的配置，比如閥值配置為100 M。為方便敘述后面都以100 M進行描述。

整個接力賽分三個階段，節(jié)點上承擔的業(yè)務(wù)逐漸轉(zhuǎn)移見下圖的橢圓部分，如圖3所示。

階段一：S節(jié)點（升級節(jié)點）負責業(yè)務(wù)全部的讀和寫，S節(jié)點上的數(shù)據(jù)向D節(jié)點（目的節(jié)點）數(shù)據(jù)遷移，遷移期間業(yè)務(wù)只能訪問S節(jié)點。數(shù)據(jù)遷移到只剩下100 M時，服務(wù)端更新路由表（數(shù)據(jù)分布節(jié)點的信息稱為數(shù)據(jù)的路由表，路由表有一個版本號，當有數(shù)據(jù)從一個節(jié)點遷移到另一個節(jié)點時，版本號會變化），此時客戶端感知路由表的變化并獲取最新的路由表（客戶端在請求消息的響應(yīng)中得到路由表的最新版本，并和本地保存的版本號比較，如果不同則主動獲取最新的路由表），得知S節(jié)點上絕大部分數(shù)據(jù)遷移到D節(jié)點，因此客戶端后續(xù)原本向S節(jié)點寫的數(shù)據(jù)重定向?qū)懙紻節(jié)點，原本向S節(jié)點讀的數(shù)據(jù)優(yōu)先到D節(jié)點讀，讀不到再重定向到S節(jié)點讀，至此第一階段結(jié)束。

階段二：S節(jié)點繼續(xù)向D節(jié)點遷移第一階段剩下的100 M數(shù)據(jù)，遷移期間D節(jié)點承擔業(yè)務(wù)全部的寫和絕大部分的讀，如果讀不到，則將客戶端按照既定策略重定向到S節(jié)點，重新向S節(jié)點發(fā)起讀請求，即S節(jié)點承擔極少部分數(shù)據(jù)的讀。

階段三：S節(jié)點向D節(jié)點遷移完所有數(shù)據(jù)后，服務(wù)端更新路由表，此時客戶端感知路由表的變化并獲取最新的路由表，得知S節(jié)點上全部數(shù)據(jù)遷移到D節(jié)點，因此客戶端后續(xù)原本向S節(jié)點讀寫的請求全部轉(zhuǎn)向D節(jié)點，至此S節(jié)點就可以下線，進行升級操作。這時只有D節(jié)點承擔業(yè)務(wù)全部的讀寫。

接力賽機制有效減小了系統(tǒng)升級期間對業(yè)務(wù)的影響。一是有效避免了在極端情況下，S節(jié)點一直有寫業(yè)務(wù)請求，導致一直有數(shù)據(jù)要遷移，遷移過程一直結(jié)束不了的情況發(fā)生。二是對影響業(yè)務(wù)的時間可控。因為在第一階段數(shù)據(jù)遷移時，基本對業(yè)務(wù)訪問無影響。在遷移第二階段的100 M數(shù)據(jù)時，僅當在D節(jié)點上讀不到所需數(shù)據(jù)時，客戶端會被重定向到S節(jié)點，再次發(fā)起讀請求，這樣延遲才會加大。但是第二階段要遷移的數(shù)據(jù)量很少，所以對業(yè)務(wù)的影響極小。因為100 M數(shù)據(jù)遷移，即使在100 Mbytes網(wǎng)絡(luò)條件下，也僅需1秒，對業(yè)務(wù)影響極小。

上面描述的是升級時的處理流程，升級結(jié)束后系統(tǒng)重啟時也會存在數(shù)據(jù)遷移，和上述流程剛好反過來。

2.2?數(shù)據(jù)一致性保證

分布式系統(tǒng)為了提高可靠性，數(shù)據(jù)要保存多份，一份稱為一個副本，其中一個副本稱為主副本，對外可讀可寫，其他副本稱為備副本，對外只讀。當主副本不能對外服務(wù)時，備副本可以通過選舉升為主副本。數(shù)據(jù)復制在可用性和性能方面給分布式系統(tǒng)帶來了巨大好處，同時也帶來了數(shù)據(jù)一致性的挑戰(zhàn)。

數(shù)據(jù)一致性是指在對一個副本數(shù)據(jù)進行更新的時候，必須確保也能夠更新其它的副本，否則不同副本之間的數(shù)據(jù)將不一致。一致性是分布式領(lǐng)域的一個重要的難題。

CAP定理[13]告訴我們，在一個分布式系統(tǒng)中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分區(qū)容錯性），三者不可兼得。我們無法找到一種能夠滿足分布式系統(tǒng)所有系統(tǒng)屬性的分布式一致性解決方案。因此，如何既保證數(shù)據(jù)的一致性，同時又不影響系統(tǒng)運行的性能，是每一個分布式系統(tǒng)都需要重點考慮和權(quán)衡的。于是，有了三種一致性級別的系統(tǒng)，分別是強一致性、弱一致性和最終一致性。簡單來說，強一致性要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到。如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性。如果經(jīng)過一段時間后要求能訪問到更新的數(shù)據(jù)，則是最終一致性。其中，最終一致性是業(yè)界大型分布式系統(tǒng)中比較主流的選擇[5]。

在電信業(yè)務(wù)工程實踐上的基礎(chǔ)上，本文設(shè)計實現(xiàn)了一種簡潔的最終一致性解決方案，保障分布式系統(tǒng)升級時數(shù)據(jù)的最終一致性。為了標識最新的數(shù)據(jù)副本，保證數(shù)據(jù)的一致性，我們設(shè)計了一個邏輯順序號LSN來標識數(shù)據(jù)寫或者刪除的時序。它是一個長整數(shù)，每次數(shù)據(jù)有修改或更新時加一，LSN值越大，表示操作發(fā)生時間越晚。

節(jié)點正常運行時，數(shù)據(jù)每修改或更新一次，LSN就加一，LSN和數(shù)據(jù)一并同步到其它副本。當節(jié)點升級完成，重啟后將本地保存的最大LSN發(fā)給備副本（此時已經(jīng)切換為主副本），檢查比對兩個LSN，并將缺失部分同步給重啟后的升級節(jié)點，保證主備數(shù)據(jù)一致。

由于系統(tǒng)的升級一般選擇在業(yè)務(wù)空閑的時間段，且接力賽機制使得升級過程需要同步的數(shù)據(jù)比較少，因此LSN相差不大。

3?實驗及應(yīng)用

本實驗使用中興電信級分布式緩存系統(tǒng)DCACHE實施，搭建包括發(fā)布主機、客戶端、服務(wù)端的集群環(huán)境。各節(jié)點配置采用通用X86服務(wù)器，配置：Intel Xeon（R） E5-2680 V2@2.80 GHz，32core;內(nèi)存128 GB DDR3/1 333 MHz;intel8391GT千兆網(wǎng)卡*6。軟件環(huán)境采用操作系統(tǒng)為CGSL5.04F1，內(nèi)核版本3.10.0-693。

實驗采用的數(shù)據(jù)量為30 G。為測試升級期間對業(yè)務(wù)的影響，啟動一個客戶端，保持10 000條/秒的持續(xù)的業(yè)務(wù)訪問量。分別測試兩個集群在2節(jié)點、4節(jié)點、6節(jié)點場景下升級耗時，業(yè)務(wù)影響時間并進行比對分析。針對分區(qū)升級的集群，因為業(yè)界最常采用二副本或三副本保障分布式系統(tǒng)中數(shù)據(jù)的可靠性，2個節(jié)點時采用2副本，即分成二個機架，4個節(jié)點時采用2副本，即分成二個機架，6個節(jié)點時采用3副本，就分成3個機架。業(yè)務(wù)影響時間就是從電信業(yè)務(wù)層面觀察到業(yè)務(wù)有超時、查詢不到數(shù)據(jù)或者得到路由不對的響應(yīng)等異常情況持續(xù)的時間。

測試對比結(jié)果如圖4所示。

可以看出：在升級時間方面，主要耗時在數(shù)據(jù)的備份和恢復。傳統(tǒng)方式因為是串行過程，升級時間與節(jié)點數(shù)量成正比。對于分區(qū)升級方式，升級時間與機架數(shù)量成正比。因為歸屬一個機架的多個節(jié)點并行執(zhí)行升級腳本，并行數(shù)據(jù)備份，所以一個機架升級時間和一個節(jié)點的升級時間大致相等。

在業(yè)務(wù)影響時間方面，在相同的網(wǎng)絡(luò)帶寬條件下，影響時間和遷移數(shù)據(jù)正相關(guān)。對傳統(tǒng)方式來說，遷移數(shù)據(jù)量大，對業(yè)務(wù)的影響時間長。對本方案來說，影響業(yè)務(wù)的時間與與點原先承載的數(shù)據(jù)量無關(guān)，只涉及升級期間閥值的數(shù)據(jù)量和變化的增量數(shù)據(jù)，這部分數(shù)據(jù)量很小，所以對業(yè)務(wù)的影響很小。

4?總結(jié)

本文結(jié)合企業(yè)已有的需求和實際工程問題出發(fā)，介紹了一種針對分布式系統(tǒng)的高效升級方法。采用邏輯機架和接力賽機制，解決升級時間長、遷移數(shù)據(jù)量大、業(yè)務(wù)影響時間長等突出問題。通過和傳統(tǒng)自動化升級方式的對比實驗驗證，以及商用生產(chǎn)環(huán)境的實際使用效果，都證明了分區(qū)升級對大規(guī)模分布式系統(tǒng)運維工作效率提升的有效性。本文提出的方法沒有針對云化場景做全面考慮，具有一定的局限性。

近年來，來自谷歌的Kubernetes社區(qū)風頭強勁，已在業(yè)界大量科技公司規(guī)模商用并致力于成為領(lǐng)先者[13]，基于Docker[14]的自動化運維技術(shù)已成為一種必然趨勢。眾多的使用分布式架構(gòu)的公司，也開始對原有系統(tǒng)進行容器或升級，傳統(tǒng)分布式架構(gòu)如何進行容器化升級是我們下一步的工作方向。

參考文獻

[1]?曹雨薇，張毅.分布式系統(tǒng)運維交付解決方案研究與應(yīng)用[J].電腦與電信， 2017（10）：44-47.

[2]?黃煒耀，分布式應(yīng)用系統(tǒng)更新及實現(xiàn)方式[J].中國新通信，2016（21）：98.

[3]?Aumani Sameer， Barbara Liskov， Liuba Shrira. Modular software upgrades for distributed systems[C]// ECOOP 2006-Object-Oriented Programming. Belin Heidelberg： Springer 2006： 452-476.

[4]?Coulouris G， Jean Dollimore， Tim Kindberg， et al. Distributed Systems：Conceptes and Design（5th Edition） [M].Boston：Addison-Wesley， 2011.

[5]?高可用架構(gòu)社區(qū)著. 高可用架構(gòu)[M]. 北京：電子工業(yè)出版社，2017.

[6]?毛承國，張衛(wèi)華，張進鐸，等.大規(guī)模集群運維自動化的探索與實踐[J].信息安全與技術(shù)， 2014（2）：60-61.

[7]?燕振斌.分布式環(huán)境下程序部署與監(jiān)控系統(tǒng)中的任務(wù)調(diào)度模型研究[D]. 北京：北京工業(yè)大學，2013.

[8]?朱清華.數(shù)據(jù)遷移云服務(wù)的設(shè)計與實現(xiàn)[D].杭州：浙江大學，2017.

[9]?黃禮駿.分布式系統(tǒng)的升級和數(shù)據(jù)遷移問題研究[D]. 北京：北京大學， 2015.

[10]?Apache ZooKeeper[DB/OL]. https：//en.wikipedia.org/wiki/Apache_ZooKeeper，2018-12-16.

[11]?武奇，劉鋼，郭建偉，等. 基于啟發(fā)式算法的數(shù)據(jù)遷移機制[J].吉林建筑大學學報， 2016，33（5）：77-80.

[12]?冒佳明，滕愛國，唐巍. 基于SaltStack的電力信息系統(tǒng)版本自動化升級工具[J].電力信息與通信技術(shù)，2017（4）：54-59.

[13]?Eric Brewer. CAP twelve years later： How the “rules” have changed[J]. IEEE Explore， 2012，45（2）：23-29.

[14]?龔正，吳治輝，葉伙榮，等.Kubernetes 權(quán)威指南[M]. 北京：電子工業(yè)出版社， 2016.

[15]?Docker Containerization Unlocks the Potential for Dev and Ops[EB/OL].https：//www.docker.com/why-docker， 2018-12-26.

（收稿日期： 2019.01.16）