转：海豚浏览器的云端之路
来自: http://www.infoq.com/cn/articles/dolphin-browser-cloud-way
海豚浏览器于2010年2月正式发布Android版本，在正式发布的近一年之后从一个纯客户端的产品开始迭代式地进化，逐渐加入各种云端服务的功能，海豚浏览器的云端之路也因此而启程。在创业之初，因为资源、人手的各种紧缺，自然而然的云端服务的部署也就成为首选。当时在国外的创业型小公司中，亚马逊云平台（Amazon AWS）备受青睐，因此我们也毫不犹豫的选择了AWS做为服务商，并且在海豚阅读（Dolphin Webzine）的第一次发布里做了大规模的尝试，随后又相继推出了海豚同步，海豚声纳等云服务。
起初接触云平台其实更多地仍然是把云平台当成普通的IDC主机租用服务在用，体验到的优势是相对于物理主机而言，云主机（instance）上线/下线都比较方便。而且不像国内很多主机服务是预充值或者预付款的消费模式，AWS平台的付款直接与信用卡挂钩，用多少就付多少，非常灵活。随着时间的推移，对云平台认识的浅显和不充分，导致我们吃了不少的苦头，当然也积累了不少经验教训。到现在，整个AWS云平台（见图1）的大部分服务我们都有实际使用的经验。
图1：AWS服务栈
云平台上的扩展性
说到云平台的使用就不得不先说说水平扩展（scale out）。之前我们的做法是在服务正式对外发布之前，部署多套同角色的机器（比如前端机器和应用服务器），就为了保证能够应对突发的流量增长。这些备用机器的部署和使用在云平台上其实是没有多大必要的。在AWS上完全可以通过ELB这样的一个弹性负载均衡器来自动实现服务的水平扩展，ELB支持多种协议，并且可以自定义水平扩展的条件，对于服务的开发者来说，这省了不少开发的活，而且对于普通的负载均衡应用场景来说，它完全可以替代Nginx或者HAProxy。
对于垂直扩展（scale up）来说，有两点比较重要，一是对云主机升降级时类型的选择，二是了解云主机的生命周期。EC2上的云主机有固定的好几种类型，首选一般都是64位机器，这样方便内存扩容，如果对于CPU消耗比较高（比如HTTPS连接），那么优先选High-CPU型的，如果是对内存要求比较大（比如MongoDB），那么优先选High-Memory型的。海豚的大多数机器选型集中在micro/small用作监控和前端，small/medium部署应用服务、消息队列，medium/large做数据库和离线计算。xlarge再往上用得很少，基本上都靠水平扩展解决了。对于云主机的生命周期来说，restart和stop/start是有区别的，升降级的时候必须要stop云主机，升降级完毕再启动的时候，机器的内部IP会发生变化（IP通过DHCP分配的），这一点经常会给依赖IP的服务配置造成问题。解决的办法有两个，一个是通过VPC来自己控制IP地址分配，另外一个就是使用Elastic IP这样的静态地址。
云平台上的存储
和计算资源一样，存储资源是一个云平台的核心要素之一。云平台上的存储按照使用场景分为三大类型：
- 临时存储。AWS的instance storage就是临时存储的一种，主要用来存放缓存和一些中间结果等内容。要注意的是临时存储的内容在云主机stop以后就会被清空，因为通过df命令往往看不出来这一点，所以之前有过把instance storage当成持久化存储的经历，损失就很惨重。
- 持久化存储。持久化存储最常指的就是物理硬盘，在AWS平台上，EBS就是这样的一个可以以任意大小被挂载的“硬盘”，实际上它的实现是一个网络文件系统，因此它的访问速率受限于网络带宽，而且不是那么稳定。通常可以通过在EBS标准的volume上做RAID或者使用最新推出的Provisioned IOPS volume来解决I/O速率问题。另外尽管EBS是持久化存储，并不意味着它就不会发生数据的丢失，EBS的年化不良率有0.1%-0.5%，因此对于单存储节点来说需要定期的去做EBS的镜像和备份，以防止意外的发生。
- 大规模冗余存储。S3就是这种存储类型的样例。S3不是一个文件系统的架构，I/O速率和延迟也不及EBS，但它的好处在于一方面可以在一个比较低的价格（和EBS差不多）提供99.999999999%的可靠性，另外一方面可以存取非常大规模，比如PB级别的数据，这些数据可以在不限于AWS的任何地方使用。海豚就用S3存储了几乎所有的镜像、数据备份和各种日志。除此之外，S3和CloudFront（AWS的CDN解决方案）集成程度很高，因此海豚也通常使用S3作为APK等内容分发的渠道。
云平台上的服务高可用
虽然云平台有着一个好听的名字，但它绝对不是完美的。那些认为在云平台上部署了服务就能自动保证高可用、高扩展的念头都是不切实际的幻想。就拿AWS来说，它的问题就不少，其中最突出的当属数据中心本身的可靠性经常有突发的挑战。比如AWS的美东区（US-East Region）就是一个事故高发区，在2012年4月和6月已经各发生了一次大规模的服务中断，导致很多依赖于AWS的知名服务在一段时间内不可用，比如Instagram、Pinterest等。事故一方面有外在原因（比如电力供应不足），另外一方面和AWS本身的发展历史也有关系。因为美东区建立得比较早，基础设施相对陈旧，再加上有很长一段时间相对于其它区的云主机要便宜一些，因此很容易因为各种瓶颈制约产生问题。所以海豚现在新上线的云服务都尽量放在AWS的其它region（比如美西区，用CloudPing可以测试你访问AWS各个区的延迟），而且从数据部署结构上尽量采用跨zone和跨region的方案，如图2所示，三个DB服务器部署在两个不同的region，另外两个服务器在同一个region但在不同的zone，然后三台服务器之间做一个同步复制。
图2：高可用的部署方案
云平台的开放性
对于一个好的云平台来说，它的开放性首先体现在其对外提供的API上。AWS平台支持Java/PHP/Python/Ruby/.NET等SDK，通过这些SDK就能够直接完成web界面上做的事情。海豚各种服务的上线和部署都通过Fabric结合这些API来完成，包括AWS EC2 API和AWS的Python接口boto。整个上线和部署的过程不需要人工干预，因此既提高了速度、降低了维护成本，又减少了人工出差错的可能。
其次，大多数云平台都会对安全考虑的比较多。举一个例子，EC2上的云主机是通过安全组（Security Group）来控制端口的访问策略，这样安全组就做了最外层的一个“访问防火墙”，完全可以取代iptables或者ufw配置的一些策略。另外IAM对云平台用户和资源访问权限的管理做了很细粒度的控制，这么精细的控制使得公司内部运维和开发的角色不再那么明显，很好地促进了运维和开发人员之间的协作和交流。迄今为止，海豚正式的全职运维人员还不到3人，他们和开发人员一起管理和使用着几百台机器。
除了这些以外，AWS还提供了免费的基础监控功能CloudWatch，不过这个基础的监控还远远满足不了我们的需求，再加上国内国外两套不一样的基础设施（国内租用的机房），我们还是选择了监控宝加上自己的监控，双重覆盖来达到比较好的监控效果。
在云平台上节省开支
对于初创企业来说，开源节流是一个好的习惯。利用云平台本身其实就已经节省和分摊了固定基础设施投入的开销。在云平台之上，依据每个云平台的特点，其实还有不少可以优化的地方。
- EC2上使用reserved instance预定一定比例的特定类型机器或者使用spot instance来做一些临时的事情都比启动on demand instance要划算，一般来说可以节省1/3甚至更多的开销。海豚就利用了EMR（间接启动spot instance）来做大数据的分析和计算。
- 用LVM来提高EBS的使用率。EBS的计费是按照分配的大小而不是实际使用的大小来计算的，比如创建了一个50G大小的EBS，但实际只使用了5G，那么费用仍然按照50G来算。我们通过LVM可以将底层的EBS挂载透明化，这样EBS可以按需来小块挂载，不需要提前分配一个比较大的空间，使用率也因此得到较大的提升。
- 在terminate云主机时记得及时清理并删除与之相关联的EBS store、Elastic IP或者镜像，所有这些都是不会自动删除并且会造成隐性开销的地方。
- 动态调整机器在不同时段的使用数目。EC2的云主机是按照在线小时计费的，用户使用服务通常都具有一定的模式，比如早上、中午和晚上分别有一次访问的高峰，那么其它时段机器的数量就可以做相应的缩减。通过使用ELB可以实现一部分，也可以通过AWS的API加上cron jobs或者Quartz来自己实现动态调整机器数量的功能。
- 网络带宽是一个不小的开销，这一点最容易被忽视，因为在传统的IDC机房和国内不少的云主机服务都是租用的固定带宽。而在AWS上，带宽的使用是没有限制的，计费按照实际的传输量，所以其开销很容易就超过你的想象。对于那些访问量比较大的网站或者服务来说，压缩、客户端缓存等都是必不可少的减少带宽消耗的手段。另外注意跨region的数据传输也是要收费的，这还包括一台机器通过外网IP访问在同一内网的另外一台机器。
- 对每日的费用做监控和分析。投入产出的优化是一个持续的过程，所以很有必要对费用情况做日常的统计和分析，有必要时还可以设定开销的报警来及时处理一些异常的行为。
寄语
海豚的云端之路一直在探索，还会继续的走下去。随着云平台技术的进一步发展，相信未来会有更多形式，更多创新的点子直接影响到更多创业型公司的成长，也希望这篇文章能够引导大家步向云端的步伐。
