将 Go 微服务分散存储在Github上不同的代码库

在微服务项目中，将每个服务封装在一个独立的 Go 包中并将其存储在父包下，可以遵守 Go 的约定。然而，这种结构会导致所有微服务存储在同一个 GitHub 存储库中，这可能会带来代码库过大、CI/CD 管道复杂等问题。因此，需要探索避免 Go 约定和 GitHub 工作方式冲突的方法。

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

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

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

有没有办法避免 go 约定和 github 工作方式之间的冲突？或者这是 ci/cd 工作中必须解决的问题？

解决方案

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

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

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

Monorepo 优势

• 易于在项目之间共享模块（即使在微服务中，也经常存在交叉问题）
• 在一个地方可以查看并了解存在哪些代码 - 对于拥有大量代码的大公司尤其有用
• 简化自动和手动代码审查流程
• 简化文档，而不是从多个互不关联的存储库中提取

Monorepo 缺点

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

here's a good discussion 介绍了 monorepo 的优缺点，here's one 特别涉及到切换到具有微服务架构的 monorepo。 Here's one more 有很多支持和反对 monorepo 的链接。

与编程中的许多其他事物（尤其是 SOA 中的许多其他事物）一样，适合您的解决方案取决于许多只有您才能确定的因素。主要的结论是，大大小小的公司在这两种选择以及介于两者之间的许多选择上都取得了成功，因此请谨慎选择，但不要太担心。

对 Go 项目依赖的子包进行版本控制可以通过 git tagging 进行跟踪。因此，鼓励使用 Go-modules 将子包移动到自己的 git 存储库中。

如果您的大部分解决方案将用 Go 编写，我建议利用 go modules。

这篇博文解释了如何管理 Go 模块的 go.mod 包依赖项及其关联的版本 git 标签：

• https://blog.golang.org/migrating-to-go-modules

本篇关于《将 Go 微服务分散存储在Github上不同的代码库》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！