這個月，我和我的同事們正在開源一個內部的架構治理平臺：ArchGuard，我們進行了一系列的遺留系統的遷移工作：

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

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

遺留微服務系統的挑戰

在我們經過了一系列的內部會議之后，決定了將 ArchGuard 開源。隨后，看到了代碼庫，我們發現了一系列的挑戰：

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

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

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

在這個場景之下，幾乎違反了上面的一系列規則。所以，我就回到了上述的 6 中去，采用 DDD 的分層架構模式。每個資源/聚合/服務在各自的包下管理(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》，意在告訴人們在團隊微服務能力和技術不夠成熟的時候，你不應該采用微服務。這里的場景和上述的這個場景并不是一樣的。對于系統的最終形態來說，單體并不一定適合這個系統，但是當于當前的我們來說，單體是最合適的。原因諸如于：

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

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

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

我們的目標架構是單體嗎?

從某種意義上，就當前來說，它是的。但是，如果管理有所不善的話，它會變成一個大泥球架構。回顧一下，一個多倉庫/多模塊的微服務系統，它與一個單體系統在物理形態上的主要區別在于：

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

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

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

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

如何遷移 ?

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

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

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

還有其它選項嗎?

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

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

其它

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