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

问大佬们个问题,关于微服务和 MQ 的

  •  
  •   Aliberter · 2019-12-23 09:28:43 +08:00 · 4793 次点击
    这是一个创建于 1558 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司的项目在搞微服务,每个模块之间是要按顺序调起执行的,比如报文请求发给了 01 模块,01 处理完毕后会通过 Fegin 去调用一个 MQ 的项目,MQ 项目中写了生产者和消费者,消费者处理完毕后再去通过 Fegin 调用 02 模块。那么问题来了,为什么不直接从 01 用 MQ 去调起 02 呢,通过 Feign 的好处是啥,还有生产者和消费者写在一个项目里,能发挥出 MQ 的优势吗?

    20 条回复    2019-12-23 20:29:33 +08:00
    Aliberter
        1
    Aliberter  
    OP
       2019-12-23 09:35:00 +08:00
    大家说说自己的想法也可以啊,帮助我拓展一下思路,我就想知道这项目目前这种设计有没有瑕疵
    zhaorunze
        2
    zhaorunze  
       2019-12-23 09:39:01 +08:00
    建议看看 《大型网站与中间件》,书不错 适合你
    Aliberter
        3
    Aliberter  
    OP
       2019-12-23 09:47:28 +08:00
    @zhaorunze 好的,谢谢啦,有空买一本看看
    dongeast52123
        4
    dongeast52123  
       2019-12-23 09:52:02 +08:00
    同一个服务自己发 MQ 的同时自己消费 MQ,两个好处。
    1. 利用 MQ 的重发机制,可以少些一些重试 /定时的代码。
    2. 提升接口的吞吐量,因为接口只负责发 MQ,并不处理实际业务。
    坏处:
    代码复杂,MQ 也需要维护,增加了一些系统复杂度。
    phpdever
        5
    phpdever  
       2019-12-23 09:55:18 +08:00
    微服务简单理解就是功能拆分为服务

    MQ 本身的作用在于解耦,微服务也是一样

    Feign,只是通讯手段,用 RestTemplate 也是一样的效果

    至于 01 模块 MQ 项目和 02 模块的调用顺序,则取决于你们项目划分的粒度了。

    文中你提到,为什么不在 01 直接用 MQ 调用 02 模块,如果 01 和 MQ 是耦合在一起的,某天当 MQ 出现性能问题需要优化,可能不是太方便,随着业务发展,可能有多个项目依赖于 MQ,如果项目和 MQ 是解耦的,则只需要处理好 MQ 即可,其他项目作为调用方也不需要关心 MQ 项目的实现细节,反之,如果耦合在一起,则会比较麻烦。

    微服务只是一个工具,前提是服务划分和治理,仅供参考。
    optional
        6
    optional  
       2019-12-23 10:04:35 +08:00
    Feign 只是一个工具而已,mq 解耦
    misaka19000
        7
    misaka19000  
       2019-12-23 10:08:56 +08:00
    解耦
    listkun
        8
    listkun  
       2019-12-23 10:23:07 +08:00   ❤️ 1
    自己发 MQ 自己收,有一个很重要的功能,我之前也没想到,来到现在的公司才了解到:堆积能力.
    利用堆积能力,能够避免突发流量压垮系统,消费端再加上简单的限流,双十一稳稳地
    abcbuzhiming
        9
    abcbuzhiming  
       2019-12-23 10:27:09 +08:00   ❤️ 4
    MQ 最重要的作用才不是解耦,是“削峰错流”。用个 MQ 就解耦了?上下游不需要对消息格式的吗?你乱发一气看看你下游服务能处理不?

    解耦这个词这几年完全被滥用了,有多少人真的认真考虑过解耦到底是怎么一回事没有?上下游服务互相有依赖的时候,你怎么解耦?只要有依赖,就不能完全解耦,无非强耦合弱耦合而已,大部分所谓解耦就是弱耦合,但是弱耦合的方案有很多种,MQ 不过是其中一种,还未必是最好的那种。用 MQ 的场合,如果不考虑削峰错流的话,我个人认为是没用对的
    pws22
        10
    pws22  
       2019-12-23 11:00:44 +08:00
    你们独立出来一个 mq 项目,推测可能你们想职责分明或者是生产能力>>消费能力,,像前面有朋友说的堆积能力,我生产者,消费者不是同一个,难道就没有堆积能力了么..,你用 fegin 去调用 mq 项目的时候,我觉得本质其实没法解耦的,一旦 mq 项目出问题,你上游 01,下游 02 都会受影响,然后如果独立出一个 mq 项目,如果一旦涉及像 mq 项目处理的类似需求,你会发现 mq 项目会越来越庞大,增加一个类似的需求 要写两个请求(一个接收,一个发送),一个 mq 消息发送,一个 mq 消息发送,其实我觉得可以想想把 mq 项目那块细分下,分到其他项目中,碰到如果是生产能力远大于消费能力的用 mq 来缓解下应用压力,其他直接 fegin 调用
    InkAndBanner
        11
    InkAndBanner  
       2019-12-23 11:57:30 +08:00
    @zhaorunze 书太老了吧
    zhaorunze
        12
    zhaorunze  
       2019-12-23 13:36:59 +08:00
    @InkAndBanner 不老,你以为是介绍怎么用框架的书呢,需要追新。
    这书介绍分布式原理的,并结合 java 有相应的方案,是我目前感觉对我帮助最大的书
    snappyone
        13
    snappyone  
       2019-12-23 13:46:13 +08:00 via Android
    @abcbuzhiming 我感觉你理解有问题,真正需要限流的场景是比较少的,相反解耦更多一点。上下游之间加一层消息队列两者发布更新都不需要互相依赖,类似 kafka 机制的消息队列下游无需上游任何改动的情况下可以实现 replay,多个消费者消费同一份消息等功能。如果是传统 api 这些事情搞起来想想多麻烦。
    hitsmaxft
        14
    hitsmaxft  
       2019-12-23 14:02:30 +08:00
    @snappyone 你的理解问题很大, 消息队列缓冲限流的责任最大,pub-sub 机制本身就是解耦的一种,不是你说的这种解耦,和改动没关系。

    生产级别流量波动出现反压很常见的,消息队列充当缓冲池解决这个问题,否则直接发送就行了。
    no1xsyzy
        15
    no1xsyzy  
       2019-12-23 14:15:53 +08:00
    @abcbuzhiming “削峰错流” 不就是 “时间上解耦” 吗?
    解耦又不一定是业务上解耦。
    xuanbg
        16
    xuanbg  
       2019-12-23 14:16:34 +08:00
    01 直接丢数据到 MQ 和调接口丢数据到 MQ 本质没什么不同,就是为了解耦,另外也能起一个削峰去谷的缓冲作用。

    不同的是,如果 01 直连 MQ,那 01 就要写和 MQ 相关的配置和代码,不直连 MQ,就不需要这些配置和代码。可能就是为了省事吧,把生产者和消费者都写在一个项目里面。
    MeteorCat
        17
    MeteorCat  
       2019-12-23 14:18:57 +08:00 via Android
    我感觉依赖程度越高,拆分出来处理更加麻烦
    InkAndBanner
        18
    InkAndBanner  
       2019-12-23 16:07:16 +08:00
    @zhaorunze 我还真就以为是介绍几个主流中间件什么的呢.....读起来感觉怎么样?晦涩吗?有点想去看
    Aliberter
        19
    Aliberter  
    OP
       2019-12-23 19:11:27 +08:00
    下班了才来回复,多谢各位大佬辛苦码字,指点迷津,所获颇丰!有几位说的甚至一语中的,我下午也去问了下领导,总结下来,这么设计的直接缘由,是因为当初项目刚开始并没有集成 MQ,到一期结束时考虑加入 MQ,所以才单独拿出来新添加一个项目,专门负责 MQ 调用分发,作用可以说是异步化业务处理,集中写 MQ 代码也省去了再在每个模块中添加配置和收发消息的代码,结构也看起来更为清晰,但是开发虽然省事了,性能上,显然,目前多这一步 Fegin 的调用可以算是多余的,去调 Fegin,将生产消费代码集成到各个模块中直接调用更好。解耦方面单独建 MQ 项目是起不到作用的,因为项目模块间关联比较紧密,尽管 MQ 环境不挂,但是 MQ 项目一挂掉,各个模块都得瘫,所以其实反而增加了耦合,反之直接用 MQ 做模块间调用可以解决这个问题,后期做集群等,就更能保证消息可靠和系统吞吐量,个人拙见,如果说的有很不对的地方欢迎继续纠正,再次谢谢各位大佬们指点!希望以后有问题还能不吝赐教!
    Takamine
        20
    Takamine  
       2019-12-23 20:29:33 +08:00 via Android
    解耦,削峰,异步。:doge:
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5349 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 58ms · UTC 08:34 · PVG 16:34 · LAX 01:34 · JFK 04:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.