大型分布式系统关键指标.docx

大型分布式系统关键指标

衡量一个大型分布式系统是否健康需要用到一些指标。

SLA

在硅谷一线大厂所维护的系统服务中，我们经常可以看见SLA这样的承诺。例如，在谷歌的云计算服务平台GoogleCloudPlatform中，他们会写着“99.9%Availability”这样的承诺，这就是一个SLA承诺。

SLA（Service-LevelAgreement），服务等级协议，指的是系统服务提供者对客户的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。

在开发设计系统服务的时候，无论面对的客户是谁，都应该对自己所设计的系统服务有一个定义好的SLA。因为SLA是一种服务承诺，所以指标可以多种多样，最常见的四个SLA指标包括可用性、准确性、系统容量和延迟。

可用性（Availabilty）

可用性指的是系统服务能正常运行所占的时间百分比。如果我们搭建了一个拥有“100％可用性”的系统服务，那就意味着这个系统在任何时候都能正常运行。但真要实现这样的目标其实非常困难，成本也会很高。即便是大名鼎鼎的亚马逊AWS云计算服务这样大型的、对用户来说极为关键的系统，也不能承诺100％的可用性，它的系统服务从推出到现在，也有过服务中断（ServiceOutage）的时候。

对于许多系统而言，四个9的可用性（99.99％Availability，或每年约50分钟的系统中断时间）即可以被认为是高可用性（Highavailability）。“99.99%Availability”指的是一天当中系统服务将会有大约8.6秒的服务间断期。服务间断也许是因为系统维护，也有可能是因为系统在更新升级系统服务。

准确性（Accuracy）

准确性指的是我们所设计的系统服务中，是否允许某些数据是不准确的或者是丢失的。不同的系统平台可能会用不同的指标去定义准确性。很多时候，系统架构会以错误率（ErrorRate）来定义这一项SLA。可以用导致系统产生内部错误（InternalError）的有效请求数，除以这期间的有效请求总数来计算错误率。

例如，我们在一分钟内发送100个有效请求到系统中，其中有5个请求导致系统返回内部错误，那我们可以说这一分钟系统的错误率是5/100=5%。

GoogleCloudPlatform的SLA中，有着这样的准确性定义：每个月系统的错误率超过5%的时间要少于0.1%，以每分钟为单位来计算。而亚马逊AWS云计算平台有着稍微不一样的准确性定义：以每5分钟为单位，错误率不会超过0.1%。你一般来说，我们可以采用性能测试（PerformanceTest）或者是查看系统日志（Log）两种方法来评估系统的准确性。

系统容量（Capacity）

在数据处理中，系统容量通常指的是系统能够支持的预期负载量是多少，一般会以每秒的请求数为单位来表示。我们常常可以看见，某个系统的架构可以处理的QPS（QueriesPerSecond）是多少又或者RPS（RequestsPerSecond）是多少。这里的QPS或者是RPS就是指系统每秒可以响应多少请求数。

之前Twitter发布的一项数据显示，Twitter系统可以响应30万的QPS来读取TwitterTimelines。这里Twitter系统给出的就是他们对于系统容量（Capacity）的SLA。那要怎么给自己设计的系统架构定义出准确的QPS呢？

可以有下面这几种方式。第一种，是使用限流（Throttling）的方式。如果你是使用Java语言进行编程的，就可以使用GoogleGuava库中的RateLimiter类来定义每秒最多发送多少请求到后台处理。假设在每台服务器都定义了一个每秒最多处理1000个请求的RateLimiter，而一共有N台服务器，在最理想的情况下，QPS可以达到1000*N。这里要注意的雷区是，这个请求数并不是设置得越多越好。因为每台服务器的内存有限，过多的请求堆积在服务器中有可能会导致内存溢出（Out-Of-Memory）的异常发生，也就是所有请求所需要占用的内存超过了服务器能提供的内存，从而让整个服务器崩溃。

第二种，是在系统交付前进行性能测试（PerformanceTest）。可以使用像ApacheJMeter又或是LoadRunner这类型的工具对系统进行性能测试。这类工具可以测试出系统在峰值状态下可以应对的QPS是多少。这里也是有雷区的。有的开发者可能使用同一类型的请求参数，导致后台服务器在多数情况下命中缓存（CacheHit）。这个时候得到的QPS可能并不是真实的QPS。