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

Service 调用问题

  •  1
     
  •   rainbowyao · 2020-05-14 09:09:01 +08:00 · 3558 次点击
    这是一个创建于 1636 天前的主题,其中的信息可能已经有所发展或是发生改变。

    Service 调用 Service 合理么?某一 service 中封装的逻辑在其他 service 直接调用,不然就存在逻辑复写了。网上看了很多有说合理,也有说不合理的。但没有具体的说明原因。不存在 Service 互相调用,应该都是单向调用。

    22 条回复    2020-05-15 10:29:41 +08:00
    sheeta
        1
    sheeta  
       2020-05-14 09:12:36 +08:00 via Android
    ServiceManager 如何
    ebingtel
        2
    ebingtel  
       2020-05-14 09:18:00 +08:00
    不合理感觉……潜在的问题是: 导致循环引用……可以在上层进行组合调用多个 service
    rainbowyao
        3
    rainbowyao  
    OP
       2020-05-14 09:19:07 +08:00
    @ebingtel 组内开发人员都约束一样,约定只能单向调用应该就不存在循环引用了
    rainbowyao
        4
    rainbowyao  
    OP
       2020-05-14 09:19:39 +08:00
    @sheeta 没怎么用过啊
    ebingtel
        5
    ebingtel  
       2020-05-14 09:27:21 +08:00
    @rainbowyao 业务 service 多了 是怎么保证单向调用对 肉眼么? 方法就是: 绝对不允许 service 之间调用
    Egfly
        6
    Egfly  
       2020-05-14 09:31:32 +08:00
    Service 之间应该不能调用。如果发现有共用的逻辑,可以考虑再抽出一层,比如 logic
    securityCoding
        7
    securityCoding  
       2020-05-14 09:44:16 +08:00
    不合理 , 往下抽一级出来 , 我习惯命名 component , 可以看看阿里巴巴开发手册关于项目结构命名的规范
    yeqizhang
        8
    yeqizhang  
       2020-05-14 09:50:26 +08:00 via Android
    分层这么严格的吗?我之前都是有注入其它 service,也没遇到什么问题。
    不知道这么写会有什么问题?有问题之后尽量不这么写了……
    DebugTy
        9
    DebugTy  
       2020-05-14 09:56:24 +08:00
    dao -> repository -> service
    rainbowyao
        10
    rainbowyao  
    OP
       2020-05-14 10:09:46 +08:00
    这么一看好像都是反对的声音,学习了
    wysnylc
        11
    wysnylc  
       2020-05-14 10:10:46 +08:00
    可以互相调用,要不然怎么重用????
    yidinghe
        12
    yidinghe  
       2020-05-14 10:13:39 +08:00
    Service 和 service 之间应该存在领域划分,应该职责边界合理分明,这样做的目的是保持数据的内聚性,避免胡乱调用导致低性能。
    xuanbg
        13
    xuanbg  
       2020-05-14 10:17:00 +08:00
    1 、搞一个公共类,两个 services 都调用公共类里面的静态方法。
    2 、搞一个基类,两个 services 都继承这个基类。
    miniliuke
        14
    miniliuke  
       2020-05-14 10:24:56 +08:00
    @yidinghe service 之间的交互通过 Eventbus 吗?总感觉这样写出了减少了耦合但是代码不可读性上升了......搞个更高层的 Service 做代理?有什么好的解决方案么?
    mazyi
        15
    mazyi  
       2020-05-14 10:49:29 +08:00
    业务 service 互相不能掉,还有基础 service 嘛。不要局限于 service,应该看看构架啦。
    yidinghe
        16
    yidinghe  
       2020-05-14 10:51:15 +08:00
    @miniliuke 如果合理的分类和命名 event/publisher/handler,并且能够在 IDE 中追踪,其实代码可读性并没有受到太大影响。比如说我有个事件 UserLoginEvent,那么代码中要有一个约定,就是所有构造 UserLoginEvent 对象的地方一定是发布事件的地方,所有将 UserLoginEvent 对象作为参数的方法一定是处理事件的方法。如果不遵守这个约定,比如将 UserLoginEvent 对象到处传递,这就影响代码可读性了。
    ZSeptember
        17
    ZSeptember  
       2020-05-14 10:52:23 +08:00
    可以相互调用的。
    optional
        18
    optional  
       2020-05-14 10:54:32 +08:00 via iPhone
    可以互相调用啊,否则为什么封装 service,不过循环引用尽量避免。
    nutting
        19
    nutting  
       2020-05-14 11:19:47 +08:00
    spring 可以自己解决循环依赖吧
    iffi
        20
    iffi  
       2020-05-14 11:29:07 +08:00
    facade 即可
    namelosw
        21
    namelosw  
       2020-05-14 12:40:55 +08:00
    首先得说清楚是什么 Service,Service 是现在 overload 最严重的词了。

    我发现楼上说得也都不是一个东西。

    我们一般说 Domain Service,Application Service,Microservice 。应该还有无数种 service 。

    凡事没有绝对,不过我们一般 Domain Service 不能互相引,Application Service 可以。

    对于 Microservice,这个问题比较复杂:
    1. 不互相引,经常会导致 service 之间逐渐分层,最后出现底层和上层 service,一般是 microservice 反模式。不过有人非得硬扯美其名曰中台。
    2. 不互相引,但是靠 BFF 或者 composer 协调,固定两层。经常会导致 BFF 或 composer 写了很多逻辑,而且很多纯给其他 service 传话用的。
    3. 不互相引,每个 service 靠 subscribe event 过日子,需要的时候得自己存一份数据。相对复杂。
    4. 互相引。很直接。开始代码简单,功能好实现,不能独立部署,但是后面会很乱,最后看起来比单体更复杂。
    5. 回单体。有时候其实也不是个坏选择,取决与业务。正如 SICP 里说的,逻辑可以被有效拆分的时候才适合用面向对象范式,领域之间互相的关系太紧密就不适合,比如模拟量子力学(所有单位都互相影响)用 OO 就是找不痛快。业务越复杂越像量子力学。Service 只是更大的 Object,所以这个说法也同样适用。

    这种问题出现的原因是切分 service 切分错误,或者粒度过细,导致 service 之间业务会互相依赖。所以碰见很多这种问题是切分问题,在 1234 或者其他选择里面选基本都是错的,没有太好的办法。如果只碰见很少这种问题怎么解都不难。

    最理想的情况是 service 之间老死不相往来,每个 service 负责一个很独立的领域,偶尔有很小的交互,这时候 123 任选就行了。所以不太确定的时候可以切得大一些,熟练了之后可以逐渐向细粒度发展或者重构。

    实在没办法改可以把关系密切的几个 service 合起来当一个小组,这个小组看作一个单独的 servcie,小组之间可以用 4,组间用 123 。
    Aaronsunny
        22
    Aaronsunny  
       2020-05-15 10:29:41 +08:00
    是可以调用的,但是最好还是往下下沉一层,从架构的角度上来看更合理。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   999 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 21:00 · PVG 05:00 · LAX 13:00 · JFK 16:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.