l雖然經受「/.效應」的考驗常被人拿來說事，但其實yahoo!的首頁才是
網際網路上最繁忙的站點
。lukas biewald講述了他的
facestat
**被yahoo！首頁上榜之後訪問人數急速上公升到100,000，因而不得不
快速完成伸縮的故事。
第一反應是建立靜態的頁面，但他們發現仍不足以在洶湧的潮水中站住腳：
難以置信，我們的web伺服器（nginx）連靜態頁面也沒辦法可靠地顯示……brendan發現我們已經達到了系統對最大檔案開啟數的限制——100,000——因為連線也算是開啟檔案。接著團隊轉向要求主機託管商增加伺服器資源，增加快取，並且開始去除一些功能：
brendan忙著安裝新的機器，我則開始砍掉系統裡所有資料庫密集的功能，chris負責增加快取……大概中午1點**重新上線，看起來很穩定。周一負荷繼續增大，於是團隊增加了memcached、監控工具，還把資料庫移到了另一台更大的機器上：
現在已經是周二的晚上，原來在一台機器上處理的負載，現在已經增長到了50倍，**看上去有點搖搖欲墜。我們有6臺應用伺服器和一台大型的資料庫伺服器。chri和brendan真是了不起的黑客，現在的工具進步也很了不起。slicehost的伸縮速度正是我們需要的。amazon的s3負擔了所有的，雖然響應延遲不甚完美，但單憑我們自己絕對解決不了這種頻寬問題。capistrano讓我們得以隨時隨處部署和回滾；git加上github讓我們得以爭分奪秒地分頭行動，再把**合併到一起做部署。god保障伺服器執行。memcached給了我們出色的快取，而痛苦非常少（基本上……lukas總結他們在三天裡得到的教訓：
編寫可伸縮的**然後隨著負載增長慢慢地提高，這是一回事；像我們這樣在一兩天裡瘋狂地重新架構乙個工作中的**則是截然不同的另一回事。我想現在 **已經是網際網路上能排得上號的了，應該不會再有更大規模的流量突然上公升……不過如果再發生這樣的事情，我已經在這次經歷中學到了一些教訓：brendan o'connor在一篇後續文章中談到了facestat應用背後的技術：（2）不要畏懼放上乙個錯誤頁面。當我們放上乙個頁面說明**掛了並解釋原因之後，收到了很多興高采烈的使用者來信。而當我們的**勉強執行，不但延 遲嚴重還斷斷續續地宕機的時候，我們收到了很多憤怒的使用者來信。不切實際的想法讓我們在**真正準備好之前一兩個小時就把它上了線。
（3）靜態生成的首頁是件好東西，memcached是件了不起的東西。
是的，我們基本上是用rails。我們實際上用的從rails衍生出來的merb，它的效率更高一些，底下用的是thin。我們發現rails類的平台對於快速打造新**的原型真是無價之寶。特別是我們啟動facestat的時候完全是當作乙個實驗品，根本不清楚人們會不會喜歡，而且最初的功能設想和後來實際的情形差別很大。chris這個ruby專家對於我們的團隊也是無價之寶:)。不過，與整體的架構相比，高層的平台實在不算什麼：我們如何使用資料庫（postgres）、如何快取（memcached/merb- cache）、如何分攤負載、如何部署新系統（xen/slicehost），這些才是真正有影響的架構議題。facestat是寫操作密集的、要執行的 統計計算也相當複雜，種種問題都不可小視。但現在我們所服務的使用者比原先的負載提高了將近100倍，也就是說我們幹得還算不錯——至少現在！
設計彈性伸縮架構
在我們討論彈性伸縮內容之前，我們先討論下與之相關的知識點 什麼是垂直擴充套件和水平擴充套件。垂直擴充套件是指提公升單個節點的自身的處理能力，比如通過公升級節點的cpu，記憶體等硬體，這種通過公升級原有的伺服器或將其更換為更強大的硬體來提公升單個節點的處理能力稱為垂直擴充套件 比如對應aws，就是通過...
可伸縮架構簡短系列
採取什麼辦法可以讓乙個web服務可大規模可擴充套件？相信你會對這個問題感興趣。通常來說，公共伺服器上的乙個可伸縮的web服務總是隱藏在乙個load balancer 負載均衡器 之後。這個負載均衡器會將負載 來自使用者的請求 均勻的分配到一組伺服器或者伺服器集群。那意味著什麼？舉個例子 某個使用者訪...
可伸縮架構簡短系列
採取什麼辦法可以讓乙個web服務可大規模可擴充套件？相信你會對這個問題感興趣。通常來說，公共伺服器上的乙個可伸縮的web服務總是隱藏在乙個load balancer 負載均衡器 之後。這個負載均衡器會將負載 來自使用者的請求 均勻的分配到一組伺服器或者伺服器集群。那意味著什麼？舉個例子 某個使用者訪...