| 摘要：美国时间4月21日凌晨开始，Amazon位于东海岸的某个数据中心发生故障，并直接导致其网络服务经历了数次严重中断(本次事件之后被命名为4.21“云震”)。 |
Twilio是一家提供云计算平台上通讯服务的公司，提供各种API服务。在本次Amazon服务中断事故当中，Twilio的API及相关服务并未受到太大的影响。下面，Twilio的CTO Evan Cooke在其团队官方博客上分享了Twilio采取的“防震”策略。以下为译文：
我们在日趋成熟并且将Twilio拓展到Amazon网络服务之上的同时，也严格遵循架构设计的原则，以尽量减少偶然发生的底层基础设施故障对业务的影响。
将故障范围控制于单独的主机之中
如果有可能，选择一些服务项目以及基础设施来模拟主机发生故障时的状况。通过建立一套简单的单主机服务系统(而不是引入多台主机)，我们就可以构建出不受其它主机工作状态影响的独立服务供应体系。
例如，如果我们的某个应用程序包含A，B，C三种业务逻辑组成部分，那么每一部分都要运行于独立的主机之上。我们当然可以将服务群组设置为(A,B,C),(A,B,C)……或者我们也可以创建一套组件池(A,A,…),(B,B,…),(C,C,…)。如果我们选择了前一种方案，那么单个主机发生故障将会使整套系统群组遭到破坏。将资源拆开并分配给独立的池则能够在单个主机发生故障时只会对该主机本身的功能性造成影响。我们会在另一篇文章中向大家介绍上述方案的其它优势及存在的缺陷。
极短超时与快速重试
当故障发生时，我们有相应的软件快速识别那些失败及重复提交的请求。通过为每项服务运行多个冗余副本的方式，我们可以使用快速超时及重试来对无法执行或连接失败的服务器进行路由操作。
1.提出请求，若该请求返回的是一条暂时性错误提示或是短时间内没有响应(这个短时间到底有多短，可以根据大家的应用程序类型而定)
2.对另一台服务器重复上述请求
3.继续对另一台服务器重复上述请求
如果不迅速采取上述措施，分布式系统——尤其是那些按序处理或是基于线程的类型——很有可能会把运算资源浪费在等待缓慢甚至完全无响应的服务器上。
幂等服务接口
构建服务器要求能够安全地对某项请求进行重复操作。如果大家对“幂等”这个概念不太熟悉，可以先读读“幂等领域的精彩世界”一文。
“在计算机科学当中，幂等这个术语被用来全面地形容一种在执行了一次或是多次的情况下始终产生相同结果的操作。”
如果某台服务器的API符合幂等定义，那就意味着其在失败请求进行重试的过程中是安全的(即我们在前文第2条中所描述的内容)。例如，如果某台服务器提供这样一种功能，将指定数目的资金汇入另一位用户的账号当中，那么具备幂等接口也就意味着该项请求若是提交失败，则无论重复提交多少次，都不会造成预期之外的负面效果。关于这个话题其实有很多内容可谈，我们以后会就更多细节展开深入的讨论。
小型无状态服务
将逻辑业务独立为小型无状态服务能够使其更容易地通过均等的池加以组织。Twilio的基础设施中包含了许多分别实现API不同功能部分的服务池。例如，当大家在TwiML中使用指令来进行录音时，对录制内容进行后期处理以改善音质并进行上传存储的工作是由录制服务中的某个池来完成的。无状态池录制服务允许上游服务通过不同的录制服务器对失败的请求进行重试。此外，录制服务池的大小在负载进行中也很容易加以调节。
放宽对一致性的要求
当对信息的一致性没有太高要求时，为复制及重复读取数据创建对应的池。大家能在应用程序层面所部署的最重要的方案之一就是将数据的读取与写入分别处理。例如，如果某个巨大的数据池在写入方面的操作极少，就应该将数据的读取与写入分别进行处理。通过这种区分，对应的池就能够独立创建一套可供服务请求重复读取的数据副本。例如，当服务器整体的数据写入表现良好而数据读取表现较差时，我们可以通过增加读取服务池的数量来改善接收及运行读取请求的效果。
AWS的事故说明我们需要认真反思一下自己云托管应用程序的设计是否合理。我们已经着重强调了几种知名的分布式系统设计的亮点，而当我们决定将其作为外部服务整合进Twilio之后，它们也确实在工作中起到了良好的作用。
AWS事故的关键症结在于Amazon弹性模块存储(简称EBS)服务。我们在Twilio中使用了EBS方案，但只应用于那些不太重要且对延迟不太敏感的任务上。我们在将EBS引入自己设施的核心部分方面一直有所保留，因为它不符合我们所追求的“局部故障只影响某台单独的主机”这一原则。如果EBS一旦发生问题，所有相关的服务也很可能同时陷入瘫痪。相反，我们一直坚持在每台EC2主机上都部署额外的临时硬盘。如果某块临时硬盘出了问题，该问题也只会影响硬盘所在的主机。
责任编辑：Alice
评论表单加载中...
