微服务项目如何管理模块，如何用 git 管理版本

[qviqvi]

小厂项目不成熟，想请教一下大家

项目是 springboot 微服务项目，不同业务功能在不同业务模块中，另外有一个公共模块，各个业务模块会依赖这个公共模块。

请问下面哪种方案好？或者有什么更好的方案？

方案一： 见一个父项目，在父项目中建立各个业务模块和公共模块，所有业务模块继承父项目并依赖公共模块。所有代码在一个 git 项目中管理

方案二： 各个业务模块各自建一个项目，公共模块也建一个项目，各个业务模块依赖公共模块，作为多个 git 项目管理

[li746224]

我们是方案 1 ，但是 1 真的很蠢。
我们内部已经吐槽过很多次了

[ForkNMB]

别埋坑啦，肯定方案二啊 公共模块有单独的 git 项目,maven 打成包引入到业务里面

[tramm]

那个, Git 自带子模块的哇.
建一个总的仓库, 各个服务作为子模块版本各自管理

[xuanbg]

第二种方案才是正确的。

[WindProtect]

我们用的 1 ，改代码什么的是爽，但 ci/cd 确实麻烦。monorepo 如果不是大公司有精力填坑，不然建议还是别搞了。。。

[samin]

方案一叫单仓多项目，腾讯现网很多项目都是这种方式，有啥毛病 ？说会成为分布式单体的，是对 maven 打包不大熟吧。运维角度来看，方案一二打包产物都一样的，只是管理方式不一样

总结：方案一可以减少版本的烦恼，方案二可以提升研发同学的开发体验

[yazinnnn]

用方案 2 的情况下, 业务模块如何引入公共模块呢?

以 maven 依赖的形式还是 git submodule 的形式?

[k9990009]

微服务是和组织构架对应的，团队多，构架组也有，就方案二。人少就一个项目就别折腾了。公共依赖里面建议再拆分成很多小的 starter ，避免过度依赖

[hhjswf]

方案 2 怎么用 Maven 引入其他模块的依赖包，传到私库上拉吗

[zsdroid]

不同模块都是你干，选 1
不同模块不同的人干，选 2

[lyonbrown4ddd]

看开发团队了么 如果你每个模块 都有独立的团队在维护 那多 git 仓库互不干扰 如果就一个团队需要维护多个模块 monorepo 比较合适

[Pettyfer]

方案 2 ，方案 1 会随时间逐渐变的庞大

[rapperx2]

根据实际场景来吧，小团队，产出未必一下就是几个 G 的代码。

还有就是开发模块都是独立负责，不用一个开发维护多个模块，那就可以多仓库

[dobelee]

1 和 2 都用过。推荐 2 。1 后期变屎山。

[OldCarMan]

有没有一种可能，存在一种比较中庸的方式：

1.相关性比较强的模块可以聚合到一个父模块下（比如你搞一个电商项目，订单中心，仓储中心，用户中心等横向服务，每个中心下的各个子模块整合到一个父模块下，也就是你上面说的方案一）

2.其他公用性 /独立性比较强的，抽出来做单独的模块（比如授权认证服务，日志服务，网关服务，监控服务，统计服务等纵向服务抽离出单独的模块，也就是你说的方案二）

3.如果你说的公共模块只是指代码层面的依赖，那么抽一个公用模块出来写公用代码没问题，不过它只是一个公用代码模块，而不是一个公用服务，凡是服务都是需要部署的，模块不一定要部署；如果它是其他业务服务依赖的公用服务，个人觉得能解耦的尽量解耦到具体业务中，不能解耦的说明其有独立性的必要，单独做一层服务，也就是我上面第一点说的横向服务，问题应该也不是很大。

[XiLingHost]

@hhjswf 内网搭一个呗，无论是 gitlab 还是 nexus 还是 artifactory 都支持 maven 仓库，甚至 gitea 现在都支持了

[james2013]

明显使用方案 1 更好,使用方案 2 很麻烦
又不是几十人,几百人开发同 1 个项目
目前项目中使用方案 1,有 1 个通用模块,其它的模块依赖通用模块
如果拆分为多个项目,开发起来很麻烦,尤其是微服务比较多时,那得打开好多个 ide,有的项目有十几个微服务,是不是要开十几个 idea?

[LeegoYih]

选择模式 2 还有一个原因是管理，给每位研发分配不同的权限，否则会像 bilibili 一样泄漏整个项目

[oneisall8955]

2

[cp19890714]

两个方案都各有优缺点，很多大厂使用的是方案 1 ，我现在使用的是方案 2 。

方案 2 优点
无论团队大小, 既然是微服务, 那肯定会为每个服务指定负责人, 而不会交错负责.
1. 每个人只需要关注自己负责的服务的代码.
2. 小团队,可以避免团队内有人随意修改他人负责的代码. 大团队,只开负责的代码仓库的权限.
3. IDEA 中只打开自己负责的代码, 搜索代码什么的都很方便.
4. CI/CD 方便
5. 版本管理方便, 减少代码冲突.

方案 2 缺点
1. 需要搭建 maven 私仓, 对所有的公共技术模块进行严格的版本管理, 在 base-pom 中对版本进行统一管理.
2. 降低开发者维护公共技术模块的意愿. 因为修改公共模块,哪怕只修改一行代码,都需要升级版本, 然后对很多 git 仓库进行代码提交. 服务发布前,还要把相关模块的版本从 SNAPSHOT 改为 RELEASE, 有点麻烦.

方案 2 的优点就是方案 1 的缺点.整体来看,我觉得方案 2 的优点更多更好.