BT

豆瓣的基础架构

作者 洪强宁 发布于 2014年4月9日 | 注意: 挥一挥衣袖,带走满满干货,关注活动大本营,时不时发福利呦!

本文根据InfoQ中文站对豆瓣洪强宁(@hongqn)的沟通交流整理而成。洪强宁介绍了豆瓣的架构和组件,并分享了豆瓣基础平台部的一些团队经验。文中截图来自洪强宁在2013年CTO俱乐部中的分享。

嘉宾介绍

洪强宁,豆瓣首席架构师。豆瓣第一位全职员工。清华毕业后,洪强宁一直做嵌入式系统。在2002年开始接触Python语言,从硬件工程师变为软件工程师,对一种语言在计算机底层如何工作有深入的理解。

架构

豆瓣整个基础架构可以粗略的分为在线和离线两大块。在线的部分和大部分网站类似:前面用LVS做HA,用Nginx做反向代理,形成负载均衡的一层;应用层主要是做运算,将运算结果返回给前面的用户,DAE平台是这两年建起来的,现在大部分豆瓣的应用基本都跑在DAE上面了;应用后面的基础服务也跟其他网站差不多,MySQL、memcached、redis、beanstalkd,不一样的是NoSQL的选择——BeansDB,这是我们在几年前开源的KV数据库,也是国内比较早开源的KV数据库。

BeansDB项目可以说是一个简化版的AWS DynamoDB,该项目在2008年启动,2009年开源,第⼀版使⽤tokyo cabinet作为存储引擎,2010年使⽤bitcask存储格式重写了存储引擎,性能更好。BeansDB对key做哈希运算找到节点来实现分布和冗余, 一个写操作会写好几个节点,而现在的配置是写三份读一份。BeansDB主要的特点是支持海量KV数据库——相比Redis这种支持几十个G到几百个G的内存KV数据库,BeansDB可以支持到上百T的数据。另外BeansDB最大的好处就是运维很简单,性能、可用性、扩容都很好,也实现了最终一致性。

BeansDB中间的Proxy是用Go语言写的,也是一个开源的组件。整体来说BeansDB的设计结构比较简单,相比Redis那种有多种value 类型的方式,BeansDB的Value比较简单一些。

在豆瓣内部建立了两个不同的BeansDB集群,一个是doubandb,一个是doubanfs,分别针对不同的场景。doubandb主要存储小型文本数据,如影评、用户个人介绍、帖子内容等,这样的好处是可以大大降低我们对MySQL的性能依赖,算是给MySQL减负;doubanfs主要存放图片和音频等中型数据。

DAE可以说是基于很多以前积累的、旧的组件做起来的。我们做的这种对内的PaaS,相比对外的PaaS而言做了很多简化,尤其是安全方面如应用间隔离、权限管理方面,我们都不用像公有云那样花大量精力去做,所以工作量其实还好。DAE现在在计划开源,当然它现在只支持Python应用。以后我们也许会让DAE支持Go语言。

上面是在线的部分,对高可用性和低时延有较大要求。离线部分则包括数据挖掘、数据分析等,技术组件分别是海量分布式文件系统MooseFS,这个文件系统的结构类似HDFS,用C语言编写,其好处在于FUSE模块实现的比较好,用文件系统就可以直接进行操作,而不需要专门的命令,可以支持的数据量也很大。另外就是自己开发的分布式计算平台DPark

DPark顾名思义是Spark的Python实现,不过现在已经跟Spark越来越不一样了。和 Hadoop 相比,Spark可以使用内存做为缓存加速分布式计算,DPark继承了这个优点,这对于大规模数据的迭代计算非常有用。在豆瓣的应用场景下,因为我们的离线计算很多是推荐算法计算,这种计算涉及大量的迭代算法,如果每次计算的结果都入磁盘再在下一轮计算加载,那性能是很差的,所以DPark能够大幅提升性能。另外,因为DPark的编写使用了函数式语言的特点,所以可以写的非常简洁:

到目前(2014年3月),DPark的集群规模和处理数据量已经比去年多了一倍左右,一天要处理60~100TB左右的数据。

团队

当前,我所负责的豆瓣平台部一共包括四个部分:核心系统,这块也是由我直接带领的,共6名工程师;DAE,现在是彭宇负责,共4名工程师;DBA两人;SA两人。

