1.一切倒闭的建筑设计、新技术引进的起源都是耍流氓。在介绍一项技术之前，首先要回答的问题是这项技术解决什么问题。就像在微服务分层架构之前，首先要回答为什么要引入微服务，微服务解决什么问题（详见《互联网架构为什么要做微服务?》）。最近分享了几篇MQ相关的文章：《MQ如何实现延时消息》《MQ如何实现消息必达》《MQ如何实现幂等性》很多网友问什么时候用MQ，MQ适合什么场景，所以发了这篇文章。2.什么是微商？MessageQueue，以下简称MQ，是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用MQ后，消息发送的上游只需要依赖MQ，逻辑上和物理上都不需要依赖其他服务。3.什么时候不使用消息总线既然MQ是互联网分层架构中的解耦工具，那么所有的通信都使用MQ不是很好吗？这是一个严重的误解。调用和被调用的关系不能用MQ代替。MQ的缺点是：系统比较复杂，加入MQ组件后消息传递路径较长。延迟将增加消息的可靠性和可重复性。这是矛盾的。很难保证上游不能同时知道下游的执行结果。这是致命的。举个栗子：在用户登录场景下，登录页面调用passport服务，passport服务的执行结果直接影响登录结果。这里的“登录页面”和“通行证服务”必须使用调用关系，不能使用MQ通信。无论如何，请记住这个结论：对于调用方实时依赖执行结果的业务场景，请使用调用而不是MQ。4、什么时候用MQ【典型场景一：数据驱动的任务依赖】什么是任务依赖？例如，互联网公司经常在凌晨进行一些数据统计任务。这些任务之间存在一定的依赖关系，比如：task3需要将task2的输出作为输入。Task2需要使用task1的输出作为输入。在这种情况下，tast1、task2和task3之间存在任务依赖关系。必须先执行task1，然后是task2，然后是task3。对于这类需求，常见的实现方式是使用cron手动安排执行时间安排：task1，0:00执行，经验执行时间为50分钟task2，1:00执行（为task1预留10分钟的缓冲），体验执行task3的时间也是50分钟，2:00执行（为task2预留10分钟的缓冲）。这种方法的缺点是：如果有一个任务的执行时间超过了预留的缓冲时间，就会得到错误的结果，因为后置任务并不知道前驱任务是否执行成功。这时需要手动重新运行任务，调度也可能需要调整。如果一个任务依赖于多个任务，这个任务将被称为关键路径。依赖关系很难体现在进度表中，容易出错。如果有一个任务的执行时间需要调整，就会有多个任务的执行时间需要调整。无论如何，使用“cronschedule”方法来耦合任务。用过的人就知道其中的痛点（用过此方法的请评论留言）。优化方案是使用MQ解耦：task1准时启动，结束后发送“task1done”消息，task2订阅“task1done”消息，一收到消息就开始执行，并发送一个“task2done”消息结束后，task3同样利用了MQ的优点：无需预留缓冲区。上游任务执行完毕后，下游任务总会立即执行，并依赖于多个任务。很容易处理多个任务的依赖关系。您只需要订阅相关消息即可更改任务执行时间。下游不需要调整任务的执行时间。需要注意的是，MQ只是用来传递上游任务执行完成的消息，并不用来传递真正的输入输出数据。【典型场景2：上游不关心执行结果】当上游需要关注执行结果时，应该使用“call”。当上游不关注执行结果时，可以使用MQ。比如58同城很多下游会员需要关注“用户发帖”事件。例如招聘用户发帖后，招聘商家奖励58豆；发帖后，二手商家想修改用户统计。对于这类需求，常见的实现方式是使用调用关系：发布服务执行后，调用下游招聘业务、房产业务、二手业务完成消息的通知，但在事实上，通知是否正常正确执行，发布服务根本不关心。这种方式的缺点是：发布后流程的执行时间增加了下游服务的宕机时间，可能导致发布后服务受到影响，上下游逻辑+物理依赖严重。就是修改代码的后期发布服务。这是最恶心的一点。是架构设计中典型的依赖倒置。用过的人都知道其中的痛点（用过此方法的请评论留言）。优化方案是使用MQ解耦：post发布成功后，向MQ发送消息，MQ下游会关注“发布成功”的消息，主动去MQ订阅。使用MQ的优点是：上游执行时间短，上下游逻辑+物理解耦，另外与MQ有物理连接，模块之间不相互依赖添加下游消息跟随器，上游不需要修改任意代码典型场景3：上游关注执行结果，但执行时间很长最重要的是调用离线处理，或者跨公网调用），经常使用回调网关+MQ来解耦。比如微信支付，跨公网调用微信接口，执行时间会比较长，但是调用方很关心执行结果。这时候怎么玩？一般采用“回调网关+MQ”的方案解耦：调用方跨公网直接调用微信接口。微信返回调用成功。这个时候并不代表返回成功。微信执行完成后，回调统一网关返回结果，通知MQ请求方接收结果通知。这里需要注意的是，不能通过Callbackgateway来调用upstream通知结果。如果是这样的话，每增加一个新的调用者，回调网关都需要修改代码，它仍然会反向依赖。使用回调网关+MQ方案添加任意调用微信支付，无需修改代码。五、总结MQ是互联网架构中常用的解耦工具。什么时候不使用MQ？上游实时关注执行结果什么时候用MQ？数据驱动任务依赖上游，不关心多个下游执行结果异步返回执行时间长作者】点此查看该作者更多好文章
