基于無中心化的分布式技術的軟件版本分發管理系統的探討

陳顯爐，李建文，于凱

深圳云天勵飛技術股份有限公司，廣東深圳，518000

0 引言

軟件版本管理是軟件研發過程中重要的環節，是指對軟件開發過程中產生的代碼和文檔進行版本控制，以保證開發的代碼、文檔能夠正確發布、分發和維護。近年來，國內外很多研究人員和企業都在嘗試基于軟件版本管理系統實現分布式版本管理，雖然基于開源項目開發的分布式軟件版本管理系統具有低成本、易維護和可擴展等優點，但這些系統仍然存在一些問題，例如系統部署的調整、系統功能和性能的升級等，嚴重影響系統運行的穩定性[1]。因此，系統組件的軟件版本的維護操作在實際的系統中是一個不可避免的情況，甚至是經常出現的情況。設計實現適用于分布式集群系統中的軟件版本分發管理系統，對于系統的可維護性、穩定性、運行的可靠性等指標具有重大的意義和價值。

1 現有分發管理系統版本存在的技術問題

1.1 版本的協同性差

常見的版本分發系統在使用中存在協同性差的問題，升級測試比較難協調統一進行，在出現問題后，也比較難協調統一地進行版本的回退或其他能暫時規避問題的操作等，例如在版本發布后，如果遇到某些問題，需要回退到上一個版本進行測試，又或者是新版本發布后遇到問題，需要回退到上一個版本進行解決。這些功能在傳統的分發系統中并不存在，因此在實際工作中往往需要手動進行相關操作，既降低了工作效率，也增加了錯誤率[2]。

1.2 版本兼容性不足

常見的分發系統的功能模塊基本是針對單個產品進行開發的，對其他產品不一定都能夠支持。軟件產品的版本越來越豐富，但由于不同平臺、不同開發語言等原因，不同用戶在使用同一款產品時會遇到各種各樣的問題，這就導致軟件產品難以適應各種用戶場景[3]。因為不同軟件產品的特性不同，在功能上有可能存在較大差異，這樣就可能會出現版本兼容的問題。并且現有的版本分發系統都是以本地為中心的，所以存在一個問題，就是當本地版本發生變更時，無法在各個渠道中及時同步。

1.3 缺少可回溯性信息

歷史可回溯性信息是軟件產品版本管理系統的重要組成部分，通過歷史可回溯性信息可以幫助我們發現問題、定位問題，并及時進行修復。但目前的常見分發系統中，歷史可回溯性信息并不完善，甚至沒有。一方面是因為版本分發系統的歷史數據都存儲在本地服務器上，如果需要查看歷史數據就需要訪問本地服務器，如果本地服務器沒有歷史數據，就無法查看；另一方面是因為版本分發系統大多都是采用單機架構設計的，不具備分布式能力。因此在后續的版本管理中，需要在分發系統中增加歷史可回溯性信息，以便查看各個分支版本之間的關系[4]。

2 無中心化的分布式軟件版本分發管理系統設計

2.1 分層次的版本的存儲規范

2.1.1 版本元信息存儲

對軟件版本元信息進行存儲，一方面可以為軟件版本管理提供有效的數據支持，另一方面也是對版本元信息進行有效存儲和管理的必要手段。通過對軟件版本元信息進行存儲，可以保證不同用戶對版本信息的訪問需求，同時也可以減少對版本管理系統的維護工作?；谶@一思路，本文設計了如圖1所示的版本元信息的存儲結構，在該結構設計中，實現了分層的元信息存儲。其中版本分為大版本和組件版本，大版本由組件版本構成。大版本的元信息存儲組件的版本的元信息的鏈接，以保持數據的一致性和節省存儲空間。每個大版本與小版本之間存在網狀映射關系，具體而言，同一個組件版本可由多個大版本共享，每個大版本中的組件版本可來自批次版本。大版本與組件版本之間，通過元數據映射組成靈活的版本組合[5]。

圖1 分層次的版本元信息的存儲和映射結構

2.1.2 版本文件數據存儲

數據存儲是軟件版本分發管理系統的核心，也是整個系統的核心功能。通過對已有版本數據存儲模式的分析，本文提出了如圖2所示的版本文件數據存儲結構，主要是指版本元信息的格式與數據映射關系。組件版本的元信息包括組件版本號，這是隨著組件的迭代發布依次遞增的版本號，包括構建的日期及構建功能版本等信息，可以判斷出兩個版本之間的更新關系。版本的唯一標識號由唯一標識生成算法生成，如UUID生成算法。版本的存儲路徑可能是本地文件系統，也可能是網絡地址。

圖2 版本的元信息格式和數據的存儲

2.1.3 版本的統一結構規范

版本的統一結構規范規定不管是組件版本還是大版本的格式標準，為了能夠按統一的框架和流程來執行版本的部署、升級，統一規定所有組件版本必須按如下格式構成，如圖3所示[6]。

2.1.4 版本的兼容性檢測用例庫

