豆瓣首席架构师分享：豆瓣的基础架构

honghu2

豆瓣首席架构师分享：豆瓣的根本架构

小白叨一叨：洪强宁，豆瓣首席架构师。豆瓣第一名全人员工。清华结业后，洪强宁一向做嵌入式体系。在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担当了这个长处，这@对%e545W%付大范%3S5Qh%围@数据的迭代计较很是有效。在豆瓣的利用场景下，由于咱们的离线计较不少是举荐算法计较，这类计较触及大量的迭代算法，若是每次计较的成果都入磁盘再鄙人一轮计较加载，那机能是很差的，以是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。

本文作者：@洪强宁；转载自：InfoQ