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

Question

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

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

Answer 1

两者都做完了，下面是一些权衡：

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

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

多个存储库：

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

毫无疑问，其他都是我在这两种情况下实际遇到的。如果您要并行发展许多服务，那么monorepo可能会更好。如果您可以彼此独立地构建服务，则多个存储库会更好。

Answer 2

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

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

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