【可靠性架构】可靠性架构第1部分：概念

可靠性

本故事的目标是提供可靠性的最佳实践来管理您的云环境。尽管它引用了AWS和Cloud，但这些原则同样适用于其他云提供商和内部环境。

本故事将分为三个部分。

• 第1部分-描述各种术语和最佳实践的概念
• 第2部分-云的弹性和可用性设计模式
• 第3部分—实现特定SLA的高可用性体系结构

本故事集中在第1部分

AWS于2015年发布了良好架构框架，并描述了良好架构原则的五大支柱，即

• 可靠性
• 安全
• 性能效率
• 成本优化
• 卓越运营

本故事侧重于可靠性支柱，提供了可靠性的要点，以供快速参考，并基于AWS白皮书和Microsoft云设计模式。

可靠性集中在以下方面

• 能够从基础设施/服务故障中恢复
• 快速获取需求资源以满足需求的能力
• 缓解配置和瞬态网络问题

可用性

可用性=正常运行时间/总时间，表示为正常运行时间的百分比，例如99.99%。简而言之，以9的数量表示，例如99.999表示为五个9

作为快速参考，99%的可用性意味着每年3天15小时的停机时间，99.999%意味着每年5分钟的停机时间。要计算特定值，请使用链接https://uptime.is/99.9或结账https://en.wikipedia.org/wiki/High_availability

如果存在相关性，则可用性是系统可用性和从属系统可用性的乘积。例如，如果系统A具有99.9%，系统B具有99.9%，并且A依赖于B，则聚合系统的可用性为99.9*99.9=99.8%

如果系统存在冗余，则正常运行时间计算为100减去组件故障率的乘积。例如，如果可用性为99.9，则故障率为0.1%，由此产生的可用性为100减去（0.1*0.1）=999.99%，这表明由于冗余而增加了可用性。

有时可能不知道依赖项的可用性。如果我们知道平均故障间隔时间（MTBF）和平均恢复时间（MTTR），那么可用性=MTBF/（MTBF+MTTR）。例如，MTBF为150天，MTTR为1小时，则可用性为99.97%。使用链接对此进行更深入的了解。

实现最高级别的可用性意味着部署/容量添加/回滚等方面的系统成本和复杂性更高。即使没有使用所有功能，也通常会为已建立的系统支付更高可用性的费用。必须考虑成本，小心制定正确的可用性目标。

弹性网络设计-关键指南

• 在设计VPC和子网CIDR块时，考虑到所有对等可能性、本地重叠、Lambdas/ELB所需的IP数量等，考虑到未来的情况。
• 为VPN连接和直连使用冗余
• 利用AWS Shield、WAF、Route 53等AWS服务防止DDoS攻击

高可用性应用程序设计

为“五个9”或更高的HA进行设计需要极端的考虑。许多服务提供商和软件库的设计并不是为了提供这样的数量，这需要添加多个服务提供商，避免单点故障和定制开发，以及操作的极端自动化和彻底的故障测试。

应用程序必须处理的一些中断类型如下

• 硬件故障
• 部署失败
• 增加的负载
• 意外的输入错误
• 凭据/证书过期
• 依赖项失败
• 电力等基础设施故障

所有这些故障都必须得到处理，恢复必须自动化。这意味着实现HA的工作不是微不足道的，并导致了可用性目标需求的细化。这可能是因为某些交易必须比其他交易更可靠，高峰时间、地理差异等。。

了解可用性需求

整个系统不需要设计为高可用性。例如，实时操作可能比批处理更重要，非高峰时间可能对可用性有容忍度，数据平面与控制平面，例如，现有EC2的健康状况和操作可能比能够启动新实例更重要，等等。

应用程序可用性设计

通过利用经验证的实践，可以显著提高应用程序可用性。以下原则指导HA的应用程序设计

• 故障隔离区：通过利用AWS可用区和区域，可以将影响降低到特定区域。跨区域利用复制技术可降低数据丢失的风险
• 冗余：避免单点故障是关键。构建对单个断层带故障具有弹性的软件非常重要
• MicroServices：通过使用MicroServices架构构建，我们可以区分不同组件之间的可用性需求。架构中存在权衡，请查看https://martinfowler.com/articles/microservice-trade-offs.html
• 面向恢复的计算：减少恢复影响时间至关重要。恢复程序基于影响而不是发生的问题类型。在某些情况下，如EC2，终止它并让ASG生成一个新实例可能比试图确定确切的问题并修复要好。定期测试恢复路径对于始终评估程序的有效性至关重要
• 分布式系统最佳实践：分布式系统的一些最佳实践包括：节流（速率限制）、在返回故障之前重试一定次数、在特定条件下快速失败、确保处理一次的Idemptency令牌、保持服务始终以恒定工作预热、检查依赖性可用性的断路器、，静态稳定性，以确保系统在故障期间工作更少，而不是使系统进一步过载

可用性的操作注意事项

规划应用程序整个生命周期中使用的自动化或人工工作流非常重要。测试是输送管道的重要组成部分。除了单元和功能测试外，性能测试、持续负载测试和故障注入测试也很重要。操作准备审查，必须评估测试、监控的完整性，并能够根据SLA审计应用程序性能

自动化部署

使用高级部署技术，如

• 金丝雀：通过监控影响，逐步引入更改并向前和向后移动
• 蓝-绿：立即建立一个并行的新堆栈和交换流量（并根据需要快速回滚）
• 功能切换-使用配置选项通过根据需要打开/关闭来部署新功能
• 故障隔离区部署：使用故障隔离区隔离部署并围绕区域故障规划容量

测试

测试必须符合可用性目标。单元测试、负载测试、性能测试、故障测试和外部依赖性测试是必要的。

监控和警报

监控需要有效检测故障并发出警报。您最不希望的是客户在您之前知道问题。监控和警报系统应与主要服务分离，服务中断不应影响监控和警报。

监测分为五个阶段

产生

确定需要监控的服务、定义度量、创建阈值和相应警报。几乎所有AWS服务都提供大量监控和日志信息供用户使用。例如Amazon ECS和AWS Lambda流日志到CloudWatch日志，VPC流日志可以在VPC中的任何或所有ENI上启用

聚合

Amazon CloudWatch和S3是主要的聚合层。一些服务（如ASG和ELB）提供开箱即用的度量，其他流服务（如VPC流日志/CloudTrail事件数据）被转发到CloudWatch日志，这些日志可以被过滤以提取度量。这可以提供触发警报的时间序列数据。

实时处理和报警

警报可以与多个用户的SNS集成，或发送到SQS进行第三方集成，或使用AWS Lambda立即采取行动。

存储和分析

CloudWatch日志可以将日志发送到AmazonS3，EMR可以用于进一步了解数据。Splunk/Logstash等第三方工具可用于聚合/处理/存储和分析。数据保留要求是关键，旧数据可以移动到AmazonGlacier进行长期存档。

作战准备审查（ORR）

ORR对于确保应用程序可用于生产非常重要。团队需要有一份初始ORR检查表，必须重复以验证准确性。一个团队的ORR必须结合从其他应用中吸取的经验教训。

审计

审核监控方面以验证可用性目标至关重要。根本原因分析需要发现发生了什么。AWS提供以下服务以跟踪事件期间的服务状态

• CloudWatch日志：存储日志并检查
• AWS配置：随时查找基础设施的状态
• AWS CloudTrail：查找由谁调用了哪些AWS API

请继续关注第2部分—高可用性体系结构，以实现特定的SLA

工具书类

• 架构良好的框架