目前，我为一个项目提供了20 个微服务。每个微服务都存储在单独的 GIT 存储库中。随后，服务数量将增加到200 个（或更多）。
每个服务都有单元测试和集成测试。每个服务都内置在 TeamCity（持续集成服务器）中。
问题：如何为一个项目存储200个微服务的源代码？在一个存储库中还是在单独的存储库中？
问问题
11621 次
7 回答
21
除非这些微服务是紧密耦合的（这意味着只下载其中一些是没有意义的，并且您只能使用它们全部），否则建议将它们分别保存在一个单独的 Git 存储库中。
但是您仍然可以在父 repo 中将它们作为子模块引用，以便在任何给定时间跟踪它们的状态。
于 2015-05-17T11:50:43.763 回答
15
git 子模块和子树也有自己的问题。脸书和谷歌？他们的所有微服务都有一个存储库。这个问题没有明确的答案，但是诸如重构、依赖管理和项目设置之类的事情可以从单一存储库中受益。同样，服务的耦合以及不同团队如何与 repo 交互是选择一个或另一个的关键。
于 2017-02-17T09:53:40.387 回答
9
我们没有使用子模块；我们所做的是分支策略
每个微服务在 base_folder 文件夹下都有自己的文件夹。
有一个发布分支 -> 目前一个主控（这拥有一切）有一个接口分支 -> 接口（这只有接口，例如所有服务的 protobuffer/grpc 文件）。这个分支总是合并到 master
每个服务都有一个分支 --> 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 合并到 interfaces ；否则不需要的文件将在您的分支中）
优点 每个微服务都只有它的代码和接口文件夹
缺点
我已经看到以下流程并不总是理想地发生，例如
sprint_interfaces --> Merge Request --> Interfaces -->master
它更像
sprint_interfaces --> Merge Request --> master
这意味着有人必须手动从 master 获取 Interfaces文件夹并合并到 Interfaces分支。但这只是纪律的事情，并没有破坏任何东西
于 2017-05-31T11:10:54.583 回答
1
我的选择是存储在不同的存储库中，我已经这样做了多年，并认为它更容易管理，然后变得复杂。如果您参考 12 因素应用程序，您应该知道拥有单独回购的好处。每个微服务都有不同的测试套件、不同的版本和生命周期。它将最终提高可交付成果的速度。
一个单一的存储库可能会起作用，但最好将它们分离到不同的存储库中，并为每个服务拥有一套完整的管道工具。正如微服务原则所说，服务可以由不同的团队管理，可以使用不同的技术构建，并且应该有自己的版本，这只能通过不同的 repos 来实现。
如果上述因素还不够，那么您可以考虑这样一种情况，即只需要通过管道单独更改和测试一个服务，然后单独的 repos 将使其更容易发布。
于 2020-07-18T18:16:59.063 回答
0
对于整个项目，无论大小，您都应该只有一个 repo。
你可以参考 12 Factor Application 来构建这样的项目，它可以从这里处理大部分事情。
12 Factor 应用程序的概念适用于具有许多微服务的大型项目。
于 2019-07-04T04:54:49.423 回答
0
我曾在一家公司工作过，我们曾经使用过 130 多种服务。一些服务连接到外部 API，即在我们的生态系统之外。但我们只是使用将每个服务保存到它们自己的 GIT 存储库中。我们在一个 BOM 下有用于加密、日志记录等的公共库。创建单独的存储库将阻止您意外地创建相互关联的微服务，这就是整个想法的目标。将来，如果需要，您可以进一步减少个人服务。使用 130 多个微服务，我们从未遇到过相互依赖的代码问题，而且部署也很顺利，无需担心其他服务。
于 2020-04-13T20:21:29.707 回答
0
拥有单独的存储库将在启动时有所帮助，但随着项目的发展，它变得非常难以管理。12 要素应用指南还建议维护一个单一的单体存储库。这些不应该是子模块，除非您在单独的存储库中管理配置等场景。拥有一个包含每个微服务子项目的单体代码库，可以让您构建CI/CD 管道。这是另一个很大的优势。例如：假设您需要处理两个或多个微服务来完成特定功能或问题。您可以针对该问题通过一次提交来跟踪所有服务。
于 2020-04-23T05:29:30.307 回答