openstack中的通信机制

我们都知道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报头等

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对应的服务怎么变化，客户端是无需关注和更新的，而这种变化对客户端也是透明的。