怎样写网络小说,天蚕土豆

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

Tumblr架構(gòu)設(shè)計

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

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),惠山企業(yè)網(wǎng)站建設(shè),惠山品牌網(wǎng)站建設(shè),網(wǎng)站定制,惠山網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,惠山網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

為什么雅虎會收購Tumblr? 這場交易中的商業(yè)價值我可能無法判斷,但是如果你對Tumblr的技術(shù)方面有所了解,你一定會為Tumblr豎起大拇指. 為什么這么說呢,請接著讀... Tumblr每月頁面瀏覽量超過150億次，已經(jīng)成為火爆的博客社區(qū)。用戶也許喜歡它的簡約、漂亮，并且它對用戶體驗強(qiáng)烈的關(guān)注，或是友好而忙碌的溝通方式，總之，它深得人們的喜愛。

每月超過30%的增長當(dāng)然不可能沒有挑戰(zhàn)，其中可靠性問題尤為艱巨。每天5億次瀏覽量，峰值每秒4萬次請求，每天3TB新的數(shù)據(jù)存儲，并運行于超過1000臺服務(wù)器上，所有這些幫助Tumblr實現(xiàn)巨大的經(jīng)營規(guī)模。

創(chuàng)業(yè)公司邁向成功，都要邁過危險的迅速發(fā)展期這道門檻。尋找人才，不斷改造基礎(chǔ)架構(gòu)，維護(hù)舊的架構(gòu)，同時要面對逐月大增的流量，而且曾經(jīng)只有4位工程師。這意味著必須艱難地選擇應(yīng)該做什么，不該做什么。這就是Tumblr的狀況。好在現(xiàn)在已經(jīng)有20位工程師了，可以有精力解決問題，并開發(fā)一些有意思的解決方案。

Tumblr最開始是非常典型的LAMP應(yīng)用。目前正在向分布式服務(wù)模型演進(jìn)，該模型基于Scala、HBase、Redis、Kafka、Finagle，此外還有一個有趣的基于Cell的架構(gòu)，用于支持Dashboard .現(xiàn)在的重點被放在了解決他們PHP程序中的短期問題，找出問題,并正確的使用服務(wù)化去解決他們. Tumblr目前的最大問題是如何改造為一個大規(guī)模網(wǎng)站。系統(tǒng)架構(gòu)正在從LAMP演進(jìn)為最先進(jìn)的技術(shù)組合，同時團(tuán)隊也要從小的創(chuàng)業(yè)型發(fā)展為全副武裝、隨時待命的正規(guī)開發(fā)團(tuán)隊，不斷創(chuàng)造出新的功能和基礎(chǔ)設(shè)施。下面就是Blake對Tumblr系統(tǒng)架構(gòu)情況的介紹。

Tumblr網(wǎng)址: http://www.tumblr.com/

統(tǒng)計

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

軟件

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

硬件

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

47 個池
30 個分區(qū)

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

構(gòu)架

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

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

老的Tumblr構(gòu)架

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

新的構(gòu)架