平台部负责的项目大多是跟业务无关的东西,贴近应用层的主要在产品线团队做,这个分工跟豆瓣工程团队的发展历史有关。早期豆瓣工程师还不多的时候,就已经分为两种倾向,一种是偏业务的,就是去做用户能看得见的东西;另一种是支持性的,运行在业务层下面、不被用户所感知的东西。下面这一层就衍变成了平台部门。

在豆瓣,不管是做产品还是做平台的工程师,技术实力都比较强,一个项目应该从哪个部门发起,并不是看这个任务的难度,而是看它是公共的还是业务特有的。有些项目即使未来可能会成为公共的,但一开始只是一个产品线需要,那么它也会从产品线发起。比如豆瓣的短信服务,最开始是产品线有需求,所以这些服务都是由他们发起完成的,平台这边主要负责提供建设服务的架构,比如DoubanService,告诉他们一个服务怎样去写、怎样去部署、怎样去对用户开放。短信服务后来成为很多产品线都在使用的服务,同时这个系统本身也越来越成熟,那么它逐渐就被转移到SA团队来进行维护。

核心系统组做过的项目,包括刚才提到的DPark、BeansDB,还有MooseFS这些二次开发的,还有搜索服务、信息推送的长连接服务等,大大小小差不多有十几个。有些项目处于维护状态,所以需要的人不是那么多。

跟豆瓣其他工程团队一样,平台部也强制大家做code review。这对于核心系统来说很重要的一点在于,code review是一个知识共享的过程:我们人少项目多,所以很多项目都是一个人做主力,很容易就变成其他人不知道你这个项目具体是什么情况,而强制code review就可以实现一种公开透明的状态,让大家都了解每个项目在做什么。

在平台部,因为你做的所有东西都会影响到全公司,测试显然很重要,我们还做了另一件事来进行质量保证,那就是一个项目由谁来主导上线,谁就要负责这个项目的故障响应——所有运维、调整系统等SA的工作,你这个第一负责人都要参与。你做的东西的好坏会影响到自己晚上能不能睡好觉,所以大家就会比较谨慎。灰度上线也是我们这边的通用做法。

平台部还有一点跟产品线不一样的是,平台部没有产品经理,所以你的工作方向更多是自己去找的,每个人自己发现问题的能力更重要。我们每个月都会问大家,你这个月想要解决什么问题?如果方向大家一致认可,那就去做。

最后,对于新技术的引入上,豆瓣整体是比较偏激进的,我们鼓励大家去看看新的技术。当然我们也不会看到新的就上,这里面有一些限制:一个是比较重要的服务如果要上新的技术,一定要有成功案例,且成功案例有跟我们量级差不多的规模,这样可以降低风险;另一个是对于引入的新技术一定要吃透——大部分引入的技术肯定是要做二次开发的,所以拿进来的技术你必须保证能完全理解它的代码结构,出了问题能修,能去掉自己无法掌控的东西。这也是为什么豆瓣不太可能在重要的地方引入Java的原因,除非别无选择,我们一般都是Python、C和Go。

采访人介绍

庄表伟,目前在华为2012实验室的研发能力中心工作。也是80年代中期就开始接触计算机和编程,一直对软件开发、技术社区、开源软件等抱有浓厚的兴趣。近期关注的重点是:如何将开源社区的经验,应用于企业内部实践。


感谢杨赛对本文的审校。本采访由庄表伟策划完成。

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

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

不错 by jiang changren

我也觉得,平台组就是应该在精,而不在多,以解决问题为导向,剥离业务,专注于基础服务。

方案应对问题 by 詹 鹏

具体的方案应对具体的问题,解决问题的设计,就是好的设计

个人觉得这样的架构有点残 by 杨 曦

个人觉得大量使用偏门技术跟自创技术的团队在CEO看来就是脑残行为,极大的加深了解决问题的难度和招人的陈本,出了问题没人会改,人跑了招不到,浪费时间在研究牛角尖而不是业务

不错 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通知我

4 讨论
提供反馈
错误报告
商务合作
内容合作
Marketing
InfoQ.com及所有内容,版权所有 © 2006-2016 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT