摘要：均衡負(fù)載多臺(tái)服務(wù)器執(zhí)行程序，將大量請(qǐng)求分?jǐn)偨o多臺(tái)服務(wù)器無(wú)論如何，一臺(tái)服務(wù)器的進(jìn)程是有限的，我們不可能無(wú)限制的把一臺(tái)服務(wù)器的加到個(gè)，把內(nèi)存加到，則是不可能的。

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

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

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

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

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

目前市面上有不同服務(wù)商的云數(shù)據(jù)庫(kù)服務(wù)，但從價(jià)格而言，云數(shù)據(jù)庫(kù)的價(jià)格經(jīng)常高于一臺(tái)普通云服務(wù)器的價(jià)格，對(duì)于中小型項(xiàng)目而言，采用兩臺(tái)服務(wù)器的成本低于購(gòu)買(mǎi)云數(shù)據(jù)庫(kù)服務(wù)來(lái)代替數(shù)據(jù)庫(kù)服務(wù)器的費(fèi)用。

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

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

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

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

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

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

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

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

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

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

寫(xiě)文章不容易啊，如果你覺(jué)得本文還不錯(cuò)，打個(gè)賞吧