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

Question

目前,我有一个项目的20个微服务.并且每个微服务都存储在单独的GIT reposotiry中.随后,服务数量将增加到200(或更多).

每项服务都有单元测试和集成测试.每个服务都在TeamCity(持续集成服务器)中构建.

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

Answer 1

除非这些微服务是紧密耦合的(意味着只下载其中一些是没有意义的,并且你只能使用所有这些),所以建议将它们分别保存在单独的Git仓库中.

但是您仍然可以将它们作为父模式中的子模块引用,以便在任何给定时间跟踪它们的状态.

Answer 2

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

Answer 3

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

每个微服务在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到接口;否则不需要的文件将在您的分支中)

优点 每个微服务都只有其代码和接口文件夹

缺点

我已经看到,下面的流程并不总是理想地发生,就像

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

它更像是

sprint_interfaces -->  Merge Request --> master

这意味着有人必须从master 手动获取Interfaces 文件夹并合并到Interfaces 分支.但这只是一种纪律,并没有破坏任何东西