自己电脑上做的网站 怎么让别人看,邯郸信息港人才招聘,平面设计免费课程视频,脚上起小水泡还很痒是什么原因在硅谷一线大厂所维护的系统服务中#xff0c;我们经常可以看见SLA这样的承诺。 例如#xff0c;在谷歌的云计算服务平台Google Cloud Platform中#xff0c;他们会写着“99.9% Availability”这样的承诺。那什么是“99.9% Availability”呢#xff1f; 要理解这个承诺是…在硅谷一线大厂所维护的系统服务中我们经常可以看见SLA这样的承诺。 例如在谷歌的云计算服务平台Google Cloud Platform中他们会写着“99.9% Availability”这样的承诺。那什么是“99.9% Availability”呢 要理解这个承诺是什么意思首先你需要了解到底什么是SLA SLAService-Level Agreement也就是服务等级协议指的是系统服务提供者Provider对客户Customer的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。 在开发设计系统服务的时候无论面对的客户是公司外部的个人、商业用户还是公司内的不同业务部门我们都应该对自己所设计的系统服务有一个定义好的SLA。 因为SLA是一种服务承诺所以指标可以多种多样。根据我的实践经验给你介绍最常见的四个SLA指标可用性、准确性、系统容量和延迟。 图片 可用性Availabilty 可用性指的是系统服务能正常运行所占的时间百分比。 如果我们搭建了一个拥有“100可用性”的系统服务那就意味着这个系统在任何时候都能正常运行。是不是很完美但真要实现这样的目标其实非常困难并且成本也会很高。 我们知道即便是大名鼎鼎的亚马逊AWS云计算服务这样大型的、对用户来说极为关键的系统也不能承诺100的可用性它的系统服务从推出到现在也有过服务中断Service Outage的时候。 对于许多系统而言四个9的可用性99.99 Availability或每年约50分钟的系统中断时间即可以被认为是高可用性High availability。 说到这里我来为你揭开一开始所提到的“99.9% Availability”的真实含义。 “99.9% Availability”指的是一天当中系统服务将会有大约86秒的服务间断期。服务间断也许是因为系统维护也有可能是因为系统在更新升级系统服务。 86秒这个数字是怎么算出来的呢 99.9%意味着有0.1%的可能性系统服务会被中断而一天中有24小时 × 60分钟 × 60秒也就是有(24 × 60 × 60 × 0.001) 86.4秒的可能系统服务被中断了。而上面所说的四个9的高可用性服务就是承诺可以将一天当中的服务中断时间缩短到只有(24 × 60 × 60 × 0.0001) 8.64秒。 准确性Accuracy 准确性指的是我们所设计的系统服务中是否允许某些数据是不准确的或者是丢失了的。如果允许这样的情况发生用户可以接受的概率百分比是多少 这该怎么衡量呢不同的系统平台可能会用不同的指标去定义准确性。很多时候系统架构会以错误率Error Rate来定义这一项SLA。 怎么计算错误率呢可以用导致系统产生内部错误Internal Error的有效请求数除以这期间的有效请求总数。 图片 例如我们在一分钟内发送100个有效请求到系统中其中有5个请求导致系统返回内部错误那我们可以说这一分钟系统的错误率是 5 / 100 5%。 下面我想带你看看硅谷一线公司所搭建的架构平台的准确性SLA。 Google Cloud Platform的SLA中有着这样的准确性定义每个月系统的错误率超过5%的时间要少于0.1%以每分钟为单位来计算。 而亚马逊AWS云计算平台有着稍微不一样的准确性定义以每5分钟为单位错误率不会超过0.1%。 你看我们可以用错误率来定义准确性但具体该如何评估系统的准确性呢一般来说我们可以采用性能测试Performance Test或者是查看系统日志Log两种方法来评估。 具体的做法我会在后面展开讲解今天你先理解这项指标就可以了。 系统容量Capacity 在数据处理中系统容量通常指的是系统能够支持的预期负载量是多少一般会以每秒的请求数为单位来表示。 我们常常可以看见某个系统的架构可以处理的QPS Queries Per Second是多少又或者RPSRequests Per Second是多少。这里的QPS或者是RPS就是指系统每秒可以响应多少请求数。 我们来看看之前Twitter发布的一项数据Twitter系统可以响应30万的QPS来读取Twitter Timelines。这里Twitter系统给出的就是他们对于系统容量Capacity的SLA。 你可能会问我要怎么给自己设计的系统架构定义出准确的QPS呢以我的经验看可以有下面这几种方式。 第一种是使用限流Throttling的方式。 如果你是使用Java语言进行编程的就可以使用Google Guava库中的RateLimiter类来定义每秒最多发送多少请求到后台处理。 假设我们在每台服务器都定义了一个每秒最多处理1000个请求的RateLimiter而我们有N台服务器在最理想的情况下我们的QPS可以达到1000 * N。 这里要注意的雷区是这个请求数并不是设置得越多越好。因为每台服务器的内存有限过多的请求堆积在服务器中有可能会导致内存溢出Out-Of-Memory的异常发生也就是所有请求所需要占用的内存超过了服务器能提供的内存从而让整个服务器崩溃。 第二种是在系统交付前进行性能测试Performance Test。 我们可以使用像Apache JMeter又或是LoadRunner这类型的工具对系统进行性能测试。这类工具可以测试出系统在峰值状态下可以应对的QPS是多少。 当然了这里也是有雷区的。 有的开发者可能使用同一类型的请求参数导致后台服务器在多数情况下命中缓存Cache Hit。这个时候得到的QPS可能并不是真实的QPS。 打个比方服务器处理请求的正常流程需要查询后台数据库得到数据库结果后再返回给用户这个过程平均需要1秒。在第一次拿到数据库结果后这个数据就会被保存在缓存中而如果后续的请求都使用同一类型的参数导致结果不需要从数据库得到而是直接从缓存中得到这个过程我们假设只需要0.1秒。那这样我们所计算出来的QPS就会比正常的高出10倍。所以在生成请求的时候要格外注意这一点。 第三种是分析系统在实际使用时产生的日志Log。 系统上线使用后我们可以得到日志文件。一般的日志文件会记录每个时刻产生的请求。我们可以通过系统每天在最繁忙时刻所接收到的请求数来计算出系统可以承载的QPS。 不过这种方法不一定可以得到系统可以承载的最大QPS。 在这里打个比喻一家可以容纳上百桌客人的餐馆刚开业因为客流量还比较小在每天最繁忙的时候只接待了10桌客人。那我们可以说这家餐馆最多只能接待10桌客人吗不可以。 同样的以分析系统日志的方法计算出来的QPS并不一定是服务器能够承载的最大QPS。想要得到系统能承受的最大QPS更多的是性能测试和日志分析相结合的手段。 延迟Latency 延迟指的是系统在收到用户的请求到响应这个请求之间的时间间隔。 在定义延迟的SLA时我们常常看到系统的SLA会有p95或者是p99这样的延迟声明。这里的p指的是percentile也就是百分位的意思。如果说一个系统的p95 延迟是1秒的话那就表示在100个请求里面有95个请求的响应时间会少于1秒而剩下的5个请求响应时间会大于1秒。 下面我们用一个具体的例子来说明延迟这项指标在SLA中的重要性。 假设我们已经设计好了一个社交软件的系统架构。这个社交软件在接收到用户的请求之后需要读取数据库中的内容返回给用户。 为了降低系统的延迟我们会将数据库中内容放进缓存Cache中以此来减少数据库的读取时间。在系统运行了一段时间后我们得到了一些缓存命中率Cache Hit Ratio的信息。有90%的请求命中了缓存而剩下的10%的请求则需要重新从数据库中读取内容。 这时服务器所给我们的p95或者p99延迟恰恰就衡量了系统的最长时间也就是从数据库中读取内容的时间。作为一个优秀架构师你可以通过改进缓存策略从而提高缓存命中率也可以通过优化数据库的Schema或者索引Index来降低p95或p99 延迟。 总而言之当p95或者p99过高时总会有5%或者1%的用户抱怨产品的用户体验太差这都是我们要通过优化系统来避免的。