本文是微服務(wù)項目代碼組織形式三部曲中的第三篇，也是最后一篇，通過這三篇文章，相信大家對于如果組織微服務(wù)中的代碼已經(jīng)有了一個基本認(rèn)知，前面兩篇分別是：

第三篇相對來說要簡單一些，本來沒打算寫，但是上周有個小伙伴問了我一個 Maven 問題，然后我就發(fā)現(xiàn)有的小伙伴對聚合工程的認(rèn)知還是不到位，因此才有了這篇文章，想和大家再聊聊聚合工程的問題。

1.微服務(wù)架構(gòu)

理論上的微服務(wù)架構(gòu)和實(shí)際應(yīng)用的微服務(wù)，往往會有一些差異。

理論上，在微服務(wù)架構(gòu)中，各個獨(dú)立的微服務(wù)可以是各種語言，像我們使用的 Eureka 注冊中心，就是支持多種語言的，這樣可以充分發(fā)揮各種語言的優(yōu)勢。如果是這樣，就沒有必要從項目整體上進(jìn)行版本管理了，也管不了。

但是在實(shí)際操作中，考慮到團(tuán)隊的技術(shù)棧，現(xiàn)有的技術(shù)生態(tài)等因素，大部分情況下，我們可能并不會在項目中摻雜其他語言進(jìn)來，比如就是用 Java 開發(fā)，相信大部分小伙伴都是這么做的。

既然統(tǒng)一都使用 Java 語言開發(fā)，那一個需求就隨之浮出水面，就是項目依賴統(tǒng)一管理。

這個問題其實(shí)不是絕對的。

大型的微服務(wù)項目分屬不同的團(tuán)隊開發(fā)，每個團(tuán)隊維護(hù)好自己的項目，然后通過 RPC 或者 HTTP 的方式互相之間進(jìn)行交互，這種情況下，版本號也可以交由各個團(tuán)隊自行維護(hù)，這樣版本升級的時候，就不必一起升級，可以各個團(tuán)隊獨(dú)自完成，逐個升級。

但是這種方式又可能會帶來另外一個問題，就是依賴版本的碎片化，在經(jīng)過 N 多次迭代之后，可能會存在兩個項目所依賴的微服務(wù)版本差異非常大。

因此，在實(shí)際操作中，有的團(tuán)隊會傾向于將項目版本統(tǒng)一管理。

統(tǒng)一管理也很簡單，就是搞一個 parent 就行了，但是有的小伙伴容易將這種 parent 和聚合工程搞混，因此松哥這里還是和大家稍微聊一下怎么統(tǒng)一管理項目版本號。

2.統(tǒng)一管理版本號

2.1 聚合工程

先來說一說聚合工程，這里我就不重新寫代碼了，以微人事(https://github.com/lenve/vhr)為例來和大家分享。

微人事項目的服務(wù)端就是一個聚合工程。

我們可以來看下 vhrserver 的 pom.xml 文件：

vhr

org.javaboy

1.0-SNAPSHOT

4.0.0

vhrserver

pom

vhr-mapper

vhr-model

vhr-service

vhr-web

在這個聚合工程中，vhr-model 用來放實(shí)體類，vhr-mapper 用來放 Dao 層，vhr-server 用來放 Service 層，vhr-web 則是一個 Spring Boot 工程。

在聚合工程中，vhr-web 作為聚合工程的一部分，是無法獨(dú)立打包的，因為它依賴 vhr-service，vhr-service 依賴 vhr-mapper ，而 vhr-mapper 則依賴 vhr-model。我們需要從 vhrserver 處打包，這樣它會自動解決 module 之間的依賴問題。

單獨(dú)給 vhr-web 打包會報如下錯誤：

從 vhrserver 處統(tǒng)一打包，結(jié)果如下：

可以看到，我們需要直接打包聚合工程，內(nèi)部的依賴問題會自動解決。

有人可能會問，既然前面報 Could not find artifact org.javaboy:vhr-service:pom:1.0-SNAPSHOT 錯誤，那我先把 vhr-service install 到本地倉庫，再去打包 vhr-web 行不行？

這個是不行的，因為這是聚合工程，不能這樣做，只能從聚合工程處打包。

2.2 統(tǒng)一管理版本號

上面說的聚合工程雖然也能實(shí)現(xiàn)版本號的統(tǒng)一管理，但是我們不能在微服務(wù)中采用這種方式。

你想一個微服務(wù)系統(tǒng)，包含了很多子系統(tǒng)，例如商品管理、交易管理、物流管理等等，要是想給商品管理打包，你還得從聚合工程處打包，打完之后，其他微服務(wù)模塊也生成了各自的包，這樣效率太低了。

但是我們還想實(shí)現(xiàn)版本號的統(tǒng)一管理，該怎么辦呢？創(chuàng)建父子工程即可。這種項目結(jié)構(gòu)和聚合工程很像，但是不一樣，很多小伙伴會搞混，所以這里我來給大家稍微演示一下。

首先我們定義一個普通的 Maven 工程作為父工程，我把 pom.xml 文件拎出來給大家參考下：

org.springframework.boot

spring-boot-starter-parent

2.3.0.RELEASE

pom

org.javaboy.vmall

vmall

1.0-SNAPSHOT

大家可以看到，這個父工程本身也有一個 parent ，就是 Spring Boot 中的 parent。

這里的 packaging 依然是 pom，然后我們定義了 dependencyManagement，將一些不包含在 spring-boot-starter-parent 中的依賴版本進(jìn)行統(tǒng)一管理。但是大家注意，這里沒有 modules 節(jié)點(diǎn)，這是一個很大的不同。

接下來，我們創(chuàng)建其他微服務(wù)項目，在創(chuàng)建的過程中，可以采用平鋪的方式，例如下面這樣：

也可以做成有層次結(jié)構(gòu)的父子形式，像下面這樣：

兩種方式都可以。

然后在各個微服務(wù)項目中，重新修改 parent 即可：

如此之后，我們就可以對各個微服務(wù)中的依賴版本進(jìn)行統(tǒng)一管理了。

這種項目結(jié)構(gòu)和聚合工程并不一樣，這種項目打包，是可以獨(dú)立打包的。

首先我們先將父工程 install 到本地倉庫：

然后再去 install vmall-common 模塊，最后給 vmall-app-manager 進(jìn)行打包，注意，現(xiàn)在的 vmall-app-manager 可以獨(dú)立打包，不需要從總的 parent 處進(jìn)行統(tǒng)一打包。微服務(wù)項目中如果需要對項目版本進(jìn)行統(tǒng)一管理，可以采用這種方式。

小伙伴們可以仔細(xì)品一品這種方式和聚合工程的差異。

3.小結(jié)

好啦，今天的內(nèi)容比較簡單，再結(jié)合前面已經(jīng)發(fā)過的兩篇文章，相信大家對于如何組織微服務(wù)項目的代碼已經(jīng)有一定的思路了。

如果小伙伴們覺得有收獲，記得點(diǎn)個在看鼓勵下松哥哦～

總結(jié)

以上是生活随笔為你收集整理的java版本号管理_微服务项目中如何管理依赖版本号？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。