开源云计算架构介绍（三）

第3章 实现 IaaS 必须考虑的架构问题

不断发展的应用程序架构

正如我们已经说明的：云计算是当前趋势和非常好的做法的自然延伸，从架构观点看云计算也是如此。再次强调，云计算并非新生事物，不过在其实现中，云计算改变我们所做的一切工作。

变革架构的途径

在 20 世纪 90 年代，人们谈论的话题是关于如何把一个应用程序分解成各种组件，然后是如何将这些组件部署到不同的服务器上，以便优化非功能要求，包括可扩展性、可用性、易管理性和安全性。现在，我们所维持的是一个分解式应用程序架构，同时实际部署到一个利用虚拟化的整合式架构上。

云计算通过提供一种有计划地部署应用程序架构的方法来继续这一趋势，最终实现一个动态数据中心的承诺。在云计算中，效率受到高度重视;如果无法快速而有计划地部署应用程序架构，那么该应用程序就可能不是一个适合于此种模式的应用程序。

变革应用程序设计

过去，应用程序设计为通过垂直扩展来处理大型工作负载。将更多处理器和内存安装在一个邮件服务器上来处理更大的流量。扩展数据中心服务器以提高吞吐量。在超级计算机上运行高性能计算作业。

从高度可扩展的对称型多处理器迁移到价格低廉但可扩展性差的 x86 架构服务器已经对应用程序设计产生了影响。开发人员并不期望应用程序运行于高度可扩展的服务器，而是重构其应用程序，以便能够在多个服务器之间进行水平扩展。此应用程序重构并不总是容易进行的，因为应用程序及其数据都必须进行设计，这样才能把处理和数据同时分解成为较小的数据块。这一已有架构趋势已经成为推广云计算的一个关键因素。这一趋势的示例包括：

高性能计算

高性能计算 (HPC) 工作负荷已经在光金属 (Bare-Metal) 计算网格上运行有一段时间了，这是通过应用程序重构实现的。例如，科学家已经找到为像 3D 气候建模这样的应用程序削减数据的方法，因而可以在许多服务器上展开应用程序。网格计算 (Grid Computing) 是云计算的“前辈”，这是因为网格计算使用工具来供应和管理多架物理服务器，这样，这些服务器就可以共同配合来解决一个问题。由于具有极高的计算、互处理通信和 I/O 需求，HPC 工作负荷非常适合于作为服务提供基础设施的云，尤其是提供对 I/O 设备进行更直接访问的光金属服务器或 Type I 虚拟机。

数据库管理系统

数据库管理系统通过水平扩展数据库服务器并在其之间对表进行分区，已经适应于在云环境中运行。此技术 [称为“分片”(Sharding)] 使多个数据库软件实例 (通常是 MySQL 软件) 可以在云环境中扩展性能。应用程序现在不是访问单个中央数据库，而是访问多个数据库实例中的一个，具体取决于哪个“碎片”(Shard) 包含所需数据 (图 7)。

CPU 密集型处理

执行像帧渲染 (Frame Rendering) 这样的活动的应用程序已经设计为不是为每个帧创建一个新线程，而是创建一个单独的虚拟机来渲染每个帧，因而通过水平扩展来提高性能。

数据密集型处理

开放源社区正在开发一般化工具，这些工具可帮助处理大量数据，然后将结果聚集到相应的进程中。例如，Hadoop 就是 MapReduce 问题的一种开放源实现，这种实现将“工人”(Worker) 虚拟机与他们所需的数据的部署集合在一起。

目标仍然相同

应用程序架构方面的许多进步都有助于促进云计算的推广。这些进步有助于支持高效地部署应用程序的目标，同时有助于使应用程序具有弹性，并适度地自动扩展。然而，杰出应用程序架构的首要目标始终没有发生任何变化：那就是支持同样的始终至关重要的特征：

?可扩展性。此特征的重要性始终未曾改变。为云计算设计的应用程序需要根据工作负荷需求进行伸缩，这样，性能及与服务水平的符合性就保持适当。为了达到这一点，必须将应用程序及其数据松散耦合，以使可扩展性最大化。“弹性”这一术语经常适用于伸缩云应用程序，因为云计算应用程序必须不仅可以扩展，而且必须在工作负荷减小时能够缩小，以免抬高在云中的部署成本。

?可用性。无论应用程序是向社交网站用户提供服务，还是管理大型制造企业的供应链，互联网应用程序用户都期望这些应用程序每时每刻都能正常运行。Sun 公司在此领域的行业领先地位早在其推出 SunToneSM 认证计划时就已确立，该计划有助于客户证明其应用程序和服务达到要求的可用性水平。

?可靠性。随着时间的推移，对于可靠性的重视程度已经发生转变。如果大型应用程序是指大型对称多处理系统，那么可靠性就意味着系统组件极少发生故障，而且即使发生故障，也可以在不中断系统正常运行的情况下进行更换。现在架构适应此特征的方式是把应用程序设计为：即使分解运行应用程序的一个或多个服务器或虚拟机，应用程序仍能继续运行，而且其数据不会受到破坏。正是在这个方面，我们曾经担心个别服务器组件发生故障，而现在我们构建即使全部服务器发生故障也不会造成破坏的应用程序。

?安全性。设备需要只对获得授权且通过身份验证的用户提供访问权，而且这些用户需要能够确信其数据是安全的。无论应用程序帮助各个互联网用户准备其纳税申报表，还是应用程序在公司及其供应商之间交换保密信息，都是如此。现今环境中的安全性是通过如下手段确立的：利用严格的身份验证、授权和帐号管理程序，确保静止和移动中数据的安全性，锁定网络，以及硬化操作系统、中间件和应用软件。安全性是这样一个系统特性，以至于我们不再单独强调安全性.―.必须将安全性融合到应用程序的各个方面以及应用程序部署和操作架构和进程中。

?灵活性和敏捷性。这些特征越来越重要，因为商业机构发现他们必须通过提高向客户提供应用程序的速度来更快地适应不断变化的经营环境。云计算强调通过利用最适合的构件 (Building Block) 来快速完成工作，使应用程序非常快速地面市。

?可维护性。一旦部署一个应用程序，就需要对其进行维护。过去，可维护性意味着使用的服务器可以在不停机或极少停机的情况下进行修理。现在，可维护性是指，更新甚至更换一个应用程序的基本基础设施组件时，不会破坏该应用程序的特征，其中包括可用性和安全性。

? 效率。这是特征列表上的新特征，或许这是最能将云计算模式与其它计算模式区别开来的一个特征。效率是云计算的意义所在，而且如果不能方便快捷地在云中部署应用程序，即使可从模式中受益，该计算模式也可能不是一个良好的可选模式。例如，企业资源规划应用程序可能最适合于垂直扩展的系统，并可能在近期通过 SaaS 提供。不过，提取、处理和呈现这些系统中派生的数据的应用程序可能非常适合于在云中部署。

一致而稳定的抽象层

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

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

虚拟机映像将始终在变化，因为虚拟机映像内的软件层将总是需要修补、升级或重新配置。不变的是创建虚拟机映像的流程，而且这是开发人员所应重视的。开发人员可以通过把 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。

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

水平扩展

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

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

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

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

（编辑：PHP编程网 - 湛江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!