這是一個入門問題，做微服務項目，首先就是要搭建 Project，代碼采用什么樣的形式來組織，這是我們面臨的第一個問題。

[[327556]]

在傳統的項目中，我們經常需要搭建聚合工程，這樣可以方便的對項目進行分模塊管理，降低維護難度。

微服務項目中，我們是否還需要繼續這種開發方式呢?今天松哥結合自己在項目中的經驗和大家簡單聊一下，微服務項目中代碼的組織形式。

1.開發模式要搞清楚代碼如何組織，首先大家要明白微服務架構到底是什么樣子!

在微服務架構中，一個完整的項目被拆分成很多獨立的微服務，例如一個電商項目，可能分為商品管理、商家管理、用戶管理、交易管理、SEO 管理、App 管理、財務管理、系統管理等很多微服務。

這些微服務都是一個個獨立的項目，由不同的團隊負責開發維護。

不同的團隊獨立開發、獨立維護、獨立測試(看情況)、獨立上線，這樣可以有效提高項目的開發效率。

結合項目的實際情況，不同的團隊甚至可以選擇不同的技術棧，比如商品管理模塊用 Java、交易管理可能用 Go、門戶網站可能用 PHP 等等，從微服務架構上來說，這些都是支持的，這也是微服務的優勢之一，即同一系統不必拘泥于同一種語言，當然在具體實踐中，還需要結合團隊的技術棧以及語言的特性來選擇。

其實看到這里，你大概就明白了，聚合工程在這里還能不能用了!

2.要不要聚合工程首先從整體上來說，也就是整個項目層面，我們不再需要聚合工程了。聚合工程可以讓項目統一打包，解決項目中的依賴問題，還可以對依賴的版本進行統一管理，但是這些特性對微服務項目來說，其實并不重要。

假如商品管理模塊用 Java、交易管理用 Go、門戶網站用 PHP，那么這三個獨立的微服務肯定是沒有必要做成一個聚合工程的，你也沒法聚合。當然這是一種比較極端的情況，即使不同微服務模塊都是使用 Java 語言開發，那也沒有必要聚合，因為不同的微服務實際上都是一個個獨立運行的項目，由不同的團隊開發維護，微服務的一大優勢就是各個團隊對獨立開發，互不影響，如果搞個聚合工程，又把各個團隊綁定在一起了。

但是不同的微服務之間，不可避免的要使用一些公共類庫，這些可以統一打包上傳到公司 Maven 私服上，然后不同的團隊自行依賴即可，或者通過 git subtree 的方式來使用。

這是從大的層面來說。具體到每一個微服務，聚合工程的優勢還在，該用還是要用，例如在商品管理模塊，聚合工程還是可以繼續使用的。

3.為什么會有疑問微服務中用不用聚合工程這個問題，本來是個很小的問題，但是為什么很多小伙伴會有疑問呢?

我說一下我了解到幾種情況。

一種情況就是公司的微服務是在舊項目的基礎上改造的，倉促上馬，改來改去，面目全非，已經顧不上架構這些東西了，功能能實現就行了，這種時候甚至在大的層面就使用了聚合工程，結果不同團隊開發起來，還是牽一發而動全身，如果有小伙伴也開發過這種項目，可能就會對聚合工程的使用產生疑問。松哥有一個朋友在廣州做某央企的項目，就是這種情況。

另一種情況可能是因為公司人少，微服務項目開發為了方便，也就從整體上做成了聚合工程，這樣在項目人少并且工程量不大的情況下，修改起來非常方便。

總之，這個問題實際上也不能一概而論，結合項目的實際情況，選擇適合自己的方案才是最好的，松哥近期也會搞一個這方面的架構給大家參考，小伙伴們敬請留意公眾號的消息～

本文授權轉載自公眾號「牧碼小子」。公眾號牧碼小子分享大量Java 微服務干貨，歡迎關注！