由于招人和開發(fā)速度等原因，改為以JVM為中心。
目標(biāo)是將一切從PHP應(yīng)用改為服務(wù)，使應(yīng)用變成請求鑒別、呈現(xiàn)等諸多服務(wù)之上的薄層。
選擇了Scala 和 Finagle
1. 在團(tuán)隊內(nèi)部有很多人具備Ruby和PHP經(jīng)驗，所以Scala很有吸引力。
2. Finagle是選擇Scala的重要因素之一。這個來自Twitter的庫可以解決大多數(shù)分布式問題，比如分布式跟蹤、服務(wù)發(fā)現(xiàn)、服務(wù)注冊等。
3. 轉(zhuǎn)到JVM上之后，F(xiàn)inagle提供了團(tuán)隊所需的所有基本功能（Thrift, ZooKeeper等），無需再開發(fā)許多網(wǎng)絡(luò)代碼，另外，團(tuán)隊成員認(rèn)識該項目的一些開發(fā)者。
4. Foursquare和Twitter都在用Finagle，Meetup也在用Scala。
5. 應(yīng)用接口與Thrift類似，性能極佳。
6. 團(tuán)隊本來很喜歡Netty，但不想用Java，Scala是不錯的選擇。
7. 選擇Finagle是因為它很酷，還認(rèn)識幾個開發(fā)者。
8. 之所以沒有選擇Node.js，是因為以JVM為基礎(chǔ)更容易擴(kuò)展。Node的發(fā)展為時尚短，缺乏標(biāo)準(zhǔn)、最佳實踐以及大量久經(jīng)測試的代碼。而用Scala的話，可以使用所有Java代碼。雖然其中并沒有多少可擴(kuò)展的東西，也無法解決5毫秒響應(yīng)時間、49秒HA、4萬每秒請求甚至有時每秒40萬次請求的問題。但是，Java的生態(tài)鏈要大得多，有很多資源可以利用。
內(nèi)部服務(wù)從C/libevent為基礎(chǔ)正在轉(zhuǎn)向Scala/Finagle為基礎(chǔ)。
開始采用新的NoSQL存儲方案如HBase和Redis。但大量數(shù)據(jù)仍然存儲在大量分區(qū)的MySQL架構(gòu)中，并沒有用HBase代替MySQL。
HBase主要支持短地址生產(chǎn)程序（數(shù)以十億計）還有歷史數(shù)據(jù)和分析，非常結(jié)實。此外，HBase也用于高寫入需求場景，比如Dashboard刷新時一秒上百萬的寫入。之所以還沒有替換HBase，是因為不能冒業(yè)務(wù)上風(fēng)險，目前還是依靠人來負(fù)責(zé)更保險，先在一些小的、不那么關(guān)鍵的項目中應(yīng)用，以獲得經(jīng)驗。
MySQL和時間序列數(shù)據(jù)sharding（分片）的問題在于，總有一個分片太熱。另外，由于要在slave上插入并發(fā)，也會遇到讀復(fù)制延遲問題。
此外，還開發(fā)了一個公用服務(wù)框架：
1. 花了很多時間解決分布式系統(tǒng)管理這個運維問題。
2. 為服務(wù)開發(fā)了一種Rails scaffolding，內(nèi)部用模板來啟動服務(wù)。
3. 所有服務(wù)從運維的角度來看都是一樣的，所有服務(wù)檢查統(tǒng)計數(shù)據(jù)、監(jiān)控、啟動和停止的方式都一樣。
4. 工具方面，構(gòu)建過程圍繞SBT（一個Scala構(gòu)建工具），使用插件和輔助程序管理常見操作，包括在Git里打標(biāo)簽，發(fā)布到代碼庫等等。大多數(shù)程序員都不用再操心構(gòu)建系統(tǒng)的細(xì)節(jié)了。
40臺服務(wù)器采用HAProxy進(jìn)行負(fù)載均衡,Varnish進(jìn)行緩存.
200臺數(shù)據(jù)庫服務(wù)器中，很多是為了提高可用性而設(shè)，使用的是常規(guī)硬件，但MTBF（平均故障間隔時間）極低。故障時，備用充足。
500臺服務(wù)器運行Apache和其他PHP程序。
6個為了支持PHP應(yīng)用的后端服務(wù)，并有一個小組專門開發(fā)后端服務(wù)。新服務(wù)的發(fā)布需要兩到三周，包括Dashboard通知、Dashboard二級索引、短地址生成、處理透明分片的memcache代理。
其中在MySQL分片上耗時很多。雖然在紐約本地非常熱，但并沒有使用MongoDB，他們認(rèn)為MySQL的可擴(kuò)展性足夠了。
Gearman用于會長期運行無需人工干預(yù)的工作。
可用性是以達(dá)到范圍（reach）衡量的。用戶能夠訪問自定義域或者Dashboard嗎？也會用錯誤率。
歷史上總是解決那些最高優(yōu)先級的問題，而現(xiàn)在會對故障模式系統(tǒng)地分析和解決，目的是從用戶和應(yīng)用的角度來定成功指標(biāo)。
最開始Finagle是用于Actor模型的，但是后來放棄了。對于運行后無需人工干預(yù)的工作，使用任務(wù)隊列。而且Twitter的util工具庫中有Future實現(xiàn)，服務(wù)都是用Future（Scala中的無參數(shù)函數(shù)，在與函數(shù)關(guān)聯(lián)的并行操作沒有完成時，會阻塞調(diào)用方）實現(xiàn)的。當(dāng)需要線程池的時候，就將Future傳入Future池。一切都提交到Future池進(jìn)行異步執(zhí)行。
Scala提倡無共享狀態(tài)。由于已經(jīng)在Twitter生產(chǎn)環(huán)境中經(jīng)過測試，F(xiàn)inagle這方面應(yīng)該是沒有問題的。使用Scala和Finagle中的結(jié)構(gòu)需要避免可變狀態(tài)，不使用長期運行的狀態(tài)機(jī)。狀態(tài)從數(shù)據(jù)庫中拉出、使用再寫回數(shù)據(jù)庫。這樣做的好處是，開發(fā)人員不需要操心線程和鎖。
22臺Redis服務(wù)器，每臺的都有8-32個實例，因此線上同時使用了100多個Redis實例。
1. Redis主要用于Dashboard通知的后端存儲。
2. 所謂通知就是指某個用戶like了某篇文章這樣的事件。通知會在用戶的Dashboard中顯示，告訴他其他用戶對其內(nèi)容做了哪些操作。
3. 高寫入率使MySQL無法應(yīng)對。
4. 通知轉(zhuǎn)瞬即逝，所以即使遺漏也不會有嚴(yán)重問題，因此Redis是這一場景的合適選擇。
5. 這也給了開發(fā)團(tuán)隊了解Redis的機(jī)會。
6. 使用中完全沒有發(fā)現(xiàn)Redis有任何問題，社區(qū)也非常棒。
7. 開發(fā)了一個基于Scala Futures的Redis接口，該功能現(xiàn)在已經(jīng)并入了Cell架構(gòu)。
8. 短地址生成程序使用Redis作為一級Cache，HBase作為永久存儲。
9. Dashboard的二級索引是以Redis為基礎(chǔ)開發(fā)的。
10. Redis還用作Gearman的持久存儲層，使用Finagle開發(fā)的memcache代理。
11. 正在緩慢地從memcache轉(zhuǎn)向Redis。希望最終只用一個cache服務(wù)。性能上Redis與memcache相當(dāng)。

