这是一个创建于 2297 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司的项目在搞微服务，每个模块之间是要按顺序调起执行的，比如报文请求发给了 01 模块，01 处理完毕后会通过 Fegin 去调用一个 MQ 的项目，MQ 项目中写了生产者和消费者，消费者处理完毕后再去通过 Fegin 调用 02 模块。那么问题来了，为什么不直接从 01 用 MQ 去调起 02 呢，通过 Feign 的好处是啥，还有生产者和消费者写在一个项目里，能发挥出 MQ 的优势吗？
 | 1 Aliberter OP 大家说说自己的想法也可以啊，帮助我拓展一下思路，我就想知道这项目目前这种设计有没有瑕疵 |
 | 2 zhaorunze 2019 年 12 月 23 日 建议看看 《大型网站与中间件》，书不错 适合你 |
 | 4 dongeast52123 2019 年 12 月 23 日 同一个服务自己发 MQ 的同时自己消费 MQ，两个好处。 1. 利用 MQ 的重发机制，可以少些一些重试 /定时的代码。 2. 提升接口的吞吐量，因为接口只负责发 MQ，并不处理实际业务。 坏处： 代码复杂，MQ 也需要维护，增加了一些系统复杂度。 |
 | 5 phpdever 2019 年 12 月 23 日 微服务简单理解就是功能拆分为服务 MQ 本身的作用在于解耦，微服务也是一样 Feign，只是通讯手段，用 RestTemplate 也是一样的效果 至于 01 模块 MQ 项目和 02 模块的调用顺序，则取决于你们项目划分的粒度了。 文中你提到，为什么不在 01 直接用 MQ 调用 02 模块，如果 01 和 MQ 是耦合在一起的，某天当 MQ 出现性能问题需要优化，可能不是太方便，随着业务发展，可能有多个项目依赖于 MQ，如果项目和 MQ 是解耦的，则只需要处理好 MQ 即可，其他项目作为调用方也不需要关心 MQ 项目的实现细节，反之，如果耦合在一起，则会比较麻烦。 微服务只是一个工具，前提是服务划分和治理，仅供参考。 |
 | 6 optional 2019 年 12 月 23 日 Feign 只是一个工具而已，mq 解耦 |
 | 7 misaka19000 2019 年 12 月 23 日 解耦 |
 | 8 listkun 2019 年 12 月 23 日  1 自己发 MQ 自己收,有一个很重要的功能,我之前也没想到,来到现在的公司才了解到:堆积能力. 利用堆积能力,能够避免突发流量压垮系统,消费端再加上简单的限流,双十一稳稳地 |
 | 9 abcbuzhiming 2019 年 12 月 23 日 4 MQ 最重要的作用才不是解耦，是“削峰错流”。用个 MQ 就解耦了？上下游不需要对消息格式的吗？你乱发一气看看你下游服务能处理不？ 解耦这个词这几年完全被滥用了，有多少人真的认真考虑过解耦到底是怎么一回事没有？上下游服务互相有依赖的时候，你怎么解耦？只要有依赖，就不能完全解耦，无非强耦合弱耦合而已，大部分所谓解耦就是弱耦合，但是弱耦合的方案有很多种，MQ 不过是其中一种，还未必是最好的那种。用 MQ 的场合，如果不考虑削峰错流的话，我个人认为是没用对的 |
 | 10 pws22 2019 年 12 月 23 日 你们独立出来一个 mq 项目,推测可能你们想职责分明或者是生产能力>>消费能力,,像前面有朋友说的堆积能力,我生产者,消费者不是同一个,难道就没有堆积能力了么..,你用 fegin 去调用 mq 项目的时候,我觉得本质其实没法解耦的,一旦 mq 项目出问题,你上游 01,下游 02 都会受影响,然后如果独立出一个 mq 项目,如果一旦涉及像 mq 项目处理的类似需求,你会发现 mq 项目会越来越庞大,增加一个类似的需求 要写两个请求(一个接收,一个发送),一个 mq 消息发送,一个 mq 消息发送,其实我觉得可以想想把 mq 项目那块细分下,分到其他项目中,碰到如果是生产能力远大于消费能力的用 mq 来缓解下应用压力,其他直接 fegin 调用 |
 | 11 InkAndBanner 2019 年 12 月 23 日 @zhaorunze 书太老了吧 |
| 12 zhaorunze 2019 年 12 月 23 日 @InkAndBanner 不老，你以为是介绍怎么用框架的书呢，需要追新。 这书介绍分布式原理的，并结合 java 有相应的方案，是我目前感觉对我帮助最大的书 |
 | 13 snappyone 2019 年 12 月 23 日 via Android @abcbuzhiming 我感觉你理解有问题，真正需要限流的场景是比较少的，相反解耦更多一点。上下游之间加一层消息队列两者发布更新都不需要互相依赖，类似 kafka 机制的消息队列下游无需上游任何改动的情况下可以实现 replay，多个消费者消费同一份消息等功能。如果是传统 api 这些事情搞起来想想多麻烦。 |
 | 14 hitsmaxft 2019 年 12 月 23 日 @snappyone 你的理解问题很大， 消息队列缓冲限流的责任最大，pub-sub 机制本身就是解耦的一种，不是你说的这种解耦，和改动没关系。 生产级别流量波动出现反压很常见的，消息队列充当缓冲池解决这个问题，否则直接发送就行了。 |
 | 15 no1xsyzy 2019 年 12 月 23 日 @abcbuzhiming “削峰错流” 不就是 “时间上解耦” 吗？ 解耦又不一定是业务上解耦。 |
 | 16 xuanbg 2019 年 12 月 23 日 01 直接丢数据到 MQ 和调接口丢数据到 MQ 本质没什么不同，就是为了解耦，另外也能起一个削峰去谷的缓冲作用。 不同的是，如果 01 直连 MQ，那 01 就要写和 MQ 相关的配置和代码，不直连 MQ，就不需要这些配置和代码。可能就是为了省事吧，把生产者和消费者都写在一个项目里面。 |
 | 17 MeteorCat 2019 年 12 月 23 日 via Android 我感觉依赖程度越高，拆分出来处理更加麻烦 |
| 18 InkAndBanner 2019 年 12 月 23 日 @zhaorunze 我还真就以为是介绍几个主流中间件什么的呢.....读起来感觉怎么样？晦涩吗？有点想去看 |
| 19 Aliberter OP 下班了才来回复，多谢各位大佬辛苦码字，指点迷津，所获颇丰！有几位说的甚至一语中的，我下午也去问了下领导，总结下来，这么设计的直接缘由，是因为当初项目刚开始并没有集成 MQ，到一期结束时考虑加入 MQ，所以才单独拿出来新添加一个项目，专门负责 MQ 调用分发，作用可以说是异步化业务处理，集中写 MQ 代码也省去了再在每个模块中添加配置和收发消息的代码，结构也看起来更为清晰，但是开发虽然省事了，性能上，显然，目前多这一步 Fegin 的调用可以算是多余的，去调 Fegin，将生产消费代码集成到各个模块中直接调用更好。解耦方面单独建 MQ 项目是起不到作用的，因为项目模块间关联比较紧密，尽管 MQ 环境不挂，但是 MQ 项目一挂掉，各个模块都得瘫，所以其实反而增加了耦合，反之直接用 MQ 做模块间调用可以解决这个问题，后期做集群等，就更能保证消息可靠和系统吞吐量，个人拙见，如果说的有很不对的地方欢迎继续纠正，再次谢谢各位大佬们指点！希望以后有问题还能不吝赐教！ |
 | 20 Takamine 2019 年 12 月 23 日 via Android 解耦，削峰，异步。:doge: |
Select Language