汪驥宇 陳武 張千秋 胡芳

摘要：在采用微服務(wù)架構(gòu)設(shè)計(jì)軟件時(shí)，隨著軟件規(guī)模的增大，需要管理的微服務(wù)越來越多，微服務(wù)版本迭代也越來越多，對(duì)微服務(wù)的版本設(shè)計(jì)與管理越來越困難。為解決該問題，文章提出了基于版本演進(jìn)模型和迭代設(shè)計(jì)模式的版本迭代方法，方法包括一個(gè)版本演進(jìn)模型和一種迭代設(shè)計(jì)模式。版本演進(jìn)模型是一個(gè)管理模型，包括軟件版本計(jì)劃管理、主倉庫、預(yù)發(fā)倉庫、開發(fā)倉庫、開發(fā)人員倉庫、緊急修復(fù)倉庫管理內(nèi)容，實(shí)現(xiàn)軟件服務(wù)全生命管理。迭代設(shè)計(jì)模式中介紹微服務(wù)版本迭代的設(shè)計(jì)模式，指導(dǎo)設(shè)計(jì)人員進(jìn)行軟件服務(wù)的版本設(shè)計(jì)。

關(guān)鍵詞：微服務(wù);版本演進(jìn)模型;迭代設(shè)計(jì)模式

中圖分類號(hào)：TP311? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2022）14-0051-03

1 引言

微服務(wù)架構(gòu)[1]從2014年被提出以來，成為軟件應(yīng)用領(lǐng)域的熱門概念，是一種新的架構(gòu)風(fēng)格。其具有易開發(fā)、維護(hù)，獨(dú)立、易擴(kuò)展、獨(dú)立部署等優(yōu)勢(shì)[2]。近年來，隨著云計(jì)算技術(shù)的進(jìn)步與服務(wù)量的不斷增長、DevOps的興起[3]，微服務(wù)架構(gòu)正在成為軟件應(yīng)用開發(fā)特別是復(fù)雜大型應(yīng)用首選架構(gòu)[4]。

軟件的快速迭代發(fā)布能夠給軟件服務(wù)的投資者帶來信心，也能夠在過程中發(fā)現(xiàn)問題以及外部環(huán)境變化，及時(shí)調(diào)整軟件的開發(fā)路線。隨著微服務(wù)項(xiàng)目的不斷增加，軟件服務(wù)規(guī)模擴(kuò)大，如何有效進(jìn)行軟件版本管理[5]、軟件迭代設(shè)計(jì)成為一個(gè)巨大的挑戰(zhàn)[6-7]。產(chǎn)品經(jīng)理、架構(gòu)師們不斷思考軟件服務(wù)的未來功能、版本規(guī)劃[8]，在進(jìn)行軟件版本迭代設(shè)計(jì)時(shí)會(huì)遇到對(duì)于未來版本功能如何設(shè)計(jì)規(guī)劃的問題。

本文提出了一種基于版本演進(jìn)模型和軟件迭代設(shè)計(jì)模式的版本迭代方法，提供了一種可行的版本演進(jìn)模型以及基于該模型的設(shè)計(jì)模式。產(chǎn)品經(jīng)理和架構(gòu)師可以很好地進(jìn)行基于微服務(wù)的軟件服務(wù)設(shè)計(jì)研發(fā)。

2 版本演進(jìn)模型

本文設(shè)計(jì)的軟件服務(wù)版本演進(jìn)模型包括5種類型倉庫和一個(gè)版本計(jì)劃：

1）主倉庫，為發(fā)布倉庫，也是生產(chǎn)倉庫。各個(gè)主版本編號(hào)在該倉庫中標(biāo)識(shí)，1.0、2.0……標(biāo)識(shí)大版本，1.1、1.2……標(biāo)識(shí)由緊急修復(fù)發(fā)版產(chǎn)生的小版本。

