OpenStack之RPC调用（一）

众所周知，OpenStack的通信方式有两种，一种是基于HTTP协议的RESTFul API方式，另一种则是RPC调用。两种通信方式的应用场景有所不同，在OpenStack中，前者主要用于各组件之间的通信（如nova与glance的通信），而后者则用于同一组件中各个不同模块之间的通信（如nova组件中nova-compute与nova-scheduler的通信）。

关于OpenStack中基于RESTFul API的通信方式主要是应用了WSGI，我会在以后的博文中详细讨论。这里主要还是分享一下关于RPC调用的一些理解。

首先，什么是RPC呢？百度百科给出的解释是这样的：“RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议”。这个概念听起来还是比较抽象，下面我会结合OpenStack中RPC调用的具体应用来具体分析一下这个协议。

其次，为什么要采用RPC呢？单纯的依靠RESTFul API不可以吗？其实原因有下面这几个：

1. 由于RESTFul API是基于HTTP协议的，因此客户端与服务端之间所能传输的消息仅限于文本

2. RESTFul API客户端与服务端之间采用的是同步机制，当发送HTTP请求时，客户端需要等待服务端的响应。当然对于这一点是可以通过一些技术来实现异步的机制的

3. 采用RESTFul API，客户端与服务端之间虽然可以独立开发，但还是存在耦合。比如，客户端在发送请求的时，必须知道服务器的地址，且必须保证服务器正常工作

基于上面这几个原因，所以OpenStack才采用了另一种远程通信机制，这就是我们今天要讨论的鼎鼎大名的RPC。

要了解OpenStack中的RPC，有一个组件是必不可少的，那就是RabbitMQ（消息队列）。OpenStack中，RPC采用AMQP协议实现进程间通信，而RabbitMQ正是AMQP的实现方式，所以可以说OpenStack中的RPC调用都是基于RabbitMq完成的（注：有关AMQP、RabbitMQ的一些知识，可以参看我上篇分享的文章——《兔子与兔子洞》）。

在Nova中，定义了两种远程调用方式——rpc.call和rpc.cast。其中rpc.call方式是指request/response（请求/响应）模式，即客户端在发送请求后，继续等待服务器端的响应结果，待响应结果到达后，才结束整个过程。rpc.cast方式是指客户端发送RPC调用请求后，不等待服务器端的响应结果。不难看出，较rpc.cast模式，rpc.call更为复杂。为了处理rpc.call，Nova采用了Topic Exchange（主题交换器）和Direct Exchange（直接交换器）两种消息交换器。其中Topic Exchange用于客户端向服务器端rpc.call的发起，Direct Exchange用于服务器端向客户端返回rpc.call。对应于这两种交换机，Nova中定义了Topic/Direct消息消费者、Topic/Direct消息发布者、Topic/Direct交换器。各部件如下图所示：