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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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