屠雪真 陳小強(qiáng)

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

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

中圖分類號： TP393

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

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

1?相關(guān)工作

分布式系統(tǒng)是其組件分布在聯(lián)網(wǎng)的計(jì)算機(jī)上，組件之間通過傳遞消息進(jìn)行通信和動作協(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)故障恢復(fù)服務(wù)所需要的時長。要想提高系統(tǒng)的可用性，要么提高M(jìn)TBF，要么降低MTTR。而影響MTBF的最大的因素是軟件版本升級，發(fā)布新版本則是MTBF最大的敵人[5]。一是要提高發(fā)布的版本質(zhì)量，另一方面要能做好版本升級的過程控制。自動升級功能是做好版本升級過程控制不可缺少的功能[6]。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2） 數(shù)據(jù)遷移完畢，機(jī)架A的三個節(jié)點(diǎn)下線，更換版本并重新啟動。機(jī)架A三個節(jié)點(diǎn)下線期間，機(jī)架B上因?yàn)榇鎯α巳繑?shù)據(jù)，能正常對外服務(wù)，因此對業(yè)務(wù)是無影響的。

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

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

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

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

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

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

2.1?接力賽機(jī)制的升級流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3?實(shí)驗(yàn)及應(yīng)用

本實(shí)驗(yàn)使用中興電信級分布式緩存系統(tǒng)DCACHE實(shí)施，搭建包括發(fā)布主機(jī)、客戶端、服務(wù)端的集群環(huán)境。各節(jié)點(diǎn)配置采用通用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í)驗(yàn)采用的數(shù)據(jù)量為30 G。為測試升級期間對業(yè)務(wù)的影響，啟動一個客戶端，保持10 000條/秒的持續(xù)的業(yè)務(wù)訪問量。分別測試兩個集群在2節(jié)點(diǎn)、4節(jié)點(diǎn)、6節(jié)點(diǎn)場景下升級耗時，業(yè)務(wù)影響時間并進(jìn)行比對分析。針對分區(qū)升級的集群，因?yàn)闃I(yè)界最常采用二副本或三副本保障分布式系統(tǒng)中數(shù)據(jù)的可靠性，2個節(jié)點(diǎn)時采用2副本，即分成二個機(jī)架，4個節(jié)點(diǎn)時采用2副本，即分成二個機(jī)架，6個節(jié)點(diǎn)時采用3副本，就分成3個機(jī)架。業(yè)務(wù)影響時間就是從電信業(yè)務(wù)層面觀察到業(yè)務(wù)有超時、查詢不到數(shù)據(jù)或者得到路由不對的響應(yīng)等異常情況持續(xù)的時間。

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

可以看出：在升級時間方面，主要耗時在數(shù)據(jù)的備份和恢復(fù)。傳統(tǒng)方式因?yàn)槭谴羞^程，升級時間與節(jié)點(diǎn)數(shù)量成正比。對于分區(qū)升級方式，升級時間與機(jī)架數(shù)量成正比。因?yàn)闅w屬一個機(jī)架的多個節(jié)點(diǎn)并行執(zhí)行升級腳本，并行數(shù)據(jù)備份，所以一個機(jī)架升級時間和一個節(jié)點(diǎn)的升級時間大致相等。

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

4?總結(jié)

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

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

參考文獻(xiàn)

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

[2]?黃煒耀，分布式應(yīng)用系統(tǒng)更新及實(shí)現(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)華，張進(jìn)鐸，等.大規(guī)模集群運(yùn)維自動化的探索與實(shí)踐[J].信息安全與技術(shù)， 2014（2）：60-61.

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

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

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

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

[11]?武奇，劉鋼，郭建偉，等. 基于啟發(fā)式算法的數(shù)據(jù)遷移機(jī)制[J].吉林建筑大學(xué)學(xué)報， 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）