http://cloud.51cto.com/art/201506/478815.htm
Basic Design Tenets
- Scalability and elasticity are our main goals
- Any feature that limits our main goals must be optional
- Everything should be asynchronous
- a) If you can't do something asynchronously, see #2
- All required components must be horizontally scalable
- Always use shared nothing architecture (SN) or sharding
- a) If you can't Share nothing/shard, see #2
- Distribute everything
- a) Especially logic. Move logic to where state naturally exists.
- Accept eventual consistency and use it where it is appropriate.
- Test everything.
- a) We require tests with submitted code. (We will help you if you need it)
可扩展性和弹性。第一条设计准则明确规定，“可扩展性和弹性是我们的主要目标;”第二条准则表明，限制主目标的任何组件都应该是可选的。这打造了一个令人关注的生态系统，其中有数百个大有帮助、不过随意性的插件。Dark Secret Software公司的首席执行官Sandy Walsh是名经验丰富的OpenStack软件开发人员，他说：“如果你看一下OpenStack代码，就会发现有许多可选的组件。一切基本上就是插件。”
异步性。等待响应、阻止入站传输会要了大规模企业系统的命。因而，OpenStack软件开发的第三条准则就是“一切都应该是异步的。”当然了，这也有其不足之处。大量耗用内存的应用程序会从异步操作中受益匪浅，而大量耗用处理器的应用程序将会饱受其苦。但是单一机器上的孤立性能并不是OpenStack的目标，大规模横向扩展性才是其目标。正因为如此，异步性是一个优先事项。Walsh说：“可扩展性和弹性是两个主要目标。这种系统一定要能够扩展。”
横向扩展。第四条设计准则认为，“所有代码应该能够横向扩展。”纵向扩展是个优点，但是编写随着越来越多的内存和处理器安装到机器上，可以相应扩展的代码并不需要大量的规划。另一方面，开发一个能够横向扩展的系统可能是个挑战，尤其是随着参与节点的数量增至三倍或四倍，更是困难重重。所有设计决策务必要牢记横向扩展这一条准则。
状态管理。企业Java应用程序遇到的最常见的性能问题之一就是，随意使用基于状态的变量，导致企业系统运行速度减慢，几乎不可能实现线性扩展。外设JVM语言已证明了使用不可变数据在可扩展性方面具有的好处，所以发现第四条准则是“使用无共享(SN)架构或分片(sharding)”也就不足为奇了。
一切都必须分布式。下一条准则就是“一切都要分布式”，尤其是“逻辑”。Hadoop等大数据成功故事一再证明了这个理念;如果能确保数据和逻辑能协同运行，而不需要网络调用，就能大大改善性能和可扩展性。
测试、测试、测试。最后，最终一条准则坚决主张开发人员必须“测试一切”，这不足为奇。要是没有经过一系列全面的测试，任何东西都不得进入代码库;未经测试就贸然提交的代码、补丁或特性改进根本得不到接受和认可。这与其说是一条准则，还不如说是标准的尽职调查，而这也是确保没有遗漏的好方法。
想法简单，执行复杂。如果这些简单的设计准则运用于异常复杂的问题，开发的OpenStack软件就会变得极其令人关注。一个典例就是OpenStack的分布式对象存储系统Swift的工作方式。SwiftStack的技术主管John Dickinson说：“借助Swift，你将存储的数据与用来存储数据的实际介质分离开来。相比较过去的数据存储策略，这正是让Swift成为全新策略的特性。”有了这种方法，开发方面的人员只需要操心将数据传送给Swift，将Swift当成它似乎就是一种公用资源。从操作的角度来看，这里要担心的唯一问题是，服务器和驱动器集群是否处于良好的工作状态。这种高度可扩展的方法日臻完善，运用OpenStack设计准则来处理这个难题：在基于云的系统中管理分布式数据。
