关于微服务多模块问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1300 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近发现一个问题，公司的项目做了服务拆分，但是每个服务的目录结构是多模块的，类似如下：

server1:
  server1-api
    src
      main ...
    pom.xml
  server1-dao
    src
      main ...
    pom.xml
  server1-provider
  ...
  pom.xml
  ...

server2:
 ...

个人理解是，既然已经拆分了，多模块显然增加了复杂度，个人更偏向于一个 jar 包完成一个功能的思想。

想看看大家怎么看这种项目结构

22 条回复 • 2021-06-02 20:30:26 +08:00

zoharSoul

2021-06-01 15:20:33 +08:00

不赞同, 毫无意义
除了如果有提供出去的 rpc interface 可以单独分个 module, 别的觉得没必要.

guisheng

2021-06-01 16:03:17 +08:00

对外的 api 如 fegin，rpc 等公共类需要建立一个单独的 module 其它的完全是自己坑自己。

huifer

2021-06-01 17:20:26 +08:00

https://my.oschina.net/huifer/blog/4970160 我的想法

2021-06-01 17:23:44 +08:00

好熟悉的目录结构，请问是 JBoot 项目吗？

zpfhbyx

2021-06-01 17:45:35 +08:00

😨 我让这玩意荼毒了一段时间了。。

quiet1991

2021-06-01 19:23:47 +08:00

除了对外提供接口层需要独立的模块，其他的数据访问层基本到项目黄了估计也不会换，没必要

aragakiyuii

2021-06-01 19:29:29 +08:00

这种除非一开始设计的非常好，否则就是给自己挖坑

amrom

2021-06-01 19:39:13 +08:00

@GM 不是，就是一般的 Spring boot 项目，还是经过拆分的架构

amrom

2021-06-01 19:43:47 +08:00

@huifer 看了你的文章，我感觉如果按照你的想法，会把简单的问题复杂化

fiypig

2021-06-01 20:11:08 +08:00 via iPhone

原公司的一个 java 大佬就要这么做，我直接逃了

oneisall8955

2021-06-01 21:15:02 +08:00 via Android

没必要，dao 也拆成模块，天才

sunmoon1983

2021-06-01 21:23:41 +08:00

java 不懂，反正我在 golang 里面是把所有公用的模块都分到一个私有的仓库中，然后所有需要用到的地方直接依赖这个私有仓库就得了

javacodecreeks

2021-06-01 21:29:14 +08:00 via iPhone

我们大佬出于中台设计理念和版本统一管理，几乎在后端每一个微服务里面都采用了模块化的管理方式，更要命的是 maven 的传递依赖链长达十几级以上的都有，遇到冲突时简直是生不如死

2021-06-01 21:38:18 +08:00 via iPhone

这显然是过度设计。我猜这些代码虽然拆分了目录但是还是一个团队维护的，要不然两个团队在一个 repo 里面早打架拆开了。如果是一个团队维护，那么拆分 repo 必定会带来复杂度损耗，显然是继续这样最简单了。

yetone

2021-06-02 00:45:46 +08:00 via iPhone

这就是 Facebook Google 和 Microsoft 这种顶级大厂喜欢搞的 monorepo 啊

rapperx2

2021-06-02 08:42:59 +08:00

过度拆解了，dao 拆解了有什么用吗？？

lei2j

2021-06-02 09:55:15 +08:00

我们公司拆分的比你这还狠，dao 、service-api 、service 、service-provider

taowen

2021-06-02 10:05:45 +08:00

还有每个字段一个微服务，每个函数一个微服务呢

xuanbg

2021-06-02 10:07:38 +08:00

楼主的想法没错，我就是这么干的。明明简单分几个包就可以了，要辣么多模块做咩？？？

acmore

2021-06-02 10:08:08 +08:00

还不够细，不如一个 Class 一个模块（狗头
没有明确目标的矫枉过正是大忌，跟过早优化是万恶之源一样

caixiaomao

2021-06-02 10:28:25 +08:00

dao 拆解感觉没必要对外的 api 拆解还是有必要的

ychost

2021-06-02 20:30:26 +08:00

设计过度了，仅需要 api 包和 service 尽可，如果没有 rpc 需求，api 都可以不要