微服務：如何存儲許多微服務的源代碼？

Question

目前，我有一個項目20微服務。並且每個微服務都存儲在單獨的GIT reposotiry中。 隨後，服務數量將增加至200（或更多）。

每項服務都有單元測試和集成測試。每個服務都建立在TeamCity（持續集成服務器）中。

問題：如何爲一個項目存儲200個微服務的源代碼？在一個存儲庫中還是在單獨的存儲庫中？

Answer 1

除非這些微服務是緊密耦合（這意味着它是沒有意義的，只下載其中的一部分，而你只用他們的所有工作），每一個讓他們在一個單獨的Git回購建議。

但是，您仍然可以在父回購庫中將它們引用爲submodule以便在任何給定時間跟蹤其狀態。

Answer 2

git submodules和subtrees也有自己的問題。 Facebook和谷歌？爲他們所有的微服務都有一個單一的存儲庫。對這個問題沒有明確的答案，但重構，依賴管理和項目設置等事情從單一存儲庫中獲益。同樣，服務的耦合以及不同團隊如何與回購交互是選擇其中一個或另一個的關鍵。

Answer 3

我們還沒有使用子模塊;我們所做的是分支策略

每個微服務都有自己的文件夾在base_folder文件夾下。有一個發行版分支 - >目前有一個主版本（這裏有所有內容） 有一個接口分支 - >接口（它只有像所有服務的protobuffer/grpc文件那樣的接口）。這個分支總是合併掌握

每個服務都有一個分支 - >其中代碼被按壓（用於代碼審查）sprint_service_name和創建掌握分支

代碼合併請求流

對於新組件

git checkout interfaces 
git checkout -b sprint_service_name 
(create branch from interface branch) 

對於現有組件

git checkout sprint_service_name 
git fetch origin interfaces 
git merge origin/interfaces (don't use git merge origin interfaces !!) 

（或對於上述兩個步驟的git拉原點接口）

下面是一個顯影劑流動

Push to sprint_service_name branch and create merge request to master branch 
git push origin sprint_service_name 

分支流

sprint_service_namexxx --> Merge Request --> master 
sprint_interfaces --> Merge Request --> Interfaces -->master 
interfaces --> sprint_service_namexxx (by all, every day) 

所有共同的部分將在接口分支

（你可以有任意數量的私人分支;但要小心，不要將master轉換爲sprint_service_name或master轉換爲接口;其他不需要的文件將在您的分支）

優點 每個微服務將只有它的代碼和接口文件夾

缺點

我已經看到下面的流程並不總是發生理想情況下，像

sprint_interfaces --> Merge Request --> Interfaces -->master 

它更像

sprint_interfaces --> Merge Request --> master 

這意味着有人要手工花費接口文件夾從主和合並對接口分支。但這僅僅是一門紀律的事情，並沒有破壞任何東西