2）緊急修復(fù)倉庫，這是管理緊急修復(fù)代碼系列分支的倉庫。當(dāng)生產(chǎn)上出現(xiàn)需要緊急bug的時(shí)候，就可以從主倉庫中拉出代碼到緊急修復(fù)倉庫，建立E1分支進(jìn)行修復(fù)，修復(fù)完成后，并入主倉庫形成小版本，修改的內(nèi)容并入開發(fā)倉庫，E1e表示E1分支結(jié)束，E1、E2……標(biāo)識(shí)緊急修復(fù)分支。

3）預(yù)發(fā)倉庫，這是管理預(yù)發(fā)分支的倉庫，管理預(yù)發(fā)分支用于用戶測(cè)試、上線測(cè)試的一個(gè)分支系列。當(dāng)完成開發(fā)測(cè)試后，測(cè)試人員提交發(fā)布測(cè)試預(yù)發(fā)申請(qǐng)，由配置人員創(chuàng)建的預(yù)發(fā)倉庫分支。該分支發(fā)現(xiàn)的bug，依據(jù)從開發(fā)人員倉庫修復(fù)à開發(fā)倉庫版本分支à開發(fā)分支à預(yù)發(fā)倉庫分支路徑，依次推到該倉庫。該倉庫測(cè)試完成后，將推到主倉庫進(jìn)行發(fā)布。用Pr1、Pr2……標(biāo)識(shí)預(yù)發(fā)分支，Pr1e、Pr2e……表示對(duì)應(yīng)預(yù)發(fā)分支結(jié)束。

4）開發(fā)倉庫，該倉庫指軟件開發(fā)過程的主要倉庫，管理主開發(fā)代碼分支和版本分支。在做新的功能、做bug修復(fù)時(shí)，是從這個(gè)倉庫分出來做。在這個(gè)倉庫下主開發(fā)代碼分支主要負(fù)責(zé)記錄開發(fā)狀態(tài)下相對(duì)穩(wěn)定的版本，即完成了某個(gè)版本或者修復(fù)了某個(gè)bug后的開發(fā)穩(wěn)定版本。版本分支是由許多分別負(fù)責(zé)不同版本開發(fā)分支組成的一個(gè)分支系列。開發(fā)測(cè)試主要基于版本分支進(jìn)行，也可以從主開發(fā)分支進(jìn)行，當(dāng)版本功能點(diǎn)開發(fā)測(cè)試完畢之后，就會(huì)合并到主分支，對(duì)應(yīng)版本分支結(jié)束。開發(fā)分支是一個(gè)連續(xù)的分支，用D0.0、D1.0、D1.1、D2.0……標(biāo)識(shí)，與主分支版本對(duì)應(yīng)。版本分支用F1、F2……標(biāo)識(shí)，與大版本對(duì)應(yīng)，F(xiàn)1e、F2e……表示對(duì)應(yīng)開發(fā)版本分支結(jié)束。

5）開發(fā)人員倉庫，指開發(fā)人員的倉庫群，每個(gè)開發(fā)人員對(duì)應(yīng)自己的倉庫，倉庫管理個(gè)人開發(fā)使用的分支，主要包括各個(gè)開發(fā)分支，分為版本開發(fā)分支和緊急修復(fù)分支兩大類分支。P1、P2……標(biāo)識(shí)個(gè)人開發(fā)分支，與開發(fā)版本分支對(duì)應(yīng)，P1e、P2e…表示對(duì)應(yīng)個(gè)人分支結(jié)束。PE1、PE2……標(biāo)識(shí)個(gè)人緊急修復(fù)分支，與緊急修復(fù)分支相對(duì)應(yīng)，PE1、PE2……表示對(duì)應(yīng)個(gè)人緊急修復(fù)分支結(jié)束。

