一，題記

前不久公司請來了位互聯(lián)網(wǎng)界的技術(shù)大牛跟我們做了一次大型網(wǎng)站架構(gòu)的培訓(xùn)，兩天12個小時信息量非常大，知識的廣度和難度也非常大，培訓(xùn)完后我很難完整理出全部聽到的知識，今天我換了個思路是回味這次培訓(xùn)，這個思路就是通過本人目前的經(jīng)驗和技術(shù)水平來思考下大型網(wǎng)站技術(shù)演進(jìn)的過程。

二，什么網(wǎng)站是大型網(wǎng)站

首先我們要思考一個問題，什么樣的網(wǎng)站才是大型網(wǎng)站，從網(wǎng)站的技術(shù)指標(biāo)角度考慮這個問題人們很容易犯一個毛病就是認(rèn)為網(wǎng)站的訪問量是衡量的指標(biāo)，懂點行的人也許會認(rèn)為是網(wǎng)站在單位時間里的并發(fā)量的大小來作為指標(biāo)，如果按這些標(biāo)準(zhǔn)那么像hao123這樣的網(wǎng)站就是大型網(wǎng)站了，如下圖所示：

[[225885]]

其實這種網(wǎng)站訪問量非常大，并發(fā)數(shù)也非常高，但是它卻能用最為簡單的web技術(shù)來實現(xiàn)：我們只要保持網(wǎng)站的充分的靜態(tài)化，多部署幾臺服務(wù)器，那么就算地球上所有人都用它，網(wǎng)站也能正常運(yùn)行。

我覺得大型網(wǎng)站是技術(shù)和業(yè)務(wù)的結(jié)合，一個滿足某些用戶需求的網(wǎng)站只要技術(shù)和業(yè)務(wù)二者有一方難度很大，必然會讓企業(yè)投入更多的、更優(yōu)秀的人力成本實現(xiàn)它，那么這樣的網(wǎng)站就是所謂的大型網(wǎng)站了。

三，初建的網(wǎng)站

一個初建的網(wǎng)站往往用戶群都是很小的，最簡單的網(wǎng)站架構(gòu)就能解決實際的用戶需求，當(dāng)然為了保證網(wǎng)站的穩(wěn)定性和安全性，我們會把網(wǎng)站的應(yīng)用部署到至少兩臺機(jī)器上，后臺的存儲使用數(shù)據(jù)庫，如果經(jīng)濟(jì)實力允許，數(shù)據(jù)庫使用單臺服務(wù)器部署，由于數(shù)據(jù)是網(wǎng)站的生命線，因此我們常常會把部署數(shù)據(jù)庫的服務(wù)器使用的好點，這個網(wǎng)站結(jié)構(gòu)如下所示：

這個結(jié)構(gòu)非常簡單，其實大部分初建網(wǎng)站開發(fā)里往往業(yè)務(wù)邏輯沒有企業(yè)級系統(tǒng)那么復(fù)雜，所以只要有個好的idea，建設(shè)一個新網(wǎng)站的成本是非常低的，所使用的技術(shù)手段也是非常的基本和簡單，不過該圖我們要準(zhǔn)備三臺服務(wù)器，而且還要租個機(jī)房放置我們的服務(wù)器，這些成本對于草根和屌絲還是非常高的。

幸運(yùn)的是當(dāng)下很多大公司和機(jī)構(gòu)提供了云平臺，我們可以花費很少的錢將自己的應(yīng)用部署到云平臺上，這種做法我們甚至不用去考慮把應(yīng)用、數(shù)據(jù)庫分開部署的問題，更加進(jìn)一步的降低了網(wǎng)站開發(fā)和運(yùn)維的成本，但是這種做法也有一個問題，就是網(wǎng)站的小命被這個云平臺捏住了，如果云平臺掛了，俺們的網(wǎng)站服務(wù)也就跟著掛了。

四，網(wǎng)站遇到的問題

這里我先講講自己獨立使用服務(wù)器部署網(wǎng)站的問題，如果我們要把網(wǎng)站服務(wù)應(yīng)用使用多臺服務(wù)器部署，這么做的目的一般有兩個：

