最近的新聞中我們得知雅虎11億美元收購了Tumblr: Yahoo bought Tumblr for $1.1 billion. 你也許會發(fā)現(xiàn)Instagram也被Facebook重金收購的介紹. 這是一個巧合嗎?這就由你來判斷吧。

為什么雅虎會收購Tumblr? 這場交易中的商業(yè)價值我可能無法判斷,但是如果你對Tumblr的技術方面有所了解,你一定會為Tumblr豎起大拇指. 為什么這么說呢,請接著讀... 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、Kafka、Finagle，此外還有一個有趣的基于Cell的架構，用于支持Dashboard .現(xiàn)在的重點被放在了解決他們PHP程序中的短期問題，找出問題,并正確的使用服務化去解決他們. Tumblr目前的最大問題是如何改造為一個大規(guī)模網站。系統(tǒng)架構正在從LAMP演進為最先進的技術組合，同時團隊也要從小的創(chuàng)業(yè)型發(fā)展為全副武裝、隨時待命的正規(guī)開發(fā)團隊，不斷創(chuàng)造出新的功能和基礎設施。下面就是Blake對Tumblr系統(tǒng)架構情況的介紹。

Tumblr網址:  http://www.tumblr.com/

統(tǒng)計

• 每天 5 億頁面瀏覽量
• 每月超過 150億 頁面瀏覽量
• 約 20 名工程師
• 峰值每秒大約 4 萬請求
• 每天有超過 1TB 的數(shù)據(jù)進入 Hadoop 集群
• 每天有幾個 TB 的數(shù)據(jù)進入 MySQL/HBase/Redis/Memcache
• 每月增長 30%
• 產品環(huán)境有大約 1000 個硬件節(jié)點
• 平均每個工程師每月處理10億頁面訪問
• 每天大約 50GB 的文章，關注者列表更新大約每天 2.7TB
• Dashboard 每秒百萬次寫，每秒 5w 讀

軟件

• OS X 用于開發(fā)，產品環(huán)境用 Linux (CentOS, Scientific)
• Apache
• PHP, Scala, Ruby
• Redis, HBase, MySQL
• Varnish, HA-Proxy, nginx,
• Memcache, Gearman, Kafka, Kestrel, Finagle
• Thrift, HTTP
• Func - 一個安全的、腳本化的遠程控制框架和 API
• Git, Capistrano, Puppet, Jenkins

硬件

• 500 臺 Web 服務器
• 200 數(shù)據(jù)庫服務器 (大多數(shù)是備用池)

1. 47 個池
2. 30 個分區(qū)

• 30 臺 memcache 服務器
• 22 臺 redis 服務器
• 15 臺 varnish 服務器
• 25 個 haproxy 節(jié)點
• 8 個 nginx
• 14 個作業(yè)隊列服務器 (kestrel + gearman)

構架

• 與其他社交網站不同的是，Tumblr有其獨特的使用模式。
  1. 每天有超過5千萬篇文章更新，平均每篇文章的跟帖又數(shù)以百計。用戶一般只有數(shù)百個粉絲。這與其他社會化網站里少數(shù)用戶有幾百萬粉絲非常不同，使得Tumblr的擴展性極具挑戰(zhàn)性。
  2. 按用戶使用時間衡量，Tumblr已經是排名第二的社會化網站。內容的吸引力很強，有很多圖片和視頻，文章往往不短，一般也不會太長，但允許寫得很長。文章內容往往比較深入，用戶會花費更長的時間來閱讀。
  3. 用戶與其他用戶建立聯(lián)系后，可能會在Dashboard上往回翻幾百頁逐篇閱讀，這與其他網站基本上只是部分信息流不同。
  4. 用戶的數(shù)量龐大，用戶的平均到達范圍更廣，用戶較頻繁的發(fā)帖，這些都意味著有巨量的更新需要處理。
• Tumblr目前運行在一個托管數(shù)據(jù)中心中，已在考慮地域上的分布式構架。

