# FaceStat 的禍根與智慧贏得了勝利 > 原文： [http://highscalability.com/blog/2008/6/9/facestats-rousing-tale-of-scaling-woe-and-wisdom-won.html](http://highscalability.com/blog/2008/6/9/facestats-rousing-tale-of-scaling-woe-and-wisdom-won.html)  盧卡斯·比瓦爾德（Lukas Biewald）分享了一次令人著迷的[大滿貫，他的](http://www.lukasbiewald.com/?p=153) [FaceStat](http://facestat.com/) 網站（上傳圖片并由大眾判斷）如何被 Yahoo 的鏈接重擊 導致其網站上幾乎瞬間出現 650,000 頁瀏覽量跳升的主頁。 雅虎花費了大量的精力來確保自己的屬性能夠處理來自主頁的真正大量流量。 將 Internet 的[大眼睛](http://www.poster.net/lord-of-the-rings-ii/lord-of-the-rings-ii-eye-of-sauron-4900244.jpg)轉向毫無疑問的新生兒站點，一定是尿布準備就緒的體驗。 Theo Schlossnagle 在[中對這些事件進行了怪異的預言，因為標點符號對網站體系結構的影響](http://highscalability.com/implications-punctuated-scalabilium-website-architecture)：隨著變化無常的互聯網尋求新的娛樂方式，大規模，意外和突然的流量高峰將變得更加普遍（我的摘要）。 完全是 FaceStat 的情況。 這也是我們首次使用 Ruby on Rails 競爭對手 Merb 編寫的應用程序。 對于那些認為 Ruby 是問題的人，他們的體系結構現在提供的服務是原始負載的 100 倍。 我們出色的 FaceStat 研究金如何抵御 Yahoo 的猛攻？ 關于 FaceStat 架構的詳細信息并不多，因此不是這樣。 讓我感興趣的是，這是 Theo 流量高峰現象的及時例子，而我也被團隊處理挑戰的能力吸引了我。 很少有人能這么快做得更好。 實際上，讓我們將 Theo 的規則應用于如何處理這些情況到 FaceStat： * **保持警惕：構建自動化系統，以快速（不到 60 秒）檢測并查明這些問題的原因。** 最初沒有，但他們正在建立更多的監視以更好地處理未來情況。 更好的監控會在問題真正被警告之前很久就使他們警覺到問題。 也許更多的潛在客戶可能已轉換為實際客戶。 您將永遠無法獲得足夠的監控！* **做好準備：系統地了解服務的瓶頸。** 由于系統相對簡單，新穎且變化迅速，我的假設是他們完全意識到系統的缺點，他們只是在忙于添加功能，而不用擔心性能和可伸縮性。* **執行分類：了解組成您的網站的各種服務的重要性。** 肯定。 為了響應負載，他們“開始淘汰所有數據庫密集型功能”。* **保持冷靜：任何未經分析驅動的動作都是在浪費時間和精力。** 從以下引言中可以看出，它們保持了驚人的鎮定：“可伸縮地編碼并在增加的負載下緩慢增長是一回事，但瘋狂地重新構建諸如 FaceStat 之類的活動站點是一整天的事情。” 我不確定他們是如何進行分析的。? 總的來說，這是對 Great Eye 始終如一的關注的令人印象深刻的回應。 但并不是所有人都給我留下深刻的印象。一位名叫 Bernard 的評論員說：*很抱歉，但這真是一個愚蠢的故事。 考慮到諸如 slicehost 和 linode 這樣便宜的東西，發瘋了，您啟動了一個 Web 應用程序并且還沒有準備好冗余的，高度可伸縮的體系結構……我要說您很遺憾，失望的用戶終于回來了。* 評論員將認為這是一個“很好的問題！” 當然，被注意到比被忽略更好。 但是 Lukas 感到遺憾的是，當他為過早注意到而感到遺憾時有一個缺點：*在努力吸引用戶訪問您的網站后，令人驚訝的是，看到成千上萬的人突然被封鎖。* 顯然，開發人員無法像創建探索性系統那樣簡單地創建可伸縮系統。 來自 Rackspace 的 Ed 表示，他們可以幫助他們實現陣列自動縮放功能。 而 Rackspace 將是一個很好的解決方案，但費用為每月 500 美元和 2500 美元的安裝費。 沒有任何一家“放映秀”的創業公司能夠承擔這些費用。 FaceStat 所處的模式是典型的：*我們發現，類似于 Rails 的平臺對于快速建立新站點的原型非常有價值，尤其是因為我們將 FaceStat 作為純粹的實驗開始時卻不知道人們是否喜歡它，并且 與后來的功能相比，這是一個非常不同的功能。* 漸進式付費模型對于可伸縮性至關重要，因為這是一開始就可以增強可伸縮性的唯一方法。 即使該行業取得了令人矚目的進步，我們仍然沒有使擴展成為第二性質的軟件基礎架構。 ## 信息來源 * [快速擴展](http://www.lukasbiewald.com/?p=153)，作者：Lukas Biewald* [FaceStat scales!](http://blog.doloreslabs.com/2008/06/facestat-scales/) on Dlores BLog ## 平臺 * [Merb](http://merbivore.com/) 。 與 ORM 無關的基于 Ruby 的 MVC 框架。* [薄](http://code.macournoyer.com/thin/)。 快速，簡單的 Ruby Web 服務器。* [Slicehost](http://www.slicehost.com/) 。 托管服務。 能夠根據需要快速配置服務器。* [亞馬遜的 S3](http://en.wikipedia.org/wiki/Amazon_S3) 。 圖像服務器。 延遲很高，但可以處理負載。* [Capistrano](http://capify.org/) 。 自動化部署。* [Git](http://git.or.cz/) 和 [github](http://github.com/) 。 源代碼控制系統。 支持高效的同步開發，快速合并和部署。* [上帝](http://god.rubyforge.org/)。 服務器監視和管理。* [Memcached](http://www.danga.com/memcached/) 。 應用程序緩存層。* [PostgreSQL](http://www.postgresql.org/) ## 統計資料 * 六個應用服務器。* 一臺大型數據庫機。 ## 架構 * FaceStat 是一個寫繁重的應用程序，并且對數據執行涉及的計算。* S3 用于減輕存儲圖像的責任。 這使他們擺脫了巨大的帶寬需求和管理自己的圖像的復雜性。* Memcached 卸載了對數據庫的讀取，以使數據庫有更多時間進行寫入。 ## 得到教訓 * **監視站點**。 您越早知道問題，可以更快地解決它。 不要依賴用戶電子郵件或來自異常處理程序的電子郵件，否則您將永遠無法解決問題。* **通過錯誤頁面**與您的用戶通信。 有意義的錯誤頁面顯示您正在關心并且正在解決問題。 對于大多數人來說，第二次機會就足夠了。* **使用緩存的靜態生成的首頁**。 很難擊敗它的性能。* **大型網站在提及較小的網站**時可能要提請注意。 只要有一封簡短而禮貌的電子郵件，說明您的世界很快就會倒過來，就可以了。* **與整體架構**相比，高級平臺確實沒有關系。 處理寫入，讀取，緩存，部署，監視等的方式相對獨立于框架，這是解決重要問題的方式。* **Ruby 和 Merb** 支持快速原型設計，以實驗和創建與他們想要的系統完全不同的系統。 據博客稱，這并不奇怪，因為他們正在 VPS 上運行 FaceStat。 如此，確實有人說對了，“知識就是智慧” ----- [http://underwaterseaplants.awardspace.com”](<a rel=) >海洋植物 [http ：//underwaterseaplants.awardspace.com/seagrapes.htm“](<a rel=) >海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](<a rel=) >海藻