【答疑解惑】|?作者?/ Edison Zhou

這是恰童鞋騷年的第265篇原創內容

---

之前在學習微軟的示例eShopOnContainers時發現它使用的是單體代碼倉庫庫，之后又發現大家在進行微服務項目開發時也都在使用單體代碼倉庫。問題來了，為啥要微服務項目都要使用單體倉庫（所有微服務都在一個代碼倉庫）呢？

1微服務應用的代碼倉庫組織

我們都知道，微服務應用相對于單體應用來說，最大的好處就是可以獨立開發、測試、部署和擴展。單體應用一般會采用單體代碼倉庫，但是微服務應用的代碼倉庫應該如何組織呢？是每個微服務一個倉庫嗎？

其實不一定，針對微服務應用的代碼倉庫組織，業界有兩種主要的實踐：

（1）多體倉庫（Multi-Repo）：即每個微服務對應各自代碼倉庫

（2）單體倉庫（Mono-Repo）：即所有微服務對應一個代碼倉庫

下圖展示了這兩種實踐的示意（引用自波波老師《Spring Boot與K8s云原生應用開發》課程）：

單體應用倉庫?vs?微服務多體倉庫 vs 微服務單體倉庫

2多體倉庫與單體倉庫的比較

多體倉庫的優點顯而易見，職責單一，代碼量和復雜性受控，支持多個團隊獨立開發，邊界清晰。單個微服務也易于獨立開發測試和擴展，不需要集中式管理。差不多，這些就是微服務帶來的好處。

但是，多體倉庫有其自己的缺點：

一來項目代碼不容易形成統一規范，每個團隊各自為政，隨意引入依賴，Code Review無法集中開展，代碼風格也會各不相同。

二來項目整體集成和部署會比較麻煩，雖然單個項目集成容易，但是整體進行集成就會收到倉庫分散帶來的困難。

三來也是我個人認為對于中小技術團隊來說最為重要的，開發人員會缺乏對于整體項目的認知，只關心自己負責的那一小塊，從而缺失對整體架構和業務目標整體性的理解。

最后，項目間可能會存在較多的冗余代碼，每個微服務一個倉庫會造成每個團隊不斷地重復造輪子，而不是去優先重用其他團隊開發的已有的項目代碼。

對于多體倉庫的缺點，單體倉庫解決了一些，這也就形成了單體倉庫的好處：

一來易于規范化項目代碼，所有微服務都在一個倉庫中，可以規范代碼風格，便于集中組織Code Review。

二來易于整體集成和部署，所有微服務都在一個倉庫中，配合DevOps工具可以方便地實現一鍵構建和部署，實現持續集成。

三來易于理解項目整體，開發人員可以將整個項目clone到本地IDE中進行Code Review也可以直接本地部署和調試從而易于掌握整體技術架構和應用目標。

最后易于重用已有輪子，開發人員在開發時容易發現和重用已有的代碼而不是去重復造輪子，當然也利于對現有的代碼進行重構。

當然，萬物都是有利有弊，單體倉庫也不例外。隨著業務的快速發展，單體倉庫中的項目代碼會變得越來越龐大，復雜性也會隨之上升。因此，對于企業來說，需要有專門的集成團隊和自動化的集成工具來支持，才能保證單體倉庫的持久應用。

3業界都有哪些企業誰在用單體倉庫？

在業界使用單體倉庫組織微服務項目的企業不少，例如Google、Facebook、Twitter和Salesforce以及Microsoft等互聯網巨頭，雖然他們內部的項目龐大，開發人員眾多，但是他們還是選擇了使用單體倉庫。

誰在用MonoRepo

eShopOnContainers項目代碼結構

剛剛我們也說道，這些巨頭企業都是有專門的集成團隊和成熟的自動化集成工具來為開發團隊進行支持，使得開發團隊可以一鍵構建和部署。

畫外音：對小企業來說，可能上微服務架構都得慎重？一百個讀者，有一百個哈姆雷特，各有各的看法。

4小結

對于中小企業/初創企業/進行數字化轉型的傳統行業企業來說，如果要上微服務架構，一般早期微服務的數量不會特別多，采用單體倉庫會比較合適。

從本文也可以了解到，微服務架構并不是倡導所有的東西都要獨立自治，像代碼倉庫就可以集中管理，而且這也是業界的最佳實踐之一。

最后，如果你在使用.NET Core開發微服務或者計劃使用.NET Core開發微服務，都可以先閱讀一下這本《.NET微服務：容器化應用架構指南》，目前已更新到ASP.NET Core 3.1版本（LTS版本）。

畫外音：欲練此功，必看此書。點擊“閱讀原文”，即可學習此書。

往期精彩推文

技術中臺與業務中臺有啥聯系？

微服務架構中的BFF到底是個啥？

點個“在看” 就是對我最大的支持

????點擊進入架構指南

總結

以上是生活随笔為你收集整理的骚年快答 | 为何微服务项目都使用单体代码仓库？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。