目前，我有一个项目的20个微服务，每个微服务都储存在单独的GIT存储库中。 随后，服务数量将增加到200（或更多）。
每个服务都有单元测试和集成测试。 每个服务在TeamCity（持续集成服务器）中构建。
问题：如何为一个项目的200个微服务存储源代码？是在一个仓库中还是在单独的仓库中？
7个回答
22
如果这些微服务没有紧密耦合（即仅下载其中一些不合理，您只能使用全部），则建议将它们放在单独的Git repo中。
但是，您仍然可以将它们作为子模块引用到父repo中，以便随时跟踪它们的状态。
- VonC
2
7除了@VonC的论点外，我想说：每个微服务都应该能够独立演化，从源代码管理的角度来看，您在将每个版本交付到生产环境时应该在您的存储库中标记它们。考虑以下情况：微服务A的版本为10，而微服务B的版本为20。如果这两个微服务存储在同一个Git存储库中，您该如何标记您的代码库呢？没有优雅的答案。最好将A和B存储在不同的存储库中。 - NicoPaez
...并且，为了扩展第一种情况的推理：如果服务提供相同的API，并且彼此依赖，则将它们放在单个存储库中可能会有所帮助。我们在我们的170个服务中使用这种方法，效果非常好。但是我们将它们作为一个单元推送到生产环境中，并没有真正跟踪各个服务版本...您的需求可能不同。 - Sternerson
15
Git子模块和子树也有自己的问题。Facebook和Google对于所有微服务都有一个单一的仓库。这个问题没有明确的答案，但是诸如重构、依赖管理和项目设置等事情从单体库中受益。再次强调，服务之间的耦合以及不同团队与仓库的互动是选择其中一个的关键。
- Oscar Perez
9
我们没有使用子模块，我们所做的是分支策略。
每个微服务都有自己的文件夹，位于base_folder文件夹下。
有一个发布分支-->当前只有一个主分支(包含所有内容)。还有一个接口分支-->interfaces(这里只包含所有服务的接口，例如protobuffer / grpc文件)。该分支始终合并到主分支上。
每个服务都有一个分支-->sprint_service_name，代码会被推送到该分支(进行代码审查)，并创建一个合并请求到主分支。 代码流程 对于新组件：
所有通用部分将会放在interfaces分支中。 （你可以有任意数量的私有分支；但是要小心，不要将master合并到sprint_service_name或interfaces中；否则，不需要的文件将出现在你的分支中） 优点 每个微服务将只有其代码和interfaces文件夹。 缺点 我看到以下流程并不总是理想的，例如：
这意味着有人必须手动将主分支中的"Interfaces"文件夹合并到"Interfaces"分支中。但这只是一种纪律性的要求，不会导致任何问题。
每个微服务都有自己的文件夹，位于base_folder文件夹下。
有一个发布分支-->当前只有一个主分支(包含所有内容)。还有一个接口分支-->interfaces(这里只包含所有服务的接口，例如protobuffer / grpc文件)。该分支始终合并到主分支上。
每个服务都有一个分支-->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 interfaces 命令）
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)
所有通用部分将会放在interfaces分支中。 （你可以有任意数量的私有分支；但是要小心，不要将master合并到sprint_service_name或interfaces中；否则，不需要的文件将出现在你的分支中） 优点 每个微服务将只有其代码和interfaces文件夹。 缺点 我看到以下流程并不总是理想的，例如：
sprint_interfaces --> Merge Request --> Interfaces -->master
它更像是
sprint_interfaces --> Merge Request --> master
这意味着有人必须手动将主分支中的"Interfaces"文件夹合并到"Interfaces"分支中。但这只是一种纪律性的要求，不会导致任何问题。
- Alex Punnen
2
请问您能否提供一个详细的教程链接，逐步解释完整的情景？ - Ghasem Sadeghi
是的 - 请注意，由于团队和开发人员的数量增加到相当大，我们已经放弃了接口分支，因为除了主分支之外的任何东西都会最终成为负担；因此只有主分支，其中包含接口目录以及所有微服务在自己的文件夹中。 - Alex Punnen
1
我的选择是将其存储在不同的代码库中，我已经这样做多年了，并认为这样更容易管理，而不是让它变得复杂。如果你参考12因素应用程序，你应该知道拥有单独的代码库的好处。每个微服务都有不同的测试套件、不同的发布和生命周期。这将增加可交付成果的速度。
一个单一的代码库可能会起作用，但最好将它们分开放置到不同的代码库中，并为每个服务提供完整的管道工具集。正如微服务原则所说，服务可以由不同的团队管理，可以使用不同的技术进行构建，并且应该有自己的发布，这只能通过不同的代码库实现。
如果以上提到的因素还不足够，那么你可以考虑一个场景，只有一个服务需要通过管道进行单独的更改和测试，然后单独的代码库将使发布更容易。
一个单一的代码库可能会起作用，但最好将它们分开放置到不同的代码库中，并为每个服务提供完整的管道工具集。正如微服务原则所说，服务可以由不同的团队管理，可以使用不同的技术进行构建，并且应该有自己的发布，这只能通过不同的代码库实现。
如果以上提到的因素还不足够，那么你可以考虑一个场景，只有一个服务需要通过管道进行单独的更改和测试，然后单独的代码库将使发布更容易。
- AjayLohani
0
- freshPrince
0
我曾在一家公司工作，我们使用了130多个服务。有些服务连接到外部API，即超出我们的生态系统。但我们只是将每个服务保留在自己的GIT存储库中。我们有一个公共库，用于加密、日志记录等，都在一个BOM下。 创建单独的存储库将阻止您意外地制作相互链接的微服务，这是整个想法的目标。将来，如果需要，您可以进一步减少单个服务。 有了130多个微服务，我们从未遇到过相互依赖的代码问题，而且部署也很顺利，不必担心其他服务。
- nimesh makwana
0
拥有单独的代码库在刚开始时会有所帮助，但当项目增长时，管理起来就变得非常困难。12-factor app guideline 还建议维护一个单一的单体式代码库。这些不应该是子模块，除非像在单独的代码库中管理配置等情况。将微服务分别作为子项目放在单体式代码库中，可以让您构建CI/CD pipeline。这是另一个重要的优势。例如：假设您需要处理两个或更多微服务才能完成特定的功能或问题。您可以使用一个提交跟踪所有服务以解决该问题。
- indika
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接