#p#

內(nèi)部通訊管道(Firehose)

內(nèi)部的應(yīng)用需要活躍的信息流通道。這些信息包括用戶創(chuàng)建/刪除的信息，liking/unliking 的提示，等等。挑戰(zhàn)在于這些數(shù)據(jù)要實時的分布式處理。我們希望能夠檢測內(nèi)部運行狀況，應(yīng)用的生態(tài)系統(tǒng)能夠可靠的生長，同時還需要建設(shè)分布式系統(tǒng)的控制中心。
以前，這些信息是基于 Scribe (Facebook 開源的分布式日志系統(tǒng)。)/Hadoop 的分布式系統(tǒng)。服務(wù)會先記錄在 Scribe 中，并持續(xù)的長尾形式寫入，然后將數(shù)據(jù)輸送給應(yīng)用。這種模式可以立即停止伸縮，尤其在峰值時每秒要創(chuàng)建數(shù)以千計的信息。不要指望人們會細(xì)水長流式的發(fā)布文件和 grep。
內(nèi)部的 firehose 就像裝載著信息的大巴，各種服務(wù)和應(yīng)用通過 Thrift 與消防管線溝通。(一個可伸縮的跨語言的服務(wù)開發(fā)框架。)
LinkedIn 的 Kafka 用于存儲信息。內(nèi)部人員通過 HTTP 鏈接 firehose。經(jīng)常面對巨大的數(shù)據(jù)沖擊，采用 MySQL 顯然不是一個好主意，分區(qū)實施越來越普遍。
firehose 的模型是非常靈活的，而不像 Twitter 的 firehose 那樣數(shù)據(jù)被假定是丟失的。
1. firehose 的信息流可以及時的回放。他保留一周內(nèi)的數(shù)據(jù)，可以調(diào)出這期間任何時間點的數(shù)據(jù)。
2. 支持多個客戶端連接，而且不會看到重復(fù)的數(shù)據(jù)。每個客戶端有一個 ID。Kafka 支持客戶群，每個群中的客戶都用同一個 ID，他們不會讀取重復(fù)的數(shù)據(jù)?？梢詣?chuàng)建多個客戶端使用同一個 ID，而且不會看到重復(fù)的數(shù)據(jù)。這將保證數(shù)據(jù)的獨立性和并行處理。Kafka 使用 ZooKeeper (Apache 推出的開源分布式應(yīng)用程序協(xié)調(diào)服務(wù)。)定期檢查用戶閱讀了多少。