保證網(wǎng)站的可用性，多臺服務(wù)器部署應(yīng)用，那么其中一些服務(wù)器掛掉了，只要網(wǎng)站還有服務(wù)器能正常運(yùn)轉(zhuǎn)，那么網(wǎng)站對外任然可以正常提供服務(wù)。

提高網(wǎng)站的并發(fā)量，服務(wù)器越多那么網(wǎng)站能夠服務(wù)的用戶，單位時間內(nèi)能承載的請求數(shù)也就越大。

不過要做到以上兩點，并不是我們簡單將網(wǎng)站分開部署就可以滿足的，因為大多數(shù)網(wǎng)站在用戶使用時候都是要保持用戶的狀態(tài)，具體點就是網(wǎng)站要記住請求是歸屬到那一個客戶端，而這個狀態(tài)在網(wǎng)站開發(fā)里就是通過會話session來體現(xiàn)的。

分開部署的web應(yīng)用服務(wù)要解決的一個首要問題就是要保持不同物理部署服務(wù)器之間的session同步問題，從而達(dá)到當(dāng)用戶第一次請求訪問到服務(wù)器A，第二個請求訪問到服務(wù)器B，網(wǎng)站任然知道這兩個請求是同一個人，解決方案很直接：服務(wù)器A和服務(wù)器B上的session信息要時刻保持同步，那么如何保證兩臺服務(wù)器之間session信息的同步呢？

為了回答上面的問題，我們首先要理解下session的機(jī)制，session信息在web容器里都是存儲在內(nèi)存里的，web容器會給每個連接它的客戶端生成一個sessionid值，這個sessionid值會被web容器置于http協(xié)議里的cookie域下，當(dāng)響應(yīng)被客戶端處理后，客戶端本地會存儲這個sessionid值，用戶以后的每個請求都會讓這個sessionid值隨cookie一起傳遞到服務(wù)器，服務(wù)器通過sessionid找到內(nèi)存中存儲的該用戶的session內(nèi)容，session在內(nèi)存的數(shù)據(jù)結(jié)構(gòu)是一個map的格式。

五，服務(wù)器越多，并發(fā)數(shù)反而越慢

那么為了保證不同服務(wù)器之間的session共享，那么最直接的方案就是讓服務(wù)器之間session不斷的傳遞和復(fù)制，例如java開發(fā)里常用的tomcat容器就采用這種方案，以前我測試過tomcat這種session同步的性能，我發(fā)現(xiàn)當(dāng)需要同步的web容器越多，web應(yīng)用所能承載的并發(fā)數(shù)并沒有因為服務(wù)器的增加而線性提升，當(dāng)服務(wù)器數(shù)量達(dá)到一個臨界值后，整個web應(yīng)用的并發(fā)數(shù)甚至還會下降，為什么會這樣了？

原因很簡單，不同服務(wù)器之間session的傳遞和復(fù)制會消耗服務(wù)器本身的系統(tǒng)資源，當(dāng)服務(wù)器數(shù)量越大，消耗的資源越多，當(dāng)用戶請求越頻繁，系統(tǒng)消耗資源也會越來越大。如果我們多部署服務(wù)器的目的只是想保證系統(tǒng)的穩(wěn)定性，采用這種方案還是不錯的，不過web應(yīng)用最好部署少點，這樣才不會影響到web應(yīng)用的性能問題，如果我們還想提升網(wǎng)站的并發(fā)量那么就得采取其他的方案了。

時下使用的比較多的方案就是使用獨立的緩存服務(wù)器，也就是將session的數(shù)據(jù)存儲在一臺獨立的服務(wù)器上，如果覺得存在一臺服務(wù)器不安全，那么可以使用memcached這樣的分布式緩存服務(wù)器進(jìn)行存儲，這樣既可以滿足了網(wǎng)站穩(wěn)定性問題也提升了網(wǎng)站的并發(fā)能力。

不過早期的淘寶在這個問題解決更加巧妙，他們將session的信息直接存儲到瀏覽器的cookie里，每次請求cookie信息都會隨著http一起傳遞到web服務(wù)器，這樣就避免了web服務(wù)器之間session信息同步的問題，這種方案會讓很多人詬病，詬病的原因是cookie的不安全性是總所周知的，如果有人惡意截取cookie信息那么網(wǎng)站不就不安全了嗎？這個答案還真不好說，但是我覺得我們僅僅是跟蹤用戶的狀態(tài)，把session存在cookie里其實也沒什么大不了的。