1. Tumblr平臺由兩個組件構成：公共Tumblelogs和Dashboard
   1. 公共Tumblelogs與博客類似，并非動態(tài)，易于緩存
   2. Dashboard是類似于Twitter的時間軸,用戶由此可以看到自己關注的所有用戶的實時更新。
      1. 與博客的擴展性不同，緩存作用不大，因為每次請求都不同，尤其是活躍的關注者。
      2. 而且需要實時而且一致，文章每天僅更新50GB，跟帖每天更新2.7TB，所有的多媒體數(shù)據(jù)都存儲在S3上面。
   3. 大多數(shù)用戶以Tumblr作為內容瀏覽工具，每天瀏覽超過5億個頁面，70%的瀏覽來自Dashboard。
   4. Dashboard的可用性已經不錯，但Tumblelog一直不夠好，因為基礎設施是老的，而且很難遷移。由于人手不足，一時半會兒還顧不上。

老的Tumblr構架

• Tumblr最開始是托管在Rackspace上的，每個自定義域名的博客都有一個A記錄。當2007年Rackspace無法滿足其發(fā)展速度不得不遷移時，大量的用戶都需要同時遷移。所以他們不得不將自定義域名保留在Rackspace，然后再使用HAProxy和Varnish路由到新的數(shù)據(jù)中心。類似這樣的遺留問題很多。
• 開始的架構演進是典型的LAMP路線
  1. 最初用PHP開發(fā)，幾乎所有程序員都用PHP
  2. 最初是三臺服務器：一臺Web，一臺數(shù)據(jù)庫，一臺PHP
  3. 為了擴展，開始使用memcache，然后引入前端cache，然后在cache前再加HAProxy，然后是非常奏效的MySQL sharding
  4. 采用“在單臺服務器上榨出一切”的方式。過去一年已經用C開發(fā)了兩個后端服務：ID generator和Staircar（用Redis進行Dashboard通知）
• Dashboard采用了“擴散-收集”方式。當用戶訪問Dashboard時將顯示事件，來自所關注的用戶的事件是通過拉然后顯示的。這樣支撐了6個月。由于數(shù)據(jù)是按時間排序的，因此sharding模式不太管用。 

新的構架

• 由于招人和開發(fā)速度等原因，改為以JVM為中心。
• 目標是將一切從PHP應用改為服務，使應用變成請求鑒別、呈現(xiàn)等諸多服務之上的薄層。
• 選擇了Scala 和 Finagle
  1. 在團隊內部有很多人具備Ruby和PHP經驗，所以Scala很有吸引力。
  2. Finagle是選擇Scala的重要因素之一。這個來自Twitter的庫可以解決大多數(shù)分布式問題，比如分布式跟蹤、服務發(fā)現(xiàn)、服務注冊等。
  3. 轉到JVM上之后，F(xiàn)inagle提供了團隊所需的所有基本功能（Thrift, ZooKeeper等），無需再開發(fā)許多網絡代碼，另外，團隊成員認識該項目的一些開發(fā)者。
  4. Foursquare和Twitter都在用Finagle，Meetup也在用Scala。
  5. 應用接口與Thrift類似，性能極佳。
  6. 團隊本來很喜歡Netty，但不想用Java，Scala是不錯的選擇。
  7. 選擇Finagle是因為它很酷，還認識幾個開發(fā)者。
  8. 之所以沒有選擇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ā)了一個公用服務框架：
  1. 花了很多時間解決分布式系統(tǒng)管理這個運維問題。
  2. 為服務開發(fā)了一種Rails scaffolding，內部用模板來啟動服務。
  3. 所有服務從運維的角度來看都是一樣的，所有服務檢查統(tǒng)計數(shù)據(jù)、監(jiān)控、啟動和停止的方式都一樣。
  4. 工具方面，構建過程圍繞SBT（一個Scala構建工具），使用插件和輔助程序管理常見操作，包括在Git里打標簽，發(fā)布到代碼庫等等。大多數(shù)程序員都不用再操心構建系統(tǒng)的細節(jié)了。