為 Dashboard 收件箱設(shè)計的 Cell 架構(gòu)

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

在紐約啟動運作

紐約具有獨特的環(huán)境，資金和廣告充足。招聘極具挑戰(zhàn)性，因為缺乏創(chuàng)業(yè)經(jīng)驗。
在過去的幾年里，紐約一直致力于推動創(chuàng)業(yè)。紐約大學(xué)和哥倫比亞大學(xué)有一些項目，鼓勵學(xué)生到初創(chuàng)企業(yè)實習(xí)，而不僅僅去華爾街。市長建立了一所學(xué)院，側(cè)重于技術(shù)。

團(tuán)隊架構(gòu)

團(tuán)隊：基礎(chǔ)架構(gòu)，平臺，SRE，產(chǎn)品，web ops，服務(wù)
基礎(chǔ)架構(gòu)：5層以下，IP 地址和 DNS，硬件配置
平臺：核心應(yīng)用開發(fā)，SQL 分片，服務(wù)，Web 運營
SRE：在平臺和產(chǎn)品之間，側(cè)重于解決可靠性和擴(kuò)展性的燃眉之急
服務(wù)團(tuán)隊：相對而言更具戰(zhàn)略性
Web ops：負(fù)責(zé)問題檢測、響應(yīng)和優(yōu)化

軟件部署

開發(fā)了一套 rsync 腳本，可以隨處部署 PHP 應(yīng)用程序。一旦機(jī)器的數(shù)量超過 200 臺，系統(tǒng)便開始出現(xiàn)問題，部署花費了很長時間才完成，機(jī)器處于部署進(jìn)程中的各種狀態(tài)。
接下來，使用 Capistrano（一個開源工具，可以在多臺服務(wù)器上運行腳本）在服務(wù)堆棧中構(gòu)建部署進(jìn)程（開發(fā)、分期、生產(chǎn)）。在幾十臺機(jī)器上部署可以正常工作，但當(dāng)通過 SSH 部署到數(shù)百臺服務(wù)器時，再次失敗。
現(xiàn)在，所有的機(jī)器上運行一個協(xié)調(diào)軟件。基于 Redhat Func（一個安全的、腳本化的遠(yuǎn)程控制框架和接口）功能，一個輕量級的 API 用于向主機(jī)發(fā)送命令，以構(gòu)建擴(kuò)展性。
建立部署是在 Func 的基礎(chǔ)上向主機(jī)發(fā)送命令，避免了使用 SSH。比如，想在組A上部署軟件，控制主機(jī)就可以找出隸屬于組A的節(jié)點，并運行部署命令。
通過Capistrano的命令實現(xiàn)部署。它可以可以從git倉庫中拉取代碼。正因為是基于HTTP的,所以非常易于擴(kuò)展。他們喜歡 Capistrano，因為它支持簡單的基于目錄的版本控制，能夠很好地管理PHP程序。版本更新的時候，每個目錄都包含一個SHA，所以很容易檢查版本的正確性。
Func API 可用于返回狀態(tài)報告，報告哪些機(jī)器上有這些軟件版本。
安全重啟任何服務(wù)，因為它們會關(guān)閉連接，然后重啟。
在激活前的黑暗模式下運行所有功能。

開發(fā)

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

招聘流程

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

經(jīng)驗及教訓(xùn)

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

英文原文：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

分享題目：Tumblr架構(gòu)設(shè)計
標(biāo)題網(wǎng)址：http://www.fisionsoft.com.cn/article/cocssse.html

新聞中心

其他資訊