时间戳

首页 > 解决方案 > 将 Go 微服务保存在 Github 上的不同存储库中

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

问题描述

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

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

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

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

标签： gogithubmicroservices

解决方案

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

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

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

Monorepo 优势

  • 易于在项目之间共享模块（即使在微服务中，也经常存在横切关注点）
  • 一个地方可以查看和了解存在哪些代码 - 在拥有大量代码的大公司中特别有用
  • 简化自动和手动代码审查流程
  • 简化文档，而不是从多个断开连接的存储库中提取

Monorepo 的缺点

  • 庞大的代码库可能具有挑战性/在本地签入/签出速度很慢
  • 如果没有非常明确、严格的指导方针，很容易导致产品之间的紧密耦合
  • 需要（稍微）更复杂的 CI/CD 工具来部分发布
  • 根据存储库平台，非常大的代码库可能会影响性能

这里有一个关于 monorepos 的优缺点的很好的讨论，这里有一个专门与切换到具有微服务架构的 monorepo 相关的讨论。 这是另外一个有很多支持和反对monorepo的链接。

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

推荐阅读