通过集群化、复制、快照、微服务和应用程序设计来提高企业工作负载的应用程序弹性和可用性。

应用程序的弹性和可用性是现代企业工作负载的关键属性。应用程序需要在硬件故障发生后，扛过服务故障(例如负载平衡器和域名系统错误)保持工作状态，并且可以忍受局域网和互联网中断的影响。每个事件都可能会影响业务收入、声誉甚至法规的符合性。以下五种方法帮助您增强应用程序弹性和服务可用性。

集群化增加应用程序弹性

群集几乎是最普遍的用于增强应用程序的弹性、性能和可用性的方法。应用程序的某一实例拥有的吞吐能力是有限的—它只能在给定的时间内做一定量的工作。如果您推送的应用程序超出其容量—期望其每秒处理的比其可以处理的事务更多—应用程序将遭遇性能降低甚至是崩溃并变得无法工作。该应用程序工作负载的每个附加实例可以增加应用程序的有效容量，并允许集群实现比单个工作负载实例能够处理更多的工作。这是可扩展性聚类的概念。如果企业需要从应用程序获得更多的工作能力，您可以将更多负载平衡的节点部署到应用程序集群。

但附加的节点将增强应用程序的可用性，这对于应用程序高可用性(HA)相当关键。如果某一节点出现故障，则集群中的其他节点将共享计算负载。负载平衡器可以识别故障节点，并将应用流量重新分配给其余节点。这样一来该应用程序仍然可工作。在很多情况下，用户永远都不会注意到这一问题。节点可以在同一数据中心本地，也可以分布在不同的数据中心，以防止可能出现的设施故障、互联网中断和其他潜在的威胁。

RAID和复制是存储可用性的基础

RAID仍然是存储可用性的重要特性。RAID 0(条带化)不提供数据保护，而是将数据分散到多个磁盘上，同时主轴用以提高存储性能。RAID 1(镜像)将一个磁盘的数据复制到另一个磁盘。如果一个磁盘发生故障，则副本可无缝地接管，您可以从工作副本中替换和重建发生故障的磁盘。RAID 5在多个磁盘或RAID组之间分散数据和奇偶校验。如果磁盘发生故障，剩余的奇偶校验信息可以重构丢失的数据，并重建有缺陷的磁盘的内容。这样可以保护存储设备组免受单磁盘故障的影响。RAID 6也可在多个磁盘间分散数据，但包含双层奇偶校验信息。这可以容忍和重建两个同时的磁盘故障——该技术被称为双重奇偶校验。

您还可以将RAID技术进行组合以实现多重优势。例如，将RAID 5或RAID 6组(RAID 1)镜像到第二个磁盘组，其结合了性能并确保在重建故障磁盘时快速访问数据。您可以制定最适合每个给定业务应用程序的存储保护方案。

复制可以在兼容的存储子系统之间进行，但IT经常使用它从一个数据中心站点定期复制数据到辅助站点或公有云——即某一非现场或远程位置，可以帮助防止数据丢失一个严重的设施问题。您可以在本地存储资源之间同步执行复制，其中延迟不是重要因素，或远程存储资源之间的异步执行，其中延迟可能很大。您可以同时使用和复制RAID。

快照和迁移提供的灵活性

虚拟化技术允许您在数据中心服务器上配置、部署和管理现代企业应用程序作为虚拟机。虚拟机提供了巨大的灵活性，因为与物理服务器相比，计算资源的利用率更高，同时也保证了共享同一物理系统的每个虚拟机的充分逻辑隔离。即使虚拟机砸死服务器内存空间中作为映像存在，但仍然必须保护这些映像不受服务器故障和应用程序崩溃的影响，从而可能危及虚拟机并导致应用程序无法使用。

然而，并不是所有的工作负载都那么重要，可以证明在集群和其他应用程序可用性选择方面的投资。快照是在服务器内存中将虚拟机的时间点状态复制到存储中的文件的常见方法。您可以经常捕获并轻松恢复快照——将应用程序恢复到当时时间点的状态。通常情况下，应用程序中断时IT人员使用快照进行应用程序回滚和快速恢复。您还可以使用快照创建重复的应用程序实例——通常用于应用程序测试、开发和评估。

在数据中心内或远程数据中心之间的虚拟化服务器之间迁移虚拟机非常简单。迁移通常用于工作负载平衡等任务。这允许IT管理员调整固定服务器上的工作负载数量，以优化可用的计算资源或通过将工作负载移动到具有更多计算资源可用性的另一台服务器来提高应用程序性能。为了防止工作负载中断，在监控和管理工具检测到该服务器运行状况的问题时，先将VM从服务器迁移出去。您还可以手动调用迁移以在服务器上执行例行维护过程。

