nova service执行流程，novaservice流程

nova service执行流程，novaservice流程

Novaproject下面具有多个service，api,compute,sceduler等等，他们的启动过程都几乎类似，这一篇博客就详细记录nova-sceduler的启动过程。文章中贴出的源码都是从OpenStackFolsom版截取过来的。

下面就开始分析nova-sceduler的启动过程了，后面还有涉及到启动之后，做的一些周期性工作，这部分可能与sceduler无关，是在compute中的，一次帖上来。

首先是解析启动脚本的参数，包括配置文件，设置日志，utils.monkey_patch现在不明白（为了能够使用高效的eventlet模块，需要打些补丁），然后创建服务，最后启动服务，等待请求。Service.Service.create(binary=’nova-scheduler)过程如下：

过程为获取hostname，topic即为用来与rabbit通信的标识，为scheduler，manager为scheduler_manager，在flags中搜索其对应的类名，其值在nova.conf中指定，默认值为nova.scheduler.manager.SchedulerManager，report_interval为节点将状态报告给数据库的时间间隔，默认为10秒。Periodic_interval，执行周期性任务的周期。再开始初始化service。

其中关键的manager，其中self.manager_class_name为nova.scheduler.manager.SchedulerManager，通过importutils.import_class动态的导入该对象，故manager_class是<class‘nova.scheduler.manager.SchedulerManager’>这么一个对象。（记住，在python中，一切都是对象，有类型对象，实例对象，譬如int为一个类型对象，5则为一个实例对象，其类型是int，而int的类型则为type。）然后，调用SchedulerManager的__init__函数完成初始化，注意SchedulerManager的__init__函数的参数列表，有args和kwargs，所以host=self.host就成了kwargs的一项。

创建完service类之后，开始启动service。

其中workers为none，执行else语句，lanuch_server如下：

使用eventlet.spawn启动一个green thread，run_server如下：

开始启动server，其中start的关键

首先获取一个到rabbitmqserver的连接，然后再注册一个rpc_dispatcher，该对象与回调函数相关，接收到rabbitmq的消息后，再由它来处理，接着创建多个consumer来接收特定topic的消息队列的消息，并设置好消息监听。这样一个服务就启动来了，在后面还有设置周期性的task。

在初始化service的过程中，会调用importutils动态导入具体的manager，对于nova-compute，导入的则是ComputeManager，该类的继承关系是，ComputeManager，Manager.SchedulerDependentManager，Manager，nova.db.Base.其中Manager包含ManagerMeta元类。可以参考RabbitMQ(三)中 的manager类关系图。对Manager与ManagerMeta的分析如下，这块代码涉及到一个资源刷新的问题。对于metaclass的分析可以参考后面的python高级中的metaclass最后一个例子分析。Manager具有一个类属性_periodic_tasks,是一个列表类型的属性，元素是各个需要周期执行的task。在manager类创建时，因为使用到了metaclass，会首先检查每个具有_periodic_task属性的函数，该属性由装饰器periodic_task装饰上的。

这部分的代码就是启动周期性的task。

LoopingCall初始化最关键的参数是f，即传递进一个函数。430行，就将service的report_state函数传递进去，然后调用start函数，下面是start函数的实现。

可以知道，start函数内部有一个闭包函数，然后启动一个greenthread的来执行这个内部函数，内部函数根据传递的参数，决定是否要推迟启动，然后开始周期性的执行传递进来的函数，即self.report_state和self.periodic_task.

查看report_state的代码，关键的如下：

主要的作用是周期性的更新数据库中的nova库service表的report_count字段，目前不知道该字段有什么作用！

再查看periodic_task函数，service.periodic_tasks函数最后会调用self.manager.periodic_tasks，该函数在nova.manager.py中，该函数会去调用被periodic_task装饰的函数，在nova-compute服务中，被periodic_task装饰的有_publish_service_capabilities函数，_report_driver_status函数等等，report_driver_status读取host的相关信息，然后更新capabilities，最后通过scheduler_rpcapi发送到scheduler服务去。

再开始看其中重要的一块RPC，Rpc参考前面的RabbtMQ三，关于rpc有详细的介绍。最后一块pluginManager。

