系统通讯方式有哪些?

• RPC调用

  RPC 全称 Remote Procedure Call——远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的方式。

  RPC 调用分类
  通讯协议层面	基于 HTTP 协议的 RPC；基于二进制协议的 RPC；基于 TCP 协议的 RPC
  是否跨平台	单语言 RPC，如 RMI, Remoting；跨平台 RPC，如 google protobuffer, restful json，http XML。
  调用过程	同步通信RPC和异步通信RPC

• 消息队列

  消息队列”是在消息的传输过程中保存消息的容器。

消息队列的应用场景

• 异步处理

  有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，在需要的时候进行处理;例如用户注册的时候发送验证邮件可以通过异步处理的方式在另外一个线程内完成发送邮件操作.

• 解耦

  在应用开发过程中随着需求的增加各个模块进行过度耦合,各模块之间形成相互调用的关系,我们可以利用消息队列形成中间层进行解耦.

• 流量削峰

  在应用某一时段会发生大流量的请求,例如双十一会造成大量请求数据库,数据库很快就会形成瓶颈.我们可将数据请求持久化在消息队列中,进行逐步处理.

• 日志收集

  在项目开发和运维的心中日志是一个很重要的部分,如果尽可能全面而又有效的收集日志进行分析是一个势在必得的任务,我们可以使用消息队列来构建统一日志处理平台.

• 事务最终一致

  在行业中使用消息队列来保证一个事务的最终一致性也是常见分布式事务的解决方案.

消息队列通讯模型

一个最基本的消息队列应该具有消息发送者,消息处理中心,消息消费者三个功能.

在MQ中消息队列主要有两种通讯模型分别是PTP点对点和Pub/Sub发布订阅

常见的消息协议

消息协议是指用于实现消息队列功能时双方通信的一个约定, 例如 如何区分客户端是生产消息还是消费消息? 客户端向消息处理中心发送"发送: I am a Javaer"字符串,那么我们根据xxx约定字符中包含发送的代表生产消息,那么我们就可以知道该客户端要发送消息内容是" I am a Javaer",常见的消息协议有AMQP,MQTT,STOMP,XMPP等

AMQP

AMQP即Advanced Message Queuing Protocol，高级消息队列协议，是面向消息中间件设计的应用层协议的一个开放标准。 它的主要特点是面向消息、队列、路由(包括点对点和发布/订阅)]、可靠性和安全。

AMQP允许来自不同供应商的消息生产者和消费者实现真正的互操作扩展，就如同SMTP、HTTP、FTP等协议采用的方式一样。而此前对于消息中间件的标准化努力则集中在API层面上(比如JMS)，且没有提供互操作性的途径。不同于JMS的仅仅定义API，AMQP是一个线路级的协议——它描述了通过网络传输的字节流的数据格式。因此，遵从这个协议的任何语言编写的工具均可以操作AMQP消息。

AMQP模型图

• Exchange即交换器，用来接收Producer发布的消息，并通过设定的路由规则将消息路由给服务器中的Queue。

• Binding即绑定器，可以理解为路由规则。它的作用就是把Exchange和Queue按照路由规则绑定起来。

• Binding Key即绑定关键字，Exchange视自身类型来决定Binding的路由行为。

• Routing Key即消息的路由关键字，Exchange根据这个关键字决定如何路由某条消息。

MQTT

MQTT 最初由 IBM 于上世纪 90 年代晚期发明和开发。它最初的用途是将石油管道上的传感器与卫星相链接。顾名思义，它是一种支持在各方之间异步通信的消息协议。异步消息协议在空间和时间上将消息发送者与接收者分离，因此可以在不可靠的网络环境中进行扩展。虽然叫做消息队列遥测传输，但它与消息队列毫无关系，而是使用了一个发布和订阅的模型。在 2014 年末，它正式成为了一种 OASIS 开放标准，而且在一些流行的编程语言中受到支持（通过使用多种开源实现）。

MQTT模型图

ATOMP

STOMP，Streaming Text Orientated Message Protocol，是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。它提供了一个可互操作的连接格式，允许STOMP客户端与任意STOMP消息代理(Broker)进行交互。由于其设计简单，很容易开发客户端，因此在多种语言和多种平台上得到广泛应用。其中最流行的STOMP消息代理是Apache ActiveMQ。

ATOMP模型图

JMS

注意: JMS不是消息队列协议的一种，更不是消息队列产品!

注意: JMS不是消息队列协议的一种，更不是消息队列产品!

注意: JMS不是消息队列协议的一种，更不是消息队列产品!

关于JMS你需要了解一点有趣的历史.

消息队列（Message Queue）起源于一位来自 MIT 的硬件设计教育工作者 Vivek Ranadivé 设想了一种通用软件总线，就像主板上的总线那样，供其他应用程序接入。Vivek在1983年成立了 Teknekron，高盛等公司作为第一批用户再金融交易中采用了 Teknekron的软件，同时还诞生了第一代消息队列软件：Teknekron 的 The Information Bus（TIB）。

Teknekron 的 TIB 允许应用开发者建立一系列规则去描述消息内容，只要消息按照这些规则发布出去，任何消费者应用都可以订阅感兴趣的内容，信息的生产者和消费者完全解耦，并且可以再传输过程中灵活混合。这个特性引起了电信特别是新闻机构的注意。1994年路透社收购了 Teknekron 。

由于消息队列再金融交易中应用的反响，BIM 在1990年也开始研发自己的消息队列软件（BIM MQ），并且逐步演化成 WebSphere MQ 并统治着商业消息队列平台市场。同时微软开发了Microsoft Message Queue（MSMQ）。然而这些商业MQ问题在供应商壁垒，各个厂商的 MQ 之间无法互通。为了解决这个问题，Java Message Service（JMS）在2001年诞生了，试图通过提供公共 Java API的方式隐藏MQ各个供应商提供的实际接口，从而跨越壁垒和解决互通问题，但是由于使用单独的标准化接口来胶合众多不同的接口使应用程序反而变得更加脆弱。

为了解决各个MQ在各个生产商之间的通讯问题，Java Message Service（JMS）在2001年诞生了，试图通过提供公共 Java API的方式隐藏MQ各个供应商提供的实际接口.是Java面向消息中间件的一套规范的Java API接口.

在JMS诞生之前大多数产品都支持点对点和发布/订阅两种方式的通讯模型.所以JMS就将这两种消息模型抽象成两类规范,由MQ厂商选择实现. 所以我们可以使用JMS的Java API在Java语言上操作具体的MQ产品.

小结

下一章节我们开始进入正式学习MQ消息通讯具体相关产品了,定个小目标,写个简单的MQ