Maven適合管理公共代碼庫嗎

1.公共代碼庫

任何項(xiàng)目，我們都不可避免的會有一個(gè)公共代碼庫，這個(gè)公共代碼庫中可能存放了一些工具類或者實(shí)體類，供其他項(xiàng)目使用。

常規(guī)的做法就是把公共代碼庫上傳到公司私服，然后每個(gè)人各自在項(xiàng)目中添加依賴即可，這種方式，相信很多小伙伴們都玩過。

但是不知道大家有沒有想過，這種方式其實(shí)有一個(gè)弊端，就是它不適用于快速迭代的項(xiàng)目。

在一個(gè)快速迭代的項(xiàng)目中，common 的變化非常頻繁，這就意味著開發(fā)者得不停的將 common 打包上傳，其他人不停的修改所引用的 common 版本號。

在傳統(tǒng)的單體應(yīng)用中，團(tuán)隊(duì)人可能不會太多，common 變化也不怎么頻繁，所以用 Maven 管理公共代碼塊的劣勢并不明顯。

而現(xiàn)在流行的微服務(wù)架構(gòu)適合大軍團(tuán)作戰(zhàn)，人多微服務(wù)數(shù)量也多，在微服務(wù)項(xiàng)目中，動輒幾十個(gè)上百個(gè)微服務(wù)。為了解決微服務(wù)之間調(diào)用時(shí)的序列化問題，我們可能將實(shí)體類都抽到一個(gè)公共的 common 中，每個(gè)微服務(wù)都可以根據(jù)自己的需求修改 common，即使每個(gè)微服務(wù)每天修改一次 common，反映到 common 身上，也是日日夜夜不停的變化，而其他的微服務(wù)就得不停的修改版本號以便日日夜夜追隨這種變化。

在這樣的情況下，顯然不適合使用 Maven 繼續(xù)管理 common，因?yàn)檫@意味著你得不停的打包，所有的微服務(wù)得不停的修改引用的 common 版本號。

“  

為了防止有人抬杠，松哥得補(bǔ)充一句，上面所說的這種情況在快速迭代的微服務(wù)項(xiàng)目中比較常見，特別是團(tuán)隊(duì)越大，微服務(wù)數(shù)量越多，Maven 管理公共代碼塊的劣勢越明顯。而傳統(tǒng)的單體應(yīng)用中，你可能并不容易感受到問題所在。

從松哥上面的描述中大家可以看出，Maven 實(shí)際上更側(cè)重于包的依賴管理，雖然它能夠做到在不同項(xiàng)目中同步公共代碼，但沒法雙向同步（所謂雙向同步，就是各個(gè)微服務(wù)中 common 的更新自動同步到 common 庫，common 庫的更新也能自動同步到各個(gè)微服務(wù)），Maven 更適用于公共代碼庫比較穩(wěn)定的情形。

2.解決方案

如果公共代碼庫總是在不停的變化，而 Maven 又并不是特別方便，那么我們還有沒有其他解決方案呢？

2.1 Git Subtree

Git Subtree 是 Git 官方給出的一個(gè)管理子項(xiàng)目的解決方案，在 Git Subtree 之前，官方給出的方案是 Git Submodule，但是從 Git1.5.2 開始，Git 新增并推薦使用這個(gè)功能來管理子項(xiàng)目，只要大家本地安裝的 Git 版本大于等于 1.5.2，都可以直接使用 Git Subtree。

Git Subtree 雖然不具備依賴管理的功能，但是在處理快速代替的公共代碼庫時(shí)，卻顯得非常得心應(yīng)手，而且它能夠做到雙向同步！

2.2 具體應(yīng)用

首先，假設(shè)我現(xiàn)在有一個(gè)項(xiàng)目叫做 vmall，vmall 是一個(gè)微服務(wù)項(xiàng)目，里邊包含了很多微服務(wù)，同時(shí)也包含了一個(gè)在快速迭代的公共代碼塊 vmall-common（注意，vmall 和 vmall-common 分屬兩個(gè)不同的倉庫）。

vmall-common 我已經(jīng)提交在 GitHub 上了，地址是 https://github.com/lenve/vmall-common。

現(xiàn)在我想在 vmall 項(xiàng)目中引用 vmall-common，怎么做呢？在 vmall 倉庫中執(zhí)行如下代碼即可：

git subtree add --prefix=vmall-common https://github.com/lenve/vmall-common.git master --squash

最后的 --squash 參數(shù)表示不拉取歷史信息，而只生成一條 commit 信息，這是一個(gè)可選參數(shù)，可以不加。這行命令執(zhí)行完成后，在 vmall 項(xiàng)目中，就可以看到 vmall-common 了，而且 vmall-common 將作為一個(gè)普通的文件夾存在，該怎么樣還是怎么樣。

 

這個(gè)時(shí)候我們就可以正常開發(fā)了。

假如說，我們在開發(fā)的過程中，修改了 vmall-common，這個(gè)時(shí)候，在 vmall 倉庫中，我們可以通過如下命令將 vmall-common 提交到它自己的倉庫中去（先將 vmall 中的變化提交到遠(yuǎn)程倉庫，再執(zhí)行如下代碼）：

git subtree push --prefix=vmall-common https://github.com/lenve/vmall-common.git master

如果是在 vmall-common 自己的倉庫中提交這種變化，那就是普通的 Git 提交命令，這個(gè)就不需要我多說了。

當(dāng) vmall-common 中的代碼發(fā)生變化了，其他微服務(wù)通過如下指令可以更新代碼：

git subtree pull --prefix=vmall-common https://github.com/lenve/vmall-common.git master --squash

這三個(gè)指令基本上就能應(yīng)付日常的大部分操作了，不過每次都要輸入一個(gè)長長的地址很不方便，我們可以給地址取一個(gè)別名：

git remote add -f vmall-common https://github.com/lenve/vmall-common.git

這樣，最上面介紹的三個(gè)命令就可以簡化了：

git subtree add --prefix=vmall-common vmall-common master --squash
git subtree pull --prefix=vmall-common vmall-common master --squash
git subtree push --prefix=vmall-common vmall-common master