《Web容量規劃的藝術》由John Allspaw(F訂ickr的工程運營經理)撰寫，結合了他個人在F1ickr成長過程中的許多經歷和很多其他產業中同行的洞察力。在衡量增長、預測趨勢、成本效益等方面，他們的經驗都會給你一些可靠並有效的指導。 網站的成功是以使用和增長來衡量的，而且網站類公司的成敗(生死)是依賴於他們是否有能力來衡量決定他們的基礎結構，從而適應不斷增長的需求。作者通過自身實踐給你提供所需要的相關知識和工具，來幫助你預知一些有威脅性的瓶頸問題和突然的網路增長，從而測量、部署並提前設計好網站套用的基本架構。
基本介紹
- 書名：Web容量規劃的藝術
- 作者：阿爾斯帕瓦(John Allspaw)
- 出版社：機械工業出版社
- 頁數：126頁
- 開本：16
- 定價：29.00
- 外文名：The Art of Capacity Planning
- 譯者：葉飛
- 出版日期：2010年1月1日
- 語種：簡體中文
- ISBN：7111274016, 9787111274018
- 品牌：機械工業出版社
內容簡介,作者簡介,媒體推薦,圖書目錄,文摘,序言,
內容簡介
《Web容量規劃的藝術》：主要內容：使用有效的工具測量和部量。對存儲、資料庫、套用伺服器進行分析和預測容量。設計架構便於增加和測量容量。處理突發流量的峰值。預測指數和爆炸性增長。把虛擬化和雲服務（例如EC2）引入容量策略。
在《Web容量規劃的藝術》中，作者吸引了多年來的一些有價值的經驗，從他在Flickr的早期管理成本和性能的權衡開始，這些對於任何成長的公司都極具參考價值。《Web容量規劃的藝術》所提供的一些建議將會幫助你為突發的增長做準備，並幫你避免很多的麻煩。
在《Web容量規劃的藝術》中，作者吸引了多年來的一些有價值的經驗，從他在Flickr的早期管理成本和性能的權衡開始，這些對於任何成長的公司都極具參考價值。《Web容量規劃的藝術》所提供的一些建議將會幫助你為突發的增長做準備，並幫你避免很多的麻煩。
作者簡介
作者：(美國)阿爾斯帕瓦(John Allspaw) 譯者：葉飛 羅江華
John AllspaW目前就職於Flickr.com並擔任工程經理一職，該網站以共享用戶上傳的照片聞名。自該網站1999年成立以來，使他聚集了豐富的經驗。這些經驗包括線上新聞雜誌（比如：Salon.com、Infoworld.com、Macworld.com）以及一些當前急速增長的社會站點（比如Friendstet和Flickr）
John在Friendster公司時，該網站曾呈五倍增長。他負責將Friend-ster站點從只有幾十台伺服器的數據中心過度到多於400台伺服器的兩個數據中心，以支持重新設計的後端基礎設施。當他加盟Flickr公司時，在溫哥華只有一個10多台伺服器的微小數據中心，現在在美國已經設立了多個數據中心。在他從事網站職業之前，John曾作為機械工程師在建模和仿真領域為國家公路交通安全局的汽車碰撞模擬實驗做出貢獻
John AllspaW目前就職於Flickr.com並擔任工程經理一職，該網站以共享用戶上傳的照片聞名。自該網站1999年成立以來，使他聚集了豐富的經驗。這些經驗包括線上新聞雜誌（比如：Salon.com、Infoworld.com、Macworld.com）以及一些當前急速增長的社會站點（比如Friendstet和Flickr）
John在Friendster公司時，該網站曾呈五倍增長。他負責將Friend-ster站點從只有幾十台伺服器的數據中心過度到多於400台伺服器的兩個數據中心，以支持重新設計的後端基礎設施。當他加盟Flickr公司時，在溫哥華只有一個10多台伺服器的微小數據中心，現在在美國已經設立了多個數據中心。在他從事網站職業之前，John曾作為機械工程師在建模和仿真領域為國家公路交通安全局的汽車碰撞模擬實驗做出貢獻
媒體推薦
本書是最佳的入門書籍，幫助網站很好地運行。不論你是在學習組織中的採購過程，還是在學習成功規劃的一些特別的方法，對於任何一個想要了解如何建立下一個Flickrl人，這都是一本必讀的書。
——Chad Dickerson，Etsy CTO，Salon.comInfoWorld.com 前任CTO，Yahoo!Developer Network和Brickhouse領導者
——Chad Dickerson，Etsy CTO，Salon.comInfoWorld.com 前任CTO，Yahoo!Developer Network和Brickhouse領導者
圖書目錄
前言
第1章 容量規劃的目標、問題和過程
快捷但不好的數學
預測你的系統何時會失敗
用系統統計表呈現問題
買東西：採購是一個過程
性能與容量：兩種不同的概念
社交網站和開放式API的影響
第2章 設定容量目標
不同種類的需求和測量方法．
架構決策
第3章 測量：容量的單位
容量跟蹤工具的方方面面
應用程式監測
API的使用率及其對容量的影響
示例和現實
小結
第4章 趨勢預測
曲線擬合
採購
增加容量後的影響
長期趨勢
疊代和校準
小結
第5章 部署
自動化部署基本原理
自動化安裝工具
自動化部署
小結
附錄A 虛擬化和雲計算
附錄B 對瞬時增長的處理
附錄C 容量工具
第1章 容量規劃的目標、問題和過程
快捷但不好的數學
預測你的系統何時會失敗
用系統統計表呈現問題
買東西：採購是一個過程
性能與容量：兩種不同的概念
社交網站和開放式API的影響
第2章 設定容量目標
不同種類的需求和測量方法．
架構決策
第3章 測量：容量的單位
容量跟蹤工具的方方面面
應用程式監測
API的使用率及其對容量的影響
示例和現實
小結
第4章 趨勢預測
曲線擬合
採購
增加容量後的影響
長期趨勢
疊代和校準
小結
第5章 部署
自動化部署基本原理
自動化安裝工具
自動化部署
小結
附錄A 虛擬化和雲計算
附錄B 對瞬時增長的處理
附錄C 容量工具
文摘
插圖：
用戶期望顯然，容量規劃的終極目標是對你的用戶提供平穩、快速的用戶體驗。除了容量之外，還有幾個影響用戶體驗的因素。你的站點有可能已經提供了大量的容量，卻仍然很慢。如何設計快速的網頁已經超出了《Web容量規劃的藝術》的範疇，但你可以從（《高性能網站》 （Highperformance Web Sites（O'Reilly），作者：Steve Souders）這本好書中找到大量有用的信息。儘管容量只是使得終端用戶體驗加快的一個部分，這個體驗還是為了進行預測我們需要測量和跟蹤的真實世界度量指標之一。例如，當提供靜態網頁服務時，你也許在任何系統層度量指標（CPU、磁碟、記憶體）到達閾值之前，到達一個難以容忍的的高流量的延時。在這種情況下，可以在網站頁面結構方面而不是伺服器傳送內容的容量方面做更多的工作。但是，由於容量改變的成本較高，所以需要恰當的調研。感覺到網頁很慢也許只是因為頁面本身太巨大，而不是由於缺乏容量（這是souders書中的其中一個基本原則）。當任何用戶感覺到慢時，好的方法是確認是否每個用例都被分析了。這個問題可以有2種解決方案：1）增加容量；2）修改網頁的大小。第一種方案通常需要更多的成本。在Flickr，我們每秒鐘需要提供上萬的照片服務。每個照片伺服器在到達它的上限之前可以提供確定速率的照片。我們沒有根據磁碟I/0、CPU、記憶體來定義上限，而是根據特定的回響時間在我們能提供多少數量的照片服務。架構決策 你的架構是關於你所有的後端組件（包括硬體和軟體）是怎樣結合的基本的設計。架構的設計對於規劃和管理容量起到至關重要的作用。架構設計是個複雜的任務，但有一些很不錯的書可以幫助你Building Scalable Web Sites（0’Reilly）（《構建可擴展網站》），和Scalable Internet Architectures（Peatson）（《可擴展的網路架構》）。你的架構幾乎會影響到性能、可靠性、管理等各個方面。建立一個好的架構可以為容量規劃減輕很多工作量。提供測量點不管是為了測量的目的，還是對變化的環境快速回響，你都希望你的架構設計完美，以便你能將它分割成不同的部分來執行離散的任務。在一個理想的情況下，後端的每個組件都有一個單獨的工作要做，但如果需要，它也可以很好地執行多個工作。同時，它對每個工作的影響也可以很容易的被測量。
用戶期望顯然，容量規劃的終極目標是對你的用戶提供平穩、快速的用戶體驗。除了容量之外，還有幾個影響用戶體驗的因素。你的站點有可能已經提供了大量的容量，卻仍然很慢。如何設計快速的網頁已經超出了《Web容量規劃的藝術》的範疇，但你可以從（《高性能網站》 （Highperformance Web Sites（O'Reilly），作者：Steve Souders）這本好書中找到大量有用的信息。儘管容量只是使得終端用戶體驗加快的一個部分，這個體驗還是為了進行預測我們需要測量和跟蹤的真實世界度量指標之一。例如，當提供靜態網頁服務時，你也許在任何系統層度量指標（CPU、磁碟、記憶體）到達閾值之前，到達一個難以容忍的的高流量的延時。在這種情況下，可以在網站頁面結構方面而不是伺服器傳送內容的容量方面做更多的工作。但是，由於容量改變的成本較高，所以需要恰當的調研。感覺到網頁很慢也許只是因為頁面本身太巨大，而不是由於缺乏容量（這是souders書中的其中一個基本原則）。當任何用戶感覺到慢時，好的方法是確認是否每個用例都被分析了。這個問題可以有2種解決方案：1）增加容量；2）修改網頁的大小。第一種方案通常需要更多的成本。在Flickr，我們每秒鐘需要提供上萬的照片服務。每個照片伺服器在到達它的上限之前可以提供確定速率的照片。我們沒有根據磁碟I/0、CPU、記憶體來定義上限，而是根據特定的回響時間在我們能提供多少數量的照片服務。架構決策 你的架構是關於你所有的後端組件（包括硬體和軟體）是怎樣結合的基本的設計。架構的設計對於規劃和管理容量起到至關重要的作用。架構設計是個複雜的任務，但有一些很不錯的書可以幫助你Building Scalable Web Sites（0’Reilly）（《構建可擴展網站》），和Scalable Internet Architectures（Peatson）（《可擴展的網路架構》）。你的架構幾乎會影響到性能、可靠性、管理等各個方面。建立一個好的架構可以為容量規劃減輕很多工作量。提供測量點不管是為了測量的目的，還是對變化的環境快速回響，你都希望你的架構設計完美，以便你能將它分割成不同的部分來執行離散的任務。在一個理想的情況下，後端的每個組件都有一個單獨的工作要做，但如果需要，它也可以很好地執行多個工作。同時，它對每個工作的影響也可以很容易的被測量。
序言
2005年7月7日凌晨3點左右，我和我的同事卡爾·亨德森正在處理將網站Flickr.com的所有訪問流量遷移到它的新家（位於德克薩斯州的一個Yahoo！數據中心）的收尾工作。原來在溫哥華的那些基礎設施的超負荷現象越來越嚴重，而且受到電力和空間的嚴重限制。因為雅虎剛剛收購了Flickr，所以是時候提高它的線上容量了。當我們將DNs記錄指向嶄新的伺服器後，大約過了一個小時，卡爾不經意間看到了一則新聞：倫敦捷運剛剛遭遇了炸彈襲擊。倫敦市民用具有拍照功能的手機和其他設備記錄下了發生的一切。在接下來的24小時裡，F1ickr的訪問流量比以往任何時候都大，因為來自災難現場的照片被不斷地上傳到網站上面。新聞也開始連結到這些照片，新伺服器的訪問流量因此到達了峰值。這不只是全民從事新聞工作的一個極佳範例，也是網站容量規劃的一堂實物教學課。不幸的是，它來自於一場災難。網路訪問流量其有偶然性和不可預測性。如果我們沒有將Flickr及時遷移到新的數據中心，它那天也許會宕掉。容量規劃古已有之，從經濟學到工程學等領域都有所套用。通俗地講，容量規劃就是資源管理。當資源有限且具有一定成本時，你就需要進行容量規劃。當一家土木工程公司設計一個新的高速公路系統時，它需要對車輛承載容量進行規劃，正如一個為大城市提供電力的能源公司需要進行容量規劃一樣。在某些方面，他們關注的重點和網站運營有很多共同點，許多基本的概念和重點都可以套用於這三門學科。雖然系統管理在20世紀60年代就已經存在，但是專注於為Web站點提供服務的分支還是新出現的。網站運營的很大一部分工作就是站點容量的規劃和管理。這些只是過程而不是目標，並且它們由不同的部分組成。儘管每個組織採取的方式各不相同，但是基本原理還是一樣的。
