开发者应该知道的OpenStack背后的设计原则设计的重要性，这种架构和设计似乎贯穿了OpenStack峰会的主题。无论这种意识是真实的还是只是个人的，与2015年5月的OpenStack会议相比，参加Amazon的re:Invent或GoogleI/O等会议的人们似乎对旗舰产品的关注和承诺程度更低。随着许多OpenStack峰会与会者的个人意见，他们对每天做出的增量架构和设计决策的重要性有了更深入的了解，因为它们可能会影响未来的发布。去影响。正因为如此，每一次更改、更新、补丁和贡献都在评估OpenStack使命宣言和OpenStack的底层设计原则的同时进行评估。使命声明既简单又雄心勃勃：开发一个无处不在的OpenStack云计算平台，该平台承诺通过易于部署和大规模可扩展性来满足大大小小的公共云和私有云的需求。在编写和部署代码时，下面列出的一些设计指南更为重要。因此，了解这些原则如何应用于OpenStack软件的开发路径至关重要。可扩展性和弹性。第一条设计指南明确指出，“可扩展性和弹性是我们的主要目标；”第二条准则指出，任何限制主要目标的组件都应该是可选的。这创建了一个有趣的生态系统，其中包含数百个有用的（如果是任意的）插件。“如果你看一下OpenStack代码，就会发现有很多可选组件。基本上一切都是插件，”经验丰富的OpenStack软件开发人员DarkSecretSoftware的首席执行官SandyWalsh说。异步性。等待响应、阻止入站流量可能会扼杀大型企业系统。因此，OpenStack软件开发的第三条格言是“一切都应该是异步的”。当然，这有其缺点。内存密集型应用程序从异步操作中受益匪浅，而处理器密集型应用程序则深受其害。但是在单机上孤立的性能并不是OpenStack的目标，大规模的水平可扩展性才是目标。因此，异步性是一个优先事项。“可扩展性和弹性是两个主要目标。系统必须能够扩展，”沃尔什说。向外扩展。第四个设计原则是“所有代码都应该能够横向扩展”。向上扩展是一个优势，但是编写随着机器上更多内存和处理器的扩展而扩展的代码并不需要大量计划。另一方面，开发横向扩展的系统可能具有挑战性，尤其是当参与节点的数量增加三倍或四倍时。在所有设计决策中牢记横向扩展的准则非常重要。状态管理。企业Java应用程序遇到的最常见的性能问题之一是随意使用基于状态的变量，这会降低企业系统的速度并使线性扩展几乎不可能。外围JVM语言已经证明了使用不可变数据的可扩展性优势，因此发现第四条准则是“使用无共享(SN)架构或分片”也就不足为奇了。一切都必须分发。下一个格言是“分配一切”，尤其是“逻辑”。Hadoop等大数据的成功案例一次又一次地证明了这一理念；如果您可以确保数据和逻辑无需网络调用即可协同工作，则可以大大提高性能和可扩展性。测试，测试，测试。***，最后一条准则坚持开发人员必须“测试一切”也就不足为奇了。没有一套全面的测试，任何东西都不允许进入代码库；未经测试而提交的代码、补丁或功能改进根本不会被接受和认可。这是比指南更标准的尽职调查，是确保没有遗漏任何内容的好方法。想法简单，执行复杂。如果将这些简单的设计原则应用到极其复杂的问题中，由此产生的OpenStack软件会变得极其有趣。一个很好的例子是OpenStack的分布式对象存储系统Swift的工作方式。SwiftStack的技术总监JohnDickinson说：“使用Swift，你将存储的数据与用于存储数据的实际介质分开。与Swift的数据存储策略相比，这是一个新策略的特点。过去。”使用这种方法，开发方只需要担心将数据获取到Swift，将Swift视为公共资源。从操作的角度来看，这里唯一关心的是服务器和驱动器集群是否处于良好的工作状态。这种高度可扩展的方法已经完善，使用OpenStack设计原则来解决这个难题：在基于云的系统中管理分布式数据。虽然这些指南在OpenStack及其周边项目和插件的日常开发中发挥了关键作用，但所有软件开发人员都可以从中吸取经验教训。测试、开发无状态应用程序、将可扩展性放在首位，以及考虑程序在变大时将如何执行是每个软件开发人员都应该在他们的组织和软件项目***实践中应用的东西。原标题：指导OpenStack软件背后的设计原则
