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

[qviqvi]

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

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

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

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

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

[RedBeanIce]

我们是方案 2

[tianmalj0613]

如果能用方案 1 的项目，会有成为分布式单体的倾向

[debuggerx]

看模块间的关联性和耦合程度。
关联性大耦合度高的就放在一个 git 里，强行分开是自找麻烦。
有些“伪微服务”项目，想跑起来就得狗一样哼哧哼次 clone 一堆仓库，动不动出问题就是某个仓库更新了，关联模块的仓库没更新……

[XiLingHost]

这种可以考虑方案二，然后依靠 gradle 和 maven 来管理依赖关系

[hhjswf]

我们是方案 1

[Akitora]

方案 1 路过

[dayeye2006199]

如果不是项目大到不行（几个 G 的源代码），直接推荐 monorepo （也就是方案 1 ）

[thinkershare]

最好去掉公共模块。不要使用公共模块，共享内核模式是个糟糕的实践。

[thinkershare]

如果需要使用共享模块，就将其当做一个第三方库引入，否则最终一定会演化为一堆耦合的分布式单体。

[chendy]

方案三：不拆服务直接单体
除非有动态扩缩，不同模块不同团队维护，模块单独卖之类的需求，否则拆服务弊大于利

[perfectlife]

推荐方案二，管理方便，并且 cicd 做起来也方便

[lzgshsj]

直接 monorepo

[wolfie]

几人团队可以 1 ，但是 1 很蠢。

[8355]

能选择的话肯定是方案 2
你现状是方案 1 吧...

[raptor]

@chendy 哈哈哈，人艰不拆。但实际上人家会觉得做单体不够高大上。

[raycool]

2 应该好点吧

[dengji85]

应该方案二吧，方案一不同的团队开发还要拉取整个工程，怎么看都不合适

[youmilk]

务必方案 2 ，方案 1 很麻烦。

[dcncy]

方案二

[nothingistrue]

看你的项目周期，项目周期短（客户小而多，每个客户都要做一次定制），需要一客户一分支甚至一客户一仓库，这样的话宜用方案一，因为用方案二的话一个月就要鸡飞狗跳的做一次新项目上不同服务之间的分支对接。项目周期大（最短的项目也要 6 个月实际开发，至少一年的商务对接时间，可能好几年就只做一个客户），那么宜用方案二，这样更能发挥微服务的好处。