go - 将 Go 微服务保存在 Github 上的不同存储库中

Question

我正在做一个微服务项目。为此，我希望每个服务都有一个 Go 包，全部包含在项目的父包中。它看起来像这样:

.
└── github.com
    └── username
        └── project
            ├── service1
            └── service2

我认为这种结构允许遵守 Go 对包名称和路径的约定。这样做的结果是我所有的微服务都在 Github 上的同一个存储库中结束，因为存储库将位于 URL 中的深度 3。我认为如果代码库变大，这可能会成为 future 的一个问题。它还可能增加 CI/CD 管道的复杂性，例如，对一个服务的更改会触发所有其他服务的构建，并且要克隆的代码会不必要地大。

有没有办法避免 Go 约定和 Github 工作方式之间的冲突？或者这是在 CI/CD 工作期间必须解决的问题？

Answer 1

这些天你所说的通常被称为“monorepo”。虽然我个人喜欢将所有项目都放在自己的独立存储库中(包括微服务和其他一切)，但也有许多支持者将公司的所有代码放在一个存储库中。有趣的是，Google和 Facebook 使用 monorepos，尽管必须说他们已经构建了许多花哨的工具来为他们工作。

需要注意的重要一点是，您的存储库与您的架构是分开的。它们之间不一定有任何相关性。您可以在一个存储库中拥有所有微服务，也可以将一个单体应用划分为多个存储库；存储库只是存储和记录代码库的工具，仅此而已。

在研究该主题时，以下是从网络上的许多文章中得出的一些优点和缺点:

Monorepo 优势

易于在项目之间共享模块(即使在微服务中，也经常存在横切关注点)

一个地方可以查看和了解存在哪些代码 - 在拥有大量代码的大公司中尤其有用

简化自动和手动代码审查流程

简化文档，而不是从多个断开连接的存储库中提取

Monorepo 缺点

海量代码库可能具有挑战性/ checkin / checkout 到本地的速度很慢

如果没有非常明确、严格的指导方针，很容易造成产品之间的紧密耦合

需要(稍微)更复杂的 CI/CD 工具才能部分发布

取决于存储库平台，非常大的代码库会影响性能

和 here's a good discussion关于 monorepos 的优缺点，以及 here's one特别是与切换到具有微服务架构的 monorepo 有关。 Here's one more有很多支持和反对monorepo的链接。

与编程中的许多其他事情一样，尤其是在 SOA 中，适合您的解决方案取决于许多只有您可以确定的因素。主要的收获是大大小小的公司在这两种选择上都取得了成功，而且还有很多介于两者之间的选择，所以请谨慎选择，但不要太担心。