多人多團(tuán)隊(duì)?wèi)?yīng)該如何實(shí)施微服務(wù)？版本如何管理？

作者：飄渺Jam 2024-01-02 08:35:17

Release版本是正式版，有bug不能再繼續(xù)使用這個(gè)版本號(hào)，需要配合開發(fā)方修改版本號(hào)；Snapshot版本是快照版，有bug可以繼續(xù)使用同一版本號(hào)，可以自動(dòng)升級(jí)。

大家好，我是飄渺。今天繼續(xù)更新DDD&微服務(wù)專欄，本篇主要與大家分享一下在多人團(tuán)隊(duì)中如何更好地組織代碼和版本控制。

代碼倉庫分離

首先，看看在多模塊多團(tuán)隊(duì)的情境下，應(yīng)該如何合理組織代碼。

以Dailymart項(xiàng)目為例，目前的代碼組織方式是將所有的業(yè)務(wù)模塊和基礎(chǔ)組件都存放在一個(gè)代碼倉庫中，這種做法在小團(tuán)隊(duì)中較為常見，而且許多開源微服務(wù)腳手架也采用了這種組織結(jié)構(gòu)。

然而，遺憾的是，這種代碼組織方式只適合小團(tuán)隊(duì)的使用。在涉及多個(gè)團(tuán)隊(duì)的大型項(xiàng)目中，每個(gè)團(tuán)隊(duì)負(fù)責(zé)獨(dú)立的開發(fā)模塊時(shí)，這樣的代碼組織結(jié)構(gòu)很可能會(huì)引發(fā)問題。

在多模塊多團(tuán)隊(duì)的開發(fā)中，每個(gè)模塊的發(fā)布日期和上線范圍可能各不相同。為了解決這個(gè)問題，通常需要在開發(fā)過程中創(chuàng)建多個(gè)分支，這導(dǎo)致多個(gè)分支版本并存的情況。

這樣的情況下，每次上線都需要協(xié)調(diào)各團(tuán)隊(duì)進(jìn)行分支代碼合并。例如，從各自的特性Feature分支合并到一個(gè)統(tǒng)一的測(cè)試分支，然后從測(cè)試分支構(gòu)建部署鏡像進(jìn)行發(fā)布。然而，合并過程中一旦出現(xiàn)代碼沖突，就需要找相關(guān)人員進(jìn)行代碼合并，這不僅耗時(shí)耗力，而且容易出錯(cuò)。（我曾參與過一個(gè)多團(tuán)隊(duì)項(xiàng)目開發(fā)，每次上線都是雞飛狗跳）

因此，在多團(tuán)隊(duì)開發(fā)時(shí)，我們建議按照業(yè)務(wù)模塊進(jìn)行代碼拆分，將每個(gè)業(yè)務(wù)模塊的代碼存放在獨(dú)立的代碼倉庫中。

這樣，盡管各自團(tuán)隊(duì)可能仍然存在多分支開發(fā)的情況，但不再需要進(jìn)行統(tǒng)一的合并，從而極大地提高了開發(fā)部署的效率。

同時(shí)，需要將所有公共組件也放置于一個(gè)單獨(dú)的代碼倉庫中，業(yè)務(wù)模塊按需引入即可。

接下來以Dailymart為例，介紹一下代碼如何拆分：

1、DailyMart項(xiàng)目中包含了用戶、訂單、購物車、庫存、商品等多個(gè)模塊，這些模塊按照普通SpringBoot項(xiàng)目的形式組織代碼，并存放在不同的代碼倉庫中。

2、將基礎(chǔ)組件模塊dailymart-starter和dailymart-dependencies模塊共同放置到另外一個(gè)單獨(dú)的倉庫中，業(yè)務(wù)模塊根據(jù)需要引入各自需要的組件。

組件版本的統(tǒng)一管理

在大型項(xiàng)目中，需要統(tǒng)一規(guī)劃依賴組件的版本，在Maven項(xiàng)目中通常通過BOM（Bill Of Materials）來實(shí)現(xiàn)。

BOM全稱是Bill Of Materials，譯作材料清單。BOM本身并不是一種特殊的文件格式，而是一個(gè)普通的POM文件，只是在這個(gè)POM中，我們羅列的是一個(gè)工程的所有依賴和其對(duì)應(yīng)的版本。該文件一般被其它工程使用，當(dāng)其它工程引用BOM中羅列的jar包時(shí)，不用顯示指定具體的版本，會(huì)自動(dòng)使用BOM對(duì)應(yīng)的jar版本。

在Dailymart項(xiàng)目中，dailymart-dependencies就是一個(gè)BOM，在該文件中定義了項(xiàng)目所需組件的版本。其他模塊只需在pom文件的dependencyManagement中引入bom依賴，后面引入定義好的組件時(shí)就不再需要指定版本了。

<dependencyManagement>  
    <dependencies>    
        <dependency>  
            <groupId>com.jianzh5</groupId>  
            <artifactId>dailymart-dependencies</artifactId>  
            <version>${revision}</version>  
            <type>pom</type>  
            <scope>import</scope>  
        </dependency>  
    </dependencies> 