6）版本計(jì)劃，每一個(gè)軟件服務(wù)的倉庫都需要有版本計(jì)劃，包括正常開發(fā)版本計(jì)劃和緊急修復(fù)版本計(jì)劃。任何開發(fā)開始前需要制訂版本計(jì)劃，配置人員根據(jù)計(jì)劃構(gòu)建主倉庫、緊急修復(fù)倉庫、預(yù)發(fā)倉庫、開發(fā)倉庫以及在倉庫中建立代碼合適分支。

版本演進(jìn)模型說明[9-13]：

1）在模塊開始開發(fā)前，由配置人員創(chuàng)建主倉庫、預(yù)發(fā)倉庫、開發(fā)倉庫、開發(fā)人員倉庫，給相關(guān)開發(fā)人員、測(cè)試人員建立賬號(hào)和完成倉庫授權(quán)。

2）各個(gè)模塊的敏捷專家制訂該模塊的版本計(jì)劃，開發(fā)負(fù)責(zé)人根據(jù)該計(jì)劃配置相關(guān)的開發(fā)倉庫。

3）開發(fā)人員在個(gè)人倉庫中建立版本分支，從開發(fā)倉庫版本分支中拉起代碼到個(gè)人版本分支，完成個(gè)人版本開發(fā)后提交合并到開發(fā)倉庫對(duì)應(yīng)的版本分支。測(cè)試人員進(jìn)行測(cè)試，測(cè)試的問題由開發(fā)人員在個(gè)人版本分支中修復(fù)，再推到開發(fā)倉庫版本分支。測(cè)試完成后，開發(fā)負(fù)責(zé)人將開發(fā)版本分支合并到開發(fā)倉庫，這里會(huì)存在多人協(xié)同開發(fā)以及bug修復(fù)多次提交。

4）版本分支開發(fā)完成后，開發(fā)負(fù)責(zé)人提出合并預(yù)發(fā)倉庫分支申請(qǐng)，由配置人員合并到預(yù)發(fā)倉庫分支，用戶進(jìn)行功能確認(rèn)測(cè)試。測(cè)試發(fā)現(xiàn)bug，由開發(fā)人員在個(gè)人開發(fā)分支中完成修復(fù)，之后參照上一步驟完成測(cè)試推送到預(yù)發(fā)分支，進(jìn)行回歸測(cè)試。

5）完成預(yù)發(fā)測(cè)試后，開發(fā)負(fù)責(zé)人標(biāo)識(shí)開發(fā)版本分支，提出預(yù)發(fā)倉庫合并到主倉庫申請(qǐng)，配置人員完成合并。合并完成后，開發(fā)負(fù)責(zé)人將開發(fā)主分支修改推送到正在進(jìn)行的版本分支。開發(fā)人員需要從版本分支中更新修改到后續(xù)開發(fā)的個(gè)人分支中。

6）當(dāng)生產(chǎn)環(huán)境發(fā)生緊急bug需要修復(fù)時(shí)，敏捷專家制訂緊急倉庫計(jì)劃，配置人員在緊急修復(fù)倉庫創(chuàng)建緊急修復(fù)分支，拉取主分支代碼。開發(fā)人員在個(gè)人倉庫中建立緊急修復(fù)分支，從該分支拉取代碼。bug修復(fù)后，提交到緊急倉庫，測(cè)試人員對(duì)緊急倉庫進(jìn)行測(cè)試。測(cè)試完成后，開發(fā)負(fù)責(zé)人合并修復(fù)代碼到開發(fā)倉庫，同時(shí)提出緊急倉庫合并到主倉庫申請(qǐng)，配置人員完成合并。開發(fā)負(fù)責(zé)人先將緊急修復(fù)分支修改的內(nèi)容同步到開發(fā)主分支，然后將開發(fā)主分支修改推送到正在進(jìn)行的版本分支。開發(fā)人員需要從版本分支中更新修改到在后續(xù)開發(fā)的個(gè)人分支中。

3 迭代設(shè)計(jì)模式

軟件服務(wù)總體設(shè)計(jì)模式中，軟件高版本為低版本的升級(jí)替換，軟件服務(wù)迭代設(shè)計(jì)的設(shè)計(jì)模式總體架構(gòu)如圖 1所示。本文中以高版本V2版、低版本V1版為例，V2版為V1版的升級(jí)版本。

在該模式總體架構(gòu)中：

1）軟件服務(wù)的版本從低版本升級(jí)到高版本。

2）在該圖中功能和服務(wù)成對(duì)出現(xiàn)，相同編號(hào)表示為同一個(gè)模式相關(guān)組件。

3）軟件內(nèi)部黑色箭頭表示組件內(nèi)部功能的調(diào)用。

4）兩個(gè)版本間的箭頭表示軟件版本的變遷。

5）模式總體架構(gòu)中包括6種模式：新增功能模式、功能等效模式、前端升版模式、前后端升版模式、新前端模式、前端升版+新后端模式。

6）在進(jìn)行新版本功能設(shè)計(jì)時(shí)需要靈活應(yīng)用這6種模式。

在軟件服務(wù)升版設(shè)計(jì)時(shí)，往往一個(gè)軟件功能需求可以采用多種設(shè)計(jì)模式來實(shí)現(xiàn)，在設(shè)計(jì)過程需要綜合考慮多種因素，包括團(tuán)隊(duì)成員情況、進(jìn)度、成本等因素。

團(tuán)隊(duì)成員情況是最重要的一個(gè)因素，對(duì)于前一個(gè)版本已經(jīng)對(duì)外提供服務(wù)，或者用于生產(chǎn)的情況下，如果團(tuán)隊(duì)成員穩(wěn)定、技術(shù)能力強(qiáng)，那么可以盡量采用服務(wù)升版的模式，這樣可以增加代碼的內(nèi)聚性，后期維護(hù)工作量最小化;如果團(tuán)隊(duì)成員變化較大、成員技術(shù)能力比較差，那么盡量采用新功能的模式，減少對(duì)原有服務(wù)代碼的修改，這樣能夠保障已發(fā)布功能的穩(wěn)定性，但是會(huì)增加后期維護(hù)工作量。

進(jìn)度、成本也是很重要的因素，如果研發(fā)時(shí)間、成本足夠，可以盡量采用服務(wù)升版的模式，盡可能地進(jìn)行抽象、內(nèi)聚的設(shè)計(jì)，優(yōu)化相關(guān)代碼，減少維護(hù)成本。如果研發(fā)時(shí)間、成本壓力大，同時(shí)還涉及運(yùn)維，那么對(duì)新功能往往會(huì)采用新功能的方式，復(fù)制一套代碼進(jìn)行修改，這樣能夠短期完成新功能，同時(shí)又不影響已有功能，但這會(huì)大大增加后期的維護(hù)以及軟件的升級(jí)。

3.1 新增功能模式

1）模式概述

該模式是通過設(shè)計(jì)新的前端功能及服務(wù)來實(shí)現(xiàn)相關(guān)需求。

2）適用場(chǎng)景

該模式適用于以下幾種情況：

在應(yīng)用低版本中沒有，需要設(shè)計(jì)新的功能。

高版本與低版本需求存在很大差異。

直接修改應(yīng)用V1版功能滿足高版本需求但沒有效益，即在進(jìn)度、成本、質(zhì)量等方面無明顯收益。

3）設(shè)計(jì)說明

前端增加新的功能，這里V1/Req表示新的前端功能設(shè)計(jì)。

后端增加新的服務(wù)，這里V1/service1表示新的后端服務(wù)設(shè)計(jì)。

3.2 功能等效模式

1）模式概述

該模式指對(duì)模塊V1版相關(guān)功能實(shí)現(xiàn)不需要修改，模塊V2版中與V1版中沒有差異。

2）適用場(chǎng)景

該模式適用于以下幾種情況：

低版本和高版本的功能一致。

