本文是Werner Vogels针对其”A word on Scalability“的评论所做的回应,为Scalability的定义新增了性能与运维效率等维度的说明.
关于a word on scalability的翻译可以参见此文: 简述伸缩性
本文原文链接为: Performance and Scalability
性能与伸缩性
By Werner Vogels,Translated By: Jametong
在简述伸缩性这篇文章中,我尽可能为伸缩性给出一个比它日常使用时更加精确的定义.这篇文章后面的评论以及The ServerSide的讨论中还有很多关于此定义的较好的评论.
我先以一种不太精确的方式回顾一下我给出的定义:
当我们往一个系统中新增资源时,它带来的性能提升与新增的资源量保持一定的比例关系,我们才认为此服务具备伸缩性.
对于一个永远在线的服务来讲，伸缩性意味着为促进冗余而增加的资源不会导致相应的性能损失。
一个具备伸缩性的服务需要能够处理异构的资源
有很大一部分评论认为伸缩性的定义中应该涵盖性能的维度.下面就是我如何在此情境中考虑性能维度的原因:我假设每个服务都有一个对应的SLA(Service Level Agreement,服务级别协议)合约来定义你的客户对此服务的预期.SLA中具体如何定义取决于商业需要哪种级别的服务;对于一个Amazon.com这样的网站来讲,有很大一部分服务的SLA是等待时间(latency)驱动的.这个等待时间会有一个特定的分布,你从这个分布区间中提取一个有代表性的时间来衡量你的SLA.例如,在Amazon,我们跟踪99.9%这个点上的等待时间,以确保几乎所有的客户都能取得等于或好于SLA的体验.
如果业务出现增长,这个SLA也必须得到保持.增长可能意味着请求数的增长、服务项目数量的增长、或者每次请求所需工作量的增长,如此等等.但是,不管朝着哪个方向增长, 你都需要确保总是可以满足你的SLA.系统沿着某些方向增长或许可以通过使用更快的CPU或者更大的内存以向上扩展(scale up)的方式实现,如果系统持续的增长,通过不断的购买更大更强的设备来向上扩展总会有尽头,这时你将不得不选择向外扩展(scale out).考虑到向上扩展通常更不经济,你不妨现在就开始考虑向外扩展,因为你最终将不得不走上这条路.
我很少看到纯粹吞吐量(throughput)驱动的SLA.常见的情况都是基于后续三点的一个综合,需要完成的工作量、这些工作量到达的时间分布、以及这些工作需要完成的时间点，这些情况综合起来导致了一个吞吐量驱动的SLA.等待时间也在此扮演的一个角色，因为确定需要什么样的吞吐量才能实现对应的输出分布区间，它通常都是其中的驱动因素。如果系统请求的到达分布不均匀，只要可以接受更长的等待时间，你就可以通过缓冲或设置一个低于峰值的吞吐量上限来达到目的。通常都是想要实现的这个等待时间的分布决定了吞吐量的需求。
关于伸缩性的定义还应包含哪些内容,讨论中还涉及一些其他问题，给出较好建议的人包含Gideon Low(我尝试连接到他个人的回应，但似乎做不到).
运维效率－随着硬件数量的增长，仅需要耗费较少的人力资源来管理此系统。
自修复能力－增加资源的数量也会增加这些资源中的一个出错的概率，但是出现故障的影响应该随着资源数量的增加而下降。
这两点与之前关于代价/容量/效率(cost/capacity/efficiency )的讨论一起都应该成为一个服务伸缩性定义的一部分。我将再深入思考下用什么合适的词语来表达此定义，并给出后续的建议。
最近评论