前不久公司請來了位互聯網界的技術大牛跟我們做了一次大型網站架構的培訓，兩天12個小時信息量非常大，知識的廣度和難度也非常大，培訓完後我很難完整理出全部聽到的知識，今天我換了個思路是回味這次培訓，這個思路就是通過本人目前的經驗和技術水平來思考下大型網站技術演進的過程。
首先我們要思考一個問題，什麼樣的網站纔是大型網站，從網站的技術指標角度考慮這個問題人們很容易犯一個毛病就是認爲網站的訪問量是衡量的指標，懂點行的人也許會認爲是網站在單位時間裏的併發量的大小來作爲指標，如果按這些標準那麼像hao123這樣的網站就是大型網站了，如下圖所示：
其實這種網站訪問量非常大，併發數也非常高，但是它卻能用最爲簡單的web技術來實現：我們只要保持網站的充分的靜態化，多部署幾臺服務器，那麼就算地球上所有人都用它，網站也能正常運行。
我覺得大型網站是技術和業務的結合，一個滿足某些用戶需求的網站只要技術和業務二者有一方難度很大，必然會讓企業投入更多的、更優秀的人力成本實現它，那麼這樣的網站就是所謂的大型網站了。
一個初建的網站往往用戶羣都是很小的，最簡單的網站架構就能解決實際的用戶需求，當然爲了保證網站的穩定性和安全性，我們會把網站的應用部署到至少兩臺機器上，後臺的存儲使用數據庫，如果經濟實力允許，數據庫使用單臺服務器部署，由於數據是網站的生命線，因此我們常常會把部署數據庫的服務器使用的好點，這個網站結構如下所示：
這個結構非常簡單，其實大部分初建網站開發裏往往業務邏輯沒有企業級系統那麼複雜，所以只要有個好的idea，建設一個新網站的成本是非常低的，所使用的技術手段也是非常的基本和簡單，不過該圖我們要準備三臺服務器，而且還要租個機房放置我們的服務器，這些成本對於草根和屌絲還是非常高的，幸運的是當下很多大公司和機構提供了雲平臺，我們可以花費很少的錢將自己的應用部署到雲平臺上，這種做法我們甚至不用去考慮把應用、數據庫分開部署的問題，更加進一步的降低了網站開發和運維的成本，但是這種做法也有一個問題，就是網站的小命被這個雲平臺捏住了，如果雲平臺掛了，俺們的網站服務也就跟着掛了。
這裏我先講講自己獨立使用服務器部署網站的問題，如果我們要把網站服務應用使用多臺服務器部署，這麼做的目的一般有兩個：
- 保證網站的可用性，多臺服務器部署應用，那麼其中一些服務器掛掉了，只要網站還有服務器能正常運轉，那麼網站對外任然可以正常提供服務。
- 提高網站的併發量，服務器越多那麼網站能夠服務的用戶，單位時間內能承載的請求數也就越大。
不過要做到以上兩點，並不是我們簡單將網站分開部署就可以滿足的，因爲大多數網站在用戶使用時候都是要保持用戶的狀態，具體點就是網站要記住請求是歸屬到那一個客戶端，而這個狀態在網站開發裏就是通過會話session來體現的。分開部署的web應用服務要解決的一個首要問題就是要保持不同物理部署服務器之間的session同步問題，從而達到當用戶第一次請求訪問到服務器A，第二個請求訪問到服務器B，網站任然知道這兩個請求是同一個人，解決方案很直接：服務器A和服務器B上的session信息要時刻保持同步，那麼如何保證兩臺服務器之間session信息的同步呢？
爲了回答上面的問題，我們首先要理解下session的機制，session信息在web容器裏都是存儲在內存裏的，web容器會給每個連接它的客戶端生成一個sessionid值，這個sessionid值會被web容器置於http協議裏的cookie域下，當響應被客戶端處理後，客戶端本地會存儲這個sessionid值，用戶以後的每個請求都會讓這個sessionid值隨cookie一起傳遞到服務器，服務器通過sessionid找到內存中存儲的該用戶的session內容，session在內存的數據結構是一個map的格式。那麼爲了保證不同服務器之間的session共享，那麼最直接的方案就是讓服務器之間session不斷的傳遞和複製，例如java開發裏常用的tomcat容器就採用這種方案，以前我測試過tomcat這種session同步的性能，我發現當需要同步的web容器越多，web應用所能承載的併發數並沒有因爲服務器的增加而線性提升，當服務器數量達到一個臨界值後，整個web應用的併發數甚至還會下降，爲什麼會這樣了？
原因很簡單，不同服務器之間session的傳遞和複製會消耗服務器本身的系統資源，當服務器數量越大，消耗的資源越多，當用戶請求越頻繁，系統消耗資源也會越來越大。如果我們多部署服務器的目的只是想保證系統的穩定性，採用這種方案還是不錯的，不過web應用最好部署少點，這樣纔不會影響到web應用的性能問題，如果我們還想提升網站的併發量那麼就得采取其他的方案了。
時下使用的比較多的方案就是使用獨立的緩存服務器，也就是將session的數據存儲在一臺獨立的服務器上，如果覺得存在一臺服務器不安全，那麼可以使用memcached這樣的分佈式緩存服務器進行存儲，這樣既可以滿足了網站穩定性問題也提升了網站的併發能力。
不過早期的淘寶在這個問題解決更加巧妙，他們將session的信息直接存儲到瀏覽器的cookie裏，每次請求cookie信息都會隨着http一起傳遞到web服務器，這樣就避免了web服務器之間session信息同步的問題，這種方案會讓很多人詬病，詬病的原因是cookie的不安全性是總所周知的，如果有人惡意截取cookie信息那麼網站不就不安全了嗎？這個答案還真不好說，但是我覺得我們僅僅是跟蹤用戶的狀態，把session存在cookie裏其實也沒什麼大不了的。
其實如此專業的淘寶這麼做其實還是很有深意的，還記得本文開篇提到的hao123網站，它是可以承載高併發的網站，它之所以可以做到這一點，原因很簡單它是個靜態網站，靜態網站的特點就是不需要記錄用戶的狀態，靜態網站的服務器不需要使用寶貴的系統資源來存儲大量的session會話信息，這樣它就有更多系統資源來處理請求，而早期淘寶將cookie存在客戶端也是爲了達到這樣的目的，所以這個方案在淘寶網站架構裏還是使用了很長時間的。
在我的公司裏客戶端的請求到達web服務器之前，會先到F5，F5是一個用來做負載均衡的硬件設備，它的作用是將用戶請求均勻的分發到後臺的服務器集羣，F5是硬件的負載均衡解決方案，如果我們沒那麼多錢買這樣的設備，也有軟件的負載均衡解決方案，這個方案就是大名鼎鼎的LVS了，這些負載均衡設備除了可以分發請求外它們還有個能力，這個能力是根據http協議的特點設計的，一個http請求從客戶端到達最終的存儲服務器之前可能會經過很多不同的設備，如果我們把一個請求比作高速公路上的一輛汽車，這些設備也可以叫做這些節點就是高速路上的收費站，這些收費站都能根據自己的需求改變http報文的內容，所以負載均衡設備可以記住每個sessionid值對應的後臺服務器，當一個帶有sessionid值的請求通過負載均衡設備時候，負載均衡設備會根據該sessionid值直接找到指定的web服務器，這種做法有個專有名詞就是session粘滯，這種做法也比那種session信息在不同服務器之間拷貝複製要高效，不過該做法還是比存cookie的效率低下，而且對於網站的穩定性也有一定影響即如果某臺服務器掛掉了，那麼連接到該服務器的用戶的會話都會失效。
解決session的問題的本質也就是解決session的存儲問題，其本質也就是解決網站的存儲問題，一個初建的網站在早期的運營期需要解決的問題基本都是由存儲導致的。上文裏我提到時下很多新建的web應用會將服務器部署後雲平臺裏，好的雲平臺裏或許會幫助我們解決負載均衡和session同步的問題，但是雲平臺裏有個問題很難解決那就是數據庫的存儲問題，如果我們使用的雲平臺發生了重大事故，導致雲平臺存儲的數據丟失，這種會不會導致我們在雲平臺裏數據庫的信息也會丟失了，雖然這個事情的概率不高，但是發生這種事情的機率還是有的，雖然很多雲平臺都聲稱自己多麼可靠，但是真實可靠性有多高不是局中人還真不清楚哦，因此使用雲平臺我們首要考慮的就是要做好數據備份，假如真發生了數據丟失，對於一個快速成長的網站而言可能非常致命。
寫到這裏一個嬰兒般的網站就這樣被我們創造出來了，我們希望網站能健康快速的成長，如果網站真的按我們預期成長了，那麼一定會有一天我們製造的寶寶屋已經滿足不了現實的需求，這個時候我們應該如何抉擇了？換掉，全部換掉，使用新的架構例如我們以前長提的SOA架構，分佈式技術，這個方法不錯，但是SOA和分佈式技術是很難的，成本是很高的，如果這時候我們通過添加幾臺服務器就能解決問題的話，我們絕對不要去選擇什麼分佈式技術，因爲這個成本太高了。上面我講到幾種session共享的方案，這個方案解決了應用的水平擴展問題，那麼當我們網站出現瓶頸時候就多加幾臺服務器不就行了嗎？那麼這裏就有個問題了，當網站成長很快，網站首先碰到的瓶頸到底是哪個方面的問題？
本人是做金融網站的，我們所做的網站有個特點就是當用戶訪問到我們所做的網站時候，目的都很明確就是爲了付錢，用戶到了我們所做的網站時候都希望能快點，再快點完成本網站的操作，很多用戶在使用我們做的網站時候不太去關心網站的其他內容，因此我們所做的網站相對於數據庫而言就是讀寫比例其實非常的均勻，甚至很多場景寫比讀要高，這個特點是很多專業服務網站的特點，其實這樣的網站和企業開發的特點很類似：業務操作的重要度超過了業務展示的重要度，因此專業性網站吸納企業系統開發的特點比較多。但是大部分我們日常常用的網站，我們逗留時間很長的網站按數據庫角度而言往往是讀遠遠大於寫，例如大衆點評網站它的讀寫比率往往是9比1。
12306或許是中國最著名的網站之一，我記得12306早期經常出現一個問題就是用戶登錄老是登不上，甚至在高峯期整個網站掛掉，頁面顯示503網站拒絕訪問的問題，這個現象很好理解就是網站併發高了，大量人去登錄網站，購票，系統掛掉了，最後所有的人都不能使用網站了。當網站出現503拒絕訪問時候，那麼這個網站就出現了最致命的問題，解決大用戶訪問的確是個超級難題，但是當高併發無法避免時候，整個網站都不能使用這個只能說網站設計上發生了致命錯誤，一個好的網站設計在應對超出自己能力的併發時候我們首先應該是不讓他掛掉，因爲這種結果是誰都不能使用，我們希望那些在可接受的請求下，讓在可接受請求範圍內的請求還是可以正常使用，超出的請求可以被拒絕，但是它們絕對不能影響到全網站的穩定性，現在我們看到了12306網站的峯值從未減少過，而且是越變越多，但是12306出現全站掛掉的問題是越來越少了。通過12036網站改變我們更進一步思考下網站的瓶頸問題。
排除一些不可控的因素，網站在高併發下掛掉的原因90%都是因爲數據庫不堪重負所致，而應用的瓶頸往往只有在解決了存儲瓶頸後纔會暴露，那麼我們要升級網站能力的第一步工作就是提升數據庫的承載能力，對於讀遠大於寫的網站我們採取的方式就是將數據庫從讀寫這個角度拆分，具體操作就是將數據庫讀寫分離，如下圖所示：
我們這時要設計兩個數據庫，一個數據庫主要負責寫操作我們稱之爲主庫，一個數據庫專門負責讀操作我們稱之爲副庫，副庫的數據都是從主庫導入的，數據庫的讀寫分離可以有效的保證關鍵數據的安全性，但是有個缺點就是當用戶瀏覽數據時候，讀的數據都會有點延時，這種延時比起全站不可用那肯定是可以接受的。不過針對12306的場景，僅僅讀寫分離還是遠遠不夠的，特別是負責讀操作的副庫，在高訪問下也是很容易達到性能的瓶頸的，那麼我們就得使用新的解決方案：使用分佈式緩存，不過緩存的缺點就是不能有效的實時更新，因此我們使用緩存前首先要對讀操作的數據進行分類，對於那些經常不發生變化的數據可以事先存放到緩存裏，緩存的訪問效率很高，這樣會讓讀更加高效，同時也減輕了數據庫的訪問壓力。至於用於寫操作的主庫，因爲大部分網站讀寫的比例是嚴重失衡，所以讓主庫達到瓶頸還是比較難的，不過主庫也有一個讀的壓力就是主庫和副庫的數據同步問題，不過同步時候數據都是批量操作，而不是像請求那樣進行少量數據讀取操作，讀取操作特別多，因此想達到瓶頸還是有一定的難度的。聽人說，美國牛逼的facebook對數據的任何操作都是事先合併爲批量操作，從而達到減輕數據庫壓力的目的。
上面的方案我們可以保證在高併發下網站的穩定性，但是針對於讀，如果數據量太大了，就算網站不掛掉了，用戶能很快的在海量數據裏檢索到所需要的信息又成爲了網站的一個瓶頸，如果用戶需要很長時間才能獲得自己想要的數據，很多用戶會失去耐心從而放棄對網站的使用，那麼這個問題又該如何解決了？
解決方案就是我們經常使用的百度，谷歌哪裏得來，對於海量數據的讀我們可以採用搜索技術，我們可以將數據庫的數據導出到文件裏，對文件建立索引，使用倒排索引技術來檢索信息，我們看到了百度，谷歌有整個互聯網的信息我們任然能很快的檢索到數據，搜索技術是解決快速讀取數據的一個有效方案，不過這個讀取還是和數據庫的讀取有所區別的，如果用戶查詢的數據是通過數據庫的主鍵字段，或者是通過很明確的建立了索引的字段來檢索，那麼數據庫的查詢效率是很高的，但是使用網站的人跟喜歡使用一些模糊查詢來查找自己的信息，那麼這個操作在數據庫裏就是個like操作，like操作在數據庫裏效率是很低的，這個時候使用搜索技術的優勢就非常明顯了，搜索技術非常適合於模糊查詢操作。
OK，很晚了，關於存儲的問題今天就寫在這裏，下一篇我將接着這個主題講解，解決存儲問題是很複雜的，下篇我儘量講仔細點。