BT

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

豌豆荚质量总监分享:从自建机房到云计算的演进之路

| 作者 杨赛 关注 3 他的粉丝 发布于 2014年8月15日. 估计阅读时间: 9 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

以下内容整理自InfoQ中文站跟豌豆荚质量总监高磊的一次采访对话。

豌豆荚作为创新工场的首批孵化项目之一,从2009年12月发展至今,用户量已经增长至4.1亿。豌豆荚的主要业务在国内,帮助用户在手机上发现、获取和消费应用、游戏、视频、电子书、壁纸等娱乐内容,在东南亚地区等海外市场也做了类似的业务探索。

这样一个快速增长的系统,对IT的底层支持也是一个相当大的挑战。本文将介绍豌豆荚在IT基础架构、工具、流程方面做过的一些事,在不同需求之间如何平衡,团队职责的划分,以及遇到的一些挑战。

受访者简介

高磊,2012年4月加入豌豆荚,现任豌豆荚质量总监,负责豌豆荚的工程生产力部门(Engineering Productivity,EP)。长期关注QA这个话题,对流程、开发技术、自动化测试、敏捷、持续集成、运维、代码库、生产力工具等方向均有所涉猎。

基础设施的建设与增长

豌豆荚诞生于2009年12月,机房部署是从2010年年初开始。那时候因为还没有成熟的云服务可用,所以选择了自建机房的方案。到目前为止,我们已经在全国各地尤其是北京、天津地区建立了多个节点。

从对基础设施资源使用的情况来看,我们的主要业务对带宽和 CDN 资源用量会比较高;而从单一业务来看,各类数据挖掘和分析对服务器资源的占用是最大的。豌豆荚从创建一开始就是数据驱动的业务,有很强的用户行为导向,因此数据挖掘的工作量非常多。

数据挖掘主要是基于Hadoop集群。豌豆荚有一个数据挖掘团队专门做产品研发(主要是面向内部),而我们这个团队则提供硬件资源和底层的Hive、HBase等基础设施的支撑和维护。整体的数据量、计算量一直都在增长,一开始的几年增长极快,最近几年稍微慢一些,也有每年几倍的增长。

差不多在2011年左右,我们开始尝试做海外版的豌豆荚Snappea。当时评估过在海外自建机房的可行性,在考察过各个地方不同位置、不同IDC、不同运营商的选项之后,我们发现即使在进展顺利的情况下,也至少需要两三个月才能建成,这个时间成本太高。如果不自建,那就只有公有云这一个选择,正好当时我们很多工程师都自己用过亚马逊的AWS,出于时间、知识门槛、成本的考量,就决定在海外使用AWS作为我们的基础支撑。

团队

EP团队的目标很明确:在主要产品的完整生命周期内,实现一流的效率、质量和服务稳定性;至于具体用什么技术或者方法,则并不做限制。一开始我们团队比较关注流程、开发工具等方面,现在我们对CI、代码库、自动化测试、运维、基础设施建设等各个方面都做了很多工作,有时候工程师要引入一些新的基础设施相关的技术或框架,我们也会进行review它们是不是靠谱,总的目标就是让产品从开始开发到线上生产环境运行这整条路径下,其稳定性和质量都有所保证。

现在整个团队的全职工程师有不到三十人,其中运维团队有十个人,而且他们也都会承担开发任务(我们叫做SRE,网站可靠性工程师),运维过程中需要什么工具、支持系统,都是由他们自己开发。运维团队的主要工作都在维护我们自建的机房系统上,AWS上面现在平均投入的维护人力差不多只有三分之一个人。这一方面是因为AWS的维护成本确实低,另一方面也是因为我们在AWS上面的规模还不是太大。

从代码库到生产环境

我们的产品发布流程还是相对成形的。不同的产品线有不同的发布频率,比较稳定的在一周两次,有些比较早期的项目可能一天一次,没有太大的压力。

产品下一个release要发布哪些feature、发布周期设置成多久间隔,主要是由产品经理和设计师来决定,工程师实现需求。到了发布日期截止之前,从代码库的主干拉一支发布分支出来做feature freeze和最后的验收测试,到发布分支上只能做bug修复,不再接受新的feature。

