(轉)大中型網站架構探祕

相信不少IT人士都有過搭建本身主頁的經驗，10多年前的我的主頁都很是簡單，不少由Frontpage構建，多屬於靜態HTML頁面，最多加一點 特效而已。不過10年間，技術的進步是驚人的。如今，一個網站毫不可能僅僅由幾個HTML頁面構成。咱們隨便舉一個例子，國內圖片網站 yupoo.com，在 chinarank排名1000左右，而Alexa排名則爲5000左右，這個網站不算大，就是這樣一箇中型站點，擁有超過60臺服務器，架構中涉及的 Web服務器就包括了Lighttpd、Apache和 nginx。Yupoo的流量不算大，就已經擁有了60臺服務器，事實上，排名前幾位的網站，都擁有成千上萬臺服務器，如何協調這些服務器之間的工做負 載，如何統一指揮調度，如何維護這些服務器硬件都是棘手的挑戰。

負載均衡：

負載均衡是全部大中型網站必備的部署。顯然，大型網站天天上千萬獨立IP的訪問量，一個Web服務器根本承擔不了，網站後臺必需有多臺服務器共同工做，所以各類負載均衡技術就應運而生了。

較早的負載均衡是DNS負載均衡。原理很簡單，只要在域名解析的時候，將多個地址配置成同一個域名，負載均衡就完成了。不一樣用戶點擊同一個域名的時 候，實際上只解析給用戶一個地址，這樣用戶實際上訪問的是不一樣的Web服務器，就減輕了每一個服務器的負擔。這個DNS負載均衡方法，通常而言是隨機抽取地 址。DNS負載均衡早期被普遍使用，優勢是簡單易用，可是DNS負載均衡仍是有一些問題存在。若是某一臺服務器發生了故障，而DNS的下一個刷新週期又沒 到，這樣就可能致使某些用戶沒法訪問站點的狀況發生。而另外一個缺點在於DNS負載均衡隨機性太強，好比一段時間內衆多訪問都被指向同一個地址，而另外的地 址卻閒置，就形成了局部繁忙的不良現象。並且有時某處服務器正在運行其餘應用而處於繁忙狀態，DNS負載均衡也無從得知，而依舊平均的解析域名。

稍微複雜一點的負載均衡，是反向代理，當外部有請求到代理服務器，代理服務器再將該請求均勻的轉發到內網的服務器上。這種方式被普遍採用，好比說上 面提到的又拍網yupoo.com，就採用了nginx做爲反向代理。此外，如今還能夠購買專業的硬件設備，好比 Plentyoffish.com(全球最大的婚介網站)就採用了網捷網絡公司的Web交換器ServerIron做爲硬件負載均 衡，ServerIron 可以有效地處理 16，000，000個併發鏈接，而且能夠改善服務器負載均衡和緩衝轉換，像ServerIron這類的硬件產品並不是只有網捷一家提供，因爲大型網站預算 充裕，所以也能夠選擇一些其餘的硬件設備來作負載均衡。固然了，咱們也別忽略了最基本的軟件負載均衡——Windows Server就帶有這樣的功能。

負載均衡還有一個極爲簡單的方法，就是創建鏡像站點。好比華軍軟件或者天空軟件，都直接採用了鏡像站點。這個方式很直接，省去了不少麻煩。以華軍軟 件園爲例，登錄華軍軟件園的時候，咱們將有多種選擇，可選電信、網通等網絡；而下載某一軟件的時候，爲了使用戶獲得更快的速度，天空和華軍在中國各地都安 排了服務器，能夠提供距離最近的下載服務。不過，也有一些麻煩，就是每一次選擇都是人工手動選擇。總之，這一系列負載均衡方法，都得以讓大型網站的負載均 勻，不會有哪一個服務器有太大的壓力。

CDN：

