网站可靠性工程中得3R：弹性、恢复性和可靠性

使用3R原则来设计一个可靠的应用程序

在我作为Capital One的弹性和网站可靠性工程（SRE）架构师的工作中，弹性、恢复和可靠性的概念对于架构成熟的应用程序至关重要。每个概念都建立在另一个概念的基础上，通过不同的视角提供体系结构考量的框架，从而共同实现更可靠的产品。

但首先，让我们先来加深对3R及其定义的理解。

定义弹性, 恢复和可靠性

1. 弹性是指通过快速响应故障并在故障后完全恢复来避免或减轻不良事件影响的能力。注重弹性通常意味着强调高可用性。这样可以增加正常运行时间。
2. 恢复是发生故障时恢复服务的能力。如上所述，恢复对于强大的弹性至关重要。恢复会直接影响恢复时间目标（RTO）和恢复点目标（RPO），恢复时间目标是指故障后应用程序恢复到正常服务水平的持续时间，而恢复点目标是指业务系统所能容忍的数据丢失量，以持续时间作为单位。由于需要确定所有可能的故障点的恢复方法，因此对恢复的关注通常会导致对设计时和运行时依赖性的充分了解。这样可以消除单点故障，并防止潜在的故障和数据丢失。
3. 可靠性是服务提供其预期功能的能力。正如Google for SRE所提出的那样，可靠性涉及许多概念，从技术执行到流程和文化。对可靠性的关注通常会使得稳定性与客户期望保持一致。 注意，这种情况下的稳定性还包括安全性。可靠的系统是高性能的，安全的并满足服务水平目标（SLO）的系统，从而逐渐建立起了信任。

利用3 R原则设计系统

接下来，让我们看一下如何将3R应用于系统设计。首先我们假设这是一个非常简单的AWS应用程序，其中计算层是为客户交易提供服务的Web层，数据库存储交易信息：

弹性视角

从 弹性 视角可以让我们检查此架构以考虑以下因素：

• 该应用程序能够水平扩容或者缩容以响应各种变化吗？
• 是否有足够的资源允许服务进行扩容？ 例如，子网是否具有足够的可用IP数？AWS的API速率限制是否会限制弹性？

这些思考可能导致如下的新架构：

我们的简单应用程序现已扩展为“高可用”架构：

1. 弹性 - 我们的单个EC2实例现在是“自动伸缩”组的一部分，这个功能使得EC2实例可以水平向上或向下进行伸缩，并使用负载均衡器作为应用程序流量的入口。负载平衡器可以在整个计算层上分配流量。 请注意，我们的VPC子网假定大小适当且未显示。
2. 高度可用的数据层 - 我们的单个RDS实例现在具有多可用区功能，在初始的主实例出现故障的情况下，它可以通过将只读副本提升为主实例来进行分布式读取和恢复过程 。

恢复视角

通过 恢复视角 可让我们鉴视此体系架构以获得其他额外的考虑：

• 可能的故障点是什么，我们将如何认识到？
• 哪些故障点是关键的，哪些不关键？
• 如何进行自动恢复，或者优雅降级并可能需要人工干预？
• 恢复的计划是什么，如何可以尽快恢复关键功能，随后再进行完全恢复？
• 故障转移策略是什么？
• 标准的恢复流程是什么，是否已经过测试？

这些考虑可能导致以下的架构变化：

我们的高可用、弹性应用程序现在通过工具和服务生态系统得到了增强，以支持恢复功能：

1. 设计时 - 自动化旨在支持对应用程序代码以及基础设施及其配置的更新（补丁，还原）。例如，Code Commit可以存储版本控制的源代码，然后可以通过CodeDeploy将其作为应用程序更新部署到CloudFormation提供的基础架构上。
2. 可观测性 - 启用Telemetry（包括日志，指标，链路追踪）以支持故障排除、调试和还原的所需的信息。例如，CloudWatch可用于指标监控、日志和警报，X-Ray用于调用链追踪，而Personal Health Dashboard可以帮助监视AWS服务问题。
3. 恢复 - 通知工程师或触发自我修复行动的标准操作程序和机制。例如，作为活文档的最新清单可以帮助指导程序化流程，电子邮件可以将通知传达给工程师，并且Aws SNS可以用来触发自我修复行为。 注意，图中未显示自我修复操作（例如自动脚本）。

可靠性视角

从 可靠性 角度看可以使我们检查架构设计，以考量其他事项，比如：

• 这些投入是否能满足客户的预期需求？换句话说，关键交易的SLO是什么？是否需要更多冗余？一个可用区足够吗？
• 安全隐患是什么？如何实现更高的安全性？
• 根据客户的期望，性能要求是什么？ 资源规模是否合适？ 是否进行了性能测试？
• 根据客户的期望，架构成本是否完全清楚？ 当前的资源配置是否最大程度地提高成本效率？

这些考虑可能导致以下情况：

现在通过一系列提高可靠性的工具和服务生态系统，我们的可恢复、弹性系统得到了增强：

1. 成本优化 - 能够跟踪一段时间内的成本使用情况，以便针对资源管理采取纠正措施。
2. 安全 - 启用保护基础结构和提供防护栏的能力。例如，IAM允许以最低特权进行访问身份验证和访问管理，Inspector允许漏洞检测和管理，KMS允许静态加密，VPC接入允许访问AWS API的流量保持在AWS骨干网内，还有VPC Flow Logs和Cloud Trail可以让我们查看和检测异常。

在应用程序中的3R原则

对弹性，恢复性和可靠性扎实透彻的了解对于设计可靠的应用程序至关重要。通过其中每一个角度来审视体系结构都有助于充分得考虑全局因素，以制定出综合全面的体系结构决策，从而实现高可用、可恢复以及提高稳定性。需要注意的是，在制定每个决策时，都需要权衡成本和复杂性。因此，实现弹性、可恢复性和可靠性的体系结构之前，我们必须首先了解和定义客户对可靠性的实际期望，这是一切努力的起点。

例如，如果客户只要求任一一笔交易是高可用和可靠的，那么对弹性、恢复和可靠性的投资和努力应该集中在支持该笔交易的组件或服务上，而不需要让构成应用程序的所有组件都满足要求。

我鼓励大家在以后的架构设计中都能够从弹性，恢复和可靠性这三个方面来审视所构建的系统。