openstack G版源码分析

     Nova在整个openstack中是代码最多的一部分也是最复杂的一部分。如果对这部分代码和架构有比较深的理解，就可以说对整个openstack的程序架构有了一个比较深的理解，这里将分步骤的进行相关的讲解，这一章先从一些核心的概念讲起。

      先提一下几个在openstack中非常重要的基本概念Server，Manager，Driver。Server顾名思义就是服务，openstack的各种应用都是以服务的形式暴露出来，openstack中主要有两种服务一种是以linux中的服务守护进程方式存在，一种是WSGIService一种以WSGI标准形式存在的web服务。在这里讨论的server就是第一种形式的服务。这个server的主要存在形式就是一个消息队列的守护进程，接受特定topic的消息执行相应的命令，对外提供一个rpc接口，一个sever对应一个topic。一个server要有什么样的具体功能，也就是可以对外提供什么样的服务功能，是由其中的manager来决定，manager顾名思义就是管理者，主要提供管理功能，具体的操作是由manager中定义driver决定的，一个driver可以看做是一个worker，在manager的管理协调下（manager可以调用其他相关模块功能，结合driver）执行相关的工作，为外界提供相关服务应用。

      我们以nova_compute service为例，从实际代码中深入理解一下上边介绍的基本概念。服务的启动时通过执行源代码中nova_master/bin目录中的nova_compute文件来实现服务的启动。

def main():
    config.parse_args(sys.argv)
    logging.setup('nova')
    utils.monkey_patch()

    if not CONF.conductor.use_local:
        block_db_access()

    server = service.Service.create(binary='nova-compute',
                                    topic=CONF.compute_topic,
                                    db_allowed=False)
    service.serve(server)
    service.wait()

 

其中create函数相当于一个工厂方法，利用python的语言特性根据出入的参数动态生成了一个server对象，其中binary可以理解为server的名，topic就是消息队列中要监听的topic，db_allowed主要是限制sever是否可以直接访问数据库（g版主要通过conductor来访问数据库，来减小数据库访问压力）。然后通过eventlet的方式启动服务守护进程，等待对应topic的请求。Manager是可以手动的方式通过create的方式传入，如果没有显示声明就解析binary参数的值来得到Manager的字符串的名字来通过动态载入的方式载入对应的Manager对象。这里自动解析到nova_master/nova/compute中的manager.py中的ComputeManager对象。其中的driver也是通过动态载入的方式得到的，相应的driver的名字是通过openstack的配置框架通过配置的方式来实现的。

    总体说来，这种程序的实现方式是非常的灵活和优雅的，非常容易扩展和修改，其中一个Manager可以对应几个driver按道理来说可以是多个，但根据程序中的注释，作者的回答是一个，应该是为了实现单一原则吧。

由于本人水平有限其中的一些理解可能不到位，希望大家多指正。

（注：这里对高级消息队列，topic，eventlet等一些概念不作解释如果有不清楚的朋友可以上网查看）