我們知道一個網站都是隨著業務的發展，逐漸演變成幾萬伺服器，幾億使用者數的大型網站，經歷了若干年，甚至上十年的
發展成為大型網站，然而真正親身經歷這個發展過程的人已經不多了，這種人也是拿著公司股票，趕都趕不走的人，所以正因
為很多人沒有親身經歷過，所以對架構的演變沒有深刻的瞭解，包括我自己在內，不過沒吃過豬肉，也看過豬跑。。。
一：第一代架構
這年頭創業大多都是從窮屌絲開始的，奔著 “快好省”的原則建立網站，將“應用程式”，“檔案”，“資料庫”通通放在一臺服務
器上，匆匆的就走上了網站架構之路。
我們知道業務的發展對技術會有更高的要求，業務的創新會觸動技術的創新，當業務逐漸發展起來的時候，最容易出現的問題就是
”儲存空間“和通用的”效能低下“，這個時候就需要做到”應用程式“和”資料“的分離。
二：第二代架構
隨著業務規模的擴大，需要將”應用程式“，”檔案“，”資料庫“進行分離，用更強大的cpu處理伺服器來承載應用程式，記得在上一
家用的cpu就是16核，”檔案“的話則需要更大的磁碟空間的伺服器，”資料庫“的話需要更大的磁碟和超大記憶體的伺服器，我們知道
sqlserver還是很吃記憶體的，記得用過最大的是120g的記憶體。
隨著業務規模不斷擴大，訪問人數逐漸增多，我們也開心了，起碼掙到錢了，然後我們會發現資料庫開始出現瓶頸了，大量的讀寫操作讓
資料庫出現訪問延遲以及死鎖現象的發生，繼而影響使用者體驗。
三：第三代架構
既然大量的讀寫操作讓資料庫出現瓶頸了，這個時候就要從兩個方面優化讀寫操作
1. 讀操作
我們知道任何東西都是遵守二八原則，也就是網站上經常訪問的東西也就那麼多，對於這種命中率非常高的東西就需要用快取來處理，
減少讀的次數，在攜程裡面的memcache就做了“資料熱度”的操作，對於熱度低的資料會自動從快取中踢掉。
2. 寫操作
這個有分及時寫和非及時寫，對於非及時寫的資料，我們可以採用 “訊息佇列”來對寫操作節流，從而緩解資料庫寫入時的瞬時壓力。
這時候資料庫的讀寫操作得到了很大的緩解，隨著業務規模的繼續擴大，使用者人數的再次暴增，我們會發現”應用程式伺服器“的CPU
經常高燒不退，被玩爆的次數越來越多。
四：第四代架構
既然被爆表了，這時候必須再拉一個應用程式伺服器來分攤前端訪問帶來的壓力，做了叢集之後，需要再配一臺”負載均衡排程器“，
不過屌絲公司用的比較多的還是nginx，高大上的公司都是動輒幾十萬的硬體負載均衡，比如攜程用的就是A10，還有市場上幾十萬F5
等等產品。
好了，先大概這麼說了，睡覺時間到了，明天繼續往下扯。