4同行回答
楼上的兄弟回答的很全面了，但问的是内部组件，我只摘录一段
rabbitmq是openstack的内部默认队列 ，非常关键，一旦阻塞或宕了，整体openstack就会全跨。原生的没有高可用，但如果真上生产，一定要要配置高可用
基于高级消息队列协议
基于 AMQP 协议进行的通信，主要是每个项目内部各个组件之间的通信，比方说 Nova 的 Nova Compute 和 Scheduler 之间，然后 Cinder 的 Scheduler 和 Cinder Volume之间。
需要说明的是，Cinder 是从 Nova Volume 演化出来的，所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系，由于 AMQP 协议进行通信也属于面向服务的架构， 虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目，但是并不要求它们安装在同一个节点上，给系统的横向扩展带来了很大的好处，可以对其中的各个组件分别按照他们负载的情况进行横向扩展，因为他们不在一个节点上，分别用不同数量的节点去承载它们的这些服务。
（ AMQP 是一种协议，OpenStack 没有规定它是用什么实现，我们经常使用的是 Private MQ，实际上用户也可以根据自身的情况选择其它的消息中间件。）
OpenStack 组件之间的通信分为四类：
1 基于 HTTP 协议
2 基于 AMQP(Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议) 协议（基于消息队列协议）
3 基于数据库连接（主要是 SQL 的通信）
4 Native API（基于第三方的 API）
基于HTTP协议进行通信
通过各项目的 API 建立的通信关系，基本上都属于这一类，这些 API 都是 RESTful Web API，最常见的就是通过 Horizon 或者说命令行接口对各组件进行操作的时候产生的这种通信， 然后就是各组件通过 Keystone 对用户身份进行校验，进行验证的时候使用这种通信，还有比如说 Nova Compute 在获取镜像的时候和 Glance 之间，对 Glance API 的调用， 还有比方说 Swift 数据的读写，也是通过这个 HTTP 协议的 RESTful Web API 来进行的。
基于高级消息队列协议
基于 AMQP 协议进行的通信，主要是每个项目内部各个组件之间的通信，比方说 Nova 的 Nova Compute 和 Scheduler 之间，然后 Cinder 的 Scheduler 和 Cinder Volume之间。
需要说明的是，Cinder 是从 Nova Volume 演化出来的，所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系，由于 AMQP 协议进行通信也属于面向服务的架构， 虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目，但是并不要求它们安装在同一个节点上，给系统的横向扩展带来了很大的好处，可以对其中的各个组件分别按照他们负载的情况进行横向扩展，因为他们不在一个节点上，分别用不同数量的节点去承载它们的这些服务。
（ AMQP 是一种协议，OpenStack 没有规定它是用什么实现，我们经常使用的是 Private MQ，实际上用户也可以根据自身的情况选择其它的消息中间件。）
基于SQL的通信
通过数据库连接实现通信，这些通信大多也属于各个项目内部，也不要求数据库和项目其它组件安装在同一个节点上，它也可以分开安装，还可以专门部署数据库服务器， 把数据库服务放到上面，之间通过基于 SQL 的这些连接来进行通信。OpenStack 没有规定必须使用哪种数据库，虽然通常用的是 MySQL
通过Native API实现通信
出现在 OpenStack 各组件和第三方的软硬件之间，比如说，Cinder 和存储后端之间的通信，Neutron 的 agent 或者说插件和网络设备之间的通信， 这些通信都需要调用第三方的设备或第三方软件的 API，我们称为它们为 Native API，那么这个就是我们前面说的基于第三方 API 的通信。
我们知道对Openstack的各个组件（nova，cinder，neutron等）来说，跨组件交互时使用的是RestAPI相互调用公共接口，组件内部各个进程间通信时使用RPC消息通信，从而实现各组件、各进程之间的解耦。Openstack RPC（Remote Producer Call）机制基于AMQP（Advanced Message Queuing Protocol）协议，搭配各种消息服务器（RabbitMQ，Qpid等）实现各个组件内部进程间的消息传递。
AMQP*
AMQP是一个提供统一消息服务的应用层标准协议，基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品、不同开发语言等条件的限制，实现异步通信。
RPC.call：发送请求到消息队列，等待返回最终结果。
RPC.cast：发送请求到消息队列，不需要等待最终返回的结果。
在AMQP模型中，几个主要功能模块连接成一个处理链完成预期的功能：
Publisher：消息发送者，将消息发送到 Exchange。
Message：由Header和Body组成，Header是由Publisher添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受（Routing Key）、优先级是多少等。而Body是真正需要传输的数据，它是对Server不可见的二进制数据流，在传输过程中不受影响……
Exchange：接收发布应用程序发送的消息，并根据Routing Key和Binding信息、Exchange Type等参数将这些消息路由到消息队列。
Binding：关联Exchange和Message Queue，提供路由规则。
Message Queue：存储消息，直到这些消息被消费者安全处理完为止。
Consumer：**消息接受者，从 Message Queue 获取消息。
使用这个模型我们可以很容易的模拟出存储转发队列和主题订阅这些典型的消息中间件概念。
AMQP是非对称的，客户端生产和消费消息，服务器存储和路由这些消息。一个AMQP服务器类似于邮件服务器，Exchange类似于消息传输代理（email里的概念），Message Queue类似于邮箱。Binding定义了每一个传输代理中的消息路由表，发布者将消息发给特定的传输代理，然后传输代理将这些消息路由到邮箱中，消费者从这些邮箱中取出消息。
AMQP模型中不同类型的Exchange对应不同的routing算法：
Direct Exchange：Point-to-Point 消息模式，Direct Exchange 根据 Routing Key 进行精确匹配，只有对应的 Message Queue 会接收到消息。
Topic Exchange：Publish-Subscribe（Pub-sub）消息模式，Topic Exchange 根据 Routing Key 进行模式匹配，只要符合模式匹配的 Message Queue 都会收到消息。
Fanout Exchange：广播消息模式，Fanout Exchange 将消息转发到所有绑定的 Message Queue。
是通过消息队列进行通讯的，比如rabbitmq，zeromq或者其他的。消息队列是支持冗余的，若出问题，将造成openstack平台瘫痪，类似人类的血管堵塞，非常危险。
收起