低版本已經(jīng)考慮了高版本需求，實(shí)現(xiàn)了相關(guān)功能。一般是在低版本設(shè)計(jì)時(shí)，對(duì)未來需求有充分考慮，進(jìn)行了相關(guān)的設(shè)計(jì)。

3）設(shè)計(jì)說明

前后端設(shè)計(jì)及實(shí)現(xiàn)不需要修改。

3.3 前端升版模式

1）模式概述

該模式指前端需要設(shè)計(jì)開發(fā)新版本，后端不需要或僅需要很小的改進(jìn)實(shí)現(xiàn)相關(guān)業(yè)務(wù)需求。

在模塊V2版上線時(shí)，需要重新配置調(diào)試階段功能菜單。

2）適用場(chǎng)景

該模式適用于以下幾種情況：

后端服務(wù)能夠支持低版本和高版本的相關(guān)業(yè)務(wù)，低版本和高版本的前端差異很小，高版本頁面布局邏輯有較大調(diào)整。

后端服務(wù)僅需要較小修改且邏輯獨(dú)立清晰，低版本和高版本的前端差異很小，高版本頁面布局邏輯有較大調(diào)整。

3）設(shè)計(jì)說明

前端開發(fā)新的版本，調(diào)試和運(yùn)行的功能差異很小，僅需要增加標(biāo)識(shí)區(qū)分。

后端服務(wù)僅僅需要很小的修改，且業(yè)務(wù)邏輯清晰簡(jiǎn)單。

3.4 前后端升版模式

1）模式概述

該模式指前端、后端都需要設(shè)計(jì)開發(fā)新版本，滿足低版本和高版本的功能需求。

2）適用場(chǎng)景

該模式適用于以下情況：

低版本和高版本的前端差異很小，高版本頁面布局邏輯有較大調(diào)整;后端邏輯實(shí)現(xiàn)需要較大修改實(shí)現(xiàn)相關(guān)業(yè)務(wù)規(guī)則。

3）設(shè)計(jì)說明

前端設(shè)計(jì)開發(fā)新的版本，低版本和高版本的功能差異很小，僅需要增加標(biāo)識(shí)區(qū)分。

后端服務(wù)需要較大修改，進(jìn)行重新設(shè)計(jì)實(shí)現(xiàn)。

3.5 新前端模式

1）模式概述

該模式指前端需要設(shè)計(jì)開發(fā)新版本，滿足高版本的功能需求，后端不需要或僅需要很小的改進(jìn)實(shí)現(xiàn)相關(guān)業(yè)務(wù)需求。

2）適用場(chǎng)景

該模式適用于以下情況：

運(yùn)行和調(diào)試的前端頁面布局及邏輯功能差異較大，后端服務(wù)僅需要較小修改且邏輯獨(dú)立清晰。

3）設(shè)計(jì)說明

前端需要設(shè)計(jì)運(yùn)行的功能界面。

后端服務(wù)僅僅需要很小的修改，且業(yè)務(wù)邏輯清晰簡(jiǎn)單。

3.6 前端升版+新后端模式

1）模式概述

該模式指前端需要設(shè)計(jì)開發(fā)新版本，后端調(diào)試服務(wù)不需要或僅需要很小的改進(jìn)實(shí)現(xiàn)相關(guān)業(yè)務(wù)需求，后端運(yùn)行需要設(shè)計(jì)新的服務(wù)以實(shí)現(xiàn)業(yè)務(wù)需求。

2）適用場(chǎng)景

該模式適用于以下情況：

低版本和高版本的前端差異較小;低版本和高版本后端業(yè)務(wù)邏輯差異較大，后端需要修改實(shí)現(xiàn)相關(guān)業(yè)務(wù)需求。

3）設(shè)計(jì)說明

前端開發(fā)新的版本，低版本和高版本的功能差異很小，僅需要增加標(biāo)識(shí)區(qū)分。

后端低版本服務(wù)不需要修改或僅僅需要很小的修改，且業(yè)務(wù)邏輯清晰簡(jiǎn)單。