兼容性檢測用例庫的作用是實現自動化的版本兼容性檢查，以實現自動化的版本升級/回溯的驗證等。為此，它需要管理各個版本的功能關系對驗證這些關系所對應的用例。為了實現以上這些需求，本文提出兼容性檢測用例庫的結構。一個兼容性檢測用例涉及以下三個元素：調用發起組件、調用接收組件、調用的輸入/輸出。針對以上三個驗證要求，本文提出了一種有向多重圖的存儲結構用于存儲兼容性用例。多重有向圖存儲的方式如下：圖中的每一個節點為系統中的一個組件類型，每一個組件類型在這個多重有向圖中都存在一個節點。

2.1.5 版本的回溯信息數據庫

版本的回溯信息數據庫的目標是當某個組件需要進行版本回溯回退的時候，可以快速得到關聯組件的回溯信息，即關聯的組件的版本是否需要進行回溯及回溯到哪個版本?；厮菪畔煊蓛杉塎ap結構構成。第一級Map，其鍵值為組件的識別符號對，假設在系統中，某兩個組件的標識號為ID(x)、ID(y)，則在第一級Map中存在鍵值為Key(ID(x)，ID(y))的Map項。如果不存在，則創建。第二級Map為某兩個組件的兩兩之間的兼容性檢測結果。

2.2 版本元信息的傳播機制

版本元信息的傳播機制的目標是在網絡傳遞版本元數據信息，其網絡中的每一個節點都掌握當前最新版本信息，其包含如下過程。

第一，由版本發布者發布新的版本的元信息及其相關的數據文件和其他必要的信息內容，設這些被注入版本信息的節點為Node(update)。

第二，在開發階段，為了節約帶寬，Node(update)僅抽取版本信息中的版本號信息向外廣播傳遞過程。

第三，Node(update)為源節點，它在自己的所有網絡接口上廣播新的版本號消息。版本號消息包括如圖4所示的內容。

圖4 版本元信息傳播格式

中間節點收到此消息時，進行以下判斷：①如果曾經收到過此類消息（組件號和版本號相同），直接結束；②如果沒有收到過，首先會在自己的版本元信息存儲庫中進行記錄；③把消息體中的TTL減1，如果結果為0，則不轉發，直接結束；④如果TTL不為0，則中間節點向這條消息進入的網絡接口以外的網絡接口進行轉發。

消息按此機制在網絡傳播，直到所有節點都收到或消息的TTL減為0為止。當以上過程完全結束后，網絡中的每個節點都知道集群中每個軟件的組件的最新版本是什么，及節點自己是否有這些版本的本地拷貝。同時，以比較低的頻度，每個節點會向網絡中廣播自己掌握的所有組件的版本號信息，消息的傳輸過程與新注入的版本信息的傳輸過程基本一致。

2.3 版本的數據文件傳輸機制

第一，每個節點根據自己掌握的分層次的版本的存儲部分所描述的信息，決定向網絡中發起某組件某版本的數據傳輸請求，設置傳輸請求所對應的數據為Data(Model(x)Version(y))。

第二，網絡中，只有少數節點擁有Da t a(Model(x)Version(y))的本地版本，所以大部分節點都會發起傳輸的請求操作。

第三，所有節點按統一約定的規則（如按固定大小切塊），對Data(Model(x)Version(y))進行切塊，設得到的塊數為(1,m), 并將(1,m)進行批次劃分，設為（1,n），則每批次為m/n塊數據。

第四，對于每一個網絡中的節點，按批次發起傳輸，一次把當前批次的m/n塊同時向外發送請求，請求有這些數據塊的節點回應它的請求。發起請求前，根據分層次的版本的存儲中掌握的信息，根據一次的時間退避。

第五，每個節點獨立重復進行3和4步驟中所述的機制，直到版本中的所有數據都傳輸完成為止。

2.4 版本的升級/回溯機制

第一，檢測當前節點所有組件的待升級的版本，確定當前批次升級所涉及的組件版本及具體的版本號。

第二，維護版本的元數據信息，創建一個新的大版本號，生成大版本號的一個唯一的標識號，根據待升級組件的版本號、不升級組件的版本號等信息，維護當前版本號的組件版本映射信息。

第三，進行備份部署，將待升級的版本通過版本中的config/update/deloy等標準化腳本部署為一個與當前運行的版本并行運行的一個復制運行實例。

第四，在這個復制的運行實例上執行兼容性測試用例庫。

第五，如果通過兼容性測試，則進行版本的實際切換，使當前的版本實際上線。同時在回溯信息數據庫中記錄已經完成的兼容性測試信息。

第六，如果沒有通過兼容性測試，則終止此次升級，并清除復制兼容性測試環境的所有組件實例，并進行相關的記錄和報錯。

3 結論

綜上所述，本文所描述的分布式軟件版本分發管理系統，將軟件版本管理過程從集中式的中心化系統遷移到分布式的無中心化系統，減少了中心化系統對數據安全和效率的影響，提高了數據和操作的安全性。