V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
amrom
V2EX  ›  Java

关于微服务多模块问题

  •  
  •   amrom · 2021-06-01 15:16:21 +08:00 · 3512 次点击
    这是一个创建于 1258 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    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
        1
    zoharSoul  
       2021-06-01 15:20:33 +08:00
    不赞同, 毫无意义
    除了如果有提供出去的 rpc interface 可以单独分个 module, 别的觉得没必要.
    guisheng
        2
    guisheng  
       2021-06-01 16:03:17 +08:00
    对外的 api 如 fegin,rpc 等公共类需要建立一个单独的 module 其它的完全是自己坑自己。
    huifer
        3
    huifer  
       2021-06-01 17:20:26 +08:00
    GM
        4
    GM  
       2021-06-01 17:23:44 +08:00
    好熟悉的目录结构,请问是 JBoot 项目吗?
    zpfhbyx
        5
    zpfhbyx  
       2021-06-01 17:45:35 +08:00
    😨 我让这玩意荼毒了一段时间了。。
    quiet1991
        6
    quiet1991  
       2021-06-01 19:23:47 +08:00
    除了对外提供接口层需要独立的模块,其他的数据访问层基本到项目黄了估计也不会换,没必要
    aragakiyuii
        7
    aragakiyuii  
       2021-06-01 19:29:29 +08:00
    这种除非一开始设计的非常好,否则就是给自己挖坑
    amrom
        8
    amrom  
    OP
       2021-06-01 19:39:13 +08:00
    @GM 不是,就是一般的 Spring boot 项目,还是经过拆分的架构
    amrom
        9
    amrom  
    OP
       2021-06-01 19:43:47 +08:00
    @huifer 看了你的文章,我感觉如果按照你的想法,会把简单的问题复杂化
    fiypig
        10
    fiypig  
       2021-06-01 20:11:08 +08:00 via iPhone
    原公司的一个 java 大佬就要这么做,我直接逃了
    oneisall8955
        11
    oneisall8955  
       2021-06-01 21:15:02 +08:00 via Android
    没必要,dao 也拆成模块,天才
    sunmoon1983
        12
    sunmoon1983  
       2021-06-01 21:23:41 +08:00
    java 不懂,反正我在 golang 里面是把所有公用的模块都分到一个私有的仓库中,然后所有需要用到的地方直接依赖这个私有仓库就得了
    javacodecreeks
        13
    javacodecreeks  
       2021-06-01 21:29:14 +08:00 via iPhone
    我们大佬出于中台设计理念和版本统一管理,几乎在后端每一个微服务里面都采用了模块化的管理方式,更要命的是 maven 的传递依赖链长达十几级以上的都有,遇到冲突时简直是生不如死
    wd
        14
    wd  
       2021-06-01 21:38:18 +08:00 via iPhone
    这显然是过度设计。我猜这些代码虽然拆分了目录但是还是一个团队维护的,要不然两个团队在一个 repo 里面早打架拆开了。如果是一个团队维护,那么拆分 repo 必定会带来复杂度损耗,显然是继续这样最简单了。
    yetone
        15
    yetone  
       2021-06-02 00:45:46 +08:00 via iPhone
    这就是 Facebook Google 和 Microsoft 这种顶级大厂喜欢搞的 monorepo 啊
    rapperx2
        16
    rapperx2  
       2021-06-02 08:42:59 +08:00
    过度拆解了,dao 拆解了有什么用吗??
    lei2j
        17
    lei2j  
       2021-06-02 09:55:15 +08:00
    我们公司拆分的比你这还狠,dao 、service-api 、service 、service-provider
    taowen
        18
    taowen  
       2021-06-02 10:05:45 +08:00
    还有每个字段一个微服务,每个函数一个微服务呢
    xuanbg
        19
    xuanbg  
       2021-06-02 10:07:38 +08:00
    楼主的想法没错,我就是这么干的。明明简单分几个包就可以了,要辣么多模块做咩???
    acmore
        20
    acmore  
       2021-06-02 10:08:08 +08:00
    还不够细,不如一个 Class 一个模块(狗头
    没有明确目标的矫枉过正是大忌,跟过早优化是万恶之源一样
    caixiaomao
        21
    caixiaomao  
       2021-06-02 10:28:25 +08:00
    dao 拆解感觉没必要 对外的 api 拆解还是有必要的
    ychost
        22
    ychost  
       2021-06-02 20:30:26 +08:00
    设计过度了,仅需要 api 包和 service 尽可,如果没有 rpc 需求,api 都可以不要
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2698 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 08:25 · PVG 16:25 · LAX 00:25 · JFK 03:25
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.