本文根據(jù)InfoQ中文站對(duì)豆瓣洪強(qiáng)寧（@hongqn）的溝通交流整理而成。洪強(qiáng)寧介紹了豆瓣的架構(gòu)和組件，并分享了豆瓣基礎(chǔ)平臺(tái)部的一些團(tuán)隊(duì)經(jīng)驗(yàn)。文中截圖來(lái)自洪強(qiáng)寧在2013年CTO俱樂(lè)部中的分享。

　　架構(gòu)

　　豆瓣整個(gè)基礎(chǔ)架構(gòu)可以粗略的分為在線和離線兩大塊。在線的部分和大部分網(wǎng)站類似：前面用LVS做HA，用Nginx做反向代理，形成負(fù)載均衡的一層；應(yīng)用層主要是做運(yùn)算，將運(yùn)算結(jié)果返回給前面的用戶，DAE平臺(tái)是這兩年建起來(lái)的，現(xiàn)在大部分豆瓣的應(yīng)用基本都跑在DAE上面了；應(yīng)用后面的基礎(chǔ)服務(wù)也跟其他網(wǎng)站差不多，MySQL、memcached、redis、beanstalkd，不一樣的是NoSQL的選擇——BeansDB，這是我們?cè)趲啄昵?a href=/yuedu/kaiyuan/ target=_blank class=infotextkey>開源的KV數(shù)據(jù)庫(kù)，也是國(guó)內(nèi)比較早開源的KV數(shù)據(jù)庫(kù)。

　　BeansDB項(xiàng)目可以說(shuō)是一個(gè)簡(jiǎn)化版的AWS DynamoDB，該項(xiàng)目在2008年啟動(dòng)，2009年開源，第?版使?tokyo cabiNET作為存儲(chǔ)引擎，2010年使?bitcask存儲(chǔ)格式重寫了存儲(chǔ)引擎，性能更好。BeansDB對(duì)key做哈希運(yùn)算找到節(jié)點(diǎn)來(lái)實(shí)現(xiàn)分布和冗余， 一個(gè)寫操作會(huì)寫好幾個(gè)節(jié)點(diǎn)，而現(xiàn)在的配置是寫三份讀一份。BeansDB主要的特點(diǎn)是支持海量KV數(shù)據(jù)庫(kù)——相比Redis這種支持幾十個(gè)G到幾百個(gè)G的內(nèi)存KV數(shù)據(jù)庫(kù)，BeansDB可以支持到上百T的數(shù)據(jù)。另外BeansDB最大的好處就是運(yùn)維很簡(jiǎn)單，性能、可用性、擴(kuò)容都很好，也實(shí)現(xiàn)了最終一致性。

　　BeansDB中間的Proxy是用Go語(yǔ)言寫的，也是一個(gè)開源的組件。整體來(lái)說(shuō)BeansDB的設(shè)計(jì)結(jié)構(gòu)比較簡(jiǎn)單，相比Redis那種有多種value類型的方式，BeansDB的value比較簡(jiǎn)單一些。

　　在豆瓣內(nèi)部建立了兩個(gè)不同的BeansDB集群，一個(gè)是doubandb，一個(gè)是doubanfs，分別針對(duì)不同的場(chǎng)景。doubandb主要存儲(chǔ)小型文本數(shù)據(jù)，如影評(píng)、用戶個(gè)人介紹、帖子內(nèi)容等，這樣的好處是可以大大降低我們對(duì)MySQL的性能依賴，算是給MySQL減負(fù)；doubanfs主要存放圖片和音頻等中型數(shù)據(jù)。

　　DAE可以說(shuō)是基于很多以前積累的、舊的組件做起來(lái)的。我們做的這種對(duì)內(nèi)的PaaS，相比對(duì)外的PaaS而言做了很多簡(jiǎn)化，尤其是安全方面如應(yīng)用間隔離、權(quán)限管理方面，我們都不用像公有云那樣花大量精力去做，所以工作量其實(shí)還好。DAE現(xiàn)在在計(jì)劃開源，當(dāng)然它現(xiàn)在只支持Python應(yīng)用。以后我們也許會(huì)讓DAE支持Go語(yǔ)言。

