多人多團隊應該如何實施微服務？版本如何管理？
大家好，我是飄渺。今天繼續更新DDD&微服務專欄，本篇主要與大家分享一下在多人團隊中如何更好地組織代碼和版本控制。
代碼倉庫分離
首先，看看在多模塊多團隊的情境下，應該如何合理組織代碼。
以Dailymart項目為例，目前的代碼組織方式是將所有的業務模塊和基礎組件都存放在一個代碼倉庫中，這種做法在小團隊中較為常見，而且許多開源微服務腳手架也采用了這種組織結構。
然而，遺憾的是，這種代碼組織方式只適合小團隊的使用。在涉及多個團隊的大型項目中，每個團隊負責獨立的開發模塊時，這樣的代碼組織結構很可能會引發問題。
在多模塊多團隊的開發中，每個模塊的發布日期和上線范圍可能各不相同。為了解決這個問題，通常需要在開發過程中創建多個分支，這導致多個分支版本并存的情況。
這樣的情況下，每次上線都需要協調各團隊進行分支代碼合并。例如，從各自的特性Feature分支合并到一個統一的測試分支，然后從測試分支構建部署鏡像進行發布。然而，合并過程中一旦出現代碼沖突，就需要找相關人員進行代碼合并，這不僅耗時耗力，而且容易出錯。（我曾參與過一個多團隊項目開發，每次上線都是雞飛狗跳）
因此，在多團隊開發時，我們建議按照業務模塊進行代碼拆分，將每個業務模塊的代碼存放在獨立的代碼倉庫中。
這樣，盡管各自團隊可能仍然存在多分支開發的情況，但不再需要進行統一的合并，從而極大地提高了開發部署的效率。
同時，需要將所有公共組件也放置于一個單獨的代碼倉庫中，業務模塊按需引入即可。
接下來以Dailymart為例，介紹一下代碼如何拆分：
1、DailyMart項目中包含了用戶、訂單、購物車、庫存、商品等多個模塊，這些模塊按照普通SpringBoot項目的形式組織代碼，并存放在不同的代碼倉庫中。
2、將基礎組件模塊dailymart-starter和dailymart-dependencies模塊共同放置到另外一個單獨的倉庫中，業務模塊根據需要引入各自需要的組件。
組件版本的統一管理
在大型項目中，需要統一規劃依賴組件的版本，在Maven項目中通常通過BOM（Bill Of Materials）來實現。
BOM全稱是Bill Of Materials，譯作材料清單。BOM本身并不是一種特殊的文件格式，而是一個普通的POM文件，只是在這個POM中，我們羅列的是一個工程的所有依賴和其對應的版本。該文件一般被其它工程使用，當其它工程引用BOM中羅列的jar包時，不用顯示指定具體的版本，會自動使用BOM對應的jar版本。
在Dailymart項目中，dailymart-dependencies就是一個BOM，在該文件中定義了項目所需組件的版本。其他模塊只需在pom文件的dependencyManagement中引入bom依賴，后面引入定義好的組件時就不再需要指定版本了。
<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>公共組件升級
當項目中有多個公共組件時會出現這樣一個問題，每個公共組件定義的版本可能不一樣。比如dailymart-common-spring-boot-starter的版本是1.0.0，dailymart-cache-spring-boot-starter的版本是1.0.1，這樣就導致項目的依賴管理變得比較混亂。
推薦的解決辦法是使用 revision 占位符統一管理基礎組件版本。
1、在pom文件中定義屬性
<properties>
<revision>2024.0.0-SNAPSHOT</revision>
</properties>2、定義組件時直接使用revision變量作為版本號
<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 變量的值，各組件版本就會統一變更，非常方便。
不過使用這種方式在公共組件模塊執行 maven install 或 maven deploy 時會出現問題，推送到maven倉庫中的pom文件仍然使用 revision 變量，業務模塊無法直接引用。
此時我們需要借助Maven插件 flatten-maven-plugin，使其在 install 或 deploy 時自動將 revision 替換成具體的版本號。
<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文件添加此插件后，執行 install 時會生成一個名為 .flattened-pom.xml 的文件，打開文件后可以看到 revision 變量已經全部替換成了具體的版本號。
Maven版本的選擇
在將自定義組件推送到maven倉庫時，可以選擇兩種不同版本：Release版本和Snapshot版本。這兩者應該如何選擇呢？
兩者區別的區別如下：
- 如果是Snapshot版本，在mvn deploy時會自動發布到快照版本庫中。引入使用快照版本的模塊，在不更改版本號的情況下，直接編譯打包時，Maven會自動從倉庫下載最新的快照版本。
- 如果是Release版本，那么在mvn deploy時會自動發布到正式版本庫中。引入正式版本的模塊，在不更改版本號的情況下，編譯打包時，如果本地已經存在該版本的模塊則不會主動去鏡像服務器上下載。
簡而言之：Release版本是正式版，有bug不能再繼續使用這個版本號，需要配合開發方修改版本號；Snapshot版本是快照版，有bug可以繼續使用同一版本號，可以自動升級。
如果是內部開發項目，推薦使用Snapshot版本，即定義組件時在版本號后面加上 -SNAPSHOP 標識符，這樣搭配上DevOps會非常方便；如果是需要對外發布的組件，還是需要使用Release版本發布。
小結
本文介紹了在多人團隊協作中更有效地組織代碼和進行版本控制的方法，希望對你有所幫助！
- 代碼倉庫優化： 建議按業務模塊分離代碼至獨立倉庫，提高開發效率。
- 組件版本統一管理： 引入BOM，通過 revision 占位符簡化組件版本管理。
- 公共組件版本升級： 推薦使用 revision 占位符集中管理基礎組件版本，借助 flatten-maven-plugin 解決版本問題。
- Maven版本選擇： 內部項目使用Snapshot版本，外部發布使用Release版本，確保靈活性和穩定性。
