BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

海豚浏览器的云端之路

| 作者 喻俨 关注 1 他的粉丝 发布于 2012年8月29日. 估计阅读时间: 12 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

海豚浏览器于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的知名服务在一段时间内不可用,比如InstagramPinterest等。事故一方面有外在原因(比如电力供应不足),另外一方面和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访问在同一内网的另外一台机器。
  • 对每日的费用做监控和分析。投入产出的优化是一个持续的过程,所以很有必要对费用情况做日常的统计和分析,有必要时还可以设定开销的报警来及时处理一些异常的行为。

寄语

海豚的云端之路一直在探索,还会继续的走下去。随着云平台技术的进一步发展,相信未来会有更多形式,更多创新的点子直接影响到更多创业型公司的成长,也希望这篇文章能够引导大家步向云端的步伐。


感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

支持! by 温 春海

很不错!www.cn-bricks.com

好文章 by wei ming

非常有技术含量,很有借鉴意义,顶海豚

实用 by Zhao Huijun

infoq上很难得见到这么实在的文章。

Re: 实用 by shi mike

同感同感,感觉现在一些虚头巴脑的文章越来越多了。

Re: 实用 by 霍 泰稳

谢谢Huijun和Mike的反馈,两位的建议很重要,能否说的再详细些,给我们的编辑提一些具体的建议,以便我们多做改进,谢谢。如果这儿不方便,可以直接邮件给我kevin@infoq.com,随时欢迎:)

背书 by sunly everly

书背的不错嘛~

Re: 实用 by shen kun

就喜欢这么朴实的文章,如果再详细点就好了,比如成本到底是多少$
4s.apple360qq.com

Re: 背书 by 霍 泰稳

必须的啊,我们来主导的啊:)请理解。

实用的经验 by Han Qinghai

我们现在也在使用Amazon的服务,不过目前只用到的AWS, EBS, Elastic IP等少数几个服务。除了IP有时会被GFW墙,以及楼主提到的AWS今年以来两次停机以外,目前感到满意,等未来有更多使用经验后希望能和大家分享。www.lotiar.com

阿里云怎么样,有哪位大哥用过吗? by Zhang James

阿里云怎么样,有哪位大哥用过吗?

国内使用速度如何? by Wei Shenghui

一直想用AWS 不知国内的可用性如何?

Re: 国内使用速度如何? by 曦 杨

这篇文章是篇实实在在的干货!非常感谢作者!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

12 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT