在 9 月 13 日周五早晨，Amazon Web Service（AWS）在美国东一区的服务再次出现宕机，由于这一地区是整个 Amazon 最大、时间最长久并且业务最繁忙的地区，这次宕机使包括 Heroku、Github 和 CMSWire 在内的一大批主流应用服务中断，还影响到了其它许多 Amazon 的客户。
就在最近这次宕机事件发生数日前，关注云端服务的评论者 Ben Kepes 还撰文写道：“每次AWS 的宕机事件，看起来都是由于东区导致了服务故障。”Kepes 还引用了分析师René Büst 的一段文字，其中将美国东一区的服务描述为“陈旧、廉价并且脆弱的”。
Amazon 目前还没有提供详细的故障报告，但上周五的问题已经基本可以归结为网络故障。在 2011 年 4 月的一次故障也是与网络问题相关，但在 2012 年 12 月和 2012 年 10 月发生的最近两次故障都是由弹性负载均衡（Elastic Load Balancer – ELB）和弹性块存储（Elastic Block Storage - EBS）服务出现问题而导致的。网络与 EBS 的故障危害性尤其巨大，因为它们会导致多个可用性区域（Availability Zone）（本应作为故障边界）产生故障，或者使提供容错能力的更高级别服务（例如 ELB）中断。
一般来说，应用程序的提供者只会使用传统的架构方式，而不会为了云端服务以及它固有的不稳定性进行针对性的设计，许多应用程序都不会考虑在一个或多个地区（region）中使用多个可用性区域。但即使针对这些故障进行专门设计，也不见得一定能避免问题的发生。Netflex 使用的那套被戏称为“猿猴军团”和“混沌猴子”的工具一直被遵为云端设计的典范。他们有意持续不断地为自己的平台产生各种错误，并以此证明整个平台良好的自我修复能力，但有些时候（如平安夜宕机事件）这个平台还是不能提供能够承受来自四面八方的负载的能力，使得某些客户所使用到的服务质量下降。
东一区连续不断的宕机，以及那些本应力挽狂澜的服务（例如ELB）的无所作为，为Amazon 在“基础架构即服务”（Infrastructure as a service）这一市场上的竞争对手带来了机会。Google 近期就为Google 计算引擎发布了它自己的负载均衡服务，并且提供了一份关于设计健壮的系统的良好提议。
查看英文原文： Amazon Web Services Stability and the September 13th US East 1 Outage
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论