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

[[327556]]

在傳統(tǒng)的項目中，我們經(jīng)常需要搭建聚合工程，這樣可以方便的對項目進(jìn)行分模塊管理，降低維護(hù)難度。

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

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

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

這些微服務(wù)都是一個個獨立的項目，由不同的團(tuán)隊負(fù)責(zé)開發(fā)維護(hù)。

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

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

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

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

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

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

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

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

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

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

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

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

本文授權(quán)轉(zhuǎn)載自公眾號「牧碼小子」。公眾號牧碼小子分享大量Java 微服務(wù)干貨，歡迎關(guān)注！