分布式系統高效升級方法研究

屠雪真 陳小強

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

關鍵詞： 移動互聯網; 云計算; 分布式系統; 高可靠; 版本升級

中圖分類號： 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?引言

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

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

1?相關工作

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

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

現有分布式系統的升級是各個節點串行進行的，每個節點的升級過程分成三個階段[7]。

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

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

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

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

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

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

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

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

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

2?分區升級方案

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

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

本系統由版本發布主機和應用集群組成，如圖1所示。

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

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

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

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

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

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

2） 在保障分布式系統中數據的可靠性的同時，綜合考慮對網絡、內存、磁盤I/O的資源需求和壓力，業界最常采用二副本或三副本。

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

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

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

數據A的主副本，在機架A的節點1上，另一個副本在機架B的節點4上。

數據B的主副本，在機架B的節點5上，另一個副本在機架A的節點2上。

數據C的主副本，在機架A的節點3上，另一個副本在機架B的節點6上。

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

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

1） 發布主機發布指令升級機架A，機架A三個節點數據遷移到機架B上的節點。

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

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

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

假設數據是N個副本，對應N個機架，節點有M個，每個節點升級時間為T，升級時間計算和比對：

1） 以邏輯機架為單元升級時，升級時間為機架數*單個節點升級時間= N*T， 升級時間與集群內節點個數無關。

2） 節點單獨升級時，整個升級時間為節點數*單個節點升級時間= M*T， 升級時間與集群內節點個數成正比。

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

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

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

整個接力賽分三個階段，節點上承擔的業務逐漸轉移見下圖的橢圓部分，如圖3所示。

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

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

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

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

上面描述的是升級時的處理流程，升級結束后系統重啟時也會存在數據遷移，和上述流程剛好反過來。

2.2?數據一致性保證

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

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

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

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

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

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

3?實驗及應用

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

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

測試對比結果如圖4所示。

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

在業務影響時間方面，在相同的網絡帶寬條件下，影響時間和遷移數據正相關。對傳統方式來說，遷移數據量大，對業務的影響時間長。對本方案來說，影響業務的時間與與點原先承載的數據量無關，只涉及升級期間閥值的數據量和變化的增量數據，這部分數據量很小，所以對業務的影響很小。

4?總結

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

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

參考文獻

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

[2]?黃煒耀，分布式應用系統更新及實現方式[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]?高可用架構社區著. 高可用架構[M]. 北京：電子工業出版社，2017.

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

[7]?燕振斌.分布式環境下程序部署與監控系統中的任務調度模型研究[D]. 北京：北京工業大學，2013.

[8]?朱清華.數據遷移云服務的設計與實現[D].杭州：浙江大學，2017.

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

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

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

[12]?冒佳明，滕愛國，唐巍. 基于SaltStack的電力信息系統版本自動化升級工具[J].電力信息與通信技術，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 權威指南[M]. 北京：電子工業出版社， 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）