微服务项目如何管理模块，如何用 git 管理版本
source link: https://www.v2ex.com/t/916288
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
小厂项目不成熟，想请教一下大家
项目是 springboot 微服务项目，不同业务功能在不同业务模块中，另外有一个公共模块，各个业务模块会依赖这个公共模块。
请问下面哪种方案好？或者有什么更好的方案？
方案一： 见一个父项目，在父项目中建立各个业务模块和公共模块，所有业务模块继承父项目并依赖公共模块。所有代码在一个 git 项目中管理
方案二： 各个业务模块各自建一个项目，公共模块也建一个项目，各个业务模块依赖公共模块，作为多个 git 项目管理
 |
RedBeanIce 14 小时 52 分钟前 via iPhone 我们是方案 2
|
 |
tianmalj0613 14 小时 49 分钟前 如果能用方案 1 的项目，会有成为分布式单体的倾向
|
 |
debuggerx 14 小时 41 分钟前 看模块间的关联性和耦合程度。
关联性大耦合度高的就放在一个 git 里，强行分开是自找麻烦。 有些“伪微服务”项目，想跑起来就得狗一样哼哧哼次 clone 一堆仓库，动不动出问题就是某个仓库更新了，关联模块的仓库没更新…… |
 |
XiLingHost 14 小时 34 分钟前 这种可以考虑方案二，然后依靠 gradle 和 maven 来管理依赖关系
|
 |
hhjswf 14 小时 24 分钟前 via Android 我们是方案 1
|
 |
Akitora 14 小时 14 分钟前 方案 1 路过
|
 |
dayeye2006199 14 小时 11 分钟前 如果不是项目大到不行（几个 G 的源代码），直接推荐 monorepo （也就是方案 1 ）
|
 |
thinkershare 14 小时 11 分钟前 最好去掉公共模块。不要使用公共模块，共享内核模式是个糟糕的实践。
|
2 |
thinkershare 14 小时 9 分钟前 如果需要使用共享模块，就将其当做一个第三方库引入，否则最终一定会演化为一堆耦合的分布式单体。
|
 |
chendy 13 小时 59 分钟前 方案三：不拆服务直接单体
除非有动态扩缩，不同模块不同团队维护，模块单独卖之类的需求，否则拆服务弊大于利 |
 |
perfectlife 13 小时 57 分钟前 推荐方案二，管理方便，并且 cicd 做起来也方便
|
 |
lzgshsj 13 小时 56 分钟前 直接 monorepo
|
 |
wolfie 13 小时 39 分钟前 几人团队可以 1 ，但是 1 很蠢。
|
 |
8355 13 小时 34 分钟前 能选择的话肯定是方案 2
你现状是方案 1 吧... |
 |
raycool 13 小时 9 分钟前 2 应该好点吧
|
 |
dengji85 13 小时 8 分钟前 应该方案二吧，方案一不同的团队开发还要拉取整个工程，怎么看都不合适
|
 |
youmilk 12 小时 58 分钟前 务必方案 2 ，方案 1 很麻烦。
|
 |
dcncy 12 小时 55 分钟前 via iPhone |
 |
nothingistrue 12 小时 54 分钟前 看你的项目周期，项目周期短（客户小而多，每个客户都要做一次定制），需要一客户一分支甚至一客户一仓库，这样的话宜用方案一，因为用方案二的话一个月就要鸡飞狗跳的做一次新项目上不同服务之间的分支对接。项目周期大（最短的项目也要 6 个月实际开发，至少一年的商务对接时间，可能好几年就只做一个客户），那么宜用方案二，这样更能发挥微服务的好处。
|
 |
li746224 12 小时 49 分钟前 我们是方案 1 ，但是 1 真的很蠢。
我们内部已经吐槽过很多次了 |
 |
ForkNMB 12 小时 18 分钟前 别埋坑啦，肯定方案二啊 公共模块有单独的 git 项目,maven 打成包引入到业务里面
|
 |
tramm 12 小时 17 分钟前 那个, Git 自带子模块的哇.
建一个总的仓库, 各个服务作为子模块版本各自管理 |
 |
xuanbg 11 小时 41 分钟前 第二种方案才是正确的。
|
 |
WindProtect 11 小时 33 分钟前 我们用的 1 ，改代码什么的是爽，但 ci/cd 确实麻烦。monorepo 如果不是大公司有精力填坑，不然建议还是别搞了。。。
|
 |
samin 11 小时 17 分钟前 方案一叫单仓多项目，腾讯现网很多项目都是这种方式，有啥毛病 ？说会成为分布式单体的，是对 maven 打包不大熟吧。运维角度来看，方案一二打包产物都一样的，只是管理方式不一样
总结：方案一可以减少版本的烦恼，方案二可以提升研发同学的开发体验 |
 |
