摘要：均衡負載多臺服務器執行程序，將大量請求分攤給多臺服務器無論如何，一臺服務器的進程是有限的，我們不可能無限制的把一臺服務器的加到個，把內存加到，則是不可能的。

在生產環境中，一個網站或服務端應用出現響應遲緩的時候，就應該考慮是否由于用戶量太多，導致服務器難以處理的情況，并應該考慮花錢來解決這個問題。當然，這里首先會想到廉價的解決方式，比如通過調整服務器配置，優化代碼性能等，但這些方式技術成本和時間成本大，有的時候優化效果也并不理想。而最簡單粗暴，也是最有效的方式，就是我們俗稱的“加機器”。本文就來談一談服務器橫向擴展。

一般而言，一臺服務器上面，最起碼要運行三個環境：服務器環境、程序語言執行環境、數據庫環境。對于我們用PHP進行開發的網站，一般會考慮Apache+NGINX+MySQL+Redis+PHP來跑整個系統，其中，nginx處理靜態資源響應，apache處理php進程，mysql負責數據存儲，redis負責經常需要進行調用的臨時性數據。但是，在這個環境中，我們往往忽視一個非常重要的因素，那就是服務器本身的硬件配置。首先是CPU和內存，這是我們比較容易想到的，CPU決定了服務器的運算速率，內存決定了一個程序系統能夠在一定時間內存放的變量和數據結構吞吐。程序對內存的操作，速度會比對硬盤的讀寫快很多，直到內存中的空間被釋放回收。而如果內存不足，則會導致程序無法完成高效的內存數據讀寫，拖慢網站或應用速度。除了CPU和內存，另一個被忽視的因素就是硬盤。傳統的機械硬盤在讀寫時，依賴硬盤的轉速，而無論如何，只要硬盤要轉，就會花費時間。

因此，單臺服務器的擴展主要是增多、擴大CPU，增加內存，增加硬盤，或更換固態硬盤。于此同時，增加寬帶來提高網絡容量。這是橫向擴展中最容易做到的，一般向服務商提供申請，或直接購買就可以完成。

PHP+MySQL的網站，其實比較大的局限在于MySQL的連接和執行效率。幾乎所有的公司都要求PHP程序員掌握MySQL的優化方法，但是無論如何優化，始終會有一個瓶頸，這個瓶頸一方面是由服務器硬件IO帶來的。因此，在很多訪問量比較大，或數據處理壓力比較大的項目中，都會采用數據庫服務器和程序服務器分離的方法。

數據庫服務器和程序執行服務器的性能配置根據實際情況而定，有的時候，數據庫的壓力更大，因此數據庫服務器配置更加高。這種擴展方式實現起來也比較簡單，例如在阿里云購買服務器，新增一臺與原來服務器在同一個網段的服務器，新服務器不安裝apache和nginx，只安裝mysql，停用原來服務器中的mysql，遷移數據后，通過局域網IP，將程序的數據庫連接到這臺新的服務器上。

目前市面上有不同服務商的云數據庫服務，但從價格而言，云數據庫的價格經常高于一臺普通云服務器的價格，對于中小型項目而言，采用兩臺服務器的成本低于購買云數據庫服務來代替數據庫服務器的費用。

服務器的靜態資源不僅占用服務器的存儲空間，同時還占用服務器的IO，當同一個靜態資源，例如圖片、視頻、css文件、js文件、其他格式的文件等等被反復請求時，服務器需要反復請求讀文件。機械硬盤的轉速最高有一個極限，當靜態文件的請求將動態文件的請求擠出隊列的時候，網站程序的反應會變得很慢。因此，當有必要的時候，將靜態資源與程序腳本進行分離，并使用CDN來對靜態資源進行節點緩存，不僅可以降低對服務器資源的消耗，也可以加快響應速度。

