校內網CTO黃晶講述網站架構變遷-54chen回憶版
這是一次公司內部的交流會，主題是校內的發展史和構架講解，主講人是校內網CTO黃晶，其中關於架構變遷的一段個人覺得是很具有代表性的過程，特在會上作了大概的筆記，現在是凌晨一點不到，正好清醒頭腦進行回憶總結。
每個網站的發展都會按照一個大致相同的路線去完成，當然這裏說的是每個相對成功的網站。
第一階段：
這一階段沒有太大的訪問量，甚至只有一臺服務器就搞定了所有的訪問。DB和前端的代碼全都在一起，壓力不高。憶者注：我覺得在alexa沒進五萬的時候，只要不是特殊的應用，基本都在此列吧。
第二階段：
網站初具規模，DB壓力大增，單獨的一臺DB已經滿足不了現在的訪問量，開始考慮讀寫分離的Master-slave庫，使用三個及以上的服務器。憶者注：這時網站的alexa基本上會在1-3萬的位置，每天的ip在5-10w的樣子，當然，DB我們都認爲是MySql。
第三階段：
訪問量繼續增加，增加到了DB的壓力在Master的機器上非常的明顯了，Master開始出現喫不消的情況，出現寫耗盡。主從也已經不能滿足要求，需要進一步解決負載問題，此時要引入Mysql Proxy程序，進行中間層代理，實現負載均衡，易於擴展。憶者注：這時網站已經不可限量了，先恭喜下你的網站能用到這段。
第四階段：
網站繼續發展，進而出現了數據量的成倍增長，原來的N臺DB都出現了一個問題，數據量巨大，無法完成正常速度的讀寫。此時，需要對網站按功能進行垂直劃分，比如用戶註冊登錄是一部分、UGC又是另一部分。與此同時，對數據本身進行水平劃分，也就是Hash散表或者是散庫。
第五階段：
真的沒了。再往下玩就滅了。
其實再進一步第五第六階段，就是無法預想的未來了，也許有什麼突飛猛進的科學技術發明也說不好。
今天和yahoo的agentZhang（openResty作者）聊起，他說到第五個階段其實應該是BigTable，的確很強大，來自google的作品。不過美中不足的是，它並不像我相像中的那樣能夠順利過渡到第五階段。以下論述來自infoQ:
Todd從定義BigTable的適用範圍開始論述。由於BigTable引入的各種代價，只有在以下情況下使用BigTable才能帶來益處：a)需要伸縮到巨量的用戶數，b)更新與讀取操作相比比例很小。Todd還着重強調爲了“優化讀取速度和可伸縮性”，所採取的理論路線與關係數據庫中的做法存在根本的分歧，很可能初看起來是違背直覺甚至相當冒險的。