當一個開發人員提升計算機系統負荷時，通常會考慮兩種方式垂直擴展和水平擴展。選用哪種策略主要依賴於要解決的問題 以及系統資源的限制。在這篇文章中我們將講述這兩種策略並討論每種策越的優缺點。如果你已經有一個軟件系統需要不斷成長，那麼你將有意或者無意中選擇這兩 種策略中的一種。
垂直擴展
在垂直擴展模型中，想要增加系統負荷就意味着要在系統現有的部件上下工夫，即通過提高系統部件的能力來實現。例如，假設你現在負責一批木材採伐的操作。
在這個例子中，我們假設有3輛卡車，每輛車一次可以運25根木材，計算花費1小時的情況下可以運送到指定地點等待處理的木材數量。通過這些數字我們可以算出我們系統最大的負荷量：
3輛卡車 * 25根木材 * 1小時=75根木材／小時
如果我們選擇垂直擴展模型，那麼我們將怎麼做來使我們每小時可以處理150根木材？我們需要至少做以下兩件事中的一件：
使每輛卡車的運輸量增加一倍（50棵樹每小時），或者使每輛卡車的運輸時間減半（每輛卡車30分鐘）。
3輛卡車 * 50棵樹 * 1小時 = 150棵樹／每小時
或者
3輛卡車 * 25棵樹 * 30分鐘 = 150棵樹／每小時
我們沒有增加系統的成員數，但是我們通過增加系統成員的生產效率來獲得期望的負荷量。
水平擴展
在水平擴展模型中，我們不是通過增加單個系統成員的負荷而是簡單的通過增加更多的系統成員來實現。也就是說，在以上運送木材的例子中，通過增加卡車的數量來運送木材。因此，當我們需要將負荷從75棵樹每小時增加到150棵樹每小時，那麼只需要增加3輛卡車。
6輛卡車 * 25棵樹 * 1小時 = 150棵樹／每小時
假如我們已經選擇了垂直擴展方式，那麼我們想要每小時處理150棵被砍伐的樹時需要怎麼做呢？我們需要做到以下兩方面之一：要麼使每輛卡車的運輸量翻倍(50棵木材一次)，要麼使每輛開車的運輸時間減半(30分鐘)。
3輛卡車 * 50棵樹 * 1小時 = 150棵樹／每小時
或者
3輛卡車 * 50棵樹 * 30分鐘 = 150棵樹／每小時
在這個例子中，系統每個成員的生產力依然沒變，我們通過增加更多的卡車來提高系統的能力。
擴展你的web數據庫
通過對水平擴展和垂直擴展的基本瞭解，下面讓我們來關注web系統的擴展。一個網站通常有很多組件都需要去考慮它們的擴展性，但是我通常喜歡關注處在最邊緣的一個：數據庫。爲什麼數據庫是最邊緣的？因爲數據庫通常是共享資源，是幾乎所有請求最終的連接點。
你的系統是什麼類型的？
在 擴展你的數據庫時，你必須要問的一個重要問題是：“我所面對的系統是什麼類型的？”你所面對的是一個讀操作多還是寫操作多的系統？讀操作多的網站一般包 括：在線商城，在商城裏用戶大部時間是在瀏覽(讀操作)，只有少數時間在付款(寫操作)、或者博客，在博客上人們大部分時間是在瀏覽博文(讀操作)，只有 少數時間是在評論或者發表博文(寫操作)。相反的，關於寫操作非常多的很好的例子包括：信用卡交易處理器，這個系統的主要負載時在處理記錄交易(寫操 作)，偶爾會查找交易(讀操作)、或者Google分析，主要工作實在記錄業務數據(寫操作)，偶爾會展示分析圖(讀操作)。
瞭解你所創建的網站是什麼類型的，可以在網站成長過程中幫助你選擇正確的技術。
讀操作擴展
如 果你的系統讀操作非常多，那麼通過關係型數據庫如mysql或者PostgreSql來垂直擴展數據存儲是一個不錯的選擇。結合你的關係型數據庫通過使用 memcached或者CDN來構建一個健壯的緩存系統，那麼你的系統將非常容易擴展。在這種模式中，如果數據庫超負荷運行，那麼將更多的數據放入緩存中 來緩解系統的讀壓力。當沒有更多的數據往緩存中放時，可以更換更快的數據存儲硬件或者買更多核的處理器來獲取更多的運行通道。摩爾定律使通過這種方法來垂 直擴展變得和購買更好的硬件一樣簡單。
寫操作擴展
如 果你的系統寫操作非常多，那麼你可能更希望考慮使用可水平擴展的數據存儲方式，比如Riak，Cassandra或者HBase。和大多數關係型數據管理 系統不同，這種數據存儲隨着增長增加更多的節點。由於你的系統大部分時間是在寫入，所以緩存曾並不能像在讀操作比較頻繁的系統中起到那麼大作用。很多寫頻 繁的系統一開始使用垂直擴展的方式，但是很快發現並不能根本解決問題。爲什麼？因爲硬盤數和處理器數在某一點達到平衡，在這個邊界上再增加一個處理器或者 一個硬盤都會是每秒鐘的I/O操作數成指數性增長。相反，如果對寫頻繁的系統採取水平擴展策略，那麼你將達到一個拐點，在這個拐點之後如果在增加一個節點 都遠比使用更多的硬盤來的實惠。
其他注意事項
另 一件事需要記住的是每種擴展策略下預想不到的開銷。採用垂直擴展的系統將開銷凡在單獨的組件上。當我們去提升系統負荷時，這些單獨的組件需要在管理上花費 更多。拿我們運送木材的例子來說，如果需要使每輛卡車的貨運量翻倍，那麼我們需要更寬、更長、或者更高的車廂。也許有的路因爲橋的高度對車輛高度有要求， 或者基於巷子寬度車寬不能太大，又或者由於機動車安全駕駛要求車廂不能太長。這裏的限制就是對單個卡車做垂直擴展做的什麼程度。同樣的概念延伸到服務器垂 直擴展：更多的處理器要求更多的空間，進而要求更多的服務器存儲架。
相反的，採用水平擴展的系統將額外的開銷放在系統中連接起來的共享組件 上。當我們去提升系統負荷時，共享的開銷和新增加的成員之間的協調性有關。在我們運送木材的例子中，當我們在路上增加更多卡車時，那麼路就是共享資源也就 成了約束條件。這條路上適合同時跑多少量卡車？我們是否有足夠的安全緩衝區使得所有的車可以同時裝運木材？如果再來看我們水平擴展的數據庫系統，那麼經常 被忽略的開銷就是服務器同時連接時的網絡開銷(譯者注：網絡爲各個系統的共享資源)。當你爲系統增加更多的節點時，共享資源的負荷也就越來越重，通常呈非 線性改變。
綜合說明
和 計算機的大多數東西一樣，好的解決辦法通常並不像我這裏列出來的這麼簡單。而我在這裏嘗試簡化這種思想用來來說明這中概念而不是講具體的解決辦法。擴展是 個困難的問題，這是個需要在實際處理的每個步驟中都要思考的問題。擴展策略沒有魔法，也沒有魔法般的軟件幫你建立一個完整可靠的可擴展系統。就像擴展中的 其他問題一樣，一個大的解決方案通常是由很多個一起協調工作的小的解決辦法組成的。這需對每一箇中解決方案進行精心正確的設計和開發。