雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
1.微服務架構
理論上的微服務架構和實際應用的微服務，往往會有一些差異。
理論上，在微服務架構中，各個獨立的微服務可以是各種語言，像我們使用的 Eureka 注冊中心，就是支援多種語言的，這樣可以充分發揮各種語言的優勢。如果是這樣，就沒有必要從項目整體上進行版本管理了，也管不了。
但是在實際操作中，考慮到團隊的技術棧，現有的技術生态等因素，大部分情況下，我們可能并不會在項目中摻雜其他語言進來，比如就是用 Java 開發，相信大部分小夥伴都是這麼做的。
既然統一都使用 Java 語言開發，那一個需求就随之浮出水面，就是項目依賴統一管理。
這個問題其實不是絕對的。
大型的微服務項目分屬不同的團隊開發，每個團隊維護好自己的項目，然後通過 RPC 或者 HTTP 的方式互相之間進行互動，這種情況下，版本号也可以交由各個團隊自行維護，這樣版本更新的時候，就不必一起更新，可以各個團隊獨自完成，逐個更新。
但是這種方式又可能會帶來另外一個問題，就是依賴版本的碎片化，在經過 N 多次疊代之後，可能會存在兩個項目所依賴的微服務版本差異非常大。
是以，在實際操作中，有的團隊會傾向于将項目版本統一管理。
統一管理也很簡單，就是搞一個 parent 就行了，但是有的小夥伴容易将這種 parent 和聚合工程搞混，是以這裡還是和大家稍微聊一下怎麼統一管理項目版本号。
2.統一管理版本号
2.1 聚合工程
先來說一說聚合工程，這裡我就不重新寫代碼了，微人事項目的服務端就是一個聚合工程。
我們可以來看下 vhrserver 的 pom.xml 檔案：
<parent>
<artifactId>vhr</artifactId>
<groupId>org.javaboy</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>vhrserver</artifactId>
<packaging>pom</packaging>
<modules>
<module>vhr-mapper</module>
<module>vhr-model</module>
<module>vhr-service</module>
<module>vhr-web</module>
</modules> 複制代碼在這個聚合工程中，vhr-model 用來放實體類，vhr-mapper 用來放 Dao 層，vhr-server 用來放 Service 層，vhr-web 則是一個 Spring Boot 工程。
在聚合工程中，vhr-web 作為聚合工程的一部分，是無法獨立打包的，因為它依賴 vhr-service，vhr-service 依賴 vhr-mapper ，而 vhr-mapper 則依賴 vhr-model。我們需要從 vhrserver 處打包，這樣它會自動解決 module 之間的依賴問題。
單獨給 vhr-web 打包會報如下錯誤：
從 vhrserver 處統一打包，結果如下：
可以看到，我們需要直接打包聚合工程，内部的依賴問題會自動解決。
有人可能會問，既然前面報 Could not find artifact org.javaboy:vhr-service:pom:1.0-SNAPSHOT 錯誤，那我先把 vhr-service install 到本地倉庫，再去打包 vhr-web 行不行？
這個是不行的，因為這是聚合工程，不能這樣做，隻能從聚合工程處打包。
2.2 統一管理版本号
上面說的聚合工程雖然也能實作版本号的統一管理，但是我們不能在微服務中采用這種方式。
你想一個微服務系統，包含了很多子系統，例如商品管理、交易管理、物流管理等等，要是想給商品管理打包，你還得從聚合工程處打包，打完之後，其他微服務子產品也生成了各自的包，這樣效率太低了。
但是我們還想實作版本号的統一管理，該怎麼辦呢？建立父子工程即可。這種項目結構和聚合工程很像，但是不一樣，很多小夥伴會搞混，是以這裡我來給大家稍微示範一下。
首先我們定義一個普通的 Maven 工程作為父工程，我把 pom.xml 檔案拎出來給大家參考下：
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.0.RELEASE</version>
<relativePath/>
</parent>
<packaging>pom</packaging>
<groupId>org.javaboy.vmall</groupId>
<artifactId>vmall</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<!--省略-->
</properties>
<dependencyManagement>
<dependencies>
<!--省略-->
</dependencies>
</dependencyManagement> 大家可以看到，這個父工程本身也有一個 parent ，就是 Spring Boot 中的 parent。
這裡的 packaging 依然是 pom，然後我們定義了 dependencyManagement，将一些不包含在 spring-boot-starter-parent 中的依賴版本進行統一管理。但是大家注意，這裡沒有 modules 節點，這是一個很大的不同。
接下來，我們建立其他微服務項目，在建立的過程中，可以采用平鋪的方式，例如下面這樣：
也可以做成有層次結構的父子形式，像下面這樣：
兩種方式都可以。
然後在各個微服務項目中，重新修改 parent 即可：
如此之後，我們就可以對各個微服務中的依賴版本進行統一管理了。
這種項目結構和聚合工程并不一樣，這種項目打包，是可以獨立打包的。
首先我們先将父工程 install 到本地倉庫：
然後再去 install vmall-common 子產品，最後給 vmall-app-manager 進行打包，注意，現在的 vmall-app-manager 可以獨立打包，不需要從總的 parent 處進行統一打包。微服務項目中如果需要對項目版本進行統一管理，可以采用這種方式。
小夥伴們可以仔細品一品這種方式和聚合工程的差異。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-02
本文作者：江南一點雨
本文來自：“
掘金”，了解相關資訊可以關注“掘金”