分布式技术发展历程来看，分布式其实就是用廉价普通的机器解决单个计算机处理复杂、大规模数据和任务时存在的性能和资源瓶颈问题。

如何来衡量一个分布式系统的优劣程度呢？

一般分布式系统的表现好坏表现在以前几个方面：

• 性能
• 资源
• 可用性
• 可扩展性

性能

其实对于什么是性能，最常听说的就是请求的响应速度。其实这只是一方面，不同的系统，对于系统的要求不一样，有的关注吞吐量，有的关注相应时间，有的关注完成时间，没错这三个指标就是最常见的性能指标。

吞吐量

吞吐量指的是系统在一定时间内可以处理的任务数。

这个指标很直观的反应处一个系统的性能，就好像在顾客非常多的情况下，看一个收银员可以一个小时能服务多少个顾客。

在互联网中吞吐量常常表现为三个具体的指标：

1. QPS
2. TPS
3. BPS

QPS，即查询数每秒，用于衡量一个系统每秒处理的查询数。这个指标通常用于读操作，越高说明对读操作的支持越好。所以，我们在设计一个分布式系统的时候，如果应用主要是读操作，那么需要重点考虑如何提高QPS，来支持高频的读操作。

TPS，即事务数每秒，用于衡量一个系统每秒处理的事务数。这个指标通常对应于写操作，越高说明对写操作的支持越好。我们在设计一个分布式系统的时候，如果应用主要是写操作，那么需要重点考虑如何提高TPS，来支持高频写操作。

BPS，即比特数每秒，用于衡量一个系统每秒处理的数据量。对于一些网络系统、数据管理系统，我们不能简单地按照请求数或事务数来衡量其性能。因为请求与请求、事务与事务之间也存在着很大的差异，比方说，有的事务大需要写入更多的数据。那么在这种情况下，BPS更能客观地反应系统的吞吐量。

响应时间

响应时间指的是，系统响应一个请求需要花费的时间。响应时间直接影响到用户体验，对于时延敏感的业务非常重要。比如用户搜索导航，特别是用户边开车边搜索的时候，如果响应时间很长，就会直接导致用户走错路。

完成时间

指的是，系统真正完成一个请求或处理需要花费的时间。任务并行（也叫作任务分布式）模式出现的其中一个目的，就是缩短整个任务的完成时间。特别是需要计算海量数据或处理大规模任务时，用户对完成时间的感受非常明显。

资源占用

资源占用指的是，一个系统提供正常能力需要占用的硬件资源，比如CPU、内存、硬盘等。

一个系统在没有任何负载时的资源占用，叫做空载资源占用，体现了这个系统自身的资源占用情况。比如，你在手机上安装一个App，安装的时候通常会提示你有多少KB，这就是该App的空载硬盘资源占用。对于同样的功能，空载资源占用越少，说明系统设计越优秀，越容易被用户接受。

一个系统满额负载时的资源占用，叫做满载资源占用，体现了这个系统全力运行时占用资源的情况，也体现了系统的处理能力。同样的硬件配置上，运行的业务越多，资源占用越少，说明这个系统设计得越好。

可用性

可用性，通常指的是系统在面对各种异常时可以正确提供服务的能力。可用性是分布式系统的一项重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。系统的可用性可以用系统停止服务的时间与总的时间之比衡量。

假设一个网站总的运行时间是24小时，在24小时内，如果网站故障导致不可用的时间是4个小时，那么系统的可用性就是4/24=0.167，也就是0.167的比例不可用，或者说0.833的比例可用。

除此之外，系统的可用性还可以用某功能的失败次数与总的请求次数之比来衡量，比如对网站请求1000次，其中有10次请求失败，那么可用性就是99%。

你可能经常在一个系统的宣传语中见到或听到3个9（或3N，3 Nines）、5个9（或9N，9 Nines）。这些宣传语中所说的3个9、5个9，实际上就是系统厂商对可用性的一种标榜，表明该系统可以在99.9%或99.999%的时间里能对外无故障地提供服务。