其實如此專業(yè)的淘寶這么做其實還是很有深意的，還記得本文開篇提到的hao123網(wǎng)站，它是可以承載高并發(fā)的網(wǎng)站，它之所以可以做到這一點，原因很簡單它是個靜態(tài)網(wǎng)站，靜態(tài)網(wǎng)站的特點就是不需要記錄用戶的狀態(tài)，靜態(tài)網(wǎng)站的服務(wù)器不需要使用寶貴的系統(tǒng)資源來存儲大量的session會話信息，這樣它就有更多系統(tǒng)資源來處理請求，而早期淘寶將cookie存在客戶端也是為了達(dá)到這樣的目的，所以這個方案在淘寶網(wǎng)站架構(gòu)里還是使用了很長時間的。

在我的公司里客戶端的請求到達(dá)web服務(wù)器之前，會先到F5，F(xiàn)5是一個用來做負(fù)載均衡的硬件設(shè)備，它的作用是將用戶請求均勻的分發(fā)到后臺的服務(wù)器集群，F(xiàn)5是硬件的負(fù)載均衡解決方案，如果我們沒那么多錢買這樣的設(shè)備，也有軟件的負(fù)載均衡解決方案，這個方案就是大名鼎鼎的LVS了！

這些負(fù)載均衡設(shè)備除了可以分發(fā)請求外它們還有個能力，這個能力是根據(jù)http協(xié)議的特點設(shè)計的，一個http請求從客戶端到達(dá)最終的存儲服務(wù)器之前可能會經(jīng)過很多不同的設(shè)備，如果我們把一個請求比作高速公路上的一輛汽車，這些設(shè)備也可以叫做這些節(jié)點就是高速路上的收費站，這些收費站都能根據(jù)自己的需求改變http報文的內(nèi)容，所以負(fù)載均衡設(shè)備可以記住每個sessionid值對應(yīng)的后臺服務(wù)器。

當(dāng)一個帶有sessionid值的請求通過負(fù)載均衡設(shè)備時候，負(fù)載均衡設(shè)備會根據(jù)該sessionid值直接找到指定的web服務(wù)器，這種做法有個專有名詞就是session粘滯，這種做法也比那種session信息在不同服務(wù)器之間拷貝復(fù)制要高效，不過該做法還是比存cookie的效率低下，而且對于網(wǎng)站的穩(wěn)定性也有一定影響即如果某臺服務(wù)器掛掉了，那么連接到該服務(wù)器的用戶的會話都會失效。

解決session的問題的本質(zhì)也就是解決session的存儲問題，其本質(zhì)也就是解決網(wǎng)站的存儲問題，一個初建的網(wǎng)站在早期的運(yùn)營期需要解決的問題基本都是由存儲導(dǎo)致的。上文里我提到時下很多新建的web應(yīng)用會將服務(wù)器部署后云平臺里，好的云平臺里或許會幫助我們解決負(fù)載均衡和session同步的問題，但是云平臺里有個問題很難解決那就是數(shù)據(jù)庫的存儲問題，如果我們使用的云平臺發(fā)生了重大事故，導(dǎo)致云平臺存儲的數(shù)據(jù)丟失，這種會不會導(dǎo)致我們在云平臺里數(shù)據(jù)庫的信息也會丟失了，雖然這個事情的概率不高，但是發(fā)生這種事情的幾率還是有的，雖然很多云平臺都聲稱自己多么可靠，但是真實可靠性有多高不是局中人還真不清楚哦，因此使用云平臺我們首要考慮的就是要做好數(shù)據(jù)備份，假如真發(fā)生了數(shù)據(jù)丟失，對于一個快速成長的網(wǎng)站而言可能非常致命。

六，網(wǎng)站的瓶頸

寫到這里一個嬰兒般的網(wǎng)站就這樣被我們創(chuàng)造出來了，我們希望網(wǎng)站能健康快速的成長，如果網(wǎng)站真的按我們預(yù)期成長了，那么一定會有一天我們制造的寶寶屋已經(jīng)滿足不了現(xiàn)實的需求，這個時候我們應(yīng)該如何抉擇了？換掉，全部換掉，使用新的架構(gòu)例如我們以前長提的SOA架構(gòu)，分布式技術(shù)，這個方法不錯，但是SOA和分布式技術(shù)是很難的，成本是很高的，如果這時候我們通過添加幾臺服務(wù)器就能解決問題的話，我們絕對不要去選擇什么分布式技術(shù)，因為這個成本太高了。上面我講到幾種session共享的方案，這個方案解決了應(yīng)用的水平擴(kuò)展問題，那么當(dāng)我們網(wǎng)站出現(xiàn)瓶頸時候就多加幾臺服務(wù)器不就行了嗎？那么這里就有個問題了，當(dāng)網(wǎng)站成長很快，網(wǎng)站首先碰到的瓶頸到底是哪個方面的問題？

本人是做金融網(wǎng)站的，我們所做的網(wǎng)站有個特點就是當(dāng)用戶訪問到我們所做的網(wǎng)站時候，目的都很明確就是為了付錢，用戶到了我們所做的網(wǎng)站時候都希望能快點，再快點完成本網(wǎng)站的操作，很多用戶在使用我們做的網(wǎng)站時候不太去關(guān)心網(wǎng)站的其他內(nèi)容，因此我們所做的網(wǎng)站相對于數(shù)據(jù)庫而言就是讀寫比例其實非常的均勻，甚至很多場景寫比讀要高，這個特點是很多專業(yè)服務(wù)網(wǎng)站的特點，其實這樣的網(wǎng)站和企業(yè)開發(fā)的特點很類似：業(yè)務(wù)操作的重要度超過了業(yè)務(wù)展示的重要度，因此專業(yè)性網(wǎng)站吸納企業(yè)系統(tǒng)開發(fā)的特點比較多。但是大部分我們?nèi)粘３Ｓ玫木W(wǎng)站，我們逗留時間很長的網(wǎng)站按數(shù)據(jù)庫角度而言往往是讀遠(yuǎn)遠(yuǎn)大于寫，例如大眾點評網(wǎng)站它的讀寫比率往往是9比1。

12306或許是中國最著名的網(wǎng)站之一，我記得12306早期經(jīng)常出現(xiàn)一個問題就是用戶登錄老是登不上，甚至在高峰期整個網(wǎng)站掛掉，頁面顯示503網(wǎng)站拒絕訪問的問題，這個現(xiàn)象很好理解就是網(wǎng)站并發(fā)高了，大量人去登錄網(wǎng)站，購票，系統(tǒng)掛掉了，最后所有的人都不能使用網(wǎng)站了。

當(dāng)網(wǎng)站出現(xiàn)503拒絕訪問時候，那么這個網(wǎng)站就出現(xiàn)了最致命的問題，解決大用戶訪問的確是個超級難題，但是當(dāng)高并發(fā)無法避免時候，整個網(wǎng)站都不能使用這個只能說網(wǎng)站設(shè)計上發(fā)生了致命錯誤，一個好的網(wǎng)站設(shè)計在應(yīng)對超出自己能力的并發(fā)時候我們首先應(yīng)該是不讓他掛掉，因為這種結(jié)果是誰都不能使用，我們希望那些在可接受的請求下，讓在可接受請求范圍內(nèi)的請求還是可以正常使用，超出的請求可以被拒絕，但是它們絕對不能影響到全網(wǎng)站的穩(wěn)定性，現(xiàn)在我們看到了12306網(wǎng)站的峰值從未減少過，而且是越變越多，但是12306出現(xiàn)全站掛掉的問題是越來越少了。通過12036網(wǎng)站改變我們更進(jìn)一步思考下網(wǎng)站的瓶頸問題。

排除一些不可控的因素，網(wǎng)站在高并發(fā)下掛掉的原因90%都是因為數(shù)據(jù)庫不堪重負(fù)所致，而應(yīng)用的瓶頸往往只有在解決了存儲瓶頸后才會暴露，那么我們要升級網(wǎng)站能力的第一步工作就是提升數(shù)據(jù)庫的承載能力，對于讀遠(yuǎn)大于寫的網(wǎng)站我們采取的方式就是將數(shù)據(jù)庫從讀寫這個角度拆分，具體操作就是將數(shù)據(jù)庫讀寫分離，如下圖所示：

