微服务：众多微服务的源代码如何存储？答案

【问题标题】：Microservices: How to store source code of many microservices?微服务：众多微服务的源代码如何存储？
【发布时间】：2015-07-28 23:14:27
【问题描述】：

目前，我在一个项目中有 20 个微服务。每个微服务都存储在单独的 GIT 存储库中。随后，服务数量将增加到200（或更多）。

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

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

【问题讨论】：

标签： git microservices

【解决方案1】：

除非这些微服务是紧密耦合的（这意味着只下载其中一些是没有意义的，并且您只能使用它们中的全部），将它们分别放在一个单独的推荐使用 Git 仓库。

但您仍然可以在父存储库中将它们引用为 submodule，以便在任何给定时间跟踪它们的状态。

【讨论】：

除了@VonC 参数，我想说：每个微服务都应该能够独立发展，并且从 SCM 视图来看，您交付到生产的每个版本都应该在您的存储库中标记。因此考虑以下情况：微服务-A 是 10 版，而微服务-B 是 20 版。如果两个微服务都存储在同一个 git 存储库中，您将如何标记您的存储库？不可能有优雅的答案。将 A 和 B 保存在不同的存储库中。
...并且，为了扩展第一条语句的推理：如果服务提供相同的 API，并且相互依赖，那么将它们放在一个 repo 中可能会有所帮助.我们将这种方法用于我们的 170 项服务，并且效果非常好。但是我们将它们作为一个单元推向生产，并没有真正跟踪各个服务版本......您的需求可能会有所不同。

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

有一个发布分支 --> 目前只有一个 master（这个拥有一切）有一个接口分支 --> 接口（这只有接口，例如所有服务的 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文件夹并合并到 Interfacesbranch。但这只是纪律的事情，并没有破坏任何东西

【讨论】：

您能否提供一个参考链接（教程），逐步解释完整的场景？
是的 - 请注意，由于团队和开发人员的数量越来越多，我们还是使用了接口分支，因为除了 master 之外的任何事情最终都会成为开销；所以只需master，它在自己的文件夹中保存包含接口和所有微服务的接口目录

【解决方案4】：

我的选择是存储在不同的存储库中，我已经这样做了多年，并认为它更容易管理，然后变得复杂。如果您参考 12 因素应用程序，您应该知道拥有单独回购的好处。每个微服务都有不同的测试套件、不同的版本和生命周期。最终会提高可交付成果的速度。

一个单一的存储库可能会起作用，但最好将它们分离到不同的存储库中，并为每个服务提供一套完整的管道工具。正如微服务原则所说，服务可以由不同的团队管理，可以使用不同的技术构建，并且应该有自己的版本，这只能通过不同的 repos 来实现。

如果上述因素还不够，那么您可以考虑这样一种情况，即只需要通过管道单独更改和测试一项服务，然后单独的 repos 将使其更容易发布。

【讨论】：

【解决方案5】：

对于整个项目，无论大小，您都应该只有一个 repo。

您可以参考 12 Factor Application 来构建此类项目，该项目处理来自here 的大部分内容。

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

【讨论】：

【解决方案6】：

我曾在一家公司工作过，我们曾经使用过 130 多种服务。一些服务正在连接到外部 API，即在我们的生态系统之外。但我们只是使用将每个服务保存到它们自己的 GIT 存储库中。我们在一个 BOM 下有用于加密、日志记录等的公共库。创建单独的存储库将阻止您意外地创建相互关联的微服务，这就是整个想法的目标。将来，如果需要，您可以进一步减少个人服务。使用 130 多个微服务，我们从未遇到过相互依赖代码的问题，而且部署也很顺利，无需担心其他服务。

【讨论】：

【解决方案7】：

拥有单独的存储库在启动时会有所帮助，但随着项目的发展，管理起来会变得非常困难。 12-factor app guideline 还建议维护一个单一的整体存储库。这些不应该是子模块，除非您在单独的存储库中管理配置等场景。拥有一个包含每个微服务子项目的整体代码库，您可以构建自己的 CI/CD 管道。这是另一个很大的优势。例如：假设您需要处理两个或多个微服务来完成特定功能或问题。您可以针对该问题通过一次提交来跟踪所有服务。

【讨论】：