基于弹性计算平台构建高可用、可扩展的应用(1)

基于弹性计算平台构建高可用、可扩展的应用(1)

前不久，Facebook宣布投资10亿美元收购仅成立15个月的移动照片分享应用Instagram，消息传出时，人们不仅惊叹于这笔巨额的交易，更为这支13个人的小团队感到不可思议。Instagram的Android版客户端发布时，24小时内下载量超过100万，高峰期达到每分钟2000次，是下载量最大的Android应用之一。究竟是什么原因让这支团队在很短的时间内一鸣惊人?又是什么技术让他们在巨大的下载量下顶住了压力?

让我们回顾一下Instagram开发团队奉行的3大原则：

1、Keep it very simple(极简主义);

2、Don't re-invent the wheel (不重复发明轮子);

3、Go with proven and solid technologies when you can (能用就用靠谱的技术);

总而言之，专注于自己的业务和擅长领域，其它事情让更专业的人去做。Instagram选择了美国的亚马逊云计算平台作为基础设施提供商，他们部署了数以百计的云服务器和存储服务，却只有区区3名工程师负责维护，不需要任何现场人员支持。如果依赖于传统的IDC服务，光是把这几百台服务器托管到IDC机房，就需要数天时间和大量的人力成本。每当发布一个新版本时，Instagram所要做的只是在云计算平台上开启更多的服务器，便可稳坐钓鱼台，看着自己应用的下载量节节攀升了。

阿里云弹性计算平台(Elastic Compute Service，简称ECS)面向中国互联网开发者和站长，致力于为中国的Instagram提供靠谱的互联网基础服务。它基于底层的飞天分布式计算系统，结合高性能虚拟化技术，实现了计算、存储和网络资源的统一调度和弹性分配。在具体的产品形式上，客户接触的是最简单的云服务器，与物理机无二，没有任何的使用门槛。由于采用了云计算技术，相比传统的IDC托管服务，弹性计算在自助管理、资源组合灵活性、基础环境定制化、数据安全性及硬件资源利用率上都有不小的优势。

在本文中，我们将和大家分享在云计算平台上构建高可用、可扩展应用的一些进阶技巧。考虑到有些读者尚未接触过ECS，所以在进入正题之前，让我们简单浏览一下ECS的各项特性。

自助管理

ECS在aliyun.com的控制台中提供了多种用户自助的操作，例如最为常见的创建、启动、关闭云服务器，将来还会陆续推出比较高级的快照、自定义镜像(Image)等功能。回想我们以前遇到服务器不可访问时，提交工单、电话催促，在经历漫长等待之后，也未必能够得到一个满意的答复。现在，我们可以在控制台中全程监控和管理每一台服务器的运行情况，从而做出快速的决定--重启或者部署新的服务器。

ECS支持目前主流的Windows和Linux系列操作系统。用户不仅可以使用这些标准的镜像，还可以在此基础上修改配置、安装软件，创建出自己的镜像，当要快速恢复基础环境或者批量部署集群时，自定义镜像将成为提高运维效率的利器。

下图简单地描述了一个自定义镜像的生产过程：

1、使用标准镜像创建一台云服务器;

2、用户登录云服务器，安装自己所需的软件，配置好系统参数;

3、安全关机，然后将云服务器当前状态存为一个自定义镜像;

4、随后，用户就可以使用刚创建的自定义镜像启动更多的云服务器了;

数据可靠性

对于写入VM磁盘的数据，ECS会实时地在不同的交换机下同步3份拷贝，当集群中的磁盘损坏时，后台进程也会自动地重建故障磁盘的数据。相比常见的RAID硬件方案，这种分布式存储系统能够提供更高的数据安全保障，因为它不受单台服务器可用性的限制，并且，由于多台服务器可以并发处理，数据恢复的时间更短。

ECS提供的在线快照功能可以完美地替代传统的复制备份，它采用先进的增量数据算法，确保做到备份空间和时间的最优化。当用户数据被误删或者系统被病毒破坏时，只需要一个简单操作就可以瞬间恢复环境。

自动故障恢复

有了分布式存储的支持，ECS可以提供比传统主机或VPS服务更高的可用性指标。当一台物理机损坏时，ECS会自动监测到硬件故障，在第一时间内把云服务器迁移到新的宿主机上，同时硬盘数据保持最后一刻的状态。 

图3 自动故障恢复

从以上介绍可以知道，托管在弹性计算平台上的应用可以获得更多的保障，但我们是否可以认为，将应用搬到云计算平台之后，它就能跑得欢快、永不宕机，还能自动扩展了?答案是NO!

每时每刻，硬盘、主板、电源或者网络设备都可能突然损坏，甚至整个数据中心发生停电。云计算技术没有办法解决所有硬件问题，只是降低了某些故障的发生几率，例如：

•普通SATA的年损坏率在2~4%，但使用分布式存储的年损坏率在1‰以下;

•自动故障恢复只是减少了服务器的宕机时间，但不能防止宕机;

如果我们的应用只能跑在单台服务器上，只能依赖单台设备的硬件升级才能应付日益增长的访问量，那么这种应用的宕机是迟早的事。我 们需要从部署架构和应用架构两个方面来破解这个难题。