</dependencyManagement>

<dependencies>
 <dependency>  
      <groupId>com.google.guava</groupId>  
      <artifactId>guava</artifactId>  
    </dependency>
</dependencies>

公共組件升級(jí)

當(dāng)項(xiàng)目中有多個(gè)公共組件時(shí)會(huì)出現(xiàn)這樣一個(gè)問題，每個(gè)公共組件定義的版本可能不一樣。比如dailymart-common-spring-boot-starter的版本是1.0.0，dailymart-cache-spring-boot-starter的版本是1.0.1，這樣就導(dǎo)致項(xiàng)目的依賴管理變得比較混亂。

推薦的解決辦法是使用 revision 占位符統(tǒng)一管理基礎(chǔ)組件版本。

1、在pom文件中定義屬性

<properties>  
    <revision>2024.0.0-SNAPSHOT</revision>
</properties>

2、定義組件時(shí)直接使用revision變量作為版本號(hào)

<parent>  
    <groupId>com.jianzh5</groupId>  
    <artifactId>dailymart-boot</artifactId>  
    <version>${revision}</version>  
</parent>  
  
<artifactId>dailymart-starter</artifactId>

3、在bom文件中通過revision占位符引入公共組件

<dependencyManagement>  
  <dependencies>  
 <!-- Internal dependencies Start-->  
 <dependency>  
  <groupId>com.jianzh5</groupId>  
  <artifactId>dailymart-common-spring-boot-starter</artifactId>  
  <version>${revision}</version>  
 </dependency>
 
 <dependency>  
     <groupId>com.jianzh5</groupId>  
     <artifactId>dailymart-ddd-spring-boot-starter</artifactId>  
     <version>${revision}</version>  
 </dependency>
  </dependencies>
  
</dependencyManagement>

這樣，若公共組件需要修改版本，只需修改 revision 變量的值，各組件版本就會(huì)統(tǒng)一變更，非常方便。

不過使用這種方式在公共組件模塊執(zhí)行 maven install 或 maven deploy 時(shí)會(huì)出現(xiàn)問題，推送到maven倉庫中的pom文件仍然使用 revision 變量，業(yè)務(wù)模塊無法直接引用。

此時(shí)我們需要借助Maven插件 flatten-maven-plugin，使其在 install 或 deploy 時(shí)自動(dòng)將 revision 替換成具體的版本號(hào)。

<build>  
    <plugins>  
        <plugin>  
            <groupId>org.codehaus.mojo</groupId>  
            <artifactId>flatten-maven-plugin</artifactId>  
            <version>${maven-flatten.version}</version>  
            <configuration>  
                <updatePomFile>true</updatePomFile>  
                <flattenMode>resolveCiFriendliesOnly</flattenMode>  
            </configuration>  
            <executions>  
                <execution>  
                    <id>flatten</id>  
                    <goals>  
                        <goal>flatten</goal>  
                    </goals>  
                    <phase>process-resources</phase>  
                </execution>  
                <execution>  
                    <id>flatten.clean</id>  
                    <goals>  
                        <goal>clean</goal>  
                    </goals>  
                    <phase>clean</phase>  
                </execution>  
            </executions>  
        </plugin>  
    </plugins>  
</build>

在pom文件添加此插件后，執(zhí)行 install 時(shí)會(huì)生成一個(gè)名為 .flattened-pom.xml 的文件，打開文件后可以看到 revision 變量已經(jīng)全部替換成了具體的版本號(hào)。

圖片

Maven版本的選擇

在將自定義組件推送到maven倉庫時(shí)，可以選擇兩種不同版本：Release版本和Snapshot版本。這兩者應(yīng)該如何選擇呢？

兩者區(qū)別的區(qū)別如下：

如果是Snapshot版本，在mvn deploy時(shí)會(huì)自動(dòng)發(fā)布到快照版本庫中。引入使用快照版本的模塊，在不更改版本號(hào)的情況下，直接編譯打包時(shí)，Maven會(huì)自動(dòng)從倉庫下載最新的快照版本。
如果是Release版本，那么在mvn deploy時(shí)會(huì)自動(dòng)發(fā)布到正式版本庫中。引入正式版本的模塊，在不更改版本號(hào)的情況下，編譯打包時(shí)，如果本地已經(jīng)存在該版本的模塊則不會(huì)主動(dòng)去鏡像服務(wù)器上下載。

簡(jiǎn)而言之：Release版本是正式版，有bug不能再繼續(xù)使用這個(gè)版本號(hào)，需要配合開發(fā)方修改版本號(hào)；Snapshot版本是快照版，有bug可以繼續(xù)使用同一版本號(hào)，可以自動(dòng)升級(jí)。

如果是內(nèi)部開發(fā)項(xiàng)目，推薦使用Snapshot版本，即定義組件時(shí)在版本號(hào)后面加上 -SNAPSHOP 標(biāo)識(shí)符，這樣搭配上DevOps會(huì)非常方便；如果是需要對(duì)外發(fā)布的組件，還是需要使用Release版本發(fā)布。