• 40臺服務器采用HAProxy進行負載均衡,Varnish進行緩存.
• 200臺數(shù)據(jù)庫服務器中，很多是為了提高可用性而設，使用的是常規(guī)硬件，但MTBF（平均故障間隔時間）極低。故障時，備用充足。
• 500臺服務器運行Apache和其他PHP程序。
• 6個為了支持PHP應用的后端服務，并有一個小組專門開發(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實例。
  1. Redis主要用于Dashboard通知的后端存儲。
  2. 所謂通知就是指某個用戶like了某篇文章這樣的事件。通知會在用戶的Dashboard中顯示，告訴他其他用戶對其內容做了哪些操作。
  3. 高寫入率使MySQL無法應對。
  4. 通知轉瞬即逝，所以即使遺漏也不會有嚴重問題，因此Redis是這一場景的合適選擇。
  5. 這也給了開發(fā)團隊了解Redis的機會。
  6. 使用中完全沒有發(fā)現(xiàn)Redis有任何問題，社區(qū)也非常棒。
  7. 開發(fā)了一個基于Scala Futures的Redis接口，該功能現(xiàn)在已經并入了Cell架構。
  8. 短地址生成程序使用Redis作為一級Cache，HBase作為永久存儲。
  9. Dashboard的二級索引是以Redis為基礎開發(fā)的。
  10. Redis還用作Gearman的持久存儲層，使用Finagle開發(fā)的memcache代理。
  11. 正在緩慢地從memcache轉向Redis。希望最終只用一個cache服務。性能上Redis與memcache相當。

#p#

內部通訊管道(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ù)被假定是丟失的。
  1. firehose 的信息流可以及時的回放。他保留一周內的數(shù)據(jù)，可以調出這期間任何時間點的數(shù)據(jù)。
  2. 支持多個客戶端連接，而且不會看到重復的數(shù)據(jù)。每個客戶端有一個 ID。Kafka 支持客戶群，每個群中的客戶都用同一個 ID，他們不會讀取重復的數(shù)據(jù)。可以創(chuàng)建多個客戶端使用同一個 ID，而且不會看到重復的數(shù)據(jù)。這將保證數(shù)據(jù)的獨立性和并行處理。Kafka 使用 ZooKeeper (Apache 推出的開源分布式應用程序協(xié)調服務。)定期檢查用戶閱讀了多少。

為 Dashboard 收件箱設計的 Cell 架構

• 現(xiàn)在支持 Dashboard 的功能的分散-集中架構非常受限，這種狀況不會持續(xù)很久。
  1. 解決方法是采用基于 Cell 架構的收件箱模型，與 Facebook Messages 非常相似。
  2. 收件箱與分散-集中架構是對立的。每一位用戶的 dashboard 都是由其追隨者的發(fā)言和行動組成的，并按照時間順序存儲。
  3. 就因為是收件箱就解決了分散-集中的問題。你可以會問到底在收件箱中放了些什么，讓其如此廉價。這種方式將運行很長時間。
• 重寫 Dashboard 非常困難。數(shù)據(jù)已經分布，但是用戶局部升級產生的數(shù)據(jù)交換的質量還沒有完全搞定。
  1. 數(shù)據(jù)量是非常驚人的。平均每條消息轉發(fā)給上百個不同的用戶，這比 Facebook 面對的困難還要大。大數(shù)據(jù)+高分布率+多個數(shù)據(jù)中心。
  2. 每秒鐘上百萬次寫入，5萬次讀取。沒有重復和壓縮的數(shù)據(jù)增長為2.7TB，每秒百萬次寫入操作來自 24 字節(jié)行鍵。
  3. 已經流行的應用按此方法運行。
• Cell構架
  1. 每個 cell 是獨立的，并保存著一定數(shù)量用戶的全部數(shù)據(jù)。在用戶的 Dashboard 中顯示的所有數(shù)據(jù)也在這個 cell 中。
  2. 用戶映射到 cell。一個數(shù)據(jù)中心有很多 cell。
  3. 每個 cell 都有一個 HBase 的集群，服務集群，Redis 的緩存集群。
  4. 用戶歸屬到 cell，所有 cell 的共同為用戶發(fā)言提供支持。
  5. 每個 cell 都基于 Finagle（Twitter 推出的異步的遠程過程調用庫），建設在 HBase 上，Thrift 用于開發(fā)與 firehose 和各種請求與數(shù)據(jù)庫的鏈接。
  6. 一個用戶進入 Dashboard，其追隨者歸屬到特定的 cell，這個服務節(jié)點通過 HBase 讀取他們的 dashboard 并返回數(shù)據(jù)。
  7. 后臺將追隨者的 dashboard 歸入當前用戶的 table，并處理請求。
  8. Redis 的緩存層用于 cell 內部處理用戶發(fā)言。
• 請求流：用戶發(fā)布消息，消息將被寫入 firehose，所有的 cell 處理這條消息并把發(fā)言文本寫入數(shù)據(jù)庫，cell 查找是否所有發(fā)布消息追隨者都在本 cell 內，如果是的話，所有追隨者的收件箱將更新用戶的 ID。
• cell 構架的優(yōu)點：
  1. 大規(guī)模的請求被并行處理，組件相互隔離不會產生干擾。 cell 是一個并行的單位，因此可以任意調整規(guī)格以適應用戶群的增長。
  2. cell 的故障是獨立的。一個 Cell 的故障不會影響其他 cell。
  3. cell 的表現(xiàn)非常好，能夠進行各種升級測試，實施滾動升級，并測試不同版本的軟件。
• 關鍵的思想是容易遺漏的：所有的發(fā)言都是可以復制到所有的 cell。
  1. 每個 cell 中存儲的所有發(fā)言的單一副本。 每個 cell 可以完全滿足 Dashboard 呈現(xiàn)請求。應用不用請求所有發(fā)言者的 ID，只需要請求那些用戶的 ID。他可以在 dashboard 返回內容。每一個 cell 都可以滿足 Dashboard 的所有需求，而不需要與其他 cell 進行通信。
  2. 用到兩個 HBase table ：一個 table 用于存儲每個發(fā)言的副本，這個 table 相對較小。在 cell 內，這些數(shù)據(jù)將與存儲每一個發(fā)言者 ID。第二個 table 告訴我們用戶的 dashboard 不需要顯示所有的追隨者。當用戶通過不同的終端訪問一個發(fā)言，并不代表閱讀了兩次。收件箱模型可以保證你閱讀到。
  3. 發(fā)言并不會直接進入到收件箱，因為那實在太大了。所以，發(fā)言者的 ID 將被發(fā)送到收件箱，同時發(fā)言內容將進入 cell。這個模式有效的減少了存儲需求，只需要返回用戶在收件箱中瀏覽發(fā)言的時間。而缺點是每一個 cell 保存所有的發(fā)言副本。令人驚奇的是，所有發(fā)言比收件箱中的鏡像要小。每天每個 cell 的發(fā)言增長 50GB，收件箱每天增長2.7TB。用戶消耗的資源遠遠超過他們制造的。
  4. 用戶的 dashboard 不包含發(fā)言的內容，只顯示發(fā)言者的 ID，主要的增長來自 ID。
  5. 當追隨者改變時，這種設計方案也是安全的。因為所有的發(fā)言都保存在 cell 中了。如果只有追隨者的發(fā)言保存在 cell 中，那么當追隨者改變了，將需要一些回填工作。
  6. 另外一種設計方案是采用獨立的發(fā)言存儲集群。這種設計的缺點是，如果群集出現(xiàn)故障，它會影響整個網站。因此，使用 cell 的設計以及后復制到所有 cell 的方式，創(chuàng)建了一個非常強大的架構。
• 一個用戶擁有上百萬的追隨者，這帶來非常大的困難，有選擇的處理用戶的追隨者以及他們的存取模式（見Feeding Frenzy）
  1. 不同的用戶采用不同并且恰當?shù)拇嫒∧Ｊ胶头植寄Ｐ?，兩個不同的分布模式包括：一個適合受歡迎的用戶，一個使用大眾。
  2. 依據(jù)用戶的類型采用不同的數(shù)據(jù)處理方式，活躍用戶的發(fā)言并不會被真正發(fā)布，發(fā)言將被有選擇的體現(xiàn)。
  3. 追隨了上百萬用戶的用戶，將像擁有上百萬追隨者的用戶那樣對待。
