【成为架构师4-2】解耦:MQ,互联网架构的解耦利器

系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结,原内容公众号“成为架构师”。

目录

        • MQ是什么
        • 不应该使用MQ的场景
        • 典型场景一:数据驱动的依赖任务
        • 典型场景二:上游不关心执行结果
        • 典型场景三:上游关注执行结果,但是执行时间较长
        • 典型场景四:削峰填谷,流量控制,保护下游

MQ是什么

MQ,消息队列,或者叫消息总线,常用于上下游之间消息通信的解耦。上游是一个消息发送进程,中间是MQ服务,下游是消息接收进程,上下游的消息进程往往不在一台服务器上。

消息的发送方不需要关注消息的接收方是谁,消息的接收方也不需要关注消息的发送方是谁,二者在物理和逻辑上都不依赖彼此。

不应该使用MQ的场景

在讲四个典型的使用场景之前,先来看不应该使用MQ的场景:当调用方密切关注执行结果的时候,应该使用RPC调用(或者Restfu接口调用),而不是使用MQ

比如一个验证密码是否正确的登录服务:

【成为架构师4-2】解耦:MQ,互联网架构的解耦利器_第1张图片
根据用户输入密码的不同,会走不同的处理,返回不同的结果,这时候调用方是强依赖于密码服务的执行结果的。

绝大部分场景都是使用的RPC调用,如果硬要用MQ来处理的话:
【成为架构师4-2】解耦:MQ,互联网架构的解耦利器_第2张图片
登录请求要等待MQ的回调,执行过程缓慢,同时因为引入的消息中间件,使得编码变得复杂,

你可能感兴趣的:(成为架构师,消息队列,架构,后端)