openstack组件间的协同工作是通过rest api调用完成的，既然组件间需要相互调用API，那么安全认证是无法避免的对吧？
keystone的主要功能是分发各组件的endpoint并为组件之间的api调用提供认证服务；
User: 指使用了openstack 服务的对象
Project(Tenant): 在openstack资源池，划分一个逻辑资源称之为1个项目
Role: 用于权限的划分，user关联了role，使user拥有不同的权限
Policy: 默认就是1个/etc/keystone/policy.json的文件，定义角色包含的权限
Tocken: 认证完毕之后发放的令牌
Credentials: 用于确认用户的身份
Authentication: 认证过程（从普通用户拿到token的认证过程）
Service: openstack中各个组件提供的服务
Endpoint: 在openstack中，每一个service(Nova/Glance/Newtron)都有三种不同的 web api end points. Admin, public, internal。
Admin是用作管理用途的，如它能够修改user/tenant(project)。public 是让客户调用的，比如可以部署在外网上让客户可以管理自己的云。internal是openstack内部调用的。# 以上3种endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放，public通常可以对外网开放，internal通常只能对安装有openstack服务的机器开放； admin url----->面向admin用户 port:3557 internal url ---->面向openstack内部组件间通信 port：5000 public url----->大家都可以访问的api port:5000（与internal url 的端口相同绑定Ip不同） # 注意：用户的权限是根据角色赋予的，所以以上3中api能否调用成功是根据用户的角色决定的，只要有权限调用哪个api都可以，但是不要随便走这样配置会比较乱；keystoneV3版新增概念
Tenant 重命名为 Project添加了 Domain 的概念：domain包含多个project添加了 Group 的概念：把N个用户加入1个组方便管理glance组件主要提供镜像服务，架构分为glance-api 和glance-registry。
glance-api负责接收客户端组件（Nova..）的 api请求，分发给glance registry
glance-registry去Maria DB中检索镜像元数据，把镜像的信息返回glance api
glance api 根据glance registry返回的镜像元数据，去存储后端拉取相应的镜像，响应给客户端
ps：
注: glance内部组件（glance-api、glance-registry）间的通信不使用消息队列，所以在glance的配置文件中配置消息队列的socket是画蛇添足；
"cinder主要提供块存储功能"
cinder包含以下组件：
cinder-api：提供rest api接口，接收客户端请求分发给cinder-scheduler（承接业务的）cinder-scheduler: 通过算法选出合适的cinder-volume， 通过rpc把cinder-api的任务调度分发给后端 cinder-volume （调度员）cinder-volume：负责处理具体的volume请求，由不同后端存储提供 volume 存储空间。目前各大存储厂商已经积极地将存储产品的 driver 贡献到 cinder 社区（具体干活的）openstack组件间通信: 调用各组件api提供的rest接口
组件内通信:基于rpc(远程过程调用)机制，而rpc机制是基于AMQP模型实现的
从rpc使用的角度出发，nova，neutron，和cinder的流程是相似的，以cinder为例阐述rpc机制：
Openstack 组件内部的 RPC（Remote Producer Call）机制的实现是基于 AMQP协议(Advanced Message Queuing Protocol)作为通讯模型，从而满足组件内部架构的松耦合性。
AMQP是用于异步消息通讯的消息中间件协议，AMQP 模型有四个重要的角色:
Exchange: 根据 Routing key 转发消息到对应的 Message Queue 中（路由器）Routing key: 用于 Exchange 判断哪些消息需要发送对应的 Message Queue（路由表）Publisher: 消息的生产者者，publish把消息发送到Exchange，并指明Routing key，以保证消息队列（Message Queue）可以接收到消息（服务端）Customer: 消息的消费者/接受者，从消息队列（Message Queue）中取出消息（客户端）Publisher可以分为4类：
Direct Publisher发送点对点的消息；（发送1对1消息）Topic Publisher采用“发布——订阅”模式发送消息；（发送组播）Fanout Publisher发送广播消息的发送；（发送广播）Notify Publisher同Topic Publisher，发送 Notification 相关的消息。Exchange可以分为3类：
Direct Exchange根据Routing Key进行精确匹配，只有对应的 Message Queue 会接受到消息；Topic Exchange根据Routing Key进行模式匹配，只要符合模式匹配的Message Queue都会收到消息；Fanout Exchange将消息转发给所有绑定的Message Queue。ps: volume-backen存储节点只是在云主机创建时，只是帮助其调用后端真实存储，开辟一块存储空间，让云主机使用，开辟完成之后，云主机和这块块设备完成挂载；
"没有虚拟机就没有云计算，Nova是通过调用hypervisor 创建出虚拟机"
nova主要组成:
nova-api：接收客户请求（控制节点1）nova-scheduler：调度nova-api下发的请求，通过算法选择出最适合创建当前虚拟机的计算节点nova-compute：通过调用 hypervisor创建出虚拟机（计算节点N）nova-conductor：nova-compute通过 nova-conductor连接MariaDB为什么会有nova-conductor这个“中间人”？
Nova-computer 众多他们都要去数据库中获取Nova-api在数据库里存放的虚拟机创建信息，容易给数据库造成压力（性能考量）Nova-compyte被攻破了后，黑客直接通过Nova-compute 从Maria DB中窃取虚拟机信息（安全考量）neutron组件包含：
neutron-server：专门接收客户端rest full api请求，然后将不同的rest full api请求分发到不同的neutron-plugin上neutron-plugin：neuton是提供网络资源的，在现实世界中会有很多网络设备厂商，而neutron-plugin就是各厂商通过plugin插件的形式把自己的网络设备的功能通过软件的实现neutron-agent：和newtron-plugin对应为neutron-plugin实现功能neutron-plugin分类
openstack刚刚兴起的时候每个网络设备厂商思科、思杰等都开发自己网络设备的插件集成到openstack，其实每个网络设备厂商开发的功能是差不多的，只是开发标准不一样，这就有一个反复造轮子、代码冗余的问题，针对这些问题 newtron-plugin一分为2。
core-plugin：Neutron中即为ML2（Modular Layer 2）提供二层网络核心功能，其他网络设备厂商基于Core-plugin开发自己的 neutron-plugin；service-plugin：即为除core-plugin以外其它的plugin，包括三层网络router、firewall、loadbalancer、×××、metering等等，主要实现L3-L7的网络服务。这些plugin要操作的资源比较丰富，对这些资源进行操作的REST API被neutron-server看作Extension API，需要厂家自行进行扩展。core-plugin ML2核心插件
ML2插件包括Type和Mechanism2部分，这2部分又都分为Manager和Driver；
所以我们要使用什么网络模式就去ML2配置文件种指定；
neutron-server和各neutron-plugin部署在控制节点或者网络节点上（接收Nova 发送的api请求）neutron agent则部署在网络节点上和计算节点上（具体实现网络功能，安装一堆交换机、路由器、VPN等Agent）转载于:https://www.cnblogs.com/jiumo/p/11502586.html
相关资源：JAVA上百实例源码以及开源项目