对于系统的性能评估，我们需要一些通用的标准来进行衡量，这篇文章我们会从普遍的角度来谈谈什么是系统的性能衡量指标
"性能"是系统设计中一个重要的概念，同时也是系统设计对所有工作角色都常见的面试主题。
直观地说我们希望我们的服务快速，为了确保每个用户都有这种体验，我们需要精确地衡量“快速”的含义。
在本文中，我们会覆盖三个衡量系统性能的标准（延时，吞吐，可用）并且在系统设计中进行优化。
延时是传递单个消息所需要的时间，以毫秒（ms）为单位。
这个概念可以应用于请求与传输数据的系统的任何方面。
作为一个互联网用户，你可能已经对 web 的请求延时似曾相识 - 有些页面是活跃与快速的，而有些页面需要耗时更久同时交互上存在延迟。
在分布式系统中，我们可能会对数据库的查询延时感兴趣。如果数据库是延时的重大源头，这可能意味着我们需要创建合适的索引或者切换新的数据库模型。
另外一个例子，我们可能会对缓存层造成的延迟影响感兴趣。 如果缓存被有效的利用，它可以通过加快数据获取来降低延时。
不过缓存如果使用不当，它可能会通过引入额外的复杂步骤来提高延时。
是什么造成了延时
-
物理距离：作为信息载体的光速是最快的传播速度，无论你的系统如何设计，空间传输所需要的时间消耗无法避免
-
复杂计算：如果一个计算是复杂的，它会造成长时间的执行从而导致高延时。比如一个在关系型数据库的包含很多关联查询，相比通过简单id查询会占用更多时间
-
过多节点：如果一个请求的路径上决策节点过多，同样会提高延时，因为每个节点在处理请求同时决定其路由上会增加时间
还有太多的细微差别影响到延时，我们没有办法一一覆盖。当处理大型分布式系统时，硬件，网络协议，用户流量会以细微方式的交互而产生高可变的延时。
如何提升延时表现
-
更好的路径：减少请求访问的节点数量
-
缓存：正确使用缓存可以极大提升延时性能，通过数据复本加快请求获取
-
协议选择：某些协议如 HTTP/2,有意地减少关联请求的开销，这可以减少延时。TCP 同时拥有的拥塞控制特性，同样可以缓解拥塞所导致的高延时
吞吐
吞吐量是在单位时间内通过系统成功传输的数据量，通常以每秒比特数（bps）为单位。
吞吐量衡量系统数据真实传输，而不是理论上系统带宽的容量。
延时，吞吐与带宽容易混淆，不过这里有个你可能已经熟悉的相似概念：公路上汽车的交通。
-
延时是从 A 到 B 开车所需要的时间
-
带宽是公路的实际宽度
-
吞吐是公路上汽车的数量
-
拥塞：就好像道路交通上由许多人试图到达同一个目的地，软件上，系统的低吞吐量可能是网络上过多的请求造成的。硬件本质上无法处理通过它的请求数量
-
协议开销：如果传输协议要求握手和其他来回确认的通信模式，网络可能因为协议本身而不是消息本身造成负载过重
-
延时：因为吞吐是单位时间内传输数据传输大小。高延时会减少整体传输数量大小
-
提升带宽：提升带宽能够带来吞吐量的提升。这也通常意味着通过添加硬件或者升级硬件解决系统瓶颈
-
提升延时性能：因为延迟制约了吞吐，提升延时性能能够帮助提升吞吐
-
协议选择：TCP 具有拥塞控制功能，可以帮助缓解导致低吞吐量的拥塞
可用性是单位时间内系统能够正确响应的时间量，即： 可用时间/（可用时间+宕机时间）。
可用性是系统的关键性能指标，因为宕机在短时间内对用户以及业务收益都造成伤害。
可用性非常重要，以至于 AWS 和 Google Cloud 等基础设施服务将在其服务级别协议 (SLA) 中保证一定的正常运行时间。
高可用的黄金标准是系统五个九：即 99.999 的运行时间。
这似乎是一个过份精确的数字，但 90% 的运行时间大约是一周17个小时的停机时间， 99% 的运行时间大约是一周1.7个小时的停机时间，对于出现定期不可用的服务来说，这也已经是相当长的时间。
如果性能与用户体验方面不平衡，五个九的黄金标准可能产生误导。 如果每个用户的请求需要花费一分钟时间进行响应，那么服务的正常运行时间可能就没有那么重要了。 在设计高度可用的系统时，确保优良的延时与吞吐也是非常重要的。
思考停机时间的时机同样很重要。 如果不幸在使用率高的时刻发生停机，如购物周，企业业务会受到显著影响。 如果意味着高峰使用时间系统能够正确运行，那么在低峰期计划更长的停机时间以及没有实现五个九的可用性同样是有好处的。
停机发生在当部分服务崩溃时，比如硬件组件失败，或者部署错误导致软件状态不一致。 系统失败原因不一而足，下面列出了大部分常用原因：
-
硬件失败：计算机组件最终出现故障，可能会导致关键服务器瘫痪，进而导致整个系统停止工作。如果数据中心发生停电或者自然灾害，整个系统也可能被关闭
-
软件故障：当代码出现错误，请求会遇到错误并且代码运行被终止（比如空指针的解引用）
-
复杂架构：系统架构越复杂，故障点就越多。同步更多的计算机并使它们对其他计算机的容错更困难
-
相关服务中断：系统所依赖的服务中断，比如 DNS 或者认证服务，在内部系统没有异常的情况下也会导致系统变得不可用
-
请求过载：系统达到最大处理时会开始对一些请求进行失败响应。太多的请求导致关键资源枯竭也会造成系统宕机，比如硬盘空间占满
-
部署问题：当进行系统部署时，对软件或者配置的更新没有按预期进行时，可能会出现许多可能导致系统不可用的问题。比如部署问题可能会使服务器处于不一致状态，阻止服务启动，相互通信，或者可能会出现资源短缺，这在分布式系统部署中可能老生常谈
部分系统故障解决方案是冗余 确保当出现问题时，有一个冗余副本能够继续服务。 冗余有许多组成部分，包括：
-
故障转移：在发生故障时切换到系统任何部分的副本。可以是并行运行以进行即时的切换，也可以是仅在需要时启动的冷故障切换
-
集群：运行系统的多个实例，如果其中一个节点宕机，其余部分可以在没有其他节点的情况下继续管理
-
备份：数据备份与复制机制，确保存储数据失败时，比如数据中心停电，依然有复本能够访问
-
异地备份：在世界不同地方部署系统，当异常发生影响一个区域时，其他地区的系统依然能够工作
-
自动测试，部署与回滚：为了缓解因部署或者架构变更引起的问题，自动化捕获软件错误非常有用，避免了人为的部署异常，并且自动回滚机制在出现问题时能够回到之前的稳定版本