[网络协议]RPC、AMQP、RESTful API 介绍

RPC、AMQP、RESTful API 介绍

前言

? 在 OpenStack 中，其各组件之间是通过REST接口相互通信的，而各组件内部采用RPC进行通信。RPC 采用了AMOP ( 高级消息队列协议)实现进程间的通信，AMQP 是采用 RabbitMQ 实现的。

OpenStack 是一个开源的云计算管理平台项目，是一系列开源软件项目的组合，由 NASA 和 Rackspace 合作研发并发起，以 Apache 许可证授权的开源代码项目。

RabbitMQ 是实现了 AMQP 的开源消息代理软件（也叫做面向消息的中间件）。

而 OpenStack 设计原则如下：

项目之间通过 RESTful API 通信；

项目内部不同服务进程之间通过消息总线进行通信。

那么接下来根据前言部分进行解释和梳理······

什么是 RPC

? 首先我们需要了解一下什么是 RPC

Remote Procedure Call ，远程过程调用，指计算机在执行一个在不同的地址空间的程序或函数时，其编码方式就像普通的本地函数调用一样，程序员无需为远程交互明确编码细节。简单来说，我在我的电脑上去调用其它电脑上的函数，这就是 RPC ，在这里很多人容易有一个误区，把 RPC当做是一种技术，而实际上 RPC 只是一种远程调用的一种概念，而实现这种概念的才是技术，当然实现了这个概念的技术有很多种，比如：

• Dubbo：国内最早开源的RPC框架，由阿里巴巴公司开发并于2011年末对外开源，仅支持Java语言。

• Motan：微博内部使用的RPC框架，于2016年对外开源，仅支持Java语言。

• Tars：腾讯内部使用的RPC框架，于2017年对外开源，仅支持C++语言。

• Spring Cloud：国外Pivotal公司2014年对外开源的RPC框架，仅支持Java语言。

1. 同步调用 ： 客户方等待调用执行完成并返回结果。

2. 异步调用 ：客户方调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。

注：异步调用是最常用的调用方法，因为同步调用会使得客户方在调用时只能一直等待到结果返回后才能去做其它的事情。

AMQP 介绍

? 在异步通讯中，消息不会立刻到达接收方，而是被存放到一个容器中，当满足一定的条件之后，消息会被容器发送给接收方，这个容器即消息队列，而完成这个功能需要双方和容器以及其中的各个组件遵守统一的约定和规则，AMQP 就是这样的一种协议，消息发送与接受的双方遵守这个协议可以实现异步通讯。这个协议约定了消息的格式和工作方式。而知名的 RabbitMQ 实现了 AMQP 的消息中间件服务。

AMQP 中包含的主要元素

1. 生产者（Producer）：向Exchange发布消息的应用。
2. 消费者（Consumer）：从消息队列中消费消息的应用。
3. 消息队列（Message Queue）：服务器组件，用于保存消息，直到发送给消费者。
4. 消息（Message）：传输的内容。
5. 交换器（Exchange）：路由组件，接收Producer发送的消息，并将消息路由转发给消息队列。
6. 虚拟主机（Virtual Host）: 一批交换器，消息队列和相关对象。虚拟主机是共享相同身份认证和加密环境的独立服务器域。
7. Broker ：AMQP的服务端称为Broker。
8. 连接（Connection）:一个网络连接，比如TCP/IP套接字连接。
9. 信道（Channel）：多路复用连接中的一条独立的双向数据流通道，为会话提供物理传输介质。
10. 绑定器（Binding）：消息队列和交换器直接的关联。

AMQP 的通信原理

（1）建立连接 Connection。由 producer 和 consumer 创建连接，连接到 broker 的物理节点上。

（2）建立消息 Channel。Channel 是建立在 Connection 之上的，一个 Connection 可以建立多个 Channel。

producer连接 Virtual Host 建立 Channel，Consumer连接到相应的queue上建立 Channel。

（3）发送消息。由 Producer 发送消息到Broker中的exchange中。

