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