一致而稳定的抽象层

　　云计算提高了抽象水平，这样，所有组件都抽象化或虚拟化，并可用来迅速组合较高级别的应用程序或平台。如果某个组件不向其客户或同行提供一致而稳定的抽象层，该组件就不适合于云计算。

　　标准部署单位是虚拟机，它本质上可运行于抽象硬件平台。人们很容易过度关注构建虚拟机映像，而忽视用来创建虚拟机映像的模式。在云计算中，维持该模式而非映像本身非常重要。该模式是保留下来的，而映像则是从该模式产生的。

　　虚拟机映像将始终在变化，因为虚拟机映像内的软件层将总是需要修补、升级或重新配置。不变的是创建虚拟机映像的流程，而且这是开发人员所应重视的。开发人员可以通过把 Web 服务器、应用程序服务器和 MySQL 数据库服务器层叠在一个操作系统映像上，应用补丁程序、配置更改，以及互连各层组件，来构建虚拟机映像。重视模式，而非虚拟机映像，可以通过重新把模式应用到一组新组件，根据需要来更新这些映像本身。

　　凭借这一标准部署单位，云架构设计师可以使用有助于以较低成本加快部署速度的设备。开发人员可以使用一个设备，该设备预配置为通过与该设备的 API 进行互动，在 OpenSolaris OS 上运行 Hadoop。架构设计师可以使用内容交换机，这些内容交换机不是作为物理设备部署的，而是作为虚拟设备部署的。部署该设备所需要做的一切事情只是与其 API 或 GUI 进行互动。即使生产带有许可证的商用软件的公司都在通过更加灵活、基于使用情况的许可模式来适应云计算。

　　无论是调用一个创建虚拟机映像的模式，还是定制一个设备，结果产生的虚拟机映像都需要存储在企业进行版本控制并提供支持的映像库中。

　　标准有助于解决复杂问题

　　云计算首先重视效率，因而采用少数标准和标准配置有助于降低维护和部署成本。拥有可简化部署的标准比拥有用于作业的非常好的环境更重要。80/20 规则就在这里发挥作用：云计算重视可以支持 80% 使用案例的少数标准。这就把经济情况从成本高的一次性实现转变为选择可最大限度地加以利用的构件。将来还会继续专业化，但起点应从标准开始。

　　对于要采用云计算的企业，标准可以包括虚拟机类型、标准虚拟机映像中的操作系统、工具以及支持的编程语言。

　　•虚拟机类型。想想虚拟机选择对于要支持的应用程序的影响。对于社交网站应用程序、出于安全性进行的隔离，以及出于可移植性进行的高水平抽象，会建议使用 Type II 虚拟机。对于高性能计算或可视化应用程序，需要直接访问硬件以实现非常好的性能，会建议使用 Type I 虚拟机。

　　•预安装、预配置的系统。必须像在物理服务器上一样维护虚拟机上的软件。操作系统仍然需要硬化、修补和升级。拥有一小组标准化的受支持配置，使开发人员可以使用当前支持的虚拟机。当升级支持的配置时，应设计要求自定义的模式，以便于容易地将更改重新应用到一个新的虚拟机映像。设备也是如此，其中，可以通过设备的标准 API 来配置当前版本。

　　•工具和语言。企业可能以标准方式使用 Java 编程语言和 Ruby on Rails;小企业可以以标准方式将 PHP 作为其用于构建应用程序的首选工具。当这些标准在云计算上下文中成熟时，它们开始形成下一层：把平台当作服务 (PaaS)。

　　虚拟化和封装技术支持重构

　　当通过组合和配置一组虚拟机映像和设备重构并创建应用程序时，要将重点放在特定虚拟机发挥什么作用上，而不是放在如何实现该虚拟机上。虚拟化和封装技术将实现细节隐藏起来，并使开发人员重新重视组件之间的接口和互动。这些组件应该提供标准接口，以便于开发人员方便快捷地构建应用程序，同时利用与性能或成本所要求的相似的功能来使用替代组件。

