微服务实战系列之MQ

发布时间:2023年12月17日
前言

从今天起,席卷北国的雪,持续了一整天,北京也不例外。这场意外的寒潮,把整个冬天渲染的格外cool。当然你可以在外面打雪仗、堆雪人、拉雪橇,也可以静坐屋内,来一场围炉煮茶的party。此刻,冬天带来的温暖与喜乐不言而喻。
当然烦恼也充斥其中:稍不留神,容易翻跟头。所以,博主先给各位盆友送一句话:雪天路滑,小心脚下

好了,我们言归正传。上一篇,博主给大家介绍了两个人如何建立通信、如何保障通信的成功以及完成通信所需的工具。当然系统本身是对物理世界的模拟实现,所以系统与系统之间、服务与服务之间,也遵循此逻辑。

各位盆友,此刻可以回想一下,我们正在开发的不管什么系统、模块、服务,本质都是建立在通信的基础上而完成的。那么如何通信是我们绕不开的话题,微服务尤甚。

今天博主为大家介绍一个新“朋友”:MQ,因为它在“通信界”真的太重要了。

在这里插入图片描述



一、 MQ简介

“消息队列”是 Microsoft 的消息处理技术,它在任何安装 Microsoft Windows 的计算机组合中,为任何应用程序提供消息处理和消息队列功能,无论这些计算机是否在同一个网络上或者是否同时联机。——来自百度百科

怎么理解上面这段话?博主总结为3个关键词:“跨网络、跨平台、跨服务”
这么优质的消息处理技术,用它做数据传递,再好不过了。我们不需要关心对方是否联机在线、是否Java或.NET,是否Window或Linux,只需两端都接入同一个MQ,剩下的由它完成就好了。

通过上图经典的MQ模型,我们可以观察到MQ的两端,一个是生产者(简称P),一个是消费者(简称C)。就好比一个卖家,一个买家,那么MQ就是销售渠道。

二、应用场景

那它有哪些主要的应用场景呢?

1. 异步

什么是异步?
博主的上一篇文章 微服务实战系列之通信 已进行说明,如需回看请速戳。

比如经典的订单系统,有库存、有物流、有产品、有订单等模块,那么如何做到功能的“快、好、省”呢? 有同学说了,并发呗。

并发是解决性能的必备手段,但是如何使用并发以及并发能够为我们带来什么,是必须思考的问题。此刻,MQ可以胜任,选择它,我们可以同时具备接入多个“消费者”。一个一个消费总比不过同时消费吧?
在这里插入图片描述

2. 解耦

软件架构中,有一句至理名言:“高内聚、低耦合”。我想各位盆友都比较熟悉了吧?MQ为什么可以做到解耦,因为它具备 “3跨”的特点。

举个栗子,我们在做单体服务开发时,模块太多耦合太紧,极容易造成系统间“一损俱损”的局面。
在这里插入图片描述

此刻,我们让MQ作为中介,驾起这座桥梁,烦恼就少多了。即使其中一个系统(比如物流系统)宕机了,也就随它去吧,不至于胆战心惊一整天,两手空空手足无措。
在这里插入图片描述

3. 防并发

为什么需要防并发?当然是基于成本和资源的可用性考虑。一块内存、一个服务器、甚至一个数据库,不管配置多高,总有个上限。

在某些高并发场景,我们既要满足用户的大量参与,又需要保障服务的安全和可靠,怎么办?如果此时不考虑并发,最大的可能性就是TPS下降了、RS上升了,直觉就是系统宕机了。

所以,在有限资源的情况下,避免并发(或有限并发)是永恒的话题。MQ迎难而上,也顺势成为最佳工具之一。

在这里插入图片描述

三、工具选择

目前主流的MQ,既有开源产品,又有商业产品,大致比较如下:
在这里插入图片描述
这是前辈们总结的各家MQ的优势和胜任的场景,各位盆友可以借鉴。


结语

MQ(消息队列)是一个消息传递的工具,而消息本身可以是日志、数据、文件等等形式。当我们开发中,如果遇到上述场景时,可以适当选择MQ作为解耦或者消息的中介。当然只要是工具,必然存在天然的劣势。比如多了一个Node,微服务链自然又延长了,如此容易让服务变得更复杂,运维代价随之上升。

所以,凡事总有好坏之分,我们只好扬长避短,才能化工具为己用,真正能够为自己带来新的技术突破。

好了,今日文章至此,该说byebye了,我们下次接着聊~

在这里插入图片描述

文章来源:https://blog.csdn.net/splendid_java/article/details/134981372
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。