我正在從事一個微服務項目。為此，我希望每個服務都有一個 Go 包，全部包含在項目的父包中。它看起來像這樣：.
└── github.com
└── username
└── project
├── service1
└── service2我認為這種結構可以遵守 Go 關于包名稱和路徑的約定。這樣做的結果是，我的所有微服務都結束在 Github 上的同一個存儲庫上，因為該存儲庫位于 URL 的深度 3 處。我認為如果代碼庫變得很大，這可能會成為未來的一個問題。它還可能增加 CI/CD 管道的復雜性，例如，對一項服務的更改將觸發所有其他服務的構建，并且要克隆的代碼將變得不必要的大。有沒有辦法避免 Go 約定和 Github 工作方式之間的沖突？或者這是 CI/CD 工作中必須解決的問題？
3 回答
POPMUISE
TA貢獻1765條經驗 獲得超5個贊
你所說的現在通常被稱為“monorepo”。雖然我個人喜歡將所有項目放在自己的獨立存儲庫中（包括微服務和其他所有內容），但有許多支持者將公司的所有代碼放在單個存儲庫中。有趣的是，谷歌和 Facebook 都使用 monorepos，盡管必須說他們已經構建了很多奇特的工具來使其為他們工作。
需要注意的一件重要事情是，您的存儲庫與您的架構是分開的。它們之間不一定有任何相關性。您可以將微服務全部放在一個存儲庫中，也可以將一個整體劃分為多個存儲庫；存儲庫只是存儲和記錄代碼庫的工具，僅此而已。
在研究該主題時，以下是從網絡上的許多文章中得出的一些優點和缺點：
Monorepo的優勢
易于在項目之間共享模塊（即使在微服務中，也經常存在交叉問題）
一個地方可以查看并了解存在哪些代碼 - 對于擁有大量代碼的大公司尤其有用
簡化自動和手動代碼審查流程
簡化文檔，而不是從多個、斷開連接的存儲庫中提取
Monorepo的缺點
大量代碼庫在本地簽入/簽出可能具有挑戰性/緩慢
如果沒有非常清晰、嚴格的指導方針，很容易導致產品之間的緊密耦合
需要（稍微）更復雜的 CI/CD 工具來進行部分發布
根據存儲庫平臺的不同，非常大的代碼庫可能會影響性能
與編程中的許多其他事物（尤其是 SOA 中的許多其他事物）一樣，適合您的解決方案取決于許多只有您可以確定的因素。主要的結論是，大大小小的公司在這兩種選擇以及許多介于兩者之間的選擇上都取得了成功，因此請謹慎選擇，但不要太擔心。
忽然笑
TA貢獻1806條經驗 獲得超5個贊
Go 項目所依賴的子包的版本控制可以通過git tagging來跟蹤。因此，鼓勵使用 Go-modules 將子包移動到他們自己的 git 存儲庫中。
如果您的大部分解決方案將用 go 編寫，我建議利用go module。
qq_笑_17
TA貢獻1818條經驗 獲得超7個贊
有一種使用單獨的存儲庫和 Go 微服務的好方法：Go 插件。簡而言之：
構建一個實現共享功能的基礎鏡像。
讓該基礎鏡像在容器中的某個位置查找Go 插件
在派生鏡像中，將功能編譯為 Go 插件，并將其放置在基礎鏡像可以找到的位置。
對于 Go/gRPC，我在這里放置了一個執行此操作的基礎映像。
- 3 回答
- 0 關注
- 160 瀏覽
添加回答
舉報
0/150
提交
取消