豆瓣的基础架构

摘要：本文根据 InfoQ 中文站对豆瓣洪强宁（@hongqn）的沟通交流整理而成。洪强宁介绍了豆瓣的架构和组件，并分享了豆瓣基础平台部的一些团队经验。

豆瓣整个基础架构能够粗略的分为在线和离线两大块。在线的部分和大部分网站相似：前面用 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。