借力云平台，很多公司在业务上取得了成功，但由于云平台上开发经验的欠缺，开发者在云平台的使用上存在不少误区。针对这一现状，本文详细讲述了使用EC2、EBS和S3三个云平台产品过程的常见问题，以及如何在云平台上架构稳定可用的服务。
在国外，基于Amazon AWS平台的成功案例越来越多，如日中天的Dropbox、提供DVD租借服务的老牌厂家Netflix，还有无数使用AWS的创业公司，都已证明AWS不仅是一个成功的商业模式，还是一个可以改变互联网传统开发模式的产品。
国内也有不少团队在使用Amazon AWS为他们的全球客户提供服务，但由于AWS访问速度的问题，很多开发者开始使用国内的云服务提供商的产品。可能是因为大家刚刚从传统的开发模式转移到云平台上，而且云平台上开发经验的分享相对较少，所以开发者在使用云平台上有不少误区。本文将详细介绍使用几个云平台（IaaS平台）产品过程中经常碰到的一些问题，以及如何在云平台上架构稳定可用的服务。
EC2/云主机
不管是从市场调查，还是从实际运营的数据来看，EC2/云主机是使用最多的产品，其概念也是用户最容易理解的。从技术角度来看，EC2/云主机背后的技术是虚拟化，而虚拟化技术是大家耳熟能详的，并且多多少少在工作过程中都接触过。虚拟化技术所带来的好处也广为人知，这里就不重述了。无论用户选择哪家云计算平台，只要申请了EC2/云主机，都可以像在使用一台真正的服务器一样，安装软件，部署程序，对外提供服务。
EC2/云主机最大的特点是按需申请、按需计费。用户可以根据自身需求，申请只有一个CPU且内存很小的超微型机器，也可以申请有多个CPU和大内存的超大型机器，这大大减少了创业团队的初期投入。因为按以前的开发模式， 产品想上线，一般需要购买机器放到机房托管。而对产品上线后的流量估计又很难做到准确，机器买少了支撑不住整个产品，买多了又浪费。至于其他优点，如多种系统支持、方便的控制台管理等，其实都是一个好的云平台应该做的事。
经常有用户会问EC2/云主机可靠吗？性能好吗？使用EC2/云主机时应该注意什么问题？怎样在EC2/云主机上搭建高可用的服务？下面将针对这些问题一一作出解答。
EC2/云主机可靠吗
EC2/云主机是寄宿在物理机上的虚拟机，和物理机一样不可靠。一旦物理机出问题，就一定会影响到虚拟机，因此不要指望云主机像钻石一般，能够恒久远，永不宕机。所有物理机会出的毛病， EC2/云主机一样都会出。
EC2/云主机性能怎样
性能的具体指标很难定义，但可以从CPU、内存和磁盘I/O上粗略看出一台机器的性能好坏。先从CPU角度来说，现在的虚拟化技术对物理机（宿主机）的CPU资源消耗比例已经非常低了，所以能够分配给虚拟机的CPU资源是比较充足的。一般来说，云平台都会有自己定义的CPU计算能力的单位（比如Amazon叫EC2 Compute Unit， ECU），然后给不同类型的云主机分配不同的计算资源。宿主机的CPU核数一般会比较大，因为CPU核数少就没有虚拟化的意义了。
从内存角度讲，宿主机也是高内存的，不同类型的云主机会分配到不同的内存，所以内存也不存在太大的问题。
现在很多系统的瓶颈都是在磁盘I/O上，虚拟化技术也不例外。哪怕宿主机用RAID提升磁盘I/O性能，性能提升还是有限。如果宿主机上的虚拟机过多，肯定会影响各个虚拟机的磁盘I/O性能。比如说，一个200核CPU的宿主机上有100个虚拟机在同时运行，那么平均分配到每个虚拟机的磁盘I/O性能只有宿主机的1%（当然所有的虚拟化技术都会进行磁盘读写的优化，所以实际上虚拟机的磁盘I/O性能要远远好于1%，但再好的优化也达不到所需要的性能）。因此，云平台都会有自己的调度算法来保证一个宿主机上的虚拟机个数不会超过可以容忍的上限。
总的来说，云主机的磁盘I/O肯定不如真正物理机上的磁盘I/O性能好，但在绝大多数场景下也是够用的。
性能的稳定性取决于以下两个因素。
云平台有没有做资源公平性的保证，有没有保证虚拟机对CPU、内存、磁盘的使用都有计量且是公平的。如果做了资源公平性保证，那么同宿主机内的虚拟机之间就不会相互影响使用。
云平台有没有超卖资源。所谓超卖是指宿主机实际只能支持100台虚拟机，但云平台卖了120台虚拟机。因为平均来说虚拟机的真正使用率并不高，所以云平台可以把用户平时多出来的资源再进行包装出去卖。但在最极端的情况下，用户的性能是得不到保证的。因此，一般的公有云平台都不会超卖，在私有云环境中超卖比较常见，因为可以明显减少企业内部的成本，而且企业内部各部门对极端情况有很好的容忍度。
总之，一般情况下，云主机的CPU和内存不是问题，其性能比一般的服务器要好。虽然磁盘I/O性能一般比不上物理机，但也基本够用。
搭建高可用服务
前面已经说了，云主机和普通服务器一样不可靠，所以用户不能只靠云主机来提供高可用的服务，原先在普通服务器上搭建高可用服务的方案都得移过来。
高可用服务最核心的思想是设计无状态的服务，不同团队有不同的实现方法。如果需要用户把原有的高可用方案都移植过来，工作量会相当大，而且有不少方案与网络直接相关，不能直接搬到云平台上。
一般的云平台都会提供负载均衡和高可用的数据库服务，用户利用负载均衡来实现Web服务的高可用，用云平台提供的数据库保证各种数据的持久化。以前用户在搭建高可用服务时，都会留下几台机器当备机，以防服务器出问题。而在云平台上，用户不需要购买备机，当有云主机出现问题时，申请一台顶上就可以。
需要注意的是，真正的云平台一定不是单机房的。单机房有可能出现各种意外情况，如整个机房断电。假如用户服务全部署在同一个机房的话，那么所有服务都将不可用，用户只能束手无策。所以推荐跨机房部署（Multi-zone）或者跨区域部署（Multi-region）。图1是Amazon zone-region概念图。
图1 Amazon zone-region概念图
Multi-zone是指在相近的区域建设几个机房，每个机房用光纤连接，保证各机房之间的ping值小于1ms，同时保证各个机房之间有足够大的带宽，这样一个机房的数据可以快速迁移到另一个机房。Multi-zone基本解决了单机房不可靠的问题，很多云服务的可靠性都依赖它。
图2展示的是云平台上一个简单的高可用服务，其中云平台提供的负载平衡和数据库服务都是跨机房的。但由于政策的原因，目前国内没有一家公有云平台有Multi-zone的实现，但相信不久的将来会有公有云服务商提供类似的服务。
图2 简单的高可用服务架构
使用EC2/云主机应注意的问题
安全和监控是使用云主机时最需要注意的问题。云平台都有安全组（Security Group）的概念，给不同的服务组件启用不同的安全组，因此不要全都使用默认的安全组设置，只开启需要使用的端口即可。有些云平台可以使用密码登录管理，而有些只能用私钥登录，建议最好禁用密码登录，只允许使用私钥登录。云平台都有会有自带的监控体系，使用时最好启用监控。
制作镜像。申请一台云主机，安装好需要的软件，设置好服务配置环境，随后制作一个镜像，就可以用这个镜像批量生成同样的环境，减轻重复劳动以节省时间。同时，在某些云主机出问题时，可以快速搭建新服务器顶上，减少服务单点时间。
在不需要时结束云主机。需要注意的是，结束云主机与关机是两个概念。用户把云主机关机，云平台会继续对用户进行计费，因为用户可以随时重启机器，云平台必须保留用户的虚拟机，用户还在占用资源，因此还需要计费。在真不需要时，要把云主机结束，而不是简单的关机。结束云主机意味着会把这台云主机上的所有数据清空。如果用户觉得有必要保存这些数据，可以采用其他手段保存。
备份。永远不要把重要数据只保存到云主机的本地硬盘上。重要的数据可以放到EBS/云硬盘上，或者定期保存到云存储上。国内外这样的悲惨例子很多。在使用公有平台时，把重要的用户数据保存在云主机的本地磁盘，结果宿主机出问题了，数据全部丢失了。重申一次，EC2/云主机和物理机一样不可靠，重要的数据一定要备份。
EBS/云硬盘
前面讲到，云主机不可靠，会宕机、会丢硬盘数据、会不可提供服务。大多数用户能容忍死机，毕竟可以马上重新申请一台新机器，用镜像快速搭建服务器，几分钟后就可以提供服务了，或者做成高可用服务，根本不怕死机。但丢数据是用户不能容忍的，因为数据才是服务的根本所在。
虽然用户可以把数据保存到云平台提供的数据库和云存储上，但用户需求是多种多样的，云平台提供的服务经常不够用。能不能提供一种方案，满足各种产品对数据持久的渴望同时又满足各种产品对数据存储方式的需求呢？于是EBS应运而生了。其实EBS也不是什么新鲜东西。很早以前大家就开始使用iSCSI方案来解决文件的持久化存储问题，EBS不过是新瓶装旧酒。
如果要用通俗的话来解释EBS，那么移动硬盘的比喻是最容易让人理解的。云主机相当于用户购买了一台物理主机，EBS相当于用户购买了一块移动硬盘，把移动硬盘插到主机上，就可以使用。在这台主机出问题时，直接把移动硬盘拔了放到另外一台云主机上就可以继续使用了。EBS和移动硬盘的区别在于，移动硬盘可能会坏，而每份数据在EBS后台都保留两份以上的副本，保证数据不会丢失，所以EBS最大的作用是给云主机提供一块不会坏的磁盘。
前面讲了虚拟化的一个瓶颈在于磁盘I/O。而EBS的另一个作用是缓解宿主机的磁盘I/O读写的压力。因为EBS是基于网络的，如果云主机的用户把所有重要数据都写到EBS上，其他数据写到本地磁盘上，那么相当于数据的写入多了一个很大的出口—网络，这大大缓解了宿主机本地磁盘读写的压力。而且宿主机的网卡不止一张，网络的吞吐量会超过本地磁盘的吞吐量，从而提高整个云主机的整体性能。
EBS不能独立于云主机而存在，正如移动硬盘离开了主机就没有使用价值了。同样，离开EBS单独存在的云主机也显然没什么优势了—不仅性能上会受到影响，如何低成本地将数据持久化保存也会成为一个难题。
EBS的性能到底如何呢？目前还没有标准答案。每家云平台的EBS实现并不一样，因此性能也不尽相同。但有两点比较明确：第一，目前EBS的性能不如本地磁盘；第二，EBS的性能取决于网络传输速度。
基于EBS，我们可以有更加廉价的高可用服务方案。如前面提到的高可用服务方案，都是需要使用负载均衡及至少两台云主机，费用会比较高。对服务停机时间有一定容忍性且对价格又比较敏感的客户来说，可以使用此方案。实施起来比较简单，将提供服务的软件环境做成镜像，将所有数据存储到EBS。当提供服务的云主机宕机时，根据镜像启动新的云主机，将EBS重新挂载上去，就可以直接恢复服务了。虽然宕机会耽误一些时间，但成本降低了。
EBS也有容量上限。目前，Amazon EBS的容量上限为1TB。之所以没有提供更大的容量，主要是因为空间太大对IO的性能影响比较大。
S3/云存储
如果说EC2和EBS解决了硬件层次的基础设施问题，让小公司也可以像大公司一样拥有丰富的IT资源，那么S3/云存储就是软件层次的基础设施，让小公司真正武装到牙齿，能够与资源丰富的大公司抗衡。
提到S3/云存储，不得不提Dropbox。Dropbox是小公司利用云计算发家致富，成为近100亿美元估值公司的经典案例。Dropbox使用S3/云存储作为后台存储，从而不用担心后台存储后院起火，不用做任何容量规划和容灾容错，因为这些问题Amazon都帮它解决了。这使得Dropbox可以专注于前端与客户端的开发。
为什么将S3/云存储当做基础设施的一部分呢？
S3/云存储解决了大规模数据待久化存储的问题。前面提到EBS虽然是持久化的，但有容量限制，最大容量为1TB。在这个信息爆炸的时代，每年产生的数据量会翻番。IDC报告宣称2012年全球新增的数据量会达到3ZB以上，如何保存海量数据成为一大难题。有S3/云存储后，用户可以把注意力集中到其他地方，更专注于业务而不用关心运维和容量规划。
S3/云存储提供的是高持久化服务。Amazon S3的耐久性是99.999999999%，可用性是99.99%，因此可认为保存到S3上的数据不会丢。用户可以把数据库的备份保存到S3/云存储，同时也把数据库的操作日志随时保存到S3/云存储，那么在需要对数据库进行灾难恢复时，用户可以有99.999999999%的可能性保证数据可以恢复到特定的时刻。
S3/云存储最大的特点是无限容量、高持久化、高可用，但它是一个Key-Value结构的存储。与EBS相比，它缺少目录结构，所以在用户的业务里，一般都会使用数据库保存在S3/云存储上数据的元信息。
理想的S3/云存储应该跨机房部署，也就是说可以跨机房访问。但目前国内的云存储服务商都还没有实现。
综上所述，EC2/云主机和EBS/云硬盘组成了云计算平台硬件的基础架构，S3/云存储是云计算平台软件层次的基础架构，在它们的基础上，可以搭建出其他云计算产品。对于一个任何一个公有云平台，这三者缺一不可。
作者郭理靖，盛大云计算云数据库产品部经理，负责开发MongoIC、数据库云等云端的数据库服务。曾就职于金山、淘宝等公司。