后端需要新設(shè)計(jì)服務(wù)，以實(shí)現(xiàn)高版本業(yè)務(wù)需求。

4 結(jié)束語

本文介紹的基于代碼版本演進(jìn)模型和軟件迭代設(shè)計(jì)模式的版本迭代方法，在微服務(wù)項(xiàng)目集群的軟件研發(fā)項(xiàng)目中具有良好的應(yīng)用實(shí)踐。項(xiàng)目管理者可以根據(jù)本文中的代碼版本演進(jìn)模型進(jìn)行項(xiàng)目的配置規(guī)劃，根據(jù)實(shí)際項(xiàng)目規(guī)模及規(guī)范定義相關(guān)的人員角色、倉庫、版本分支的規(guī)劃。在做系統(tǒng)服務(wù)版本設(shè)計(jì)時(shí)，架構(gòu)師、設(shè)計(jì)人員再參考設(shè)計(jì)模式進(jìn)行設(shè)計(jì)，合理規(guī)劃好系統(tǒng)服務(wù)各個(gè)版本的功能以及各個(gè)功能采用的模式。

參考文獻(xiàn)：

[1] 王磊.微服務(wù)架構(gòu)與實(shí)踐[M].北京：電子工業(yè)出版社，2016.

[2] 龍新征，彭一明，李若淼.基于微服務(wù)框架的信息服務(wù)平臺(tái)[J].東南大學(xué)學(xué)報(bào)（自然科學(xué)版），2017， 47（z1）： 48-52.

[3] Newman S.微服務(wù)設(shè)計(jì)[M]. 崔力強(qiáng)，張駿，譯.北京：人民郵電出版社，2016.

[4] 杜圣東，楊燕，滕飛.交通大數(shù)據(jù)：一種基于微服務(wù)的敏捷處理架構(gòu)設(shè)計(jì)[J].大數(shù)據(jù)，2017，3（3）：53-67.

[5] 李欣，張路，謝冰，等.基于構(gòu)件的軟件版本管理系統(tǒng)[J].電子學(xué)報(bào)，2000，28（11）：119-121，131.

[6] 萬志波.協(xié)同設(shè)計(jì)系統(tǒng)中的版本管理技術(shù)研究[D].成都：西南交通大學(xué)，2005.

[7] Mason M.版本控制之道：使用Subversion[M].陶文，譯.北京：電子工業(yè)出版社，2007.

[8] 劉燕秋，勉玉靜，趙文耘.軟件配置管理中版本管理技術(shù)研究[J].計(jì)算機(jī)工程與應(yīng)用，2003，39（21）：68-71.

[9] 張宇光，王俊杰，胡淵喆，等.面向工作流的Gitlab服務(wù)化設(shè)計(jì)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2017，26（9）：224-231.

[10] 張宇光.Gitlab 用戶權(quán)限管理增強(qiáng)與服務(wù)化方法的設(shè)計(jì)與實(shí)現(xiàn)[D].北京：中國科學(xué)院大學(xué)，2017.

[11] 李勛雄.淺析和家湖南的代碼管理與部署—利用Gitlab，Jenkins實(shí)現(xiàn)CI/CD[J].數(shù)字化用戶，2019，25（45）： 107-108，110.

[12] 魏海超.基于gitlab的多版本并行開發(fā)方法及系統(tǒng)：CN112698815A[P].2021-04-23.

[13] 馮韜，但斌，蘭林春，等.面向大規(guī)模定制的產(chǎn)品族結(jié)構(gòu)與配置管理[J].計(jì)算機(jī)集成制造系統(tǒng)-CIMS，2003，9（3）：210-213.

收稿日期：2022-02-26

作者簡(jiǎn)介：汪驥宇（1981—），男，安徽績(jī)溪人，高級(jí)工程師，碩士研究生，主要研究方向?yàn)槠髽I(yè)級(jí)軟件架構(gòu)、企業(yè)數(shù)據(jù)治理。