　　应用程序开发是有计划地完成的，甚至用来部署应用程序的程序也可以封装，以便于利用和重新利用。可以封装部署三层式 Web 基础设施的程序，这样，该程序的参数就会包括指向用于 Web 服务器、业务逻辑和数据库层的虚拟机映像的指针。然后就可以执行此设计模式，以便于部署标准应用程序，而不必重新设想或甚至重新考虑 (例如) 支持每层所要求的网络架构。

　　应用程序维护的云计算原则并非修补，而是重新部署。管理创建虚拟机映像的模式，而不是映像本身，简化了这种重新部署。部署之后发现的问题解决起来相当容易，或者通过更新组件虚拟机并调用用于重新部署的设计模式，来发布应用程序的新版本。当开发人员修补虚拟机时，只需要创建一个虚拟机映像，而且要有计划地复制并部署其余映像。应对虚拟机进行版本控制，以便于必要时回滚。

　　松散耦合、无状态、原地失败 (Fail-in-Place)

　　计算 几年以来，基于 Web 的应用程序已在向松散耦合和无状态转变。在云计算中，这些特征甚至更加重要，因为云计算具有更加动态的性质。应用程序映像不修补，它们是用完丢弃的对象，因而需要是无状态的。如果一个虚拟机失败，应用程序必须继续不间断地运行。应用程序之间的耦合需要是松散的，这样，任何组件发生故障都不会影响整个应用程序的可用性。一个组件应该做到“原地故障”，极少甚至不会对应用程序产生影响。

　　由于应用程序组件越来越具有临时性，因而不能包含存在时间超过任何应用程序实例的数据。应通过将状态推出软件来尽可能使应用程序无状态，从而尽可能地将处理与数据分开。能够做到这一点的技术包括：

　　• 以 Cookie 的形式将状态推出到用户，或者将状态代码编入 URL。

　　• 将状态下推至后端数据库

　　• 维护数据的补充副本，这是 Hadoop 使用的一个策略

　　•使用基于网络的持久性技术，例如，GlassFish 应用程序服务器中的.Terracotta 或

　　Shoal。

　　“原地失败”计算对操作活动的影响是，即使是硬件也应该是无状态的，以便于云正常工作。硬件配置应存储在元数据中，这样，在发生故障时就能够恢复配置。

　　水平扩展

　　云计算使得大规模水平可扩展性可以用于有条件利用的应用程序。现在出现一个设计并重构应用程序以在水平扩展环境中顺利工作的趋势，该趋势意味着越来越多的应用程序能够很好地适应云计算。

　　利用水平扩展的应用程序应该重视假如个别组件发生故障整个应用程序的可用性。多数云平台是在一个虚拟服务器资源池上构建的，其中，如果任何一个物理服务器发生故障，该服务器托管的虚拟机只是在一个不同的物理服务器上进行重构。把无状态和松散耦合的应用程序组件与水平扩展技术结合在一起，可促成一种“原地失败”策略，这种策略与任何一个组件的可靠性都没有关系。

　　水平扩展不必局限于单个云。根据应用程序数据的大小和位置，“超负荷”计算可用来扩展一个云的能力，以适应临时性工作负荷增加。在超负荷计算中，运行于专用云的应用程序可能会根据需要吸纳来自公用云的额外资源。

　　超负荷计算很大程度上取决于数据的数量和位置。如果是一个位于企业数据中心的专用云，而且该企业数据中心扩展为使用互联网上某个其它位置的一个公用云，需要移动到公用云的数据的数量需要分解为等式 (参阅下面的“数据物理”一节)。如果是一个驻留在与公用云提供商相同的托管场所的专用云，数据位置问题就会大大减小，因为几乎无限的自由带宽可以连接这两个云。

         版权声明：

　　本文由上海爱可生信息技术有限公司根据甲骨文公司官方文档翻译整理而成，版权归属甲骨文公司，转载请保留此版权声明。