Question

目前，我为一个项目提供了 20个微服务。并且每个微服务都存储在单独的GIT reposotiry中。随后，服务数量将增加至200（或更多）。

每项服务都有单元测试和集成测试。每个服务都在TeamCity（持续集成服务器）中构建。

问题：如何为一个项目存储200个微服务的源代码？在一个存储库中还是在单独的存储库中？

Answer 1

除非这些微服务紧密耦合（意味着仅下载其中一些微服务没有意义，并且你只能使用所有），所以将它们分别保存在一个单独的建议使用Git repo。

但您仍然可以在父回购中将其引用为 submodule ，以便在任何给定时间跟踪其状态。

Answer 2

git子模块和子树也有自己的问题。 Facebook和谷歌？为他们所有的微服务都有一个存储库。这个问题没有明确的答案，但重构，依赖管理和项目设置等功能可以从单一存储库中获益。同样，服务的耦合以及不同团队如何与回购交互是选择一个或另一个的关键。

Answer 3

我们没有使用子模块;我们所做的是分支战略

每个微服务在base_folder文件夹下都有自己的文件夹。

有一个发布分支 - ＆gt;目前有一位大师（这里有一切）有一个接口分支 - ＆gt;接口（这只有接口，例如所有服务的protobuffer / grpc文件）。此分支始终合并为主

每项服务都有一个分支 - ＆gt; sprint_service_name，其中推送代码（用于代码审查）和创建到主分支的合并请求

代码流

对于新组件

git checkout interfaces
git checkout -b sprint_service_name 
(create branch from interface branch)

对于现有组件

git checkout sprint_service_name
git fetch origin interfaces
git merge origin/interfaces (don't use git merge origin interfaces !!)

（或上面两步git pull origin接口）

这是一个开发者流程

Push to sprint_service_name branch and create merge request to master branch
git push origin  sprint_service_name

分行流程

sprint_service_namexxx --> Merge Request --> master
sprint_interfaces -->  Merge Request --> Interfaces -->master
interfaces --> sprint_service_namexxx (by all, every day)

所有常见部分都在接口分支

中

（您可以拥有任意数量的私有分支;但请注意不要将master合并到sprint_service_name或master到接口;否则不需要的文件将在您的分支中）

<强>赞成每个微服务都只有其代码和接口文件夹

<强>缺点

我已经看到下面的流程并不总是理想地发生，比如

sprint_interfaces -->  Merge Request --> Interfaces -->master

更像是

sprint_interfaces -->  Merge Request --> master

这意味着有人必须手动从主设备接收文件夹并合并到接口分支。但这只是一种纪律，并没有破坏任何东西

Answer 4

我的选择是存储在不同的存储库中，并且我已经做了很多年，并认为它使管理变得容易，然后使其变得复杂。如果您参考12因子应用程序，则应该了解拥有单独存储库的好处。每个微服务将具有不同的测试套件，不同的发行版和生命周期。最终将提高可交付成果的速度。

适用于所有人的单个存储库可能会起作用，但最好将它们分成不同的存储库，并为每项服务提供一套完整的管道工具。正如微服务原则所言，服务可以由不同的团队管理，可以以不同的技术构建，并且应该有自己的发行版，只有通过不同的存储库才能实现。

如果上述因素还不够，那么您可以考虑以下情形：仅需要更改一项服务并通过管道进行单独测试，然后使用单独的存储库将使其更易于发布。

Answer 5

在github上创建存储库
本地计算机上的git clone存储库
在存储库中创建项目并提交->在存储库中推送项目

Answer 6

整个项目，无论大小，都应该只有一个仓库。

您可以参考12因素应用程序来构建可处理here中大部分内容的项目。

12因素应用程序的概念适用于具有许多微服务的大型项目。

Answer 7

我曾在一家曾经使用130多种服务的公司工作。一些服务正在连接到外部API，即我们的生态系统之外。但是我们只是使用了将每个服务保存在自己的GIT存储库中。我们有一个共享库，用于在一个BOM表下进行加密，记录等。创建单个存储库将阻止您意外地创建互连的微服务，这是整个想法的目标。将来，如果需要，您可以进一步减少个别服务。有了130多个微服务，我们再也不会出现相互依赖的代码问题，并且部署顺畅，无需担心其他服务。

Answer 8

拥有单独的存储库将对启动有所帮助，但是当项目增长时，将变得非常难以管理。 12-factor app guideline还建议维护一个整体存储库。那些不应该是子模块，除非您在单独的存储库中管理配置之类的方案。每个微服务都有一个带有子项目的整体代码库，可让您构建 CI / CD管道。那是另一个很大的优势。例如：假设您需要使用两个或多个微服务来完成特定功能或问题。您可以通过一次提交来跟踪所有服务。

微服务：如何存储许多微服务的源代码？

8 个答案: