解析豆瓣的网站建设技术架构

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

豆瓣的技术架构与主要组件

豆瓣作为一个早期就选择以python为主要编程语言的公司，网站所使用到的技术很多都与python相关，包括主要框架quixote、自行实现的dpark等等。在其它技术的选择上，并没有太大不同：nginx、mysql、memcached、beansdb、redis……都是知名开源项目。在这些开源项目之上，豆瓣根据自己产品的特性，针对性地做了配置与部署设置。

除了使用开源项目，豆瓣也根据自身需要自主研发或实现了一些产品，比较有特色的如dae、dpark等等。

dae全名douban application engine，顾名思义它是一个类似于gae、sae的内部paas系统。使用这样的paas有很多好处，比如第三方库数量丰富并且支持多个版本并存、资源配置灵活等等，能够为工程师省去很多不必要的工作。

beansdb是dae中非常重要的一个组件，设计思想源于亚马逊的dynamo，但是简化了dynamo的一些复杂之处。beansdb主要应用于小型文本和中型的图片、音频，它们的共同特点在于写次数特别少，这也正是beansdb所擅长的领域。
dpark类似于spark，是豆瓣用python实现map-reduce类似框架。虽然python的性能低于基于jvm的clojure，但这样做避免了程序员程序员进入不熟悉的领域，而且豆瓣使用开源项目的原则是：如果无法完全掌握，宁可不用。“此外将spark移植到python上也很简单，基本上是一对一的翻译。

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的编写使用了函数式语言的特点，所以可以写的非常简洁：