微服务和容器为虚拟化提供新的机会

应用程序设计的一大新兴趋势是放弃传统的单片设计并将应用程序重新映射为使用API传达命令和数据的更小的“无状态”功能或服务的集合。这就是微服务的方法。您可以分别构建、测试、部署和扩展每个组件。而且由于每个组件都是无状态的，所以一个组件的故障或故障不会导致整体应用中严重的数据丢失或不稳定;您可以简单地重新启动某一出现问题的组件。

更新微服务应用程序更加容易。尽管单片应用程序更新将需要完整的功能回归测试，但组件更新只需要测试该特定组件。由于组件是独立存在的，因此在单片应用程序中经常存在的相互状态关系并不存在而无需测试。

构成微服务应用程序的组件经常部署到虚拟化容器之中。容器是用于提供服务器资源的替代化虚拟化技术。每个虚拟机提供完全隔离的操作环境，每个容器共享相同的底层操作系统、驱动程序和其他依赖项。这种共享方法使每个容器的体积之小和资源有效性都达到极限，允许更多容器驻留在同一台服务器上。容器可被快速创建和销毁，因此您可以根据需要对构成微服务应用程序的组件进行启动和扩展。

在设计阶段预先构造应用程序弹性

应用程序弹性通常涉及工作负载在其某一或多个组件中发生故障后的生存能力，以及仍可为业务及其用户提供最佳可能的服务的程度。这意味着您本应将可用性集成到现代应用程序的设计和测试阶段之中。

更新微服务应用程序更加容易。尽管单片应用程序更新将需要完整的功能回归测试，但组件更新只需要测试该特定组件。由于组件是独立存在的，因此在单片应用程序中经常存在的相互状态关系并不存在而无需测试。

构成微服务应用程序的组件经常部署到虚拟化容器之中。容器是用于提供服务器资源的替代化虚拟化技术。每个虚拟机提供完全隔离的操作环境，每个容器共享相同的底层操作系统、驱动程序和其他依赖项。这种共享方法使每个容器的体积之小和资源有效性都达到极限，允许更多容器驻留在同一台服务器上。容器可被快速创建和销毁，因此您可以根据需要对构成微服务应用程序的组件进行启动和扩展。

在设计阶段预先构造应用程序弹性

应用程序弹性通常涉及工作负载在其某一或多个组件中发生故障后的生存能力，以及仍可为业务及其用户提供最佳可能的服务的程度。这意味着您本应将可用性集成到现代应用程序的设计和测试阶段之中。

应用程序灵活性讨论的一部分以应用程序架构和设计为中心。微服务器方法只是构建复杂高度可扩展应用程序的新兴设计范例的一种流行演示。自动化以及编排提供扩充组件，并根据流量需求随时间变化自动平衡负载提供了相应能力。例如，如果较大应用程序的一个组件或功能需要处理更多的流量请求，那么您可以复制该组件(仅复制该组件)来处理额外的流量。

弹性应用程序设计的思考

弹性的应用程序设计，如微服务器，需要重新关注测试和审查每项对应用程序的更改。了解每个组件、模块、服务或依赖关系的损失将如何影响应用程序的整体可用性。如果应用程序在测试期间不符合既定目标，则不应将其发布到生产环境中。有时，您必须改进相关服务或依赖关系(如存储)的可用性，以满足应用程序的可用性目标。

您还必须评估应用程序的安全性，作为用户授权和对外部和内部攻击的硬度的测量方法。衡量业务数据的安全性，并确保只有授权用户可以访问应用程序的数据，并保护数据免遭丢失或被盗。这可能包括某种形式的身份和访问管理框架，以及在运行和非运行状态下一定级别的数据加密。

此外，评估应用程序的可扩展性，以确定如何轻松地扩展工作负载以满足流量需求。现代模块化应用程序往往更加容易进行扩充，因为通常可以通过更少的计算资源来更快地(通常是自动的)部署其他组件并平衡负载。

所有这些概念经常伴随着综合的应用程序性能管理工具，旨在帮助您了解工作负载在生产环境中如何执行其设计目标。

应用程序也经常设法接受无状态设计。基本上，无状态功能从外部获取所需要的所有数据，执行其各自的任务，然后将其结果传递给用户或其他功能——不考虑模式、选集、选择或配置偏好对功能行为的负面影响。如果功能发生故障，您可以简单地重新启动它，而免受数据损失数据的风险。

作者：Stephen J. Bigelow

来源：51CTO