有的产品线有统一的测试机制,有的产品线则主要靠工程师自己做测试。无论是哪种测试模式,在进入CI做集成之前和之后都会统一进行静态检查和已有的单元测试用例,然后才上到staging环境。从staging环境开始就属于运维负责的领域了,我们的staging没有真实的流量,但是环境跟线上是一模一样的,可以说是一直处在最新版本的服务,然后staging再跟线上环境同步代码。

这一套自动发布、部署的流程虽然也不是很完善,比如持续集成的检查点还不够多,单元测试率还比较低,不过还算跑的不错。现在AWS上也是同样的一套部署过程,当时适配起来也很快,大概做了一个星期就跑上去了。

监控

我们的监控系统要实现的目的无非是两个:实时的报警,以及可以追溯的历史数据,其他都是衍生的功能。跟大部分互联网公司一样,我们一开始做监控也都是用开源软件搭起来的,不过开源的监控软件现在越来越不能满足我们的需求。

这里面有两个挑战:

  1. 性能问题
  2. 数据采集的定制化问题

数据采集的定制化主要是涉及到一些业务数据的采集,通用的开源软件也还是要做适配,需要自己去写实现,这个其实还好。性能问题是一个更加严重的问题,这个问题来自于三个方面:越来越多的机器、越来越多的采集项、越来越高的采集频率。

以前我们监控,可能5分钟抓一次数据就行;现在我们希望做到秒级的采集。监控系统需要有实时分析日志的能力,而到机器数量增长到千台以上之后,要做秒级的采集和分析,无论是数据收集的速度还是数据分析的速度都会遇到瓶颈。

所以现在我们正在自己重写一套监控的系统,专门针对我们自建的机房体系,包括对多机房架构的支持、与资产系统的对接等等。而AWS上我们直接使用了其CloudWatch监控功能,目前来讲完全够用了。

一些挑战

因为业务跟数据密切相关,而我们部门承担了给数据分析团队提供基础设施的责任。

业务对数据报告的需求一般有两类:

1、定制化的、定期的数据指标报告

此类报告有按天的、按周的、按月的或者按小时的,一般都是比较常规的监测指标,持续监控、持续分析,中间数据保留完整,需要的计算量和存储量容易预测。这种报告需求比较容易满足。

2、按需出报告

此类需求经常是针对之前没有中间数据的监测值,之前并不知道需要针对此类数值做分析,现在忽然发现需要了,业务部门会要求一次性分析过去半年到一年跟该数据相关的趋势。此类报告往往很耗时,有时候我们做估算,一年的数据分析完毕需要用多长时间,结果可能是用我们现在的计算资源,可能要分析一个月才能产出他想要的报告,但这是无法满足业务需求的。

要提高分析速度,最直接的做法就是投入更多的计算资源——放在我们自建的机房就是扩容,如果用公有云就是起更多的实例。一方面扩容是要做的,另一方面现在AWS进入国内,我们也在考察使用AWS来做这种任务的可能性。

实际上我们用了AWS以来,也逐渐发现我们之前系统设计的并不是那么好。比如我们在海外的数据分析,原本是想用EMR的,但是发现我们现在这套东西搬过去不好直接用,只好基于EC2来做这个事情。为什么呢?因为AWS的理念是让不同的组件做不同的事,比如EC2只做计算,数据持久化存储最好都放在S3;但是我们的系统一开始设计并没有考虑这些,数据都存在本地计算节点上,如果要重构,需要投入的时间还是挺多的。

包括scaling这件事也是,现在我们基本没有用到scaling,因为我们的应用上下游之间的依赖关系太重,所以对scaling机制支持的不好。这些都是需要努力的方向。一个比较好的事情是,我们豌豆荚的工程师都是比较有情怀的,对重构这件事情比较支持。当然,这里面有投入成本和产出的考量,我们首先要满足的还是业务需求,解决业务问题,至于重构的工作,会随着我们在AWS上的业务规模更大而变得优先级更高。

最后想分享的是,EC2的reserved instance如果用好了,能够比on demand模式节省很多。我们一开始不知道AWS除了on demand之外还有reserved instance、spot instance这些玩法,最近才刚知道。Reserved instance非常适合Web Service使用,临时性数据分析用spot instance则比较合适。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的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通知我

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT