導讀：和許多新興的網(wǎng)站一樣，著名的輕博客服務Tumblr在急速發(fā)展中面臨了系統(tǒng)架構的瓶頸。每天5億次瀏覽量，峰值每秒4萬次請求，每天3TB新的數(shù)據(jù)存儲，超過1000臺服務器，這樣的情況下如何保證老系統(tǒng)平穩(wěn)運行，平穩(wěn)過渡到新的系統(tǒng)，Tumblr正面臨巨大的挑戰(zhàn)。近日，HighScalability網(wǎng)站的Todd Hoff采訪了該公司的分布式系統(tǒng)工程師Blake Matheny，撰文系統(tǒng)介紹了網(wǎng)站的架構，內容很有價值。
Tumblr每月頁面瀏覽量超過150億次，已經成為火爆的博客社區(qū)。用戶也許喜歡它的簡約、美麗，對用戶體驗的強烈關注，或是友好而忙碌的溝通方式，總之，它深得人們的喜愛。
每月超過30%的增長當然不可能沒有挑戰(zhàn)，其中可靠性問題尤為艱巨。每天5億次瀏覽量，峰值每秒4萬次請求，每天3TB新的數(shù)據(jù)存儲，并運行于超過1000臺服務器上，所有這些幫助Tumblr實現(xiàn)巨大的經營規(guī)模。
創(chuàng)業(yè)公司邁向成功，都要邁過危險的迅速發(fā)展期這道門檻。尋找人才，不斷改造基礎架構，維護舊的架構，同時要面對逐月大增的流量，而且曾經只有4位工程師。這意味著必須艱難地選擇應該做什么，不該做什么。這就是Tumblr的狀況。好在現(xiàn)在已經有20位工程師了，可以有精力解決問題，并開發(fā)一些有意思的解決方案。
Tumblr最開始是非常典型的LAMP應用。目前正在向分布式服務模型演進，該模型基于Scala、HBase、Redis（著名開源K-V存儲方案）、Kafka（Apache項目，出自LinkedIn的分布式發(fā)布-訂閱消息系統(tǒng)）、Finagle（由Twitter開源的容錯、協(xié)議中立的RPC系統(tǒng)），此外還有一個有趣的基于Cell的架構，用來支持Dashboard（CSDN注：Tumblr富有特色的用戶界面，類似于微博的時間軸）。
Tumblr目前的最大問題是如何改造為一個大規(guī)模網(wǎng)站。系統(tǒng)架構正在從LAMP演進為最先進的技術組合，同時團隊也要從小的創(chuàng)業(yè)型發(fā)展為全副武裝、隨時待命的正規(guī)開發(fā)團隊，不斷創(chuàng)造出新的功能和基礎設施。下面就是Blake Matheny對Tumblr系統(tǒng)架構情況的介紹。
網(wǎng)站地址
主要數(shù)據(jù)
▲每天5億次PV（頁面訪問量）
▲每月超過150億PV
▲約20名工程師
▲ 峰值請求每秒近4萬次
▲每天超過1TB數(shù)據(jù)進入Hadoop集群
▲ MySQL/HBase/Redis/memcache每天生成若干TB數(shù)據(jù)
▲每月增長30%
▲近1000硬件節(jié)點用于生產環(huán)境
▲平均每位工程師每月負責數(shù)以億計的頁面訪問
▲每天上傳大約50GB的文章，每天跟帖更新數(shù)據(jù)大約2.7TB（CSDN注：這兩個數(shù)據(jù)的比例看上去不太合理，據(jù)Tumblr數(shù)據(jù)科學家Adam Laiacano在Twitter上解釋，前一個數(shù)據(jù)應該指的是文章的文本內容和元數(shù)據(jù)，不包括存儲在S3上的多媒體內容）
軟件環(huán)境
▲開發(fā)使用OS X，生產環(huán)境使用Linux（CentOS/Scientific）
▲Apache
▲PHP, Scala, Ruby
▲Redis, HBase, MySQL
▲memcache, Gearman（支持多語言的任務分發(fā)應用框架）, Kafka, Kestrel（Twitter開源的分布式消息隊列系統(tǒng)）, Finagle
▲ Thrift, HTTP
▲Func——一個安全、支持腳本的遠程控制框架和API
▲ Git, Capistrano（多服務器腳本部署工具）, Puppet, Jenkins
硬件環(huán)境
▲500臺Web服務器
▲200臺數(shù)據(jù)庫服務器（47 pool，20 shard）
▲30臺memcache服務器
▲22臺Redis服務器
▲15臺Varnish服務器
▲25臺HAproxy節(jié)點
▲8臺nginx服務器
▲14臺工作隊列服務器（Kestrel + Gearman）
架構
1. 相對其他社交網(wǎng)站而言，Tumblr有其獨特的使用模式：
▲每天有超過5千萬篇文章更新，平均每篇文章的跟帖又數(shù)以百計。用戶一般只有數(shù)百個粉絲。這與其他社會化網(wǎng)站里少數(shù)用戶有幾百萬粉絲非常不同，使得Tumblr的擴展性極具挑戰(zhàn)性。
▲按用戶使用時間衡量，Tumblr已經是排名第二的社會化網(wǎng)站。內容的吸引力很強，有很多圖片和視頻，文章往往不短，一般也不會太長，但允許寫得很長。文章內容往往比較深入，用戶會花費更長的時間來閱讀。
▲用戶與其他用戶建立聯(lián)系后，可能會在Dashboard上往回翻幾百頁逐篇閱讀，這與其他網(wǎng)站基本上只是部分信息流不同。
▲用戶的數(shù)量龐大，用戶的平均到達范圍更廣，用戶較頻繁的發(fā)帖，這些都意味著有巨量的更新需要處理。
2. Tumblr目前運行在一個托管數(shù)據(jù)中心中，已在考慮地域上的分布性。
3. Tumblr作為一個平臺，由兩個組件構成：公共Tumblelogs和Dashboard
▲公共Tumblelogs與博客類似（此句請Tumblr用戶校正），并非動態(tài)，易于緩存
▲Dashboard是類似于Twitter的時間軸,用戶由此可以看到自己關注的所有用戶的實時更新。與博客的擴展性不同，緩存作用不大，因為每次請求都不同，尤其是活躍的關注者。而且需要實時而且一致，文章每天僅更新50GB，跟帖每天更新2.7TB，所有的多媒體數(shù)據(jù)都存儲在S3上面。
▲大多數(shù)用戶以Tumblr作為內容瀏覽工具，每天瀏覽超過5億個頁面，70%的瀏覽來自Dashboard。
▲Dashboard的可用性已經不錯，但Tumblelog一直不夠好，因為基礎設施是老的，而且很難遷移。由于人手不足，一時半會兒還顧不上。
老的架構
Tumblr最開始是托管在Rackspace上的，每個自定義域名的博客都有一個A記錄。當2007年Rackspace無法滿足其發(fā)展速度不得不遷移時，大量的用戶都需要同時遷移。所以他們不得不將自定義域名保留在Rackspace，然后再使用HAProxy和Varnish路由到新的數(shù)據(jù)中心。類似這樣的遺留問題很多。
開始的架構演進是典型的LAMP路線：
▲最初用PHP開發(fā)，幾乎所有程序員都用PHP
▲最初是三臺服務器：一臺Web，一臺數(shù)據(jù)庫，一臺PHP
▲為了擴展，開始使用memcache，然后引入前端cache，然后在cache前再加HAProxy，然后是MySQL sharding（非常奏效）
▲采用“在單臺服務器上榨出一切”的方式。過去一年已經用C開發(fā)了兩個后端服務：ID生成程序和Staircar（用Redis支持Dashboard通知）
Dashboard采用了“擴散-收集”方式。當用戶訪問Dashboard時將顯示事件，來自所關注的用戶的事件是通過拉然后顯示的。這樣支撐了6個月。由于數(shù)據(jù)是按時間排序的，因此sharding模式不太管用。
新的架構
▲由于招人和開發(fā)速度等原因，改為以JVM為中心。目標是將一切從PHP應用改為服務，使應用變成請求鑒別、呈現(xiàn)等諸多服務之上的薄層。
▲這其中，非常重要的是選用了Scala和Finagle。
▲在團隊內部有很多人具備Ruby和PHP經驗，所以Scala很有吸引力。
▲Finagle是選擇Scala的重要因素之一。這個來自Twitter的庫可以解決大多數(shù)分布式問題，比如分布式跟蹤、服務發(fā)現(xiàn)、服務注冊等。
▲轉到JVM上之后，F(xiàn)inagle提供了團隊所需的所有基本功能（Thrift, ZooKeeper等），無需再開發(fā)許多網(wǎng)絡代碼，另外，團隊成員認識該項目的一些開發(fā)者。
▲Foursquare和Twitter都在用Finagle，Meetup也在用Scala。
▲應用接口與Thrift類似，性能極佳。
▲團隊本來很喜歡Netty（Java異步網(wǎng)絡應用框架，2月4日剛剛發(fā)布3.3.1最終版），但不想用Java，Scala是不錯的選擇。
▲選擇Finagle是因為它很酷，還認識幾個開發(fā)者。
之所以沒有選擇Node.js，是因為以JVM為基礎更容易擴展。Node的發(fā)展為時尚短，缺乏標準、最佳實踐以及大量久經測試的代碼。而用Scala的話，可以使用所有Java代碼。雖然其中并沒有多少可擴展的東西，也無法解決5毫秒響應時間、49秒HA、4萬每秒請求甚至有時每秒40萬次請求的問題。但是，Java的生態(tài)鏈要大得多，有很多資源可以利用。
內部服務從C/libevent為基礎正在轉向Scala/Finagle為基礎。
開始采用新的NoSQL存儲方案如HBase和Redis。但大量數(shù)據(jù)仍然存儲在大量分區(qū)的MySQL架構中，并沒有用HBase代替MySQL。HBase主要支持短地址生產程序（數(shù)以十億計）還有歷史數(shù)據(jù)和分析，非常結實。此外，HBase也用于高寫入需求場景，比如Dashboard刷新時一秒上百萬的寫入。之所以還沒有替換HBase，是因為不能冒業(yè)務上風險，目前還是依靠人來負責更保險，先在一些小的、不那么關鍵的項目中應用，以獲得經驗。MySQL和時間序列數(shù)據(jù)sharding（分片）的問題在于，總有一個分片太熱。另外，由于要在slave上插入并發(fā)，也會遇到讀復制延遲問題。
此外，還開發(fā)了一個公用服務框架：
▲花了很多時間解決分布式系統(tǒng)管理這個運維問題。
▲為服務開發(fā)了一種Rails scaffolding，內部用模板來啟動服務。
▲所有服務從運維的角度來看都是一樣的，所有服務檢查統(tǒng)計數(shù)據(jù)、監(jiān)控、啟動和停止的方式都一樣。
▲工具方面，構建過程圍繞SBT（一個Scala構建工具），使用插件和輔助程序管理常見操作，包括在Git里打標簽，發(fā)布到代碼庫等等。大多數(shù)程序員都不用再操心構建系統(tǒng)的細節(jié)了。
200臺數(shù)據(jù)庫服務器中，很多是為了提高可用性而設，使用的是常規(guī)硬件，但MTBF（平均故障間隔時間）極低。故障時，備用充足。
為了支持PHP應用有6個后端服務，并有一個小組專門開發(fā)后端服務。新服務的發(fā)布需要兩到三周，包括Dashboard通知、Dashboard二級索引、短地址生成、處理透明分片的memcache代理。其中在MySQL分片上耗時很多。雖然在紐約本地非常熱，但并沒有使用MongoDB，他們認為MySQL的可擴展性足夠了。
Gearman用于會長期運行無需人工干預的工作。
可用性是以達到范圍（reach）衡量的。用戶能夠訪問自定義域或者Dashboard嗎？也會用錯誤率。
歷史上總是解決那些最高優(yōu)先級的問題，而現(xiàn)在會對故障模式系統(tǒng)地分析和解決，目的是從用戶和應用的角度來定成功指標。（后一句原文似乎不全）
最開始Finagle是用于Actor模型的，但是后來放棄了。對于運行后無需人工干預的工作，使用任務隊列。而且Twitter的util工具庫中有Future實現(xiàn)，服務都是用Future（Scala中的無參數(shù)函數(shù)，在與函數(shù)關聯(lián)的并行操作沒有完成時，會阻塞調用方）實現(xiàn)的。當需要線程池的時候，就將Future傳入Future池。一切都提交到Future池進行異步執(zhí)行。
Scala提倡無共享狀態(tài)。由于已經在Twitter生產環(huán)境中經過測試，F(xiàn)inagle這方面應該是沒有問題的。使用Scala和Finagle中的結構需要避免可變狀態(tài)，不使用長期運行的狀態(tài)機。狀態(tài)從數(shù)據(jù)庫中拉出、使用再寫回數(shù)據(jù)庫。這樣做的好處是，開發(fā)人員不需要操心線程和鎖。
22臺Redis服務器，每臺的都有8-32個實例，因此線上同時使用了100多個Redis實例。
▲Redis主要用于Dashboard通知的后端存儲。
▲所謂通知就是指某個用戶like了某篇文章這樣的事件。通知會在用戶的Dashboard中顯示，告訴他其他用戶對其內容做了哪些操作。
▲高寫入率使MySQL無法應對。
▲通知轉瞬即逝，所以即使遺漏也不會有嚴重問題，因此Redis是這一場景的合適選擇。
▲這也給了開發(fā)團隊了解Redis的機會。
▲使用中完全沒有發(fā)現(xiàn)Redis有任何問題，社區(qū)也非常棒。
▲開發(fā)了一個基于Scala Futures的Redis接口，該功能現(xiàn)在已經并入了Cell架構。
▲短地址生成程序使用Redis作為一級Cache，HBase作為永久存儲。
▲Dashboard的二級索引是以Redis為基礎開發(fā)的。
▲Redis還用作Gearman的持久存儲層，使用Finagle開發(fā)的memcache代理。
▲正在緩慢地從memcache轉向Redis。希望最終只用一個cache服務。性能上Redis與memcache相當。
內部的firehose(通信管道)
▲內部的應用需要活躍的信息流通道。這些信息包括用戶創(chuàng)建/刪除的信息，liking/unliking的提示，等等。挑戰(zhàn)在于這些數(shù)據(jù)要實時的分布式處理。我們希望能夠檢測內部運行狀況，應用的生態(tài)系統(tǒng)能夠可靠的生長，同時還需要建設分布式系統(tǒng)的控制中心。
▲以前，這些信息是基于Scribe(Facebook開源的分布式日志系統(tǒng)。)/Hadoop的分布式系統(tǒng)。服務會先記錄在Scribe中，并持續(xù)的長尾形式寫入，然后將數(shù)據(jù)輸送給應用。這種模式可以立即停止伸縮，尤其在峰值時每秒要創(chuàng)建數(shù)以千計的信息。不要指望人們會細水長流式的發(fā)布文件和grep。
▲內部的firehose就像裝載著信息的大巴，各種服務和應用通過Thrift與消防管線溝通。(一個可伸縮的跨語言的服務開發(fā)框架。)
▲LinkedIn的Kafka用于存儲信息。內部人員通過HTTP鏈接firehose。經常面對巨大的數(shù)據(jù)沖擊，采用MySQL顯然不是一個好主意，分區(qū)實施越來越普遍。
▲firehose的模型是非常靈活的，而不像Twitter的firehose那樣數(shù)據(jù)被假定是丟失的。
▲firehose的信息流可以及時的回放。他保留一周內的數(shù)據(jù)，可以調出這期間任何時間點的數(shù)據(jù)。
▲支持多個客戶端連接，而且不會看到重復的數(shù)據(jù)。每個客戶端有一個ID。Kafka支持客戶群，每個群中的客戶都用同一個ID，他們不會讀取重復的數(shù)據(jù)?？梢詣?chuàng)建多個客戶端使用同一個ID，而且不會看到重復的數(shù)據(jù)。這將保證數(shù)據(jù)的獨立性和并行處理。Kafka使用ZooKeeper(Apache推出的開源分布式應用程序協(xié)調服務。)定期檢查用戶閱讀了多少。
為Dashboard收件箱設計的Cell架構
▲現(xiàn)在支持Dashboard的功能的分散-集中架構非常受限，這種狀況不會持續(xù)很久。
▲解決方法是采用基于Cell架構的收件箱模型，與Facebook Messages非常相似。
▲收件箱與分散-集中架構是對立的。每一位用戶的dashboard都是由其追隨者的發(fā)言和行動組成的，并按照時間順序存儲。
▲就因為是收件箱就解決了分散-集中的問題。你可以會問到底在收件箱中放了些什么，讓其如此廉價。這種方式將運行很長時間。
▲重寫Dashboard非常困難。數(shù)據(jù)已經分布，但是用戶局部升級產生的數(shù)據(jù)交換的質量還沒有完全搞定。
▲數(shù)據(jù)量是非常驚人的。平均每條消息轉發(fā)給上百個不同的用戶，這比Facebook面對的困難還要大。大數(shù)據(jù)+高分布率+多個數(shù)據(jù)中心。
▲每秒鐘上百萬次寫入，5萬次讀取。沒有重復和壓縮的數(shù)據(jù)增長為2.7TB，每秒百萬次寫入操作來自24字節(jié)行鍵。
▲已經流行的應用按此方法運行。
▲cell
▲每個cell是獨立的，并保存著一定數(shù)量用戶的全部數(shù)據(jù)。在用戶的Dashboard中顯示的所有數(shù)據(jù)也在這個cell中。
▲用戶映射到cell。一個數(shù)據(jù)中心有很多cell。
▲每個cell都有一個HBase的集群，服務集群，Redis的緩存集群。
▲用戶歸屬到cell，所有cell的共同為用戶發(fā)言提供支持。
▲每個cell都基于Finagle（Twitter推出的異步的遠程過程調用庫），建設在HBase上，Thrift用于開發(fā)與firehose和各種請求與數(shù)據(jù)庫的鏈接。(請糾錯)
▲一個用戶進入Dashboard，其追隨者歸屬到特定的cell，這個服務節(jié)點通過HBase讀取他們的dashboard并返回數(shù)據(jù)。
▲后臺將追隨者的dashboard歸入當前用戶的table，并處理請求。
▲Redis的緩存層用于cell內部處理用戶發(fā)言。
▲請求流：用戶發(fā)布消息，消息將被寫入firehose，所有的cell處理這條消息并把發(fā)言文本寫入數(shù)據(jù)庫，cell查找是否所有發(fā)布消息追隨者都在本cell內，如果是的話，所有追隨者的收件箱將更新用戶的ID。（請糾錯）
▲cell設計的優(yōu)點：
▲大規(guī)模的請求被并行處理，組件相互隔離不會產生干擾。 cell是一個并行的單位，因此可以任意調整規(guī)格以適應用戶群的增長。
▲cell的故障是獨立的。一個Cell的故障不會影響其他cell。
▲cell的表現(xiàn)非常好，能夠進行各種升級測試，實施滾動升級，并測試不同版本的軟件。
▲關鍵的思想是容易遺漏的：所有的發(fā)言都是可以復制到所有的cell。
▲每個cell中存儲的所有發(fā)言的單一副本。 每個cell可以完全滿足Dashboard呈現(xiàn)請求。應用不用請求所有發(fā)言者的ID，只需要請求那些用戶的ID。(“那些用戶”所指不清，請指正。)他可以在dashboard返回內容。每一個cell都可以滿足Dashboard的所有需求，而不需要與其他cell進行通信。
▲用到兩個HBase table ：一個table用于存儲每個發(fā)言的副本，這個table相對較小。在cell內，這些數(shù)據(jù)將與存儲每一個發(fā)言者ID。第二個table告訴我們用戶的dashboard不需要顯示所有的追隨者。當用戶通過不同的終端訪問一個發(fā)言，并不代表閱讀了兩次。收件箱模型可以保證你閱讀到。
▲發(fā)言并不會直接進入到收件箱，因為那實在太大了。所以，發(fā)言者的ID將被發(fā)送到收件箱，同時發(fā)言內容將進入cell。這個模式有效的減少了存儲需求，只需要返回用戶在收件箱中瀏覽發(fā)言的時間。而缺點是每一個cell保存所有的發(fā)言副本。令人驚奇的是，所有發(fā)言比收件箱中的鏡像要小。(請糾錯)每天每個cell的發(fā)言增長50GB，收件箱每天增長2.7TB。用戶消耗的資源遠遠超過他們制造的。
▲用戶的dashboard不包含發(fā)言的內容，只顯示發(fā)言者的ID，主要的增長來自ID。(請Tumblr用戶糾錯)
▲當追隨者改變時，這種設計方案也是安全的。因為所有的發(fā)言都保存在cell中了。如果只有追隨者的發(fā)言保存在cell中，那么當追隨者改變了，將需要一些回填工作。
▲另外一種設計方案是采用獨立的發(fā)言存儲集群。這種設計的缺點是，如果群集出現(xiàn)故障，它會影響整個網(wǎng)站。因此，使用cell的設計以及后復制到所有cell的方式，創(chuàng)建了一個非常強大的架構。
▲一個用戶擁有上百萬的追隨者，這帶來非常大的困難，有選擇的處理用戶的追隨者以及他們的存取模式（見Feeding Frenzy）
▲不同的用戶采用不同并且恰當?shù)拇嫒∧Ｊ胶头植寄Ｐ停瑑蓚€不同的分布模式包括：一個適合受歡迎的用戶，一個使用大眾。
▲依據(jù)用戶的類型采用不同的數(shù)據(jù)處理方式，活躍用戶的發(fā)言并不會被真正發(fā)布，發(fā)言將被有選擇的體現(xiàn)。(果真如此？請Tumblr用戶糾錯)
▲追隨了上百萬用戶的用戶，將像擁有上百萬追隨者的用戶那樣對待。
▲cell的大小非常難于決定。cell的大小直接影響網(wǎng)站的成敗。每個cell歸于的用戶數(shù)量是影響力之一。需要權衡接受怎樣的用戶體驗，以及為之付出多少投資。
▲從firehose中讀取數(shù)據(jù)將是對網(wǎng)絡最大的考驗。在cell內部網(wǎng)絡流量是可管理的。
▲當更多cell被增添到網(wǎng)絡中來，他們可以進入到cell組中，并從firehose中讀取數(shù)據(jù)。一個分層的數(shù)據(jù)復制計劃。這可以幫助遷移到多個數(shù)據(jù)中心。
在紐約啟動運作
紐約具有獨特的環(huán)境，資金和廣告充足。招聘極具挑戰(zhàn)性，因為缺乏創(chuàng)業(yè)經驗。
在過去的幾年里，紐約一直致力于推動創(chuàng)業(yè)。紐約大學和哥倫比亞大學有一些項目，鼓勵學生到初創(chuàng)企業(yè)實習，而不僅僅去華爾街。市長建立了一所學院，側重于技術。
團隊架構
▲團隊：基礎架構，平臺，SRE，產品，web ops，服務；
▲基礎架構：5層以下，IP地址和DNS，硬件配置；
▲平臺：核心應用開發(fā)，SQL分片，服務，Web運營；
▲SRE：在平臺和產品之間，側重于解決可靠性和擴展性的燃眉之急；
▲服務團隊：相對而言更具戰(zhàn)略性，
▲Web ops：負責問題檢測、響應和優(yōu)化。
軟件部署
▲開發(fā)了一套rsync腳本，可以隨處部署PHP應用程序。一旦機器的數(shù)量超過200臺，系統(tǒng)便開始出現(xiàn)問題，部署花費了很長時間才完成，機器處于部署進程中的各種狀態(tài)。
▲接下來，使用Capistrano（一個開源工具，可以在多臺服務器上運行腳本）在服務堆棧中構建部署進程（開發(fā)、分期、生產）。在幾十臺機器上部署可以正常工作，但當通過SSH部署到數(shù)百臺服務器時，再次失敗。
▲現(xiàn)在，所有的機器上運行一個協(xié)調軟件?；赗edhat Func（一個安全的、腳本化的遠程控制框架和接口）功能，一個輕量級的API用于向主機發(fā)送命令，以構建擴展性。
▲建立部署是在Func的基礎上向主機發(fā)送命令，避免了使用SSH。比如，想在組A上部署軟件，控制主機就可以找出隸屬于組A的節(jié)點，并運行部署命令。
▲部署命令通過Capistrano實施。
▲Func API可用于返回狀態(tài)報告，報告哪些機器上有這些軟件版本。
▲安全重啟任何服務，因為它們會關閉連接，然后重啟。
▲在激活前的黑暗模式下運行所有功能。
展望
▲從哲學上將，任何人都可以使用自己想要的任意工具。但隨著團隊的發(fā)展壯大，這些工具出現(xiàn)了問題。新員工想要更好地融入團隊，快速地解決問題，必須以他們?yōu)橹行模⒉僮鞯臉藴驶?/p>
▲過程類似于Scrum（一種敏捷管理框架），非常敏捷。
▲每個開發(fā)人員都有一臺預配置的開發(fā)機器，并按照控制更新。
▲開發(fā)機會出現(xiàn)變化，測試，分期，乃至用于生產。
▲開發(fā)者使用VIM和TextMate。
▲測試是對PHP程序進行代碼審核。
▲在服務方面，他們已經實現(xiàn)了一個與提交相掛鉤的測試基礎架構，接下來將繼承并內建通知機制。
招聘流程
▲面試通常避免數(shù)學、猜謎、腦筋急轉彎等問題，而著重關注應聘者在工作中實際要做什么。
▲著重編程技能。
▲面試不是比較，只是要找對的人。
▲挑戰(zhàn)在于找到具有可用性、擴展性經驗的人才，以應對Tumblr面臨的網(wǎng)絡擁塞。
▲在Tumblr工程博客（Tumblr Engineering Blog），他們對已過世的Dennis Ritchie和John McCarthy予以紀念。
經驗及教訓
▲自動化無處不在
▲MySQL（增加分片）規(guī)模，應用程序暫時還不行
▲Redis總能帶給人驚喜
▲基于Scala語言的應用執(zhí)行效率是出色的
▲廢棄項目——當你不確定將如何工作時
▲不顧用在他們發(fā)展經歷中沒經歷過技術挑戰(zhàn)的人，聘用有技術實力的人是因為他們能適合你的團隊以 及工作。
▲選擇正確的軟件集合將會幫助你找到你需要的人
▲建立團隊的技能
▲閱讀文檔和博客文章。
▲多與同行交流，可以接觸一些領域中經驗豐富的人，例如與在Facebook、Twitter、LinkedIn的工程師 多交流，從他們身上可以學到很多
▲對技術要循序漸進，在正式投入使用之前他們煞費苦心的學習HBase和Redis。同時在試點項目中使用 或將其控制在有限損害范圍之內。
翻譯：包研，張志平，劉江；審校：劉江