刚收到你的邮件。这些问题你在百度上搜了吗？没有满意的答案吗？本来我的电脑上有这些答案，无奈机子系统坏了。
=======================执行流程
1. 从页面开始，提交表单或者点击链接会触发一个action
2. action交给struts2处理，读取src目录struts.xml文件，在配置中找到对应的action
3. 根据class="XXXAction"交给Spring(为什么struts的action会交给spring处理呢？原因是：Struts2提供一个jar包：struts2-spring-plugin-2.1.2.jar，有个struts.properties文件配置了这样一句话：struts.objectFactory.spring.autoWire = name。也就是有了上面那个jar包之后，根据name自动提交给Spring处理)，读取Spring容器的配置文件/WebRoot/WEB-INF/applicationContext.xml文件。
根据applicationContext.xml配置文件找到xxx.xxx.action.xxxAction类，其中有一个属性xxxService,并提供了setxxxService()方法，由applicationContext.xml文件得知该xxxService对象由Spring容器依赖注入，set注入。
4. 取得xxxService对象(接口对接口实现类的一个引用)后，调用它的方法。后面的就是访问DAO了，一长串省略号代替
5.执行的结果会在action的对应的方法中以字符串的形式给出。然后根据配置文件中的result.找到下一步要执行的动作，是跳转到页面显示还是继续交给其他的action处理。
6. 显示页面。
=========================执行原理
在struts-config.xml 中的action的type实现spring 的请求代理 。而在spring的配置文件中对action类进行注入。
action类中注入service 而在service中注入dao. 当服务器起动时，spring会对类自动设置 。 当访问*.do时。它的执行的顺序。 从action --->service----->dao.然后反回。
===========================最后的那个问题没有任何意义把。
s2sh不就是mvc模式搭建的吗？
 

OpenStack其实有三个与存储相关的组件，这三个组件被人熟知的程度和组件本身出现时间的早晚是相符的，按熟悉程度排列如下：
Swift——提供对象存储 （Object Storage），在概念上类似于Amazon S3服务，不过swift具有很强的扩展性、冗余和持久性，也兼容S3 API
Glance——提供虚机镜像（Image）存储和管理，包括了很多与Amazon AMI catalog相似的功能。（Glance的后台数据从最初的实践来看是存放在Swift的）。
Cinder——提供块存储（Block Storage），类似于Amazon的EBS块存储服务，目前仅给虚机挂载使用。
（Amazon一直是OpenStack设计之初的假象对手和挑战对象，所以基本上关键的功能模块都有对应项目。除了上面提到的三个组件，对于AWS中的重要的EC2服务，OpenStack中是Nova来对应，并且保持和EC2 API的兼容性，有不同的方法可以实现）
三个组件中，Glance主要是虚机镜像的管理，所以相对简单；Swift作为对象存储已经很成熟，连CloudStack也支持它。Cinder是比较新出现的块存储，设计理念不错，并且和商业存储有结合的机会，所以厂商比较积极。
Swift
关于Swift的架构和部署讨论，除了官方网站，网上也有很多文章，这里就不重复.(也可以参考我之前在OpenStack中国行活动中上海站演讲的PPT)。从开发上看，最近也没有太大的结构性调整，所以我想主要说说比较适用的应用领域好了。
从我所了解的实际案例来看，Swift出现的领域有4个，(应该还有更多，希望大家看到实际用例能够指教)
1.网盘。
Swift的对称分布式架构和多proxy多节点的设计导致它从基因里就适合于多用户大并发的应用模式，最典型的应用莫过于类似Dropbox的网盘应用，Dropbox去年底已经突破一亿用户数，对于这种规模的访问，良好的架构设计是能够支撑的根本原因。
Swift的对称架构使得数据节点从逻辑上看处于同级别，每台节点上同时都具有数据和相关的元数据。并且元数据的核心数据结构使用的是哈希环，一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。另外数据是无状态的，每个数据在磁盘上都是完整的存储。这几点综合起来保证了存储的本身的良好的扩展性。
另外和应用的结合上，Swift是说HTTP协议这种语言的，这使得应用和存储的交互变得简单，不需要考虑底层基础构架的细节，应用软件不需要进行任何的修改就可以让系统整体扩展到非常大的程度。
2.IaaS公有云
Swift在设计中的线性扩展，高并发和多租户支持等特性，使得它也非常适合做为IaaS的选择，公有云规模较大，更多的遇到大量虚机并发启动这种情况，所以对于虚机镜像的后台存储具体来说，实际上的挑战在于大数据（超过G）的并发读性能，Swift在OpenStack中一开始就是作为镜像库的后台存储，经过RACKSpace上千台机器的部署规模下的数年实践，Swift已经被证明是一个成熟的选择。
另外如果基于IaaS要提供上层的SaaS 服务，多租户是一个不可避免的问题，Swift的架构设计本身就是支持多租户的，这样对接起来更方便。
3.备份归档
RackSpace的主营业务就是数据的备份归档，所以Swift在这个领域也是久经考验，同时他们还延展出一种新业务--“热归档”。由于长尾效应，数据可能被调用的时间窗越来越长，热归档能够保证应用归档数据能够在分钟级别重新获取，和传统磁带机归档方案中的数小时......余下全文>>