微服務(wù)項目搭建到底要不要聚合工程

這篇文章給大家介紹微服務(wù)項目搭建到底要不要聚合工程，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

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

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

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

1.開發(fā)模式

要搞清楚代碼如何組織，首先大家要明白微服務(wù)架構(gòu)到底是什么樣子！

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

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

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

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

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

2.要不要聚合工程

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

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

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

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

3.為什么會有疑問

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

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

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

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

關(guān)于微服務(wù)項目搭建到底要不要聚合工程就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。