消息系统本质论

烟雾信号、快递服务、信鸽和信号量这些都是通讯的一种方式，你可能会立马想到消息。人类总是有相互联系的需求，同时总是去寻找新的通信方式去战胜距离带来的挑战。现代的通讯科技已经有了很大的进步，但是纠其本质，不过是发送者、接受者、和以消息为核心构成的通讯架构体系。

同步通信模型

软件应用也有同样的需求，系统之间需要交换消息。他们通常需要确保消息一定能够送达目的地。他们有时候需要立即收到接受者的回复，但是不总是这样。在一些应用案例中，他们可能需要接收到多个回复，都是基于不同的场景和不同的需求，也就衍生了不同形式的通讯。

所有的这些都可以用下面的图来表达：

上图描述的请求-应答模式是最普遍的一种模式，本地系统（client）与通过远程系统（server）暴露的通信终端进行同步通讯。在形式上无论是远程系统调用，还是web service调用，或者是远程资源的消费，这些在本质上都是一个模型，只是表现形式不同：本地系统向远程系统发送消息，本地系统同步等待远程系统返回应答，系统之间通过点对点的方式通讯。

这种方式有优点也优缺点，一方面，基于这种模型易于编程，程序工作的形式和单一的程序没什么区别。然而，另一方面看，这种模型使得不同系统之间紧密耦合，存在在系统系统架构层面难以优化和扩展等等问题。

one way style模型

下面来看看one way style方式：

在one way style方式中，系统之间通过传递消息的方式异步交互，所谓异步也就是系统A在发送完消息之后不需要同步等待系统B的应答。这种模型通常依赖一个叫做消息经纪人（Broker）的第三方系统。在上面的图中，我们也可以叫它消息队列，系统扮演着消息的发送者（producer）和消息的接受者（consumer）角色。producer将消息发送给broker，producer依赖broker将消息送达consumer。如果producer需要得到consumer的应答，那么他们通过同样的机制进行消息的交换，只是这个时候消息的发送者和消息的接受者调换个位置。

loosely coupled模型

使用消息方式给系统体系结构带来的好处是它使得系统之间能够松散的耦合。系统之间不需要知道各自都在什么地方，系统A想要与系统B通信，只需要知道系统B的代号即可。而在消息经纪人的帮助下（broker），系统A能够确信消息一定能够被送达到系统B的手中，我们可以用下面的图来表达：

上图我们可以看出：

1. 系统之间不会因为因为某个系统瘫痪而相互影响。
   

2. 系统的单机性能不会影响其他系统。
   

3. 通过增加和减少系统可以扩展应用的整体负载。
   

4. 消息的发送者可以不用关心消息的接受者在哪里，用的是什么技术。

这种体系结构给开发者带来的影响是：在消息系统中，事情变得稍微复杂了些，开发者需要改变编程方式。

如果通过上面的介绍还是有点模糊，我们可以用大家熟悉的简单邮件传输协议（SMTP）来模拟一下。在这个协议中，邮件被投递到SMTP服务器，拿到邮件的服务器会将邮件转发到下一个SMTP服务器，直到邮件被送达接受者的SMTP服务器。这个时候，消息被放在指定邮箱的队列中，等待消费者查看，通常是通过POP3协议或者是IMAP协议。通过SMTP服务，邮件的发送者不需要知道邮件什么时候被送达到邮件接受者手中，甚至不用关心邮件到底会不会被最终送达到邮件接受者的手中。当邮件送达失败之后，邮件的发送者会收件送达失败的消息。我们能够确认的是，broker已经成功接受producer初始发送的消息。

如果消息的发送者需要得到消息接受者的应答，消息会被以同样的机制送达到消息发送者的手中，这个时候消息的发送者变成了后来的消息接收者，消息的接收者相反。我们可以用下面的图来表示：

这篇文章翻译自《RabbitMQ Essentials》，主要在介绍RabbitMQ依赖的AMQP协议之前先简单介绍一下消息的本质概念。