每個微服務對應一個程式碼庫嗎？ - Reddit

回答
1. 我一直為每個服務使用一個 repo，但這主要是因為我們在工作中使用 maven 和 GitHub。我發現 monorepo 的想法很有趣，但我一直無法找到正確的工具，也不想花時間自己動手。

我反對monorepo的想法。一旦你建立了一個完整的微服務生態系統，它們就會變得非常大，而且很難在企業規模上工作。

例如，在我的公司裡有一個近4GB的 repo。它不斷有50多個PR在等待審查/批准/合併。

在許多情況下，開發團隊可能很少互動，也不在彼此的程式碼上工作。因此，他們沒有必要為了在自己的專案上工作而被迫下載另一個團隊的程式碼，以monorepo的形式。

如果開發團隊之間聯絡緊密，並且經常需要其他團隊的大部分工作來完成自己的開發任務，那麼單庫就非常好。

另外，擁有較小的儲存庫使得管理使用者訪問和授權變得更加容易。我非常喜歡在大型專案中使用單獨的軟體庫。


2. 不存在 "一刀切 "的情況

典型的例子：當開始一個專案的時候，有可能邊界不是很清楚，因此服務之間的介面經常變化。如果是這樣的話，一個monorepo就更方便了：把所有的服務放在一個地方，可以更好地看到什麼在哪裡。

另一個典型的例子：一些服務變得 "獨立"，因為它開始被不同的客戶使用，這些客戶使用不同的服務版本。這樣的服務應該有自己的資源庫。

或者，那可以是一組相關的服務。

或者，我們根本不在乎，反正就是把所有東西都放在一個地方。

換句話說：這個問題沒有上下文是錯誤的。我們需要看一下當前情況的需要。

Tha說，即使我們想問這個問題，回答這個問題也是錯誤的。回答是錯誤的，因為無論哪種方式都可以取得體面的結果。這是一個騎自行車的問題，是一個不太重要的問題。儘管人們會過分執著於一個或另一個答案，但這是真的。


3. 每個服務的Repo。簡化了部署，並確保內部管理的依賴關係只通過版本化的工件消費。


4. 我兩種都用過。Monorepo更容易。

內部的依賴性變得非常簡單。本地開發始終是最新的，可以很容易地用一個指令碼/命令來控制，因為所有的東西都在那裡，並且始終保持同步。整合測試有一個有意義的家，可以毫無顧慮地在本地執行。

你可以在一個分支/PR中為多個服務編寫程式碼，這是一個巨大的人體工程學的好處。

如果你的團隊不大，GitHub/gitlab的介面很好，因為你不需要開啟20個標籤來檢視正在發生的事情，即使你只有幾個開發人員。

我傾向於預設使用Monorepo來處理任何不是真正獨立的專案。


5. 你得到的主要好處是。

原子化修改。當你做一個廣泛的改變時，你不需要提交到多個倉庫。

所有的東西在任何時候都是在一個版本的依賴關係上。從安全的角度來看，這對避免某些微妙的bug很有用。

每個人都可以很容易地接觸、搜尋和以其他方式使用所有的程式碼。

主要的缺點是，當 repo 越來越大時，你需要專門的工具。這通常意味著需要一個專門的團隊來完成。這真的只對小型和大型公司有意義，對那些處於中間的公司來說，交易是很差的。


6. banq：這取決於你對領域和上下文的劃分，每個子領域對應一個程式碼庫，當然，複雜核心子域是每個BC對應一個程式碼庫，這還和clean架構實現有關。