OpenStack架构分析与实践
OpenStack以每年两个版本的速度不断迅速演进,所以对于OpenStack的架构而言,也是不断向前发展的。回顾一下E版本OpenStack的,它只有5个组件:新星,Galnce,迅速、地平线和基石;当发展到F版本后,其核心组件发展到了7个,比E版本多了中子和煤渣两个组件,它们分别实现计算网络和计算体积的功能,但是从后续的发展中可以看的出,它们远远超出了计算网络和计算体积所支持的功能。
<强>一、业务架构设计思路
OpenStck做的比较好的一点就是架构设计比较通过,对于不同的模块,其业务架构设计方面一般满足以下设计思路:
?REST API接收外部请求
?调度器负责调度服务
?工人负责任务分配
?司机负责任务实现
?消息队列负责组件内部通信
?数据库服务
接下来分别介绍一下上述设计思路。
REST API接收外部请求。OpenStack中的逻辑关系是要各个组件之间的信息传输来实现的，而不同的组件间的消息的传递与交互是通过各个组件的REST API进行的。可以理解为，REST API是所有服务的入口，它对外接收客户发来的REST请求，对内实现请求转发。
REST API还有一个好处就是可以对外隐藏内部实现细节，提供统一的访问接口，由于其模块化的设计，REST API可以很方便的与第三方系统进行集成；在大规模环境下，REST API可以采用分布式部署的方式，从而极大的提高了API的高可用。
Scheduler负责调度服务。这里所说的Scheduler只是一个统称，并不是说每一个组件中都有一个xxx-scheduler的服务，但是大部分组件中都有一个提供类似功能的服务，它可能是单独存在，也有可能是与其他的服务柔和在一起共同提供服务。
我们以Nova为例来说明一下Scheduler的调度服务。当我们创建虚拟机时，往往需要选择出合适的计算节点，然后在这个节点上进行虚拟机的创建，那么，这里对节点的筛选就需要借助nova-scheduler的调度功能。
Worker负责工作服务。上面提到的Scheduler只会负责任务的分配，它有点类似于公司中的项目经理，它会统筹大家的工作，把工作分配给合适的人去做，而Worker才是真正执行相关任务的服务。例如：在Nova中，Worker就是nova-compute服务；在Heat中，heat-engine就是Worker，在许多组件中，我们可以把xxx-engine看作是不同的Worker。
当把负责调度的Scheduler和负责工作的Worker分开后，就使得OpenStack更加容易扩展，这也使得我们可以从不同的方面考虑如何去提高系统的并发性与应对大规模请求的场景。
Driver负责任务实现。为了拥抱不同的技术，OpenStack采用了大量的Driver，例如，在Nova组件中，nova-compute服务可以支持多种不同的Hypervisor，用户可以根据需要通过配置文件进行配置，当修改完配置文件后，只需要重新启动一下服务即可；在Glance组件中，它支持多种存储后端，如：本地文件系统、Ceph、Cinder和Swift等。
其实说白了，之所以可以支持各种不同的Driver，是因为不同的组件会有各自的Driver框架，用户只需要把符合需求的Driver配置好即可使用。Driver框架的存在，也降低了上层开发人员对底层知识的要求。上层开发人员无需关心底层Driver是如何实现的，关于Diver的实现完全可以交给专的人员去做。
消息队列负责组件内部通信。通过前几章节的学习相信大家对这个并不会感到陌生，消息队列的产生，极大的解耦了同一组件的不同服务，使得它们可以实现分布式独立部署。在生产中，我们经常使用的消息队列调用方式有：同步调用和异步调用。
同步调用，从调用关系上来看，是REST API直接调用组件内部服务，以Nova为例，同步调用就是nova-api服务直接调用nova-scheduler且等待返回结果。在这种方式下，当后端面没有返回响应时，REST API服务将一直处于等待状态。
异步调用，与同步调用相反，即，当REST请求发出后，发送方并不会等待接收方的响应而是直接返回。
数据库服务。OpenStack中每一个组件都需要维护各自的状态信息，所以各个组件后端都会有一个数据库服务与之对应。
二、部署架构设计思路
模块化的业务架构极大的将不同组件进行了解耦，正因如此，也使得同一组件不同服务之间实现解耦。这样以来，非但不同的组件可以实现分布式部署，就连同一组件的不同服务的也可以实现分布式部署，近几年随着容器技术的兴趣，OpenStack组件分离及服务模块化的设计更加容易实现容器化部署。
