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

我们是方案 2

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

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

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

我们是方案 1

方案 1 路过

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

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

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

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

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

直接 monorepo

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

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

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

2 应该好点吧

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

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

方案二

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

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

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

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

第二种方案才是正确的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2

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

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

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

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

方案一 还是方案二 主要还是看你们有没有足够的人来管理 ：

方案一等于是所有的都放到一个池子里，所有的子模块与父模块保持版本一致，如果每次发布的版本都是整体发布而不是单独发布，这个方案方便管理，即使人很少也很好维护

方案二 如果子模块可以被其他多个项目复用，例如一个第三方接口的客户端实现等，同时项目足够复杂，有足够的程序员， 每个模块由不同的组来维护管理， 有一个很清晰的 release note 等， 发布的时候每个模块可以有不同版本

当然是方案二

很多大厂都是方案 1 ，包括谷歌，因为他们强制上线会把所有得模块都 build 一遍，保证整体可编译。至于 monorepo 多大，看团队了。又不是所有团队得代码都放在一起。