導讀:和許多新興的網(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胶头植寄P停瑑蓚€不同的分布模式包括:一個適合受歡迎的用戶,一個使用大眾。
▲依據(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。同時在試點項目中使用 或將其控制在有限損害范圍之內。
翻譯:包研,張志平,劉江;審校:劉江