（4）路由转发。exchange 收到消息后，根据一定的路由策略，将消息转发到相应的 queue 中去。

（5）消息接收。Consumer 会监听相应的 queue，一旦 queue 中有可以消费的消息，queue 就将消息发送给

Consumer端。

（6）消息确认。当 Consumer 完成某一条消息的处理之后，需要发送一条 ACK 消息给对应的 Queue。 Queue 收到ACK信息后， 才会认为消息处理成功，并将消息从 Queue 中移除；如果在对应的 Channel 断开后，Queue 没有收到这条消息的 ACK 信息， 该消息将被发送给另外的 Channel 。 至此一个消息的发送接收流程走完

了。消息的确认机制提高了通信的可靠性。

AQMP 的应用场景

异步处理

比如公司新入职一个员工，需要开通系统账号，有几件事情要做，开通系统账号，发短信通知用户，发邮件
给员工，在公司内部通讯系统中发送消息给员工。其中发短信，发邮件，发内部通讯系统消息，这三件事情可以串行也可以并行，并行的好处就是可以提高效率，这时可以应用
MQ 来实现并行。

应用解耦

在公司内部系统中，有人事系统，OA
系统，财务系统，外围应用系统等等，当人事发生变动的时候（离职入职调岗），人事系统需要将这些变动通知给其他系统，这时只需人事系统发送一条消息，各个外围系统订阅该消息，就可得知人事变动，与实时服务调用相比，如果人事系统挂掉，各个外围系统不会受到影响，继续运行。

流量缓冲

在有些流量会瞬间暴增的场景下，如秒杀，为了防止流量突然增大而使得应用挂掉，可以引入
MQ，将请求存入MQ中，如果超过了MQ的长度，就把请求丢弃掉，这样来限制流量。

日志处理

将消息队列引入到日志处理中，如 kafka 的应用，解决了大量日志的传输问题。日志客户端负责采集日志数据，并定期写入kafka
队列，kafka 负责接收，存储和转发日志，日志处理系统订阅并消费 kafka 中的日志数据。

RESTful API 介绍

Representational State Transfer,（资源）表征状态转移

定义：简单来说REST是一种系统架构设计风格（而非标准），一种分布式系统的应用层解决方案。

目的：Client和Server端进一步解耦。

RESTful API 概念

1，资源。首先是弄清楚资源的概念。资源就是网络上的一个实体，一段文本，一张图片或者一首歌曲。资源总是要通过一种载体来反应它的内容。文本可以用TXT，也可以用HTML或者XML、图片可以用JPG格式或者PNG格式，JSON是现在最常用的资源表现形式。

2，统一接口。RESTful风格的数据元操CRUD（create,read,update,delete）分别对应HTTP方法：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源，这样就统一了数据操作的接口。

3，URI。可以用一个URI（统一资源定位符）指向资源，即每个URI都对应一个特定的资源。要获取这个资源访问它的URI就可以，因此URI就成了每一个资源的地址或识别符。一般的，每个资源至少有一个URI与之对应，最典型的URI就是URL。

4，无状态。所谓无状态即所有的资源都可以URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而变化。有状态和无状态的区别，举个例子说明一下，例如要查询员工工资的步骤为第一步：登录系统。第二步：进入查询工资的页面。第三步：搜索该员工。第四步：点击姓名查看工资。这样的操作流程就是有状态的，查询工资的每一个步骤都依赖于前一个步骤，只要前置操作不成功，后续操作就无法执行。如果输入一个URL就可以得到指定员工的工资，则这种情况就是无状态的，因为获取工资不依赖于其他资源或状态，且这种情况下，员工工资是一个资源，由一个URL与之对应可以通过HTTP中的GET方法得到资源，这就是典型的RESTful风格。

参考博客

http://blog.csdn.net/yinwenjie/article/details/50820369

https://blog.csdn.net/bbwangj/article/details/100916687

https://blog.csdn.net/hjc1984117/article/details/77334616