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

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

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

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

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

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

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

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

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

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

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

為什么單體更適合當前?

再回到多年以前， Martin Fowler 寫了那篇《Monolithic First》，意在告訴人們在團隊微服務能力和技術(shù)不夠成熟的時候，你不應該采用微服務。這里的場景和上述的這個場景并不是一樣的。對于系統(tǒng)的最終形態(tài)來說，單體并不一定適合這個系統(tǒng)，但是當于當前的我們來說，單體是最合適的。原因諸如于：

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

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

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

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

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

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

所以，只要我們用相似的形態(tài)來構(gòu)建一個單體應用，那么它在部署形態(tài)上就可以變成是微服務架構(gòu)。簡單來說，就是：

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

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

如何遷移 ?

接著，我們就開始合并多個代碼倉庫，其中的一些

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

就遷移過程來說，它并不復雜，就是耗時。

還有其它選項嗎?

相似的場景，如果一個開發(fā)人員多個微服務，并且在不考慮單機部署的情況下，Monorepo 是一個更好的選擇，把所有微服務項目的代碼放在一個倉庫里。

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

其它

回過頭來看，對于小的團隊來說，單體會不會是更合適的選擇?那么大的團隊呢?