讲到了可用性，你可能还会想到一个非常近似的术语：可靠性（Reliability）。那可靠性和可用性有什么区别呢？ 可靠性通常用来表示一个系统完全不出故障的概率，更多地用在硬件领域。而可用性则更多的是指在允许部分组件失效的情况下，一个系统对外仍能正常提供服务的概率。 杰夫 · 迪恩（Jeff Dean）曾在Google I/O大会上透露：谷歌一个基于1000台通用计算机的集群，一年之内就有1000+硬盘会出现故障。由于现在比较常见的分布式系统基本上都是基于通用计算机的，这就意味着在这些系统中无法实现真正的可靠，所以我们也会在一些场合见到可靠性和可用性交换使用的情况。

可扩展性

可扩展性，指的是分布式系统通过扩展集群机器规模提高系统性能(吞吐、响应时间、 完成时间)、存储容量、计算能力的特性，是分布式系统的特有性质。

分布式系统的设计初衷，就是利用集群多机的能力处理单机无法解决的问题。然而，完成某一具体任务所需要的机器数目，即集群规模，取决于单个机器的性能和任务的要求。

当任务的需求随着具体业务不断提高时，除了升级系统的性能做垂直/纵向扩展外，另一个做法就是通过增加机器的方式去水平/横向扩展系统规模。

这里垂直/纵向扩展指的是，增加单机的硬件能力，比如CPU增强、内存增大等；水平/横向扩展指的就是，增加计算机数量。好的分布式系统总在追求“线性扩展性”，也就是说系统的某一指标可以随着集群中的机器数量呈线性增长。

衡量系统可扩展性的常见指标是加速比（Speedup），也就是一个系统进行扩展后相对扩展前的性能提升。

一个分布式系统是否可以保证每个指标都达到理性水平？

答案是否定的，无论是高可用，高性能，还是高扩展性，都会受到资源占用的限制，说白了就是受到成本的限制。

然而，虽然出于硬件成本、开发效率等因素的约束，我们无法在性能、可用性、可靠性和资源占用做到面面俱到。所以在不同的业务场景中，设计者们需要有所取舍。

接下来，我带你一起看一下典型的电商、IoT、电信、HPC（高性能计算）、大数据、云计算、区块链等业务或系统对不同指标的诉求。

• 电商系统。对于一个电商系统而言，系统设计者最看重的是吞吐量，为了处理更多的用户访问或订单业务，甚至不惜牺牲一些硬件成本。
• IoT。对于一个IoT系统而言，设计者最看重的是资源占用指标，因为在一些功能极简的IoT设备上RAM、ROM的可用资源通常都是KB级的。
• 电信业务。对于电信业务而言，最重要的无疑是响应时间、完成时间，以及可用性。因为，你在打电话时不希望你的声音半天才被对方听到，也不希望半天才听到对方的回应，更不希望你的电话无法拨出。
• HPC。HPC系统最显著的特点是任务执行时间极长，一个天体物理任务的分析和计算通常耗时数周甚至数月。因此，通过水平扩展来提高系统的加速比，是HPC系统设计者需要关注的。
• 大数据。大数据任务的处理时间可能相对HPC系统来讲比较短，但常见的完成时间也达到了小时级，所以扩展性也是大数据系统首先要考虑的。
• 云计算。对于一个云计算系统而言，常见任务是虚拟主机或容器的创建、资源调整、销毁等操作，如何减少这些操作的完成时间，从而提升用户体验是设计者们要重点关注的。另外，云计算系统本质上卖的是资源，那么降低系统本身的资源开销，也是系统设计的重中之重。
• 区块链。区块链的吞吐量比较低，比特币的TPS只有7次每秒，单平均一次交易的确认就需要10分钟左右，因此吞吐量和完成时间通常是区块链系统设计者的首要目标。