• cell 的大小非常難于決定。cell 的大小直接影響網站的成敗。每個 cell 歸于的用戶數(shù)量是影響力之一。需要權衡接受怎樣的用戶體驗，以及為之付出多少投資。
• 從 firehose 中讀取數(shù)據(jù)將是對網絡最大的考驗。在 cell 內部網絡流量是可管理的。
• 當更多 cell 被增添到網絡中來，他們可以進入到 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é)調軟件。基于 Redhat Func（一個安全的、腳本化的遠程控制框架和接口）功能，一個輕量級的 API 用于向主機發(fā)送命令，以構建擴展性。
• 建立部署是在 Func 的基礎上向主機發(fā)送命令，避免了使用 SSH。比如，想在組A上部署軟件，控制主機就可以找出隸屬于組A的節(jié)點，并運行部署命令。
• 通過Capistrano的命令實現(xiàn)部署。它可以可以從git倉庫中拉取代碼。正因為是基于HTTP的,所以非常易于擴展。他們喜歡 Capistrano，因為它支持簡單的基于目錄的版本控制，能夠很好地管理PHP程序。版本更新的時候，每個目錄都包含一個SHA，所以很容易檢查版本的正確性。
   
• Func API 可用于返回狀態(tài)報告，報告哪些機器上有這些軟件版本。
• 安全重啟任何服務，因為它們會關閉連接，然后重啟。
• 在激活前的黑暗模式下運行所有功能。

