大型網(wǎng)站的服務(wù)器架構(gòu)設(shè)計-1
上述架構(gòu)對于一般中小型商用網(wǎng)站已經(jīng)足夠。在用戶規(guī)模達(dá)到100萬人左右，隨著網(wǎng)站流量不斷增加，就會出現(xiàn)網(wǎng)站性能不佳的問題，一般表現(xiàn)為：
- Database Loading 過重，CPU Loading 始終維持在80%以上；
- 存放圖片及靜態(tài)資源的硬盤Loading 過高，顯示比較慢；
- 前端網(wǎng)頁容易出現(xiàn) timeout 的錯誤信息；
進(jìn)入成長期
遇到上面的問題，其實是好消息，表示網(wǎng)站已至成長期，一般網(wǎng)站會進(jìn)行下列系統(tǒng)優(yōu)化，并橫向擴(kuò)展Web Server。
1. 數(shù)據(jù)庫優(yōu)化
Query 優(yōu)化、Index 優(yōu)化，將負(fù)荷重的Table 進(jìn)行反范式規(guī)范重新設(shè)計，以減少Database的負(fù)荷。
建立Master/Salve 數(shù)據(jù)庫，分散Master 數(shù)據(jù)庫服務(wù)器的Loading，將讀寫數(shù)據(jù)庫動作分離，Master DB Server 只負(fù)責(zé)Insert / Update / Delete 等等更新操作和復(fù)制，Salve DB Server 負(fù)責(zé)Query操作。
提升數(shù)據(jù)庫Server的硬件能力，如增加 CPU / RAM等等，將32bit 版本轉(zhuǎn)為 64bit版本。
2. 分散式存檔存儲
建立多個File Server，寫hash function 將上傳的圖片及資源文件平均分散到 File server上的文件夾。
3. 建立 Cache
可是有ASP.NET 的Cache 存儲數(shù)據(jù)集，或使用PHP APC 建立 opcode Cache，將不經(jīng)常變化的動態(tài)網(wǎng)頁區(qū)塊轉(zhuǎn)成靜態(tài)Cache 用戶控件。
4. 代碼優(yōu)化
減少的大量的數(shù)據(jù)庫訪問操作，可使用 Connection pool 加快鏈接數(shù)據(jù)庫的速度，使用MVC 架構(gòu)等等。
流量大爆發(fā)期
到這個階段，說明前面的努力沒有白費，而技術(shù)人員每天幾乎都要熬到半夜才能回家，調(diào)整代碼性能及硬件擴(kuò)展的都做了。但此時公司業(yè)務(wù)和流量爆炸性成長，網(wǎng)站會員達(dá)到 200 萬，也該月的成長速度，半年內(nèi)會達(dá)到 1000 萬人，系統(tǒng)根本無法支持。
此時系統(tǒng)會發(fā)生的問題：
由于網(wǎng)站流量很大，導(dǎo)致存放圖片資源的硬盤不堪重負(fù)，讀取及寫入的量已超過其讀寫物理限制，而變得十分緩慢；
數(shù)據(jù)庫性能的提高已經(jīng)不能通過增加Slave DB 來解決了，若要轉(zhuǎn)為大型數(shù)據(jù)庫中心，費用相當(dāng)高；
IDC 帶寬成本驚人，特定促銷或事件，會導(dǎo)致網(wǎng)站灌爆；
Facebook、Youtube、Twitter、Myspace 這些流量快速成長的小型公司，都有遇到爆炸性流量的問題，而且也都樂于分享解決方式，我們可以在網(wǎng)上找到許多資料。不同類型的網(wǎng)站，其要求也可能不一致。如 SNS 網(wǎng)站對速度要求高，對準(zhǔn)確性要求不高；而電子商務(wù)網(wǎng)站，對速度和準(zhǔn)確性都有要求。此時，可能一般的數(shù)據(jù)庫 或 SAN 存儲架構(gòu)都無法滿足其快速讀取大量數(shù)據(jù)的需求，因此產(chǎn)生了目前稱為云端運算的技術(shù)，這些網(wǎng)站已不是上百臺Server，而是擁有成千上萬的Server。此時，不要擔(dān)心資金問題了，如果網(wǎng)站達(dá)到這個境界，一堆人排隊送錢過來。
下面歸納一些解決方案：
1. Memory Cache
http://memcached.org/ 這個不同于 ASP.NET 的Cache，ASP.NET的Cache 分散在不同的Server上，不能共用也不能相互更新。在數(shù)據(jù)庫和AP Server中間架設(shè) Memcached server，將訪問頻率高的信息Cache在Memory中，會提高讀取性能。
可以將比較老舊的Server 或CPU 等級不高的Server 串接，建立Memcached server 群組，在Memcached client 端建立 consistent hashing 機(jī)制，來分散各個cache 值到各臺Server，使用consistent hashing 可以讓日后增加新Server時，不會導(dǎo)致cache存放位置大亂，而必須重新到數(shù)據(jù)庫讀取，造成數(shù)據(jù)庫瞬間癱瘓。
架構(gòu)如下，圖片來源：Designing and Implementing Scalable Applications with Memcached and MySQL
其原理可參考下文：http://forum.homeserver.com.tw/index.php?topic=5.0
當(dāng)數(shù)據(jù)庫過大時，還可以用DB Sharding的方式，將Master DB 依Customer ID 切成多個Shard，來增加效率，有興趣的可以參考下面的文章：Database Sharding At Netlog
2. NoSQL
除了一些固定的數(shù)據(jù)增長，時常需要變動的數(shù)據(jù)如個人Profile、Friend List … 等等，還有一些其他輔助性數(shù)據(jù)，如留言…. 等等，這些數(shù)據(jù)不停的增長，人一多，數(shù)據(jù)量更大，這些數(shù)據(jù)由關(guān)系型數(shù)據(jù)庫處理相當(dāng)耗時，且意義不大，因此就有一些俗稱的NoSQL的Solution產(chǎn)生。
其概念為，如太多人讀取單一硬盤的大量數(shù)據(jù)，超過了硬盤的 IO 處理能力怎么辦？有人想到吧數(shù)據(jù)切成多個Block 碎片，復(fù)制并分散到3個不同的存儲節(jié)點，有需求的時候在從這些節(jié)點取出組合，這樣就分散了單一硬盤的使用量，并且效率更好，以這樣的概念建立的新的數(shù)據(jù)庫系統(tǒng)，并衍生出新的數(shù)據(jù)庫形態(tài)。
目前主流的平臺有 –
Google GFS / BigTable – Google開發(fā)并使用在多個服務(wù)上；
Hadoop HDFS / Hive / Hbase — Yahoo及Facebook 都使用Hadoop , Facebook使用HIVE做Data warehouse；
Apache Cassandra — Facebook提出的open source架構(gòu)，目前使用者為Digg，Twitter本來計劃使用，于2010年7月暫停了轉(zhuǎn)移計劃；
HyperTable — 百度使用Hadoop HDFS結(jié)合HyperTable 的技術(shù)，用Mapreduce做搜索引擎的核心計算。
Kyoto Cabinet / Tokyo Tyrant — 日本最大社群網(wǎng)站MIXI就是使用該架構(gòu)，其他用戶有Plurk及Scribd， Plurk以此架構(gòu)衍生出新的opensource架構(gòu)LightCloud；
Amazon Dynamo — Amazon 使用的key-value 數(shù)據(jù)庫，主要應(yīng)用在儲存best seller lists, shopping carts, customer preferences, session management, sales rank, and product catalog…等數(shù)據(jù)，目前并沒有對外開放使用。
Voldemort — Linkedin 使用該key-value數(shù)據(jù)庫；
MongoDB – Foursquare為用戶代表，與key-value形態(tài)的DB不同的是，MonogoDB支持document形態(tài)的數(shù)據(jù)，如XML存儲，想必Foursquare 用戶的check-in 數(shù)據(jù)全存儲在MongoDB上了。
這里的Database 大都以 key-value 為存儲方式，因此無法用關(guān)系型數(shù)據(jù)庫的標(biāo)準(zhǔn)語法來讀取數(shù)據(jù)，也不支持原始數(shù)據(jù)的update，但這樣的架構(gòu)很適合存儲超大量的數(shù)據(jù)，如Twitter每個人的Timeline、Facebook 上的News Feed、搜索引擎Crawl 的Web 資料、Web game的Notification … 等等，這類數(shù)據(jù)有如下特性：
1. 不斷的大量數(shù)據(jù)增長；
2. 不停在Add new 新數(shù)據(jù)，但不必更新（update）；
3. 隨時需要導(dǎo)出大量的數(shù)據(jù)；
如果網(wǎng)站的數(shù)據(jù)有上述特性，可以考慮這個Solution，想必對性能及規(guī)模擴(kuò)張有很大的幫助。
其他相關(guān)NoSQL 信息請參考 http://nosql-database.org/
3. CDN
當(dāng)網(wǎng)站使用了Memcached 及 NoSQL DB 改善了數(shù)據(jù)處理性能問題后，大量的圖片等靜態(tài)資源還是會有性能上的瓶頸，這樣就需要使用CDN（Content Delivery Network）的解決方案來改善了。
CDN 公司大都有超大規(guī)模的機(jī)房遍布各地，可以幫助其客戶在不用升級設(shè)備的狀況下，使用其超大規(guī)模的架構(gòu)，把內(nèi)容散播出去，客戶完全不用擔(dān)心Web Server Loading的問題，其技術(shù)原理如下：
- CDN 會定時到客戶網(wǎng)站，進(jìn)行復(fù)制并散播到其網(wǎng)絡(luò)節(jié)點去；
- 客戶需要把Cache內(nèi)容的DNS位置指向CDN；
- 使用者連上客戶網(wǎng)站時，其實連到CDN 最近的Cache節(jié)點，不用繞過多層的網(wǎng)絡(luò)節(jié)點；
Youtube 及 Facebook 都有使用到CDN服務(wù)，F(xiàn)acebook的圖片就是用CDN來加速，但由于CDN費用的關(guān)系，F(xiàn)acebook 建立了新架構(gòu)HayStack 來降低對CDN的依賴。
結(jié) 論
我們可以發(fā)現(xiàn)，這波的超大型網(wǎng)站都沒有使用商用平臺，一開始也都不用高檔的商用Server，所有的架構(gòu)都有論文基礎(chǔ)，并且愿意Open source 出來，Startup 公司思考的是用最經(jīng)濟(jì)的方式達(dá)到最高效益，而非完全依賴商用平臺花錢了事，這種研究精神十分值得敬佩及學(xué)習(xí)。不像國內(nèi)的某些公司，在談到如何解決網(wǎng)絡(luò)超大流量時，一副無可奉告，是高級機(jī)密的態(tài)度 …… 可見國內(nèi)對于分享技術(shù)這塊還有很大的進(jìn)步空間。
非常感謝臺灣朋友提供這一篇有用的文章。
原文鏈接：
