這個(gè)月，我和我的同事們正在開(kāi)源一個(gè)內(nèi)部的架構(gòu)治理平臺(tái)：ArchGuard，我們進(jìn)行了一系列的遺留系統(tǒng)的遷移工作：

• 從 Maven 到 Gradle。原因是靈活的自定義 task，還有自帶的增量構(gòu)建等。
• 依賴庫(kù)的更新。
• 系統(tǒng)從微服務(wù)到單體。
• 構(gòu)建規(guī)范和對(duì)應(yīng)的規(guī)范工具化
• 持續(xù)交付。結(jié)合 GitHub Action、Docker Hub 等一系列的 DevOps 開(kāi)源基礎(chǔ)設(shè)施，進(jìn)行全自動(dòng)化的構(gòu)建。
• ……

其中，最有意思的一個(gè)故事莫過(guò)于：從微服務(wù)到單體架構(gòu)。因?yàn)?，它是一種反主流的形式，又或者是反主流的技術(shù)架構(gòu)。

遺留微服務(wù)系統(tǒng)的挑戰(zhàn)

在我們經(jīng)過(guò)了一系列的內(nèi)部會(huì)議之后，決定了將 ArchGuard 開(kāi)源。隨后，看到了代碼庫(kù)，我們發(fā)現(xiàn)了一系列的挑戰(zhàn)：

• 過(guò)多的服務(wù)/模塊。這個(gè)在內(nèi)部開(kāi)發(fā)多年的系統(tǒng)，由多個(gè)微服務(wù)組成 + 代碼庫(kù)組成，
• 知識(shí)缺少沉淀。先前并沒(méi)有留下太多的開(kāi)發(fā)文檔，不了解當(dāng)時(shí)做的一系列技術(shù)決策，需要從 Git 歷史中汲取。
• 復(fù)雜的部署架構(gòu)。同樣是工具，對(duì)比于 Jenkins/Sonarqube 的部署方式，相對(duì)較為復(fù)雜。
• 不一定合理的服務(wù)劃分。我們需要部署一系列的服務(wù)，但是只有掃描器(Arch Scanner)才需要彈性伸縮這樣的特性。

于是呢，我們重新思考合理的后端服務(wù)(微服務(wù))的顆粒度應(yīng)該是怎樣的?所以，參考于過(guò)去總結(jié)的什么用微服務(wù)?以及有多少個(gè)微服務(wù)更合理?先前的一個(gè)結(jié)論，類似于：

1. 微服務(wù)的數(shù)量不超過(guò)開(kāi)發(fā)人員的數(shù)量。
2. 滿足康威定律。微服務(wù)與開(kāi)發(fā)團(tuán)隊(duì)對(duì)齊。
3. 兩個(gè)比薩團(tuán)隊(duì)原則 —— 開(kāi)發(fā)團(tuán)隊(duì)的人員數(shù)量維護(hù)在 3 \~ 12 人。一個(gè)微服務(wù)只由一個(gè)開(kāi)發(fā)團(tuán)隊(duì)維護(hù)。
4. 高內(nèi)聚，低耦合。單個(gè)服務(wù)與其它服務(wù)依賴少。如：兩個(gè)服務(wù)存在相互調(diào)用，耦合度相對(duì)較高，可以考慮合為一個(gè)服務(wù)。
5. 收益大于開(kāi)銷。創(chuàng)建服務(wù)的開(kāi)銷是否超過(guò)了獨(dú)立成服務(wù)的好處。
6. 你不一定需要微服務(wù)?？紤]采用 DDD (領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))分層架構(gòu)來(lái)劃分，以方便未來(lái)拆分為微服務(wù)。

在這個(gè)場(chǎng)景之下，幾乎違反了上面的一系列規(guī)則。所以，我就回到了上述的 6 中去，采用 DDD 的分層架構(gòu)模式。每個(gè)資源/聚合/服務(wù)在各自的包下管理(common 除外)：

├── Application.kt
├── clazz
├── code
├── common
├── config
├── evaluation_bak
├── evolution
├── method
├── metrics
├── module
├── packages
├── qualitygate
├── report
├── report_bak
├── scanner
├── scanner2
└── system_info

由于是合并的代碼，所以代碼中除在于 _bak 還有 scanner2 這樣看似重復(fù)，又或者是遷移中的代碼。

為什么單體更適合當(dāng)前?

再回到多年以前， Martin Fowler 寫了那篇《Monolithic First》，意在告訴人們?cè)趫F(tuán)隊(duì)微服務(wù)能力和技術(shù)不夠成熟的時(shí)候，你不應(yīng)該采用微服務(wù)。這里的場(chǎng)景和上述的這個(gè)場(chǎng)景并不是一樣的。對(duì)于系統(tǒng)的最終形態(tài)來(lái)說(shuō)，單體并不一定適合這個(gè)系統(tǒng)，但是當(dāng)于當(dāng)前的我們來(lái)說(shuō)，單體是最合適的。原因諸如于：

