2.2 服务水平协议(SLA)
为了保证应用程序可以在限定的(bounded)时间内递送(deliver)其功能,一个平台内的任何一个依赖都在一个更加限定的时间
内递送其功能。客户端和服务端采用服务水平协议(SLA),其为客户端和服务端在几个系统相关的特征上达成一致的一个正式协
商合约,其中,最突出的包括客户对特定的 API 的请求速率分布的预期要求,以及根据这些条件,服务的预期延时。一个简单
的例子是一个服务的 SLA 保证:在客户端每秒 500 个请求负载高峰时,99.9%的响应时间为 300 毫秒。
在 Amazon 的去中心化的面向服务的基础设施中,服务水平协议发挥了重要作用。例如,一个页面请求某个电子商务网站,通
常需要页面渲染(rendering)引擎通过发送请求到 150 多个服务来构造其响应。这些服务通常有多个依赖关系,这往往是其他
服务,因此,有一层以上调用路径的应用程序通常并不少见。为了确保该网页渲染引擎在递送页面时可以保持明确的时限,调
用链内的每个服务必须履行合约中的性能指标。
图 1 显示了 Amazon 平台的抽象架构,动态网页的内容是由页面呈现组件生成,该组件进而查询许多其他服务。一个服务可以
使用不同的数据存储来管理其状态,这些数据存储仅在其服务范围才能访问。有些服务作为聚合器使用其他一些服务,可产生
合成(composite)响应。通常情况下,聚合服务是无状态,虽然他们利用广泛的缓存。
图 1:面向服务的 Amazon 平台架构。
行业中,表示面向性能的 SLA 的共同做法是使用平均数(average),中值(median)和预期变化(expected variance)。在
Amazon,我们发现,这些指标不够好,如果目标是建立一个对所有,而不是大多数客户都有着良好体验的系统。例如,如果
个性化(personalization)技术被广泛使用,那么有很长的历史的客户需要更多的处理,性能影响将表现在分布的高端。前面所
述的基于平均或中值响应时间的 SLA 不能解决这一重要客户段的性能问题。为了解决这个问题,在 Amazon,SLA 是基于分布
的 99.9 百分位来表达和测量的。选择百分位 99.9 的而不是更高是根据成本效益分析,其显示出在 99.9 之后,要继续提高性
能,成本将大幅增加。系统的经验与 Amazon 的生产表明,相比于那些基于平均或中值定义的 SLA 的系统,该方法提供了更好
的整体体验。
本文多次提到这种 99.9 百分位分布,这反映了 Amazon 工程师从客户体验角度对性能不懈追求。许多论文统计平均数,所以
在本论文的一些地方包括它可以用来作比较。然而,Amazon 的工程和优化没有侧重于平均数。几种技术,如作为写协调器
(coordinators)的负载均衡的选择,纯粹是针对控制性能在 99.9 百分位的。
存储系统在建立一个服务的 SLA 中通常扮演重要角色,特别是如果业务逻辑是比较轻量级时,正如许多 Amazon 的服务的情况。
状态管理就成为一个服务的 SLA 的主要组成部分。对 dynamo 的主要设计考虑的问题之一就是给各个服务控制权,通过系统属
性来控制其耐用性和一致性,并让服务自己在功能,性能和成本效益之间进行权衡。
2.3 设计考虑
在商业系统中,数据复制(Data replication)算法传统上执行同步的副本(replica)协调,以提供一个强一致性的数据访问接口。
为了达到这个水平的一致性,在某些故障情况下,这些算法被迫牺牲了数据可用性。例如,与其不能确定答案的正确性与否,
不如让该数据一直不可用直到它绝对正确时。从最早期的备份(replicated)数据库,众所周知,当网络故障时,强一致性和高可
用性不可能性同时实现[2,11]。因此,系统和应用程序需要知道在何种情况下可以达到哪些属性。
对于容易出现的服务器和网络故障的系统,可使用乐观复制技术来提高系统的可用性,其变化可以在后台传播到副本,同时,
并发和断开(disconnected)是可以容忍的。这种方法的挑战在于,它会导致更改冲突,而这些冲突必须检测并协调解决。这种