可靠性
假设你为医疗保健组织运行一个临床系统。 临床医生和护理人员几乎不能忍受任何停机。 他们需要全天候访问临床 IT 系统，确保始终提供最高质量的医疗服务。
为了满足临床医生的全天候需求，应用程序必须能够在对用户造成最小影响的情况下处理故障。 在发生局部事件和大规模灾难时，如何使确保应用程序保持正常运行？
本单元将介绍如何在体系结构设计中包含可靠性支柱中的元素。
什么是可靠性？
在复杂应用程序中，任何数量的组件都可能发生任何规模的故障。 单个服务器和硬盘驱动器可能会发生故障。 部署问题可能无意中删除数据库中的所有表。 整个数据中心可能变得不可访问。 勒索软件事件可能恶意加密你的所有数据。 你的应用程序不仅要保持可靠，还要能够处理具有局部性影响和广泛影响的事件，这一点至关重要。
可靠性设计包括在遇到小规模事件和暂时性状况（例如部分网络中断）时保持正常运行。 通过将高可用性集成到应用程序的每个组件，可以确保应用程序能够处理局部故障。 此应用程序设计消除了单一故障点。 此类设计还能尽量减轻基础设施维护造成的影响。 通常情况下，高可用性设计旨在快速自动消除事件的影响，确保系统可以在不受多大影响或根本不受影响的情况下继续处理请求。
可靠性设计还侧重于在发生数据丢失和大规模灾难后进行恢复。 若要从这些类型的事件中恢复，通常需要进行积极的干预，不过，自动恢复步骤可以缩短恢复所需的时间。 此类事件可能会导致一定时间的停机或永久性数据丢失。 灾难恢复与执行相关，但也离不开精心的规划。
在体系结构设计中包含高可用性和可恢复性，可在发生停机和数据丢失时防止企业遭受经济损失。 它们还可以保护你的企业免受客户失去信任而导致的声誉损失。
可靠性的构建可确保应用程序符合你对客户做出的承诺。 你想要确保系统对最终用户可用，并且可以从任何故障中恢复。
构建高可用性体系结构
在可用性方面，需要确定承诺的服务级别协议 (SLA)。 检查应用程序中与 SLA 相关的潜在高可用性功能，并确定 SLA 的涵盖范围是否适当，以及是否需要做出改进。 你的目标是向体系结构的各个组件添加冗余，以尽量减少服务中断。
高可用性设计组件的示例包括群集和负载均衡：
群集是使用一组协调的 VM 取代单个 VM。 当一个 VM 发生故障或不可访问时，服务可以故障转移到另一个能够为请求提供服务的 VM。
负载均衡将请求分散在服务的多个实例上，检测有故障的实例，并阻止将请求路由到这些实例。
生成可以从故障中恢复的体系结构
在可恢复性方面，应通过执行分析来检查可能的数据丢失和重大停机情况。 你的分析应该包括考察每个恢复策略及其在成本/效益方面的利弊。 本练习将提供组织中优先事务的重要见解，并帮助阐明应用程序的角色。 分析结果应包括应用程序的以下持续时间值：
恢复点目标 (RPO)：可接受数据丢失的最长持续时间。 RPO 以时间为单位进行度量，而不以数量为单位进行度量。 例如，“30 分钟的数据”、“4 个小时的数据”等等。 RPO 与限制数据丢失以及在数据丢失后进行恢复相关，与数据失窃无关。
恢复时间目标 (RTO)：可接受停机的最长持续时间，其中规范定义了“停机”。 例如，如果发生灾难时可接受的停机持续时间为 8 小时，则 RTO 为 8 小时。
定义 RPO 和 RTO 后，可以根据这些目标将备份、还原、复制和恢复功能设计到体系结构中。
每家云提供商都会提供一套可用于改善应用程序可用性与可恢复性的服务和功能。 如果可能，请使用现有的服务和最佳做法，尽量避免自行创建。
硬盘驱动器可能发生故障，数据中心可能变得不可访问，黑客可能发起攻击。 必须使用可用性与可恢复性向客户保持良好的声誉。 可用性侧重于在遇到网络中断等状况时如何保持正常运行，可恢复性侧重于在发生灾难后如何检索数据。