1 概念和基本结构

我们先看看消息代理的基本结构。

标准端口 5672 高级消息队列协议或AMQP简称

user1  \                          /  service 3
        \                        /
user2 --- message broker(消息代理)  ---- service 1
        /                        \
user3  /                          \  service 2  

2 常用架构方案

消息同步方案

• 同步：

            HTTP，如 REST、SOAP、RPC、gRPC 等
  

• 异步：

       消息队列，如 AMQP、Kafka、MQTT 等
  

对消息可靠性要求较高时考虑 RabbitMQ，否则kafka

RabbitMQ
Apache Qpid
Apache Kafka
Apache ActiveMQ
Redis

Eclipse OpenMQ

JoramMQ

Eclipse Mosquitto

HiveMQ

Solace PubSub+

Google Cloud Pub/Sub

Amazon SQS

Amazon MQ

IBM MQ

Azure Event Hubs

Azure Service Bus

注意：Headers 表示具有任意数量键的 dictionary 或 map，而 attrs 表示一组有限的键值对。

• 相似点：

所有协议都有队列的 FIFO 概念

所有协议都基于 TCP

所有协议都有生产者、消费者的概念

所有协议都有负载（payload）与正文（body）

• 不同点：

AMQP 有不同的消息传递模型

Cloud-based 的消息队列具有死信队列

消息检索（routing key）方法不同

Headers 和 attrs 的支持有限

Redis、STOMP、MQTT 的功能最不丰富，而 AMQP 的功能最丰富

Cloud-based 的消息队列具有一些独特的配置以及相关 API。

3 消息代理的任务

这是分布式系统中的一种架构模式，其中消息代理是一种应用程序，它将来自源应用程序的单个协议消息转换为来自目标应用程序的协议消息，从而充当它们之间的中介。

此外，消息代理的任务包括：

	检查消息是否有错误；
	路由到特定的接收者；
	将消息拆分为几个较小的消息，然后汇总接收者的响应并将结果发送到源；
	将消息保存到数据库；
	调用网络服务；
	向订阅者分发消息；

但它到底是什么？

如果您简化这个庞大的描述，您可以将消息代理描绘成现实生活中的邮局（您已经多次遇到过）：

发件人（您产品的用户）将包裹（任何数据）带到邮局并指定收件人（另一种服务）。

邮局员工接受包裹并将其放入存储区（将其放入待发送队列中）并发出包裹已成功接收寄件人的收据。

一段时间后，包裹被送到收件人（另一种服务），他不必在家接受包裹。

在这种情况下，他的包裹将在邮箱中等待，直到他收到为止。

4 小结

使用这种架构模式可以解决的最重要的问题之一是并行化任务并保证结果，解决如何转发的问题，即使在发送数据时接收服务不可用。

由于微服务架构在大多数现代项目中占主导地位，这种方法可以最大限度地提高整个系统的性能和弹性。

发件人将包裹交给 消息代理后，不再关心包裹如何送达，但他知道无论如何都会送达。