CDN( Content Delivery Network)，內容分發網絡也是大型網站必備的部署之一。CDN的原理不難理解，就是將網頁內容存放到離用戶更近的緩存服務器上，減小路由，從而加快 遠距離的訪問速度。好比說，你隨意登錄一個國外小站，速度可能很慢。由於國外網站到國內的最終客戶端的路徑冗長，可是若是你登錄部署了CDN的網站，好比 Plentyoffish.com，你會發現速度很是快，跟國內的網站訪問速度差別已經沒法從感知上判斷。依照Cache存放的位置不一樣，CDN也有一些 類別，不一樣的網站會根據具體需求，有不一樣的選擇。CDN一般是由獨立的CDN商提供的。舉一個例子，就是網易，個人查詢時間是2008年2月28日，咱們 發現，同一個域名下的有不少個IP地址，這就說明了首頁CDN的部署。

C:\>nslookup www.163.com

Server: ns.lnpta.net.cn

Address: 202.96.64.68

Non-authoritative answer:

Name: www.cache.split.netease.com

Addresses: 202.108.9.37, 202.108.9.38, 202.108.9.39, 202.108.9.51

202.108.9.52, 202.108.9.31, 202.108.9.32, 202.108.9.33, 202.108.9.34

202.108.9.36

Aliases: www.163.com

而咱們若是查詢一個簡單的我的網站，則不可能有CDN；另外，若是有興趣，咱們也能夠仔細察看一個網站多個二級域名的CDN狀況。

平臺設計：

大型網站通常都有着很是複雜的與用戶交互的內容，必須大量調用數據庫，所以一個完善的數據庫設計對於大型網站很是重要。例如上面提到的 Plentyoffish.com，這個站實際上是我的網站，但流量大的驚人，該網站有一個主要的數據庫，兩個搜索數據庫，早些時 候，plentyoffish.com的數據庫設計問題頻頻，常常到數據庫堵塞，因此站長花費時間最多的地方就是數據庫優化。數據庫優化沒有什麼特別的捷 徑，其實不多有一次成型的完美數據庫構建，只能是按照特定的須要來設計數據庫，若有不足再去着手改進。不過大型網站仍是有一些共性，好比說圖片存儲單獨使 用圖片數據庫，儘可能使用靜態頁面來減小數據庫調用等等。

還有不少大型網站，都有着很是深厚的技術實力，能夠開發屬於本身的平臺。好比說谷歌，Google.com就有着本身獨特的平臺，主要包括 GFS、MapReduce和 BigTable。由於海量數據存儲，因此常規的數據庫調用查詢是很是恐怖的，每次查詢都將調用百億個頁面，成千上萬個併發檢索足以使得谷歌系統崩潰，因 此Google File System將大量頁面以獨特的方法壓縮以後再提供檢索；整個系統一共包括超過兩百個集羣，再由MapReduce來協同做業。不只僅谷歌，好比百度、中 搜等等網站也都有本身研發的獨特的平臺。

硬件配置：

大型網站的硬件配置必定就好嗎？答案是否認的。好比說全球最大的網站谷歌，google.com的整個架構的基礎是幾十萬臺普通的PC級別服務器。 谷歌一些服務器的細節爲商業機密，可是根據谷歌已經披露的資料顯示，在2006年以前谷歌擁有45萬臺服務器，這些服務器都是很是普通的PC級服務器，甚 至硬盤接口都仍是有些過期的IDE接口。這也是谷歌的獨特架構決定的，而對比谷歌，維基百科則擁有很是強勢的服務器，所有爲SCSI硬盤，並且主要的主機 中都有多達6塊硬盤，超過16GB內存。這比較容易理解，由於谷歌在全球擁有不少個數據中心，員工數量衆多，徹底有能力管理數以萬計服務器的運行，而維基 百科則爲非營利機構，主要依靠捐贈生存，員工數量很是稀少，所以必須配備強勢的服務器。其實，每一個網站都應該根據本身獨特的狀況來配置硬件，目前 1TB SATA硬盤已經步入了量產階段，但是2年之前1TB的硬盤只能經過RAID 0來實現，可見硬件的更新速度很是驚人，因此即使預算充裕，在配置服務器的時候也應該多考慮實際用途，而不必定要擁有最好的配置。

總結：

以上只是大型網站的歸納總結，其實每一個網站都有本身獨特的一面，因此以上的每一條規則都未必是死規定。好比說着重溝通的Twitter.com，本質就是一個異步聊天室，所以靜態頁面就不見的有必要。總之，網站架構沒有死定律，只要合適網站的，就是好的架構。