用于微服务架构的 git 存储库结构的标准和更好的方法是什么？

Question

用于基于微服务架构的应用程序的存储库结构的更好方法？

例如，我通过 Microsoft 参考架构，即 github 存储库中的 eShopContainers [ https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src] 进行引用。但这带来了一些更复杂的动态工作环境，其中团队在各种 UI、微服务上工作，因此在一个存储库下的所有内容都使得合并/冲突等过程更加耗时。 一些团队成员希望拥有每个微服务在开发时在单独的存储库中进行更好的管理，然后在生产后导出到组存储库，即 BAU。感谢讨论利弊，以便为​​我们的环境做出更好的决定。

Answer 1

两者都完成后，这里有一些权衡：

对于 monorepo（同一个 repo 中的所有代码和服务）：

• 保持相关更改同步要容易得多（例如，生产者和消费者都更改；对两者的更改可以保存为单个提交）。
• 设置一致的构建环境更容易。正确设置后，所有服务都可以使用完全相同的工具链和可能相同的 Makefile 构建。
• 如果您选择使用单个 GOPATH，则所有服务都需要保持同步。如果一项服务需要切换到具有重大更改的库的较新版本，这可能会导致很多痛苦；使用该库的每个服务都必须立即升级。多个 GOPATHS 使过程维护起来更加复杂。
• 如果使用 CI 和测试进行适当管理，则可以始终将 HEAD 保持在可部署状态，从而降低最终获得一组因不匹配而无法互操作的服务的机会。

多个存储库：

• 使服务达到稳定水平并且不理会它要容易得多。因为它位于自己的存储库中，所以即使另一个服务需要更新版本的库，或者您决定更改库（例如从 Gin 到 Echo），也不需要进行升级。
• 容易忽视稳定服务的升级（例如，从 Gin 到 Echo 的更改），可能需要在时间压力下对重大更改进行重大更新；肯定会增加维护负载（我们是对 Echo 进行长期推迟的升级，还是将其留在 Gin 中？如果我们必须对 API 进行重大更改，那么我们需要使用多少种不同的框架？那？）
• 存储库的激增使得在需要时更难找到某些东西（我们在哪个服务中定义了它？我需要在这里重用它）
• 多个存储库中重复或（更糟糕的）接近重复的代码激增。很容易养成将服务作为基础复制然后在旧代码之上进行更改的习惯，从而导致整个代码库中出现一系列分形差异，尤其是因为“工作”代码往往不会更新为匹配更改。

毫无疑问，还有其他一些，但这些是我在这两种情况下实际经历过的一些。如果您要并行发展许多服务，monorepo 可能会更好；如果您可以构建几乎彼此独立的服务，则多个存储库会更好。

Answer 2

使用微服务架构的主要好处之一是能够引入新技术而无需执行完全重写。人们很容易只考虑编程语言和框架 - 但事实是版本控制软件是完全相同的。我见过一些团队从 SVN 迁移到 Git 或 TFS。相信 Git 会永远陪伴我们的想法是天真的。我相信这是使用多个存储库的有力论据。

单一存储库——只要它有优势——总是会诱使开发人员进行某种跨项目依赖。也许它将是用于编译所有微服务的特定构建工具中的一个构建文件。它可能是一个公共库目录，其中包含特定版本的外部 dll 或 jar 或其他任何内容。总是会有创造这样的东西的倾向。这最终将使这些微服务以某种方式绑定和依赖。

我相信这是将使用微服务架构创建的项目存储在多个独立存储库中的好方法。