我們這時要設(shè)計兩個數(shù)據(jù)庫，一個數(shù)據(jù)庫主要負(fù)責(zé)寫操作我們稱之為主庫，一個數(shù)據(jù)庫專門負(fù)責(zé)讀操作我們稱之為副庫，副庫的數(shù)據(jù)都是從主庫導(dǎo)入的，數(shù)據(jù)庫的讀寫分離可以有效的保證關(guān)鍵數(shù)據(jù)的安全性，但是有個缺點就是當(dāng)用戶瀏覽數(shù)據(jù)時候，讀的數(shù)據(jù)都會有點延時，這種延時比起全站不可用那肯定是可以接受的。

不過針對12306的場景，僅僅讀寫分離還是遠(yuǎn)遠(yuǎn)不夠的，特別是負(fù)責(zé)讀操作的副庫，在高訪問下也是很容易達(dá)到性能的瓶頸的，那么我們就得使用新的解決方案：使用分布式緩存，不過緩存的缺點就是不能有效的實時更新，因此我們使用緩存前首先要對讀操作的數(shù)據(jù)進(jìn)行分類，對于那些經(jīng)常不發(fā)生變化的數(shù)據(jù)可以事先存放到緩存里，緩存的訪問效率很高，這樣會讓讀更加高效，同時也減輕了數(shù)據(jù)庫的訪問壓力。

至于用于寫操作的主庫，因為大部分網(wǎng)站讀寫的比例是嚴(yán)重失衡，所以讓主庫達(dá)到瓶頸還是比較難的，不過主庫也有一個讀的壓力就是主庫和副庫的數(shù)據(jù)同步問題，不過同步時候數(shù)據(jù)都是批量操作，而不是像請求那樣進(jìn)行少量數(shù)據(jù)讀取操作，讀取操作特別多，因此想達(dá)到瓶頸還是有一定的難度的。聽人說，美國牛逼的facebook對數(shù)據(jù)的任何操作都是事先合并為批量操作，從而達(dá)到減輕數(shù)據(jù)庫壓力的目的。

七，海量數(shù)據(jù)檢索

上面的方案我們可以保證在高并發(fā)下網(wǎng)站的穩(wěn)定性，但是針對于讀，如果數(shù)據(jù)量太大了，就算網(wǎng)站不掛掉了，用戶能很快的在海量數(shù)據(jù)里檢索到所需要的信息又成為了網(wǎng)站的一個瓶頸，如果用戶需要很長時間才能獲得自己想要的數(shù)據(jù)，很多用戶會失去耐心從而放棄對網(wǎng)站的使用，那么這個問題又該如何解決了？

解決方案就是我們經(jīng)常使用的百度，谷歌哪里得來，對于海量數(shù)據(jù)的讀我們可以采用搜索技術(shù)，我們可以將數(shù)據(jù)庫的數(shù)據(jù)導(dǎo)出到文件里，對文件建立索引，使用倒排索引技術(shù)來檢索信息，我們看到了百度，谷歌有整個互聯(lián)網(wǎng)的信息我們?nèi)稳荒芎芸斓臋z索到數(shù)據(jù)，搜索技術(shù)是解決快速讀取數(shù)據(jù)的一個有效方案，不過這個讀取還是和數(shù)據(jù)庫的讀取有所區(qū)別的，如果用戶查詢的數(shù)據(jù)是通過數(shù)據(jù)庫的主鍵字段，或者是通過很明確的建立了索引的字段來檢索，那么數(shù)據(jù)庫的查詢效率是很高的，但是使用網(wǎng)站的人跟喜歡使用一些模糊查詢來查找自己的信息，那么這個操作在數(shù)據(jù)庫里就是個like操作，like操作在數(shù)據(jù)庫里效率是很低的，這個時候使用搜索技術(shù)的優(yōu)勢就非常明顯了，搜索技術(shù)非常適合于模糊查詢操作。