openstack源码剖析（openstack原理）
本文目录一览：
- 1、如何获取openstack nova各版本源码
- 2、如何阅读OpenStack源码
- 3、全面认识openstack，它到底是什么？包含什么
- 4、openstack指的是什么？包含什么？
- 5、如何优雅的阅读openstack源代码？
如何获取openstack nova各版本源码
1.可能很多人把git当作github的客户端了，以为git管理的文件只能提交到github或者其他的git网站上。2.认为git只能管理代码由于git的仓库数据是分布式存储的，具有脱离服务器依然全功能可用、历史可查的特性，所以对于如何使用git的问题，我们完全可以发挥一下想象力，让git不光可以管理代码，还可以管理我们的其他文件，让所有的文档、资料甚至照片都处于有历史可查、可分支编辑的状态。
如何阅读OpenStack源码
OpenStack 本身用 python 语言编写，虽然我一直觉得自己的 python 功底已经不错了，但在看源码的过程中，还总是觉得自己掌握的东西太少了，所以，首要的一点，如果你在看 OpenStack 源码，请一定要打牢你的 python 基础，不然有些技巧性的代码可能让你停滞不前。
看源码，如果能一气呵成最好。什么叫一气呵成呢？我先讲个每个人生活中都可能遇到的一些情况：你在做 A 事，但是突然 B 打电话，让你帮着解决 C 事，然后你就去做 C 事了，等你做完 C 事，发现家里有 D 事必须要做，然后你又去做 D 事……这样的结果就是，你把 A 事给遗忘了，即便你空闲时候想起来了，但是再去做的时候，发现没有第一次那样熟悉 A 事了，你需要重新花费一些时间来熟悉它。试想，如果一开始你就把 A 事做到底，会怎样？
看源码其实是一个很漫长的过程，特别对一个大型项目而言，如果你要看完它的源码，过程是很曲折的，这里的看完不仅仅是过目了一遍，脑子里还要能把逻辑关系理顺。你可能有疑问了，要看源码，一天两天解决不了，但是又要保证一气呵成，这根本就是无稽之谈嘛！事情也的确是这样，鱼与熊掌不可兼得！这里就有一个技巧的问题了，你不妨想象，这么大一个项目，它是怎么开发出来的？难道一开始，项目就已经策划好了？需要多少个源文件，每个文件里面的源码是什么也都做好了？有点经验的程序员都知道，这是不可能的。项目的开发是慢慢细化的，一开始只是核心，然后是骨架，然后有血肉，然后有做 A 事的工具……到这里，或许你知道我要说什么了，源码怎么一步步写出来的，我们就怎么一步步的去看它。先研究核心，再研究骨架，然后血肉，其它工具……。还有一个问题，就算我知道怎么看这些源码，我怎么去一气呵成？这就好比你要完成一件大事情，但是你发现给自己定这么宏大的目标对自己来说比登天还难，所以你就想到用小目标来不断激励自己，最终不断接近大目标。这里的一气呵成既然不能一气把所有源码呵成，那就分段吧！不要心急，不要总想着还有很多源码都还没看，保持淡定！
其实，看源码都是一样的，从架构处着手，然后慢慢扩展到细枝末叶。这里，说一些 utilities 。看源码是很枯燥的，一点都不形象不说，还要让脑子一直保持着源码中的很多东西，如果你想偷懒，如果你想让生活更简单，那就用图形吧，图形加速了整个 IT 的发展，它的强大与便利有目共睹。源码中的各个模块，类怎么耦合的，用了什么设计模式，拿张纸，画几笔，就显而易见了，当然，做个 PPT 更好。源码之间的互相交错是最让人头疼的，很多人一开始看源码，就从这个源文件的某个函数跳转到另一个源文件的某个函数，我想问一下，你以为你的大脑是电脑吗？你的大脑也可以像电脑那样按着调用顺序依次调用各个函数？？如果你在看一个源文件，OK，先把这个源文件一气呵成再说，不要跳转到其它源文件，如果引用的其它源文件中的函数你不知道是干嘛的，先 pass ，以后再说，只要你知道调用它的函数是干嘛的就行，等你以后研究到另外一个源文件的时候，这个关系就很明确了。还有一个现象，很多人一接触一个项目的源码，看见那么多源文件，一下子就懵了，不知道如何下手，别人说，从 main 开始看，于是，他就从 main 开始看了，其实这个无所谓，还是那句话，不要以为你的大脑是电脑，做一些人脑力所能及的事，随便找个源文件，然后用心去看它，不要觉得这里的随便就是随便，虽然它的确是随便，但是如果你不知道我说的随便是哪个随便，那就只有随便你了。不管哪个项目，源码包中大致结构一看，基本上就知道各个东西大致是干嘛的，开发这些东西的也是人脑，不是电脑，为了方便理解，基本上文件取名都还是见名知意的。看源码是一件很有挑战的事情，对源码而言，记住，你永远都要站在它的对面，而不是将自己深埋进源码中，一旦你钻进去了，你就已经迷失了自己。还有很多……（稍后补充）
上面说了那么多，都没有谈到 OpenStack ，其实这个是相辅相成的，上面的你知道了，看 OpenStack 你也应该没有问题了，OpenStack 的核心项目是 nova, glance, swift ，最核心的就是 nova 了，所以，从 nova 开始看吧。nova 源码包中有很多子包，源文件。除了版权版本以及和其它组件交互的东西，随便找一个开始看吧。切记，在开始看之前，最好能把你知道的 nova 架构图烂熟于心。 这个很重要，因为你之后随时有可能沉迷进源码大军中。
好了，文章到这里，基本上就结束了。貌似没有给冲着 OpenStack 源码来的读者一个很好的建议，其实，任何事都没有一蹴而就的方法，想做成它，最好的方法就是，保持淡定的心态，一步步，走下去！作为过来人，还是给个建议，从 虚拟化开始看，因为这个里面用到了适配器设计模式，你稍微看一点就知道了这个包是干嘛的了，而且，可以提升你继续看源码的信心。
全面认识openstack，它到底是什么？包含什么
（1）官方的解释相信大家都已经了解了，不了解也没有关系。现在从常识的角度来给大家解释和说明。
OpenStack是一个云平台管理的项目，它不是一个软件。这个项目由几个主要的组件组合起来完成一些具体的工作。
OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目，OpenStack被公认作为基础设施即服务（简称IaaS）资源的通用前端。
如果这些还不明白，那么从另外的角度给大家介绍：
首先让大家看下面两个图就很简单明了了：
此图为openstack的登录界面
下面是openstack的一个管理界面
从这两个图，相信有一定开发经验，就能看出openstack是什么了。可以说他是一个框架，甚至可以从软件的角度来理解它。如果不明白，就从传统开发来讲解。不知道你是否了解oa，erp等系统，如果不了解可以到网上去找，资料一大把。他和oa，erp有什么不同。很简单就是openstack是用做云计算的一个平台，或则一个解决方案。它是云计算一个重要组成部分。
上面对openstack有了一个感性的认识。
（2）openstack能干什么。
大家都知道阿里云平台，百度云平台，而阿里云平台据传说就是对openstack的二次开发。对于二次开发相信只要接触过软件的都会明白这个概念。不明白的自己网上去查一下。也就是说openstack，可以搭建云平台，什么云平台，公有云，私有云。现在百度在招聘的私有云工程师，应该就是这方面的人才。
（3）openstack自身都包含什么
以下是5个OpenStack的重要构成部分：
l Nova – 计算服务
l Swift – 存储服务
l Glance – 镜像服务
l Keystone – 认证服务
l Horizon – UI服务
图1 OpenStack基本构架
下图展示了Keystone、Dashboard二者与其它OpenStack部分的交互。
下面详细介绍每一个服务：
（一）OpenStack计算设施—-Nova Nova是OpenStack计算的弹性控制器。OpenStack云实例生命期所需的各种动作都将由Nova进行处理和支撑，这就意味着Nova以管理平台的身份登场，负责管理整个云的计算资源、网络、授权及测度。虽然Nova本身并不提供任何虚拟能力，但是它将使用libvirt API与虚拟机的宿主机进行交互。Nova通过Web服务API来对外提供处理接口，而且这些接口与Amazon的Web服务接口是兼容的。
功能及特点
l 实例生命周期管理
l 计算资源管理
l 网络与授权管理
l 基于REST的API
l 异步连续通信
l 支持各种宿主：Xen、XenServer/XCP、KVM、UML、VMware vSphere及Hyper-V
OpenStack计算部件
l Nova弹性云包含以下主要部分：
l API Server（nova-api）
l 消息队列（rabbit-mq server）
l 运算工作站（nova-compute）
l 网络控制器（nova-network）
l 卷管理（nova-volume）
l 调度器（nova-scheduler）
API服务器（nova-api）
API服务器提供了云设施与外界交互的接口，它是外界用户对云实施管理的唯一通道。通过使用web服务来调用各种EC2的API，接着API服务器便通过消息队列把请求送达至云内目标设施进行处理。作为对EC2-api的替代，用户也可以使用OpenStack的原生API，我们把它叫做“OpenStack API”。
消息队列（Rabbit MQ Server）
OpenStack内部在遵循AMQP（高级消息队列协议）的基础上采用消息队列进行通信。Nova对请求应答进行异步调用，当请求接收后便则立即触发一个回调。由于使用了异步通信，不会有用户的动作被长置于等待状态。例如，启动一个实例或上传一份镜像的过程较为耗时，API调用就将等待返回结果而不影响其它操作，在此异步通信起到了很大作用，使整个系统变得更加高效。
运算工作站（nova-compute）
运算工作站的主要任务是管理实例的整个生命周期。他们通过消息队列接收请求并执行，从而对实例进行各种操作。在典型实际生产环境下，会架设许多运算工作站，根据调度算法，一个实例可以在可用的任意一台运算工作站上部署。
网络控制器（nova-network）
网络控制器处理主机的网络配置，例如IP地址分配，配置项目VLAN，设定安全群组以及为计算节点配置网络。
卷工作站（nova-volume）
卷工作站管理基于LVM的实例卷，它能够为一个实例创建、删除、附加卷，也可以从一个实例中分离卷。卷管理为何如此重要？因为它提供了一种保持实例持续存储的手段，比如当结束一个实例后，根分区如果是非持续化的，那么对其的任何改变都将丢失。可是，如果从一个实例中将卷分离出来，或者为这个实例附加上卷的话，即使实例被关闭，数据仍然保存其中。这些数据可以通过将卷附加到原实例或其他实例的方式而重新访问。
因此，为了日后访问，重要数据务必要写入卷中。这种应用对于数据服务器实例的存储而言，尤为重要。
调度器（nova-scheduler）
调度器负责把nova-API调用送达给目标。调度器以名为“nova-schedule”的守护进程方式运行，并根据调度算法从可用资源池中恰当地选择运算服务器。有很多因素都可以影响调度结果，比如负载、内存、子节点的远近、CPU架构等等。强大的是nova调度器采用的是可插入式架构。
目前nova调度器使用了几种基本的调度算法：
随机化：主机随机选择可用节点；
可用化：与随机相似，只是随机选择的范围被指定；
简单化：应用这种方式，主机选择负载最小者来运行实例。负载数据可以从别处获得，如负载均衡服务器。
（二）OpenStack镜像服务器—-GlanceOpenStack镜像服务器是一套虚拟机镜像发现、注册、检索系统，我们可以将镜像存储到以下任意一种存储中：
本地文件系统（默认）
l OpenStack对象存储
l S3直接存储
l S3对象存储（作为S3访问的中间渠道）
l HTTP（只读）
功能及特点
提供镜像相关服务
Glance构件
l Glance控制器
l Glance注册器
（三）OpenStack存储设施—-Swift
Swift为OpenStack提供一种分布式、持续虚拟对象存储，它类似于Amazon Web Service的S3简单存储服务。Swift具有跨节点百级对象的存储能力。Swift内建冗余和失效备援管理，也能够处理归档和媒体流，特别是对大数据（千兆字节）和大容量（多对象数量）的测度非常高效。
功能及特点
l 海量对象存储
l 大文件（对象）存储
l 数据冗余管理
l 归档能力—–处理大数据集
l 为虚拟机和云应用提供数据容器
l 处理流媒体
l 对象安全存储
l 备份与归档
l 良好的可伸缩性
Swift组件
l Swift账户
l Swift容器
l Swift对象
l Swift代理
l Swift RING
Swift代理服务器
用户都是通过Swift-API与代理服务器进行交互，代理服务器正是接收外界请求的门卫，它检测合法的实体位置并路由它们的请求。
此外，代理服务器也同时处理实体失效而转移时，故障切换的实体重复路由请求。
Swift对象服务器
对象服务器是一种二进制存储，它负责处理本地存储中的对象数据的存储、检索和删除。对象都是文件系统中存放的典型的二进制文件，具有扩展文件属性的元数据（xattr）。
注意：xattr格式被Linux中的ext3/4，XFS，Btrfs，JFS和ReiserFS所支持，但是并没有有效测试证明在XFS，JFS，ReiserFS，Reiser4和ZFS下也同样能运行良好。不过，XFS被认为是当前最好的选择。
Swift容器服务器
容器服务器将列出一个容器中的所有对象，默认对象列表将存储为SQLite文件（译者注：也可以修改为MySQL，安装中就是以MySQL为例）。容器服务器也会统计容器中包含的对象数量及容器的存储空间耗费。
Swift账户服务器
账户服务器与容器服务器类似，将列出容器中的对象。
Ring（索引环）
Ring容器记录着Swift中物理存储对象的位置信息，它是真实物理存储位置的实体名的虚拟映射，类似于查找及定位不同集群的实体真实物理位置的索引服务。这里所谓的实体指账户、容器、对象，它们都拥有属于自己的不同的Rings。
（四）OpenStack认证服务（Keystone）
Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖自身REST（基于Identity API）系统进行工作，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。事实上，授权通过对动作消息来源者请求的合法性进行鉴定。如下图所示：
Keystone采用两种授权方式，一种基于用户名/密码，另一种基于令牌（Token）。除此之外，Keystone提供以下三种服务：
l 令牌服务：含有授权用户的授权信息
l 目录服务：含有用户合法操作的可用服务列表
l 策略服务：利用Keystone具体指定用户或群组某些访问权限
认证服务组件
服务入口：如Nova、Swift和Glance一样每个OpenStack服务都拥有一个指定的端口和专属的URL，我们称其为入口（endpoints）。
l 区位：在某个数据中心，一个区位具体指定了一处物理位置。在典型的云架构中，如果不是所有的服务都访问分布式数据中心或服务器的话，则也称其为区位。
l 用户：Keystone授权使用者
译者注：代表一个个体，OpenStack以用户的形式来授权服务给它们。用户拥有证书（credentials），且可能分配给一个或多个租户。经过验证后，会为每个单独的租户提供一个特定的令牌。[来源：]
l 服务：总体而言，任何通过Keystone进行连接或管理的组件都被称为服务。举个例子，我们可以称Glance为Keystone的服务。
l 角色：为了维护安全限定，就云内特定用户可执行的操作而言，该用户关联的角色是非常重要的。
译者注：一个角色是应用于某个租户的使用权限集合，以允许某个指定用户访问或使用特定操作。角色是使用权限的逻辑分组，它使得通用的权限可以简单地分组并绑定到与某个指定租户相关的用户。
l 租间：租间指的是具有全部服务入口并配有特定成员角色的一个项目。
译者注：一个租间映射到一个Nova的“project-id”，在对象存储中，一个租间可以有多个容器。根据不同的安装方式，一个租间可以代表一个客户、帐号、组织或项目。
（五）OpenStack管理的Web接口—-Horizon
Horizon是一个用以管理、控制OpenStack服务的Web控制面板，它可以管理实例、镜像、创建密匙对，对实例添加卷、操作Swift容器等。除此之外，用户还可以在控制面板中使用终端（console）或VNC直接访问实例。总之，Horizon具有如下一些特点：
l 实例管理：创建、终止实例，查看终端日志，VNC连接，添加卷等
l 访问与安全管理：创建安全群组，管理密匙对，设置浮动IP等
l 偏好设定：对虚拟硬件模板可以进行不同偏好设定
l 镜像管理：编辑或删除镜像
l 查看服务目录
l 管理用户、配额及项目用途
l 用户管理：创建用户等
l 卷管理：创建卷和快照
l 对象存储处理：创建、删除容器和对象
l 为项目下载环境变量
openstack指的是什么？包含什么？
OpenStack是一个云平台管理的项目，它不是一个软件。这个项目由几个主要的组件组合起来完成一些具体的工作。
OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目，OpenStack被公认作为基础设施即服务（简称IaaS）资源的通用前端。
openstack自身都包含什么
以下是5个OpenStack的重要构成部分：
l Nova – 计算服务
l Swift – 存储服务
l Glance – 镜像服务
l Keystone – 认证服务
l Horizon – UI服务
OpenStack是一个由NASA（美国国家航空航天局）和Rackspace合作研发并发起的，以Apache许可证授权的自由软件和开放源代码项目。
OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API以进行集成。
OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目。它的社区拥有超过130家企业及1350位开发者，这些机构与个人都将OpenStack作为基础设施即服务（IaaS）资源的通用前端。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性。本文希望通过提供必要的指导信息，帮助大家利用OpenStack前端来设置及管理自己的公共云或私有云。
OpenStack云计算平台，帮助服务商和企业内部实现类似于 Amazon EC2 和 S3 的云基础架构服务(Infrastructure as a Service, IaaS)。OpenStack 包含两个主要模块：Nova 和 Swift，前者是 NASA 开发的虚拟服务器部署和业务计算模块；后者是 Rackspace开发的分布式云存储模块，两者可以一起用，也可以分开单独用。OpenStack除了有 Rackspace 和 NASA 的大力支持外，还有包括 Dell、Citrix、 Cisco、 Canonical等重量级公司的贡献和支持，发展速度非常快，有取代另一个业界领先开源云平台 Eucalyptus 的态势。
如何优雅的阅读openstack源代码？
OpenStack 本身用 python 语言编写，虽然我一直觉得自己的 python 功底已经不错了，但在看源码的过程中，还总是觉得自己掌握的东西太少了，所以，首要的一点，如果你在看 OpenStack 源码，请一定要打牢你的 python 基础，不然有些技巧性的代码可能让你停滞不前。看源码，如果能一气呵成最好。什么叫一气呵成.我先讲个每个人生活中都可能遇到的一些情况：你在做 A 事，但是突然 B 打电话，让你帮着解决 C 事，然后你就去做 C 事了，等你做完 C 事，发现家里有 D 事必须要做，然后你又去做 D 事……这样的结果就是，你把 A 事给遗忘了，即便你空闲时候想起来了，但是再去做的时候，发现没有第一次那样熟悉 A 事了，你需要重新花费一些时间来熟悉它。试想，如果一开始你就把 A 事做到底，会怎样。
看源码其实是一个很漫长的过程，特别对一个大型项目而言，如果你要看完它的源码，过程是很曲折的，这里的看完不仅仅是过目了一遍，脑子里还要能把逻辑关系理顺。你可能有疑问了，要看源码，一天两天解决不了，但是又要保证一气呵成，这根本就是无稽之谈嘛！事情也的确是这样，鱼与熊掌不可兼得！这里就有一个技巧的问题了，你不妨想象，这么大一个项目，它是怎么开发出来的难道一开始，项目就已经策划好了。需要多少个源文件，每个文件里面的源码是什么也都做好了。有点经验的程序员都知道，这是不可能的。项目的开发是慢慢细化的，一开始只是核心，然后是骨架，然后有血肉，然后有做 A 事的工具……到这里，或许你知道我要说什么了，源码怎么一步步写出来的，我们就怎么一步步的去看它。先研究核心，再研究骨架，然后血肉，其它工具。还有一个问题，就算我知道怎么看这些源码，我怎么去一气呵成。这就好比你要完成一件大事情，但是你发现给自己定这么宏大的目标对自己来说比登天还难，所以你就想到用小目标来不断激励自己，最终不断接近大目标。这里的一气呵成既然不能一气把所有源码呵成，那就分段吧。