　　上面是在線的部分，對(duì)高可用性和低時(shí)延有較大要求。離線部分則包括數(shù)據(jù)挖掘、數(shù)據(jù)分析等，技術(shù)組件分別是海量分布式文件系統(tǒng)MooseFS，這個(gè)文件系統(tǒng)的結(jié)構(gòu)類似HDFS，用C語(yǔ)言編寫，其好處在于FUSE模塊實(shí)現(xiàn)的比較好，用文件系統(tǒng)就可以直接進(jìn)行操作，而不需要專門的命令，可以支持的數(shù)據(jù)量也很大。另外就是自己開發(fā)的分布式計(jì)算平臺(tái)DPark。

　　DPark顧名思義是Spark的Python實(shí)現(xiàn)，不過(guò)現(xiàn)在已經(jīng)跟Spark越來(lái)越不一樣了。和Hadoop 相比，Spark可以使用內(nèi)存做為緩存加速分布式計(jì)算，DPark繼承了這個(gè)優(yōu)點(diǎn)，這對(duì)于大規(guī)模數(shù)據(jù)的迭代計(jì)算非常有用。在豆瓣的應(yīng)用場(chǎng)景下，因?yàn)槲覀兊碾x線計(jì)算很多是推薦算法計(jì)算，這種計(jì)算涉及大量的迭代算法，如果每次計(jì)算的結(jié)果都入磁盤再在下一輪計(jì)算加載，那性能是很差的，所以DPark能夠大幅提升性能。另外，因?yàn)镈Park的編寫使用了函數(shù)式語(yǔ)言的特點(diǎn)，所以可以寫的非常簡(jiǎn)潔：

　　到目前（2014年3月），DPark的集群規(guī)模和處理數(shù)據(jù)量已經(jīng)比去年多了一倍左右，一天要處理60~100TB左右的數(shù)據(jù)。

　　團(tuán)隊(duì)

　　當(dāng)前，我所負(fù)責(zé)的豆瓣平臺(tái)部一共包括四個(gè)部分：核心系統(tǒng)，這塊也是由我直接帶領(lǐng)的，共6名工程師；DAE，現(xiàn)在是彭宇負(fù)責(zé)，共4名工程師；DBA兩人；SA兩人。

　　平臺(tái)部負(fù)責(zé)的項(xiàng)目大多是跟業(yè)務(wù)無(wú)關(guān)的東西，貼近應(yīng)用層的主要在產(chǎn)品線團(tuán)隊(duì)做，這個(gè)分工跟豆瓣工程團(tuán)隊(duì)的發(fā)展歷史有關(guān)。早期豆瓣工程師還不多的時(shí)候，就已經(jīng)分為兩種傾向，一種是偏業(yè)務(wù)的，就是去做用戶能看得見的東西；另一種是支持性的，運(yùn)行在業(yè)務(wù)層下面、不被用戶所感知的東西。下面這一層就衍變成了平臺(tái)部門。

　　在豆瓣，不管是做產(chǎn)品還是做平臺(tái)的工程師，技術(shù)實(shí)力都比較強(qiáng)，一個(gè)項(xiàng)目應(yīng)該從哪個(gè)部門發(fā)起，并不是看這個(gè)任務(wù)的難度，而是看它是公共的還是業(yè)務(wù)特有的。有些項(xiàng)目即使未來(lái)可能會(huì)成為公共的，但一開始只是一個(gè)產(chǎn)品線需要，那么它也會(huì)從產(chǎn)品線發(fā)起。比如豆瓣的短信服務(wù)，最開始是產(chǎn)品線有需求，所以這些服務(wù)都是由他們發(fā)起完成的，平臺(tái)這邊主要負(fù)責(zé)提供建設(shè)服務(wù)的架構(gòu)，比如DoubanService，告訴他們一個(gè)服務(wù)怎樣去寫、怎樣去部署、怎樣去對(duì)用戶開放。短信服務(wù)后來(lái)成為很多產(chǎn)品線都在使用的服務(wù)，同時(shí)這個(gè)系統(tǒng)本身也越來(lái)越成熟，那么它逐漸就被轉(zhuǎn)移到SA團(tuán)隊(duì)來(lái)進(jìn)行維護(hù)。

