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

Question

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

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

Answer 1

两者都做了，这里有一些权衡:

对于单一代码库(所有代码和服务都在同一个代码库中):

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

多个存储库:

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

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