非功能性指标

可用性availability

可用性是某项服务或基础设施在正常情况下对客户可访问并运行的时间百分比。例如，如果一个服务的可用性为 100％，这意味着该服务始终按预期方式运行并响应。

A(percent)=(TotalTime−AmountOfTimeServiceWasDown)TotalTimeA(percent) = \frac{(TotalTime - Amount Of Time Service Was Down)}{TotalTime}A(percent)=TotalTime(TotalTime−AmountOfTimeServiceWasDown)​

我们将可用性度量为几个九。以下表格显示了在使用给定数量的九时允许的停机时间。

Availability	**Downtime per Year **	**Downtime per Month **	**Downtime per Week **
90% (1 nine)	36.5 days	72 hours	16.8 hours
99% (2 nines)	3.65 days	7.20 hours	1.68 hours
99.5% (2 nines)	1.83 days	3.60 hours	50.4 minutes
99.9% (3 nines)	8.76 hours	43.8 minutes	10.1 minutes
99.99% (4 nines)	52.56 minutes	4.32 minutes	1.01 minutes
99.999% (5 nines)	5.26 minutes	25.9 seconds	6.05 seconds
99.9999% (6 nines)	31.5 seconds	2.59 seconds	0.605 seconds
99.99999% (7 nines)	3.15 seconds	0.259 seconds	0.0605 seconds

可靠性Reliability

可靠性， R ，是指服务在指定时间内执行其功能的概率。 R 衡量服务在不同操作条件下的表现。

我们经常使用故障间隔时间（MTBF）和修复时间（MTTR）作为衡量 R 的指标。

我们努力追求更高的 MTBF 值和更低的 MTTR 值。

可伸缩性Scalability

可伸缩性是系统处理增加的负责而不影响性能的能力。例如，搜索引擎必须适应增加的用户数量，以及索引的数据量。

负载类型

负载分为：

1. 请求负载
2. 存储负载

扩展维度

可伸缩性的不同维度：

1. 大小可扩展：如果我们可以简单地向系统添加额外的用户和资源，则系统在大小上是可伸缩的。
2. 管理可扩展：这是指越来越多的组织或用户能够轻松共享单个分布式系统的能力。
3. 地理可扩展：这涉及程序如何在保持可接受性能约束的同时轻松适应其他地区。换句话说，系统可以轻松地为广泛的地理区域提供服务，也可以为较小的地区提供服务。

扩展的方式

扩展的不同方式：

1. 垂直扩展：垂直扩展，也称为“横向扩展”，是指通过为现有设备提供额外功能（例如额外的 CPU 或 RAM）来进行扩展。垂直扩展允许我们扩展当前的硬件或软件容量，但我们只能将其扩展到服务器的限制。垂直扩展的成本通常很高，因为我们可能需要使用特殊组件来进行扩展。
2. 水平扩展：水平扩展，也称为“横向扩展”，指的是增加网络中的机器数量。我们使用商品节点来实现这一目的，因为它们具有吸引人的成本效益。关键在于我们需要构建一个系统，让许多节点共同工作，就好像我们拥有一个单一的巨大服务器一样。

可维护性Maintainability

除了建立系统之外，之后的主要任务之一是通过查找和修复错误，添加新功能，保持系统平台更新，并确保系统运行顺畅来保持系统的运行。定义这种卓越系统设计要求的一个显著特征是可维护性。

可维护性分为三方面：

1. 可操作性：这是指在正常情况下，我们可以确保系统平稳运行并在故障情况下实现正常条件的便捷程度。
2. 清晰度：这指的是代码的简单性。代码基础越简单，理解和维护就越容易，反之亦然。
3. 可修改性：这是系统集成修改、新功能和意外功能的能力，无需任何麻烦。

可维护性， M ，是指服务在故障发生后恢复其功能的概率。 M 衡量了服务恢复正常运行状态的便利程度和速度。

例如，假设一个组件在半小时内具有 95%的可维护性值。在这种情况下，将该组件恢复到完全活跃状态的概率为 0.95。

我们使用（平均修复时间）MTTR 作为衡量 M 的指标。

MTTR 是修复和恢复故障组件所需的平均时间。我们的目标是尽可能降低 MTTR 的值。

容错性Fault tolerance

容错性是指系统即使其中一个或多个组件出现故障，仍能持续执行的能力。在这里，组件可以是软件或硬件。构想一个百分之百容错的系统在实际中非常困难。

实现容错性相关的手段

复制 Replication

最广泛使用的技术之一是基于复制的容错技术。通过这种技术，我们可以复制服务和数据。我们可以用健康的节点替换失败的节点，用其副本替换失败的数据存储。一个大型服务可以在不影响最终客户的情况下透明地进行切换。

我们在不同的存储中创建数据的多个副本。所有副本都需要定期更新，以确保数据一致性。在数据更新时，更新副本是一项具有挑战性的工作。当系统需要强一致性时，我们可以同步更新副本中的数据。然而，这会降低系统的可用性。当我们可以容忍最终一致性时，我们也可以异步更新副本中的数据，这会导致过时读取，直到所有副本收敛。因此，在这两种一致性方法之间存在权衡。在失败情况下，我们要么牺牲可用性，要么牺牲一致性——这是 CAP 定理中所概述的现实。

检查点CheckPoint

检查点是一种技术，它将系统状态保存在稳定存储中，以便在发生错误或服务中断导致故障时进行后续检索。检查点是一种容错技术，在不同时间间隔的许多阶段执行。当分布式系统发生故障时，我们可以从先前的检查点中获取最后计算的数据，并从那里开始工作。

检查点是以这样一种方式为系统中的不同个体进程执行的，以便它们代表系统实际执行的全局状态。根据状态，我们可以将检查点分为两种类型：

1. 一致状态：一个状态是一致的，当系统的所有个体进程对系统中发生的共享状态或事件序列有一致的视图时。在一致状态下拍摄的快照具有一致的数据状态，代表系统的可能情况。为了使检查点一致，通常需要满足以下标准：
   1. 所有在检查点之前完成的数据更新都会被保存。任何正在进行中的数据更新都会被回滚，就好像它们没有启动一样。
   2. 检查点包括截至检查点之前发送或接收的所有消息。 为避免消息丢失的情况，没有消息正在传输中
   3. 系统组件之间的关系和依赖以及它们的状态与正常运行期间预期的情况相匹配。
2. 不一致的状态：这是一个系统中不同进程的保存状态存在差异的状态。换句话说，不同进程之间的检查点不是一致和协调的。