上圖中出現了三臺服務器，其中nginx服務器，不僅承擔了靜態資源服務器，而且還承擔端口代理的角色。因為用戶訪問網站的入口只有一個，所以不可能同一次訪問到達兩臺服務器；而且，也需要有一個程序來識別，用戶的這個請求到底是要請求靜態資源，還是請求程序。這種擴展方式被廣泛用在中小型項目中，用以減輕服務器的巨大壓力。

無論如何，一臺服務器的進程是有限的，我們不可能無限制的把一臺服務器的CUP加到64個，把內存加到1T，則是不可能的。因此，出現了均衡負載技術，通過將多臺服務器組合成一組可以完成相同任務的服務器，當用戶發出請求時，根據每臺服務器的運行狀態，讓那些相對而言有富余的服務器來執行這個用戶的請求。

上圖中，出現了多臺Apache服務器，這些服務器的配置不一定相同，但是他們的環境一定是一樣，每一臺上面都存放著相同的程序代碼，能夠保證同一個請求，無論到達哪一臺服務器進行執行，都能得到相同的結果。而上圖中多出了一個“控制器”，一般而言，有兩種方式來進行控制，一種是DNS，也就是域名解析的時候，根據訪問壓力情況，解析到不同的服務器上面去；另一種則是域名統一解析到一臺固定的服務器，由這臺服務器來決定這個請求應該由哪一臺服務器來進行處理。

雖然從上圖中，我們能夠簡單的理解這種擴展模式，但是實際生產中，會遇到非常嚴重的問題。例如，session怎么來處理？服務器的讀寫怎么來解決同步性問題？數據庫的寫入和更新順序怎么來解決等等。由于程序被不同的服務器執行，這就導致不同服務器之間執行附帶行為結果產生不同，例如日志，同一個用戶的日志可能散落在不同的服務器上，怎么樣確保在進行日志調用的時候，能夠將這些日志統一處理呢？這里面都還有很多問題去解決。

從上面的圖形進化來看，數據庫服務器的均衡負載也是必要的。但是和程序執行服務器的均衡負載不同，不是在每臺服務器上面丟相同的一套程序就可以滿足數據庫問題的。和程序的均衡負載有著極大的不同，由于數據庫是隨時隨地都要用的，它的讀寫是即時的，不可能像程序一樣，在每一臺服務器上放上相同的代碼就可以解決問題，如果處理不好，很有可能導致用戶請求的時候，一會兒有數據，一會兒沒數據。主從數據庫的概念很早就有，簡單的理解就是將數據庫的讀寫操作分離，讀操作由從數據庫完成，寫操作由主數據庫完成，寫完之后，立即將數據同步到從數據庫。

為了解決數據庫的均衡負載問題，主從數據庫技術也進行了多次升級，但是就目前而言，仍然沒有從理論上達到完美解決這種問題。由于查詢動作沒有造成文件的變化，因此實際上和程序代碼的均衡負載一樣，從數據庫也可以由多個服務器來協同完成，只不過在執行寫入更新操作之后，主數據庫要同步到所有的從數據庫。

因此，在這種情況下，采用云數據庫，則是一種比較明智的選擇。

為了解決這種復雜的服務器橫向擴展問題，新浪云SAE、阿里云ACE、百度云BAE，以及未來騰訊云也要推出的云引擎，這些云計算服務以統一的策略，為我們提供了架構問題，也就是說，在這些云引擎中去運行我們的程序，就不用再過多的考慮均衡負載問題。云引擎的架構遠不止這種均衡負載這么簡單，如果你去深入研究新浪云的架構，就會為這種牛X的設計驚嘆。云引擎+云數據庫+CDN，就像一把利劍為我們的項目解決了服務器的基礎問題，這也是這個時代云計算服務商的偉大之處。

我的個人博客 www.tangshuang.net 偶爾寫一些學習中的感想和經驗，希望有相同興趣的朋友到博客來交流。

寫文章不容易啊，如果你覺得本文還不錯，打個賞吧