yazinnnn 10 小时 58 分钟前 用方案 2 的情况下, 业务模块如何引入公共模块呢?
以 maven 依赖的形式还是 git submodule 的形式? |
 |
k9990009 10 小时 57 分钟前 via Android 微服务是和组织构架对应的，团队多，构架组也有，就方案二。人少就一个项目就别折腾了。公共依赖里面建议再拆分成很多小的 starter ，避免过度依赖
|
|
hhjswf 10 小时 28 分钟前 via Android 方案 2 怎么用 Maven 引入其他模块的依赖包，传到私库上拉吗
|
 |
zsdroid 10 小时 14 分钟前 不同模块都是你干，选 1
不同模块不同的人干，选 2 |
 |
lyonbrown4ddd 10 小时 11 分钟前 看开发团队了么 如果你每个模块 都有独立的团队在维护 那多 git 仓库互不干扰 如果就一个团队需要维护多个模块 monorepo 比较合适
|
 |
Pettyfer 10 小时 7 分钟前 方案 2 ，方案 1 会随时间逐渐变的庞大
|
 |
rapperx2 10 小时 2 分钟前 根据实际场景来吧，小团队，产出未必一下就是几个 G 的代码。
还有就是开发模块都是独立负责，不用一个开发维护多个模块，那就可以多仓库 |
 |
dobelee 9 小时 58 分钟前 1 和 2 都用过。推荐 2 。1 后期变屎山。
|
 |
OldCarMan 9 小时 53 分钟前 有没有一种可能，存在一种比较中庸的方式：
1.相关性比较强的模块可以聚合到一个父模块下（比如你搞一个电商项目，订单中心，仓储中心，用户中心等横向服务，每个中心下的各个子模块整合到一个父模块下，也就是你上面说的方案一） 2.其他公用性 /独立性比较强的，抽出来做单独的模块（比如授权认证服务，日志服务，网关服务，监控服务，统计服务等纵向服务抽离出单独的模块，也就是你说的方案二） 3.如果你说的公共模块只是指代码层面的依赖，那么抽一个公用模块出来写公用代码没问题，不过它只是一个公用代码模块，而不是一个公用服务，凡是服务都是需要部署的，模块不一定要部署；如果它是其他业务服务依赖的公用服务，个人觉得能解耦的尽量解耦到具体业务中，不能解耦的说明其有独立性的必要，单独做一层服务，也就是我上面第一点说的横向服务，问题应该也不是很大。 |
|
XiLingHost 9 小时 52 分钟前 @hhjswf 内网搭一个呗，无论是 gitlab 还是 nexus 还是 artifactory 都支持 maven 仓库，甚至 gitea 现在都支持了
|
 |
james2013 9 小时 51 分钟前 明显使用方案 1 更好,使用方案 2 很麻烦
又不是几十人,几百人开发同 1 个项目 目前项目中使用方案 1,有 1 个通用模块,其它的模块依赖通用模块 如果拆分为多个项目,开发起来很麻烦,尤其是微服务比较多时,那得打开好多个 ide,有的项目有十几个微服务,是不是要开十几个 idea? |
 |
LeegoYih 9 小时 49 分钟前 选择模式 2 还有一个原因是管理，给每位研发分配不同的权限，否则会像 bilibili 一样泄漏整个项目
|
 |
oneisall8955 8 小时 35 分钟前 via Android |
 |
cp19890714 7 小时 28 分钟前 两个方案都各有优缺点，很多大厂使用的是方案 1 ，我现在使用的是方案 2 。
方案 2 优点 无论团队大小, 既然是微服务, 那肯定会为每个服务指定负责人, 而不会交错负责. 1. 每个人只需要关注自己负责的服务的代码. 2. 小团队,可以避免团队内有人随意修改他人负责的代码. 大团队,只开负责的代码仓库的权限. 3. IDEA 中只打开自己负责的代码, 搜索代码什么的都很方便. 4. CI/CD 方便 5. 版本管理方便, 减少代码冲突. 方案 2 缺点 1. 需要搭建 maven 私仓, 对所有的公共技术模块进行严格的版本管理, 在 base-pom 中对版本进行统一管理. 2. 降低开发者维护公共技术模块的意愿. 因为修改公共模块,哪怕只修改一行代码,都需要升级版本, 然后对很多 git 仓库进行代码提交. 服务发布前,还要把相关模块的版本从 SNAPSHOT 改为 RELEASE, 有点麻烦. 方案 2 的优点就是方案 1 的缺点.整体来看,我觉得方案 2 的优点更多更好. |
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK