版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/hgyan25/article/details/81949896
我们都知道openstack中有至少两种通信机制，一种是RESTful API，另一种是RPC调用，举个例子，当nova与glance通信的时候可能用的是RESTful API，而nova-api与nova-scheduler进行通信的时候，却是使用rabbitmq中的消息队列。为什么呢？另外在一个架构设计中应该选择哪一种通信机制。需要我们对这两种机制有一定的了解。
分类
- RESTFUL API
- RPC
RESTful API
- RESTFUL API是一套架构约束条件和原则
- REST定义的原则
- 所有事物都定义了ID。openstack中每个资源都有唯一的UUID
- 所有事物都链接在一起。在openstack中将资源的ID放在URL中。
- 使用标准的方法。比如说GET是查询资源，POST是添加资源，PUT是更新资源等等。
- 使用RESTful API架构，实现的目标
- 客户端与服务端的独立性: 在公共接口不变的情况下，客户端和服务端的代码可以独立开发。
- 无状态性: 用户的状态保存在客户端，服务端不再保存用户的状态。客户端向服务端发送请求时，必须发送所有的数据，包括用户状态。
- 统一的接口: RESTful API的URL格式需要遵守统一的规范。可以降低客户端服务器的耦合度，使得编码更加简单。
- 利用PasteDeploy定制WSGI服务(openstack中所有web服务都是通过WSGI部署的，例如httpserver.serve(…))
api-paste.ini文件——app(应用程序)、filter(过滤器)、pipeline(管道)、composite(复合体)
wsgi_paste.py文件
带过滤器的WSGI服务 - 特点
基于HTTP协议
使用PasteDeploy配置WSGI服务
mapper类来实现URL映射的管理 - 缺点
消息仅限于文本
客户端与服务端采取同步机制，当发送http请求时客户端需要等待服务器的响应
客户端与服务器虽然可以独立开发，但也存在耦合。客户端必须要知道服务器的地址才可以正常工作。 - 其他
REST是面向资源的，资源通过URL暴露
REST本身可以利用HTTP的一些特征，如HTTP动词、状态码、HTTP报头等
- REST定义的原则
RPC
- RPC协议，即远程过程调用（Remote Procedure Call Protocol）
RPC采用AMQP协议实现进程间通信。openstack中采用rabbitmq和qpid。
- AMQP:高级消息队列，基于消息的中间件提供的开放的应用层标准协议。能够有效地支持各种通信模型或者报文传送方面的应用。
- 特点：二进制的应用层通信协议，进城之间对称的异步通信协议，消息格式，一系列标准化的但可拓展的消息能力(订阅者和发布者，两个节点无需知道对方是什么节点，也不用管对方节点怎么去处理发送的消息，拥有过滤器可以修改订阅者的接收内容)
- 组成：发布者，中间件(消息的存储、交换和路由)，订阅者
- 流程：发布者将消息发送到中间件，中间件将消息存储到消息队列中，最后订阅者从消息队列中获取消息。
- nova中使用rabbitmq实现RPC调用
客户端(发布者)无需知道服务器(订阅者)的位置
客户端与服务器无需同步运行。客户端可以先发RPC调用，然后存储在消息队列中。
远程调用的随机均衡性，当客户端发起RPC调用时，可以随机选择一个服务器来处理消息。
两种交换方式：直接交换方式(direct exchange，主要用于服务器端返回rpc.call调用的结果，订阅者直接点名要哪台服务器进行响应)和主题交换方式(topic exchange,主要用于客户端发起远程调用rpc.call和rpc.cast，发布者不指定响应的服务器，可实现负载均衡)
区别
只需要记住一点：RPC是以动词为中心的， REST是以名词为中心的，此处的动词指的是一些方法，名词是指资源。
- 以动词为中心，意味着，当你要需要加入新功能时，你必须要添加更多的动词，这时候服务器端需要实现相应的动词（方法），客户端需要知道这个新的动词并进行调用。
- 而以名词为中心， 假使我请求的是 hostname/friends/， 无论这个URI对应的服务怎么变化，客户端是无需关注和更新的，而这种变化对客户端也是透明的。