• 單體部署架構(gòu)決定應(yīng)用架構(gòu)。使用 Docker，盡管 Saas 也是更友好的。但是，作為一個(gè)剛起步的開(kāi)源項(xiàng)目，并不會(huì)資金來(lái)支撐這種規(guī)模的 SaaS 服務(wù)。
• 最終用戶是開(kāi)發(fā)者。軟件的使用者本身又可能成為開(kāi)發(fā)者，所以能一次啟動(dòng)就應(yīng)該一次啟動(dòng)。
• 開(kāi)發(fā)者體驗(yàn)優(yōu)先。開(kāi)源與面向開(kāi)發(fā)者決定了 ArchGuard 是一個(gè)開(kāi)發(fā)者體驗(yàn)優(yōu)先的系統(tǒng)。如果一個(gè)參與到 ArchGuard 項(xiàng)目的開(kāi)發(fā)者，要在多個(gè)項(xiàng)目中切換， 那么這中體驗(yàn)是非常差的。在開(kāi)源社區(qū)里，一直都是單體優(yōu)先，如 Gradle、Spring 等。
• 首次部署速度。
• setup 速度。

總體來(lái)說(shuō)，作為一個(gè)開(kāi)源應(yīng)用/工具，軟件工程的模式受限于其合作模式。所以，常規(guī)的軟件開(kāi)發(fā)架構(gòu)，并不一定適用，我們需要一些更好的模式。

那么，我們還有別的選擇嗎?

我們的目標(biāo)架構(gòu)是單體嗎?

從某種意義上，就當(dāng)前來(lái)說(shuō)，它是的。但是，如果管理有所不善的話，它會(huì)變成一個(gè)大泥球架構(gòu)?；仡櫼幌拢粋€(gè)多倉(cāng)庫(kù)/多模塊的微服務(wù)系統(tǒng)，它與一個(gè)單體系統(tǒng)在物理形態(tài)上的主要區(qū)別在于：

• 微服務(wù)使用的是進(jìn)程間調(diào)用，單體是進(jìn)程內(nèi)調(diào)用。
• 微服務(wù)最終有多個(gè)制品包，而單體只有一個(gè)或者是插件化的一帶多。

所以，只要我們用相似的形態(tài)來(lái)構(gòu)建一個(gè)單體應(yīng)用，那么它在部署形態(tài)上就可以變成是微服務(wù)架構(gòu)。簡(jiǎn)單來(lái)說(shuō)，就是：

• 代碼庫(kù)內(nèi)，包(package、service)間的調(diào)用使用 HTTP 調(diào)用，而不是函數(shù)調(diào)用。
• 通過(guò)自定義的構(gòu)建腳本，在構(gòu)建時(shí)拆分代碼庫(kù)，生成多個(gè)服務(wù)制品，并進(jìn)行部署。

從結(jié)果來(lái)說(shuō)，便是將系統(tǒng)放置在一種臨界狀態(tài)。以讓人們根據(jù)自己的需要，做出不同的選擇。如在 SaaS 化的時(shí)候，這就可以變成微服務(wù)的形態(tài)，單體部署時(shí)，則可以變成單體的狀態(tài)。唯一麻煩的是，需要開(kāi)發(fā)者對(duì)于構(gòu)建系統(tǒng)有足夠的了解，并設(shè)計(jì)好充足的自動(dòng)化測(cè)試設(shè)施。

如何遷移 ?

接著，我們就開(kāi)始合并多個(gè)代碼倉(cāng)庫(kù)，其中的一些

1. 保留歷史提交記錄的合并。主要是結(jié)合 git-filer-repo 來(lái)進(jìn)行過(guò)濾和選擇路徑。
2. 構(gòu)建配置的全集。對(duì) Application.properties 等進(jìn)行統(tǒng)一。
3. 使用相同的依賴版本。由于不同的年代的原因，所以選擇的依賴版本也有所不同，需要嘗試先統(tǒng)一，才能合并代碼。
4. 解決沖突。因?yàn)椋缓喜⒘?src 目錄下的內(nèi)容，如果包名有問(wèn)題，如沖突了，需要重置。類似的問(wèn)題，還有：Application 重復(fù)、Bean 沖突、Service 沖突。

就遷移過(guò)程來(lái)說(shuō)，它并不復(fù)雜，就是耗時(shí)。

還有其它選項(xiàng)嗎?

相似的場(chǎng)景，如果一個(gè)開(kāi)發(fā)人員多個(gè)微服務(wù)，并且在不考慮單機(jī)部署的情況下，Monorepo 是一個(gè)更好的選擇，把所有微服務(wù)項(xiàng)目的代碼放在一個(gè)倉(cāng)庫(kù)里。

畢竟，Google 都可以把所有的代碼倉(cāng)庫(kù)放一起，我們又有什么不可以的。當(dāng)然了，Google 使用的技術(shù)原理是不一樣的。不過(guò)，它能提供一個(gè)足夠強(qiáng)壯的理由。

其它

回過(guò)頭來(lái)看，對(duì)于小的團(tuán)隊(duì)來(lái)說(shuō)，單體會(huì)不會(huì)是更合適的選擇?那么大的團(tuán)隊(duì)呢?