如何评价亚马逊云服务(AWS)在12月7日的us-east-1出现的问题？ 第1页

此次事故网上的信息不多，可以确认的是AWS的US-EAST-1区域(region)出现故障下线了。该区域内有大量的服务器所提供的API影响到了Amazon和其他第三方客户的大量服务。时间约6小时，据不可靠消息是网络故障。

AWS的区域一共21个，其中此次出事故的US-EAST-1区域部署在弗吉尼亚州。大家可以将区域的概念理解为一个机房，机房内存放了大量的服务。建设机房的成本非常高昂，因此数量并不多。Amazon全部的21个区域里，US开头的美国机房仅有4个，此次受影响最大的业务也普遍在美国。亚太地区虽然区域更多，但基本都是部署在东亚地区，跨区域服务会有时延的提高，带宽也未必如愿。

网络故障数据中心来说还是比较常见的，但此次故障升级为事故，还是暴露了很多问题。而良好的架构设计可以尽量降低事故损失，甚至在有一定冗余的情况下对用户不可见。比如此次受到影响的很多手机APP，就可以在尝试连接服务器时，设置一个域名列表，每个域名在DNS上设置对应多个服务器。这样即便有部分DNS服务器故障，也未必能让全部DNS下线。而不同域名则可以选择一部分部署在AWS以外的云平台，防止像此次AWS的区域故障，直接导致服务完全不可用的情况发生。

多年前我在视频网站工作时，CDN的工作原理中就包含了很多高可用设计。比如用户请求一个视频时，发来视频ID后，服务器会返回视频URL的列表，里面包含至少4个视频的播放地址。客户端则会按顺序依次访问，找到第一个可以播放的地址，就播放给用户。这样的设计使得整个系统的可用性提高到很高的水平。在后来多次发生的CDN搬迁期间，工作人员甚至是直接拔服务器电源搬迁，到了新机房接入电源和网线就开始工作。整个系统的对外服务也未受到用户可见的影响。而且那时虽然公司没有自建机房，但所有的CDN服务器分布在40+个租用的机房，也使得整个系统的鲁棒性达到了非常高的水平。

在云计算平台出现以后，服务器端也可以根据服务状况自动扩容缩容来实现高可用。比如此次US-EAST-1区域故障，那么其他区域如US-WEST-1区域或者阿里云，就可以在检测到服务负载升高时，立即调用云平台的接口申请服务器资源，来应付突发而来的流量。在发生此类故障时，流量的突然转移，会使得没有做自动扩容的服务很容易也跟着宕机，进而导致服务雪崩。在服务恢复后，也要一步步的开流量，避免刚恢复的服务器受到突发的流量，大量缓存溅出导致服务器负载飙升而再次宕机。

事故中AWS的dashboard逻辑设计也暴露出一些问题。在请求US-EAST-1并未对错误进行处理，而是进行了隐藏，使得网络上很多用户吐槽该区域下线时"No Recent Events"，如下图所示。在Erlang语言的设计中就有一条很好的规则，Let-it-crash。就是在发生问题时，与其做负载的隐藏，不如直接了当的向上报告。有些故障不是通过重试能处理的。反倒是大量的重试也会产生风暴来压跨重新启动的系统。

最后就是AWS本身已经成了美国很多公司的单点瓶颈，在过去几年里，AWS的多次故障也同时压跨了很多公司的服务。这其中虽然有客观上的故障，但良好的设计可以通过冗余解决掉大部分的故障，而不使其成为用户可见的事故。在云平台的用户选择弹性计算服务器时就选择区域，本身就是个设置单点瓶颈的行为，希望未来的serverless可以更好的解决故障时自动切流的需求。同时为了不使AWS持续作为单点瓶颈，注重服务稳定性的公司，也应该考虑引入多个云平台同时提供服务，比如通过相同的服务也部署在阿里云，并且都做好自动扩容，来应对一些不可预知故障。在国际权威机构Gartner发布的最新报告中，阿里云在计算、存储、网络、安全四项核心评比中均取得了最高分。