ActiveMQ 1.概述

最新推荐文章于 2021-01-28 20:39:46 发布

GardenerHan

最新推荐文章于 2021-01-28 20:39:46 发布

阅读量222

点赞数

分类专栏：消息中间件 ActiveMQ 文章标签：消息中间件 ActiveMQ

本文链接：https://blog.csdn.net/hgx_suiyuesusu/article/details/102489035

版权

9 篇文章 0 订阅

订阅专栏

9 篇文章 0 订阅

订阅专栏

ActiveMQ

@Author:hanguixian

@Email:hn_hanguixian@163.com

微服务架构后，链式调用是我们在写程序时候的一般流程，为了完成一个整体功能会将其拆分成多个函数(或子模块)，比如模块A调用模块B,模块B调用模块C，模块C调用模块D。但在大型分布式应用中，系统间的RPC交互繁杂，一个功能背后要调用上百个接口并非不可能，从单机架构过渡到分布式微服务架构的通例，这种架构会有哪些问题???

系统之间接口耦合比较严重，每新增一个下游功能，都要对上有的相关接口进行改造;
举个例子:假如系统A要发送数据给系统B和C，发送给每个系统的数据可能有差异，因此系统A对要发送给每个系统的数据进行了组装，然后逐一发送;
当代码上线后又新增了一个需求:把数据也发送给D,新上了一个D系统也要接受A系统的数据。此时就需要修改A系统，让他感知到D的存在，同时把数据处理好再给D。在这个过程中你会看到，每接入一个下游系统，都要对A系统进行代码改造，开发联调的效率很低。
其整体架构如下图

activeMq1

每个接口模块的吞吐能力是有限的，这个上限能力如同堤坝，当大流量(洪水)来临时，容易被冲垮。
举个栗子秒杀业务:
- 上游系统发起下单购买操作，我就是下单一个操作
- 下游系统完成秒杀业务逻辑(读取订单，库存检查，库存冻结，余额检查，余额冻结，订单生成，余额扣减，库存扣减，生成流水，余额解冻，库存解冻)

RPC接口基本上是同步调用，整体的服务性能遵循“木桶理论”，即整体系统的耗时取决于链路中最慢的那个接口。比如A调用B/C/D都是50ms，但此时B又调用了B1，花费2000ms,那么直接就拖累了整个服务性能。

activeMQ2

根据上述的几个问题，在设计系统时可以明确要达到的目标:

面向消息的中间件(message-oriented middle ware)MOM能够很好的解决以上问题。
是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
通过提供消息传递和消息排队模型在分布式环境下提供应用解耦、弹性伸缩、冗余存储、流量削峰、异步通信、数据同步等功能。
大致的过程是这样的:
发送者把消息发送给消息服务器，消息服务器将消息存放在若干队列/主题中，在合适的时候，消息服务器会将消息转发给接受者。在这个过程中，发送和接受是异步的，也就是发送无需等待，而且发送者和接受者的生命周期也没有必然关系: 尤其在发布pub/订阅sub模式下，也可以完成一对多的通信，即让一个消息有多个接受者。

消息发送者可以发送一个消息而无须等待响应。消息发送者将消息发送到一条虛拟的通道(主题或队列)上;
消息接收者则订阅或监听该通道。一条信息可能最终转发给一个或多个消息接收者，这些接收者都无需对消息发送者做出同步回应。整个过程都是异步的。
案例:也就是说，一个系统跟另外一个系统之间进行通信的时候，假如系统A希望发送一个消息给系统B，让他去处理。但是系统A不关注系统B到底怎么处理或者有没有处理好，所以系统A把消息发送给MQ,然后就不管这条消息的“死活”了，接着系统B从MQ里消费出来处理即可。至于怎么处理，是否处理完毕，什么时候处理，都是系统B的事儿，与系统A无关。

activeMQ3