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按道理来说可以是多个,但根据程序中的注释,作者的回答是一个,应该是为了实现单一原则吧。

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

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/e819d30582d22f44b7e4e1abbe576067.html