通过认证服务的学习，我们可以以不同的身份访问企业云平台，可以通过研发部的账户登录研发部，可以通过业务部访问业务部的资源，也可以通过IT 工程部的身份登录查看整个系统的运行状况；下面我们继续学习消息服务（RabbitMQ ）、镜像服务（Glance ）和计算控制服务（Nova ），了解这3个组件是如何为平台的正常运行提供支撑的。
了解RabbitMQ 、Glance 和Nova 的基本概念。
理解3种服务的服务流程和工作机制。
掌握3种服务的基本操作及常见运维。
消息队列服务
在日常的工作生活中，消息传递是一个必不可少的需求。
在大型软件的内部信息交换和外部信息传递中，消息传递都是不可或缺的。
在系统间通信窗体的最基本方法是socket ，但是这是一个最底层的协议，所以在使用时需要程序来调用。
在进行后序的学习过程之前，小李首先要了解消息服务的基本状况和使用的情景，以及OpenStack 的RPC （远程呼叫机制）的运行机制。
1．消息队列
AMQP 是一种标准化的消息中间件协议，全称为高级消息队列协议（advanced message queuing protocol ）。
可以让不同语言、不同系统的应用互相通信，并提供一个简单统一的模型和编程接口。
这样，就可以采用各种语言和平台来实现自身的应用，当需要和其他系统通信时，只要承认AMQP 协议即可。
2．Rabbitmq 消息服务
RabbitMQ 是一个基于AMQP 协议的高级消息中间件，它主要的技术特点是可用性，
学习目标 项目 基础控制服务 四
OpenStack 云计算基础架构平台技术与应用
52
提示
available ）高可用性集群。
1．了解消息队列AMQP
消息队列AMQP 服务架构，如图4-1所示。
AMQP 中有3个重要的角色，如图4-2所
示。
Publisher ：消息的发出者。
Exchange ：消息的传递者。
Consumer ：消息的接收者。
用户可以模拟写信作为其工作的方式来说
明。
为了传递给收件人，首先需要用信封把信
的内容装起来，然后在信封上写好收件人的信
息，再把信放到邮筒里；后面邮局会拿到信然
后根据信封上的收件人信息来看最终把信给
谁。
写信的人就是那个Publisher ，邮局就是
Exchange ，收件人就是Consumer 。
不同的Consumer 会创建不同的Queue （消息队列），然后将对应的Exchange 绑定到Queue 上。
在消息的传递过程中，Publisher 不会直接的把Message 放到Queue 中，也不管Message 如何分发。
Publisher 只管准备好消息，然后交给
Exchange ，而Exchange 做的事情也很简单，一手从Publisher 拿到消息，然后就把消息放入Queue 中。
对于Exchange ，是放到某一个Queue 中，还是放到多个Queue ？实际上，在Publisher 发出消息的时候会附加一个条件，Exchange 会根据这个条件来决定发送的方法，这个条件就是
routingkey 。
图4-2 AMQP 消息传递示意图 2．了解Rabbitmq 消息服务
Rabbitmq 架构图，如图4-3所示。
通过上面这张应用相结合的结构图既能够清晰的看清楚整体的send Message 到 图4-1 AMQP 架构图
项目四基础控制服务Receive Message的一个大致的流程。
图4-3 RabbitMQ架构图
首先Rabbitmq有如下几种命令行工具。
①rabbitmqctl：用来管理RabbitMQ中间件的命令行工具.它通过连接中间件节点来执
行所有操作。
②rabbitmq-plugins：rabbitmq-plugins 是管理RabbitMQ broker插件的命令行。
3．OpenStack的消息服务
OpenStack采用AMQP作为它的消息传递技术。
AMQP的控制端（Broker），不管是RabbitMQ或者Qpid，它的作用是允许任何两个相同组件以松散耦合的方式进行交流。
更准确地说，OpenStack的组件均可以使用远程呼叫机制（RPC）进行彼此沟通。
然而，这种范式是建立在“publish/subscribe模式”（订阅/发布模式，订阅发布模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。
这个主题对象在自身状态变化时，会通知所有订阅者对象，使它们能够自动更新自己的状态）。
如图4-4所示。
这样做的好处如下。
（1）客户端和服务端之间的解耦（如客户端不需要知道服务引用）。
（2）客户机和服务之间不需要同时使用消息调用，只需要其中一端发送消息调用指令。
（3）随机平衡的远程调用会随机将运行的指令发送到一个节点。
53
OpenStack云计算基础架构平台技术与应用
54
图4-4 OpenStack中的消息服务
下面以计算服务Nova为例，讲解OpenStack组件使用消息服务的原理和机制。
Nova
中的每个组件都会连接消息服务器，一个组件可能是一个消息发送者（如API、Scheduler），也可能是一个消息接收者（如compute、volume、network）。
发送消息有2种方式：同步调用rpc.call和异步调用rpc.cast。
Nova实现了RPC（包括请求+响应的rpc.call和只有请求的rpc.cast），Nova通过AMQP提供一个代理类，这个类提供了函数调用的消息数据编码和数据解码，每个Nova服务（如计算）在初始化时创建两个队列，一个接受消息路由的关键节点类型产生对应的节点编号”（例如compute.hostname），另一个接受消息路由键返回的节点类型编号生成通用的“节点类型”（例如计算）。
前者是专门用来当Nova-API需要重定向命令像terminate（终止）一个实例的在特定的节点，在这种情况下，只有主机的计算节点的虚拟机监控程才能杀死序正在运行的虚拟机实例。
API作为消费者当RPC调用请求/响应，否则只是充当发布，如图4-5所示。
4．Nova RPC映射
当一个实例在OpenStack云部署和共享，每个组件在Nova连接到messagebroker，根据其个性，如计算节点或网络节点，可以使用队列作为调用者（如API或调度器）或一个运行组件（如计算或网络）。
调用器和组件不实际存在于Nova对象模型，但是在这个例
项目四基础控制服务
子中使用它们作为一个抽象对象。
一个调用程序是一个组件，使用rpc发送消息队列系统，接收消息的队列系统，并相应地回复rpc调用操作，如图4-6所示。
图4-5 Nova消息传递
图4-6 OpenStack rpc调用机制
下面介绍几个OpenStack在消息传递过程中常用的对象。
（1）Topic Publisher：该对象在进行rpc.call或rpc.cast调用时创建，每个对象都会连接同一个topic类型的交换器，消息发送完毕后对象被回收。
（2）Direct Publisher：该对象在进行rpc.call调用时创建，用于向消息发送者返回响应。
该对象会根据接收到的消息属性连接一个direct类型的交换器。
55
OpenStack云计算基础架构平台技术与应用
56 （3）Direct Consumer：该对象在进行rpc.call调用时创建，用于接收响应消息。
每一个
对象都会通过一个队列连接一个direct类型的交换器（队列和交换器以UUID命名）。
（4）Topic Consumer：该对象在内部服务初始化时创建，在服务过程中一直存在。
用于从队列中接收消息，调用消息属性中指定的函数。
该对象通过一个共享队列或一个私有队列连接一个topic类型的交换器。
每一个内部服务都有两个topic consumer，一个用于rpc.cast 调用（此时连接的是binding-key为“topic”的共享队列）。
另一个用于rpc.call调用（此时连接的是binding-key为“topic.host”的私有队列）
（5）Topic Exchange：topic类型交换器，每一个消息代理节点只有一个topic类型的交换器。
（6）Direct Exchange：direct类型的交换器，存在于rpc.call调用过程中，对于每一个rpc.call的调用，都会产生该对象的一个实例。
（7）Queue Element：消息队列。
可以共享也可以私有。
routing-key为“topic”的队列会在相同类型的服务中共享（如多个compute节点共享一个routing-key为“topic”的队列）。