我正在做一个微服务项目。为此,我希望每个服务都有一个 Go 包,全部包含在项目的父包中。它看起来像这样:
.
└── github.com
└── username
└── project
├── service1
└── service2
我认为这种结构允许遵守 Go 对包名称和路径的约定。这样做的结果是我所有的微服务都在 Github 上的同一个存储库中结束,因为存储库将位于 URL 中的深度 3。我认为如果代码库变大,这可能会成为 future 的一个问题。它还可能增加 CI/CD 管道的复杂性,例如,对一个服务的更改会触发所有其他服务的构建,并且要克隆的代码会不必要地大。
有没有办法避免 Go 约定和 Github 工作方式之间的冲突?或者这是在 CI/CD 工作期间必须解决的问题?
最佳答案
这些天你所说的通常被称为“monorepo”。虽然我个人喜欢将所有项目都放在自己的独立存储库中(包括微服务和其他一切),但也有许多支持者将公司的所有代码放在一个存储库中。有趣的是,Google和 Facebook 使用 monorepos,尽管必须说他们已经构建了许多花哨的工具来为他们工作。
需要注意的重要一点是,您的存储库与您的架构是分开的。它们之间不一定有任何相关性。您可以在一个存储库中拥有所有微服务,也可以将一个单体应用划分为多个存储库;存储库只是存储和记录代码库的工具,仅此而已。
在研究该主题时,以下是从网络上的许多文章中得出的一些优点和缺点:
Monorepo 优势
Monorepo 缺点
和here's a good discussion关于 monorepos 的优缺点,以及 here's one特别是与切换到具有微服务架构的 monorepo 有关。 Here's one more有很多支持和反对monorepo的链接。
与编程中的许多其他事情一样,尤其是在 SOA 中,适合您的解决方案取决于许多只有您可以确定的因素。主要的收获是大大小小的公司在这两种选择上都取得了成功,而且还有很多介于两者之间的选择,所以请谨慎选择,但不要太担心。
关于go - 将 Go 微服务保存在 Github 上的不同存储库中,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58267056/