開發(fā)

• 從哲學上，任何人都可以使用自己想要的任意工具。但隨著團隊的發(fā)展壯大，這些工具出現(xiàn)了問題。新員工想要更好地融入團隊，快速地解決問題，必須以他們?yōu)橹行?，建立操作的標準化?/li>
• 過程類似于 Scrum（一種敏捷管理框架），非常敏捷。
• 每個開發(fā)人員都有一臺預配置的開發(fā)機器，并按照控制更新。
• 開發(fā)機會出現(xiàn)變化，測試，分期，乃至用于生產。
• 開發(fā)者使用 VIM 和 TextMate。
• 測試是對 PHP 程序進行代碼審核。
• 在服務方面，他們已經實現(xiàn)了一個與提交相掛鉤的測試基礎架構，接下來將繼承并內建通知機制。

招聘流程

• 面試通常避免數(shù)學、猜謎、腦筋急轉彎等問題，而著重關注應聘者在工作中實際要做什么。
• 著重編程技能。
• 面試不是比較，只是要找對的人。
• 挑戰(zhàn)在于找到具有可用性、擴展性經驗的人才，以應對 Tumblr 面臨的網絡擁塞。
  1. 例如，對于一個新的ID生成器器，他們需要一個高可用的JVM進程,并且需要在1萬次每分鐘的請求下及最多使用500兆內存的情況下完成1毫秒以下的響應。他們發(fā)現(xiàn)串行收集器給這個特定的工作負載帶來最低的延遲。在 JVM優(yōu)化上花了大量的時間。
• 在 Tumblr 工程博客（Tumblr Engineering Blog），他們對已過世的 Dennis Ritchie 和 John McCarthy 予以紀念。

經驗及教訓

• 自動化無處不在
• MySQL（增加分片）規(guī)模，應用程序暫時還不行
• Redis 總能帶給人驚喜
• 基于 Scala 語言的應用執(zhí)行效率是出色的
• 廢棄項目——當你不確定將如何工作時
• 不顧用在他們發(fā)展經歷中沒經歷過技術挑戰(zhàn)的人，聘用有技術實力的人是因為他們能適合你的團隊以及工作。
• 選擇正確的軟件集合將會幫助你找到你需要的人
• 建立團隊的技能
• 閱讀文檔和博客文章。
• 多與同行交流，可以接觸一些領域中經驗豐富的人，例如與在 Facebook、Twitter、LinkedIn 的工程師多交流，從他們身上可以學到很多
• 對技術要循序漸進，在正式投入使用之前他們煞費苦心的學習 HBase 和 Redis。同時在試點項目中使用或將其控制在有限損害范圍之內。

英文原文：The Tumblr Architecture Yahoo Bought For A Cool Billion Dollars

譯文鏈接：http://www.oschina.net/translate/the-tumblr-architecture-yahoo-bought-for-a-cool-billion-doll