　　核心系統(tǒng)組做過(guò)的項(xiàng)目，包括剛才提到的DPark、BeansDB，還有MooseFS這些二次開發(fā)的，還有搜索服務(wù)、信息推送的長(zhǎng)連接服務(wù)等，大大小小差不多有十幾個(gè)。有些項(xiàng)目處于維護(hù)狀態(tài)，所以需要的人不是那么多。

　　跟豆瓣其他工程團(tuán)隊(duì)一樣，平臺(tái)部也強(qiáng)制大家做code review。這對(duì)于核心系統(tǒng)來(lái)說(shuō)很重要的一點(diǎn)在于，code review是一個(gè)知識(shí)共享的過(guò)程：我們?nèi)松夙?xiàng)目多，所以很多項(xiàng)目都是一個(gè)人做主力，很容易就變成其他人不知道你這個(gè)項(xiàng)目具體是什么情況，而強(qiáng)制code review就可以實(shí)現(xiàn)一種公開透明的狀態(tài)，讓大家都了解每個(gè)項(xiàng)目在做什么。

　　在平臺(tái)部，因?yàn)槟阕龅乃袞|西都會(huì)影響到全公司，測(cè)試顯然很重要，我們還做了另一件事來(lái)進(jìn)行質(zhì)量保證，那就是一個(gè)項(xiàng)目由誰(shuí)來(lái)主導(dǎo)上線，誰(shuí)就要負(fù)責(zé)這個(gè)項(xiàng)目的故障響應(yīng)——所有運(yùn)維、調(diào)整系統(tǒng)等SA的工作，你這個(gè)第一負(fù)責(zé)人都要參與。你做的東西的好壞會(huì)影響到自己晚上能不能睡好覺(jué)，所以大家就會(huì)比較謹(jǐn)慎。灰度上線也是我們這邊的通用做法。

　　平臺(tái)部還有一點(diǎn)跟產(chǎn)品線不一樣的是，平臺(tái)部沒(méi)有產(chǎn)品經(jīng)理，所以你的工作方向更多是自己去找的，每個(gè)人自己發(fā)現(xiàn)問(wèn)題的能力更重要。我們每個(gè)月都會(huì)問(wèn)大家，你這個(gè)月想要解決什么問(wèn)題？如果方向大家一致認(rèn)可，那就去做。

　　最后，對(duì)于新技術(shù)的引入上，豆瓣整體是比較偏激進(jìn)的，我們鼓勵(lì)大家去看看新的技術(shù)。當(dāng)然我們也不會(huì)看到新的就上，這里面有一些限制：一個(gè)是比較重要的服務(wù)如果要上新的技術(shù)，一定要有成功案例，且成功案例有跟我們量級(jí)差不多的規(guī)模，這樣可以降低風(fēng)險(xiǎn)；另一個(gè)是對(duì)于引入的新技術(shù)一定要吃透——大部分引入的技術(shù)肯定是要做二次開發(fā)的，所以拿進(jìn)來(lái)的技術(shù)你必須保證能完全理解它的代碼結(jié)構(gòu)，出了問(wèn)題能修，能去掉自己無(wú)法掌控的東西。這也是為什么豆瓣不太可能在重要的地方引入Java的原因，除非別無(wú)選擇，我們一般都是Python、C和Go。

it知識(shí)庫(kù)：豆瓣的基礎(chǔ)架構(gòu)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。