豆瓣的基礎架構

摘要：本文根據 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。