OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.(作为一个云操作系统，OpenStack在数据中心中管理着大量的计算、存储、网络资源池，用户可以很方便地通过其Web UI 面板来管理基于openstack的数据中心。由于虚拟化和SDN技术的发展和成熟，使得软件定义的资源得以实现，人们可以更加智能、弹性、快捷地使用虚拟化了的硬件资源。与传统操作系统相比，目前的OpenStack更突出了其管理和运维的角色，在基础设施层面还是按需分配资源，备份资源，监控系统负荷、异常等等。随着市场需求的变化，OpenStack在系统服务、软件服务层上面引入了比如Trove这样的数据库服务，DNS服务等等，逐渐形成一个云端生态系统。不断更新和孵化的服务，使得应供开发者不需要过多关注存储、灾备、网络等common问题，而更加关注自身业务逻辑，也为应用迁入云端提供了方便。）
3. OpenStack子项目
由于良好的结构和接口设计，OpenStack子项目们提供的服务之间松耦合，服务可以热拔插。在架构设计方法上面，OpenStack从用户、技术、运维角度出发最终选出可用的架构，再进行论证。在接口设计上面遵循通用的REST API规范。常见分布式算法和灾备策略在各子项目中的应用非常广泛，值得关注和学习的有：分布式消息队列Rabbit Message Queue在OpenStack中的应用、比如DHT在SWIFT中的应用，数据的主从复制等。除此之外，在项目运作方面，如何管理一个上万人的社区，有效推动项目的发展，OpenStack也有一套有效的方法论，也值得大家认真研究。
3.1. OpenStack核心服务
核心服务的各个项目都拥有稳定的版本，也广泛地应用于各大公司生产和测试环境。
ph2
- 详细清晰地定义业务目标和需求
- 从业务、客户、最终用户出发增加项目的支持度和参与度
4.2.2 技术
- 从OpenStack整体项目出发，协调和整合OpenStack架构，更高效地利用社区资源。
- 尽可能多地发掘出自动化相关的需求来加速产品开发和部署，架构时也需要考虑如何实现高度自动化。
- 使用合适的工具完成开发工作。
- 做更好更多的测试度量方法和测试工具来支撑持续集成开发、测试流程和自动化。
4.2.3 组织
- 团队管理最求更高效的沟通。
- 在团队中构建更好的概念认知文化：OpenStack，云系统架构，敏捷开发，持续开发、集成、测试等所有开发过程中的概念的更好的认识。
4.2.4 需求管理本身
- 悲观：时刻警惕任何东西和服务都有可能失效。
- 把鸡蛋放到不同的篮子里去：利用不同的服务提供者，在地理上面分区分域来避免全线停服，设计时考虑可移植性。
- 性价比：低效的系统常常是因为其无法扩展，高效的系统在扩展时所花费的精力往往非常廉价，设计时应该去除没有必要的组件。
- 偏执：深度考虑系统安全，在各个层级零容忍安全问题，系统交互过程中不能轻易相信对方。
- 不要太过于偏执：不是所有的软件系统都需要铂金级别的解决方案。对不同层级进行分层架构设计，不同层级配以不同的安全要求。
- 数据管理：对于云系统架构和集成架构来讲，数据是最不灵活的和复杂的，不要轻视数据在分析和索引寻址上面的需求。
- 自动化：利用自动化来讲强系统稳定性、质量、和减少系统响应时间。
- 分而治之：尽可能地对系统和业务进行分层、分区、分域，各个部分分而治之。设计尽可能单一功能的组件，在层级之间考虑负载均衡。
- 系统的弹性：在系统资源扩容时能直观地在性能和扩展上面得到成比例的增长，反之亦然。
- 动态性：支持对系统的动态配置，比如自动地调整规模，故障恢复，资源的发现与定位以适应生产环境中发生的各种问题。
- 缩小延迟：高交互性的组件和服务需要部署在离数据节点近的地方。
- 松耦合：坚持松耦合设计，使用良好的面向服务的API，对业务关注点的划分、抽象。
- 关注成本：系统自伸缩性，数据的传输，软件许可证，预留的资源等等都需要相当大的成本，必须紧密监控系统成本开销。