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

Question

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

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

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

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

Answer 1

你所说的现在通常被称为“monorepo”。虽然我个人喜欢将所有项目放在自己的独立存储库中（包括微服务和其他所有内容），但有许多支持者将公司的所有代码放在单个存储库中。有趣的是，谷歌和 Facebook 都使用 monorepos，尽管必须说他们已经构建了很多奇特的工具来使其为他们工作。需要注意的一件重要事情是，您的存储库与您的架构是分开的。它们之间不一定有任何相关性。您可以将微服务全部放在一个存储库中，也可以将一个整体划分为多个存储库；存储库只是存储和记录代码库的工具，仅此而已。在研究该主题时，以下是从网络上的许多文章中得出的一些优点和缺点：Monorepo的优势易于在项目之间共享模块（即使在微服务中，也经常存在交叉问题）一个地方可以查看并了解存在哪些代码 - 对于拥有大量代码的大公司尤其有用简化自动和手动代码审查流程简化文档，而不是从多个、断开连接的存储库中提取Monorepo的缺点大量代码库在本地签入/签出可能具有挑战性/缓慢如果没有非常清晰、严格的指导方针，很容易导致产品之间的紧密耦合需要（稍微）更复杂的 CI/CD 工具来进行部分发布根据存储库平台的不同，非常大的代码库可能会影响性能与编程中的许多其他事物（尤其是 SOA 中的许多其他事物）一样，适合您的解决方案取决于许多只有您可以确定的因素。主要的结论是，大大小小的公司在这两种选择以及许多介于两者之间的选择上都取得了成功，因此请谨慎选择，但不要太担心。

Answer 2

Go 项目所依赖的子包的版本控制可以通过git tagging来跟踪。因此，鼓励使用 Go-modules 将子包移动到他们自己的 git 存储库中。如果您的大部分解决方案将用 go 编写，我建议利用go module。

Answer 3

有一种使用单独的存储库和 Go 微服务的好方法：Go 插件。简而言之：构建一个实现共享功能的基础镜像。让该基础镜像在容器中的某个位置查找Go 插件在派生镜像中，将功能编译为 Go 插件，并将其放置在基础镜像可以找到的位置。对于 Go/gRPC，我在这里放置了一个执行此操作的基础映像。