大型網站的架構設計問題----大型高併發高負載網站的系統架構

隨着中國大型IT企業信息化速度的加快，大部分應用的數據量和訪問量都急劇增加，大型企業網站正面臨性能和高數據訪問量的壓力，而且對存儲、安全以及信息檢索等等方面都提出了更高的要求……

    本文中，我想通過幾個國外大型IT企業及網站的成功案例，從Web技術人員角度探討如何積極地應對國內大型網站即將面臨的擴展（主要是技術方面，而較少涉及管理及營銷等方面）矛盾。

一、 國外大型IT網站的成功之道
(一) MySpace
    今天，MySpace已經成爲全球衆口皆碑的社區網站之王。儘管一流和營銷和管理經驗自然是每個IT企業取得成功的首要因素，但是本節中我們卻拋棄這一點，而主要着眼於探討在數次面臨系統擴張的緊急關頭MySpace是如何從技術方面採取應對策略的。
第一代架構—添置更多的Web服務器
    MySpace最初的系統很小，只有兩臺Web服務器（分擔處理用戶請求的工作量）和一個數據庫服務器（所有數據都存儲在這一個地方）。那時使用的是Dell雙CPU、4G內存的系統。在早期階段，MySpace基本是通過添置更多Web服務器來對付用戶暴增問題的。但到在2004年早期，在 MySpace用戶數增長到五十萬後，其數據庫服務器已經開始疲於奔命了。

第二代架構—增加數據庫服務器
    與增加Web服務器不同，增加數據庫並沒那麼簡單。如果一個站點由多個數據庫支持，設計者必須考慮的是，如何在保證數據一致性的前提下讓多個數據庫分擔壓力。

    MySpace運行在三個SQL Server數據庫服務器上—一個爲主，所有的新數據都向它提交，然後由它複製到其它兩個；另兩個數據庫服務器全力向用戶供給數據，用以在博客和個人資料欄顯示。這種方式在一段時間內效果很好——只要增加數據庫服務器，加大硬盤，就可以應對用戶數和訪問量的增加。

    這一次的數據庫架構按照垂直分割模式設計，不同的數據庫服務於站點的不同功能，如登錄、用戶資料和博客。垂直分割策略利於多個數據庫分擔訪問壓力，當用戶要求增加新功能時，MySpace只需要投入新的數據庫加以支持。在賬戶到達二百萬後，MySpace還從存儲設備與數據庫服務器直接交互的方式切換到SAN（存儲區域網絡）—用高帶寬、專門設計的網絡將大量磁盤存儲設備連接在一起，而數據庫連接到SAN。這項措施極大提升了系統性能、正常運行時間和可靠性。然而，當用戶繼續增加到三百萬後，垂直分割策略也變得難以維持下去。

第三代架構—轉到分佈式計算架構
    幾經折騰，最終，MySpace將目光移到分佈式計算架構——它在物理上分佈的衆多服務器，整體必須邏輯上等同於單臺機器。拿數據庫來說，就不能再像過去那樣將應用拆分，再以不同數據庫分別支持，而必須將整個站點看作一個應用。現在，數據庫模型裏只有一個用戶表，支持博客、個人資料和其他核心功能的數據都存儲在相同數據庫。

    既然所有的核心數據邏輯上都組織到一個數據庫，那麼MySpace必須找到新的辦法以分擔負荷——顯然，運行在普通硬件上的單個數據庫服務器是無能爲力的。這次，不再按站點功能和應用分割數據庫，MySpace開始將它的用戶按每百萬一組分割，然後將各組的全部數據分別存入獨立的SQL Server實例。目前，MySpace的每臺數據庫服務器實際運行兩個SQL Server實例，也就是說每臺服務器服務大約二百萬用戶。據MySpace的技術人員說，以後還可以按照這種模式以更小粒度劃分架構，從而優化負荷分擔。

第四代架構—求助於微軟方案
    2005年早期，賬戶達到九百萬，MySpace開始用微軟的C#編寫ASP.NET程序。在收到一定成效後，MySpace開始大規模遷移到ASP.NET。
    賬戶達到一千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性能問題，但站點目前的要求已經開始週期性超越SAN的I/O容量——即它從磁盤存儲系統讀寫數據的極限速度。

第五代架構—增加數據緩存層並轉到支持64位處理器的SQL Server 2005
    2005年春天，MySpace賬戶達到一千七百萬，MySpace又啓用了新的策略以減輕存儲系統壓力，即增加數據緩存層——位於Web服務器和數據庫服務器之間，其唯一職能是在內存中建立被頻繁請求數據對象的副本，如此一來，不訪問數據庫也可以向Web應用供給數據。

    2005年中期，服務賬戶數達到兩千六百萬時，MySpace因爲我們對內存的渴求而切換到了還處於beta測試的支持64位處理器的SQL Server 2005。升級到SQL Server 2005和64位Windows Server 2003後，MySpace每臺服務器配備了32G內存，後於2006年再次將配置標準提升到64G。

    事實上，MySpace的Web服務器和數據庫仍然經常發生超負荷，其用戶頻繁遭遇“意外錯誤”和“站點離線維護”等告示，他們不得不在論壇抱怨不停……

    MySpace正是在這樣不斷重構站點軟件、數據庫和存儲系統中，才一步步走到今天。事實上，MySpace已經成功解決了很多系統擴展性問題，其中存在相當的經驗值得我們借鑑。MySpace系統架構到目前爲止保持了相對穩定，但其技術人員仍然在爲SQL Server支持的同時連接數等方面繼續攻堅，儘可能把事情做到最好。

(二) Amazon
    亞馬遜書店無疑是電子商務發展的里程碑。2000年到現在，世界網絡業腥風血雨。Amazon曾經成爲網絡泡沫的頭號代表。如今，當這個“最大的泡沫”用幾經易改的數字把自己變成了堅實的IT巨人。

    歷覽Amazon發展過程，其成功經驗在於，它創造性地進行了電子商務中每一環節的探索，包括系統平臺的建設，程序編寫、網站設立、配送系統等等方面。用Amazon當家人貝索斯的話說就是，“在現實世界的商店最有力的武器就是地段，地段，地段，而對於我們來說最重要的三件事就是技術，技術，技術。”

(三) eBay
    eBay是世界聞名的拍賣網站，eBay公司通信部主管凱文•帕斯格拉夫認爲，“eBay成功的最重要原因在於公司管理和服務。”
    其成功的奧祕可以列舉爲以下幾點：
    ①敢爲天下先—在網絡尚不普及的時代，eBay率先進入網絡拍賣領域；
    ②依託虛擬商場所產生的特有的“零庫存”是eBay公司取得成功的另一個重要原因。該公司的核心業務沒有任何庫存風險，所有的商品都是由客戶提供，它只需要負責提供虛擬的拍賣平臺—網絡和軟件。所以，eBay公司的財務報表上不會出現“庫存費用”和“保管費用”等。
③自eBay公司成立開始，它就一直遵循兩條“黃金原則”：建設虛擬社區，給網民以家的感覺；保證網站穩定安全地運行。

二、 國內大型網站開發時的幾點建議
    從本節開始，我們將結合國內外大型IT網站在技術擴展方面的沉痛教訓和成功經驗，探討在如今剛剛開始的Web 2.0時代如何應對國內網站即將面臨的數據訪問量增加（甚至是急劇膨脹）的問題，並提出一些供參考的策略和建議。

(四) 搭建科學的系統架構
    構建大型的商業網站絕對不可能像構建普通的小型網站一樣一蹴而就，需要從嚴格的軟件工程管理的角度進行認真規劃，有步驟有邏輯地進行開發。對於大型網站來說，所採用的技術涉及面極其廣泛，從硬件到軟件、編程語言、數據庫、Web服務器、防火牆等各個領域都有了很高的要求，已經不是原來簡單的 html靜態網站所能比擬的。以著名的Yahoo!爲例，他們的每一個大型網站工程都需要大量相應專業人員的參與。

(五) 頁面靜態化
    可不要小看純靜態化的HTML頁面！其實在很多情況下，HTML往往意味着“效率最高、消耗最小”，所以我們儘可能使我們的網站上的頁面採用靜態頁面來實現。但是，對於大量內容並且頻繁更新的網站，我們無法全部手動實現，因此可以開發相應的自動化更新工具，例如我們常見的信息發佈系統CMS。像我們經常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發佈系統來管理和實現的。信息發佈系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、權限管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。

(六) 存儲問題
    存儲也是一個大問題，一種是小文件的存儲，比如圖片這類；另一種是大文件的存儲，比如搜索引擎的索引。
大家知道，對於Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統壓力，並且可以保證系統不會因爲圖片問題而崩潰，在應用服務器和圖片服務器上，可以進行不同的配置優化以保證更高的系統消耗和執行效率。

(七) 數據庫技術—集羣和庫表散列
    對於大型網站而言，使用大型的數據庫服務器是必須的事情。但是，在面對大量訪問的時候，數據庫的瓶頸仍然會顯現出來，這時一臺數據庫將很快無法滿足應用，於是我們需要藉助於數據庫集羣或者庫表散列技術。

    在數據庫集羣方面，很多數據庫廠商都有自己的解決方案，Oracle、Sybase、SQL Server等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案。因此，你使用了什麼樣的數據庫，就參考相應的解決方案來實施即可。

    上面提到的數據庫集羣由於在架構、成本、擴張性方面都會受到所採用數據庫類型的限制，於是我們需要從應用程序的角度來考慮改善系統架構，其中，庫表散列是常用並且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不同的模塊對應不同的數據庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數據庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能並且有很好的擴展性。在這一方面一個現成的例子就是搜狐。它的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，然後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加一臺低成本的數據庫進來補充系統性能。

(八) 緩存策略
    這絕對不單指低級的緩存技術相關的編程，應從整個架構角度着眼，深入研究Web服務器、數據庫服務器的各層級的緩衝策略，最後纔是低級的緩衝技術的編程。不同的Web服務器、數據庫服務器及Web編程語言都有自己不同的緩衝策略。例如數據庫存儲方面，SQL Serve 2005中的主動式緩存機制，Oracle數據的cache group技術，Hibernate的緩存包括Session的緩存和SessionFactory的緩存；Web服務器方面，Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力，IIS緩衝器技術；至於web開發語言，所用緩存技術更存在很大不同，例如ASP.NET 2.0中提出了兩種緩存應用程序數據和緩存服務頁輸出的策略，這兩種緩存技術相互獨立但不相互排斥，PHP有Pear的Cache模塊，等等。

(九) 鏡像
    鏡像是大型網站常採用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網絡接入商和地域帶來的用戶訪問速度差異。在鏡像的細節技術方面，這裏不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟件實現的思路，比如Linux上的rsync等工具。

(十) 負載均衡
    負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，基於LAMP解決方案的Lighttped+Squid是相當不錯的解決負載均衡和加速系統的有效方式。

(十一) 硬件四層交換
    第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。第四層交換功能就象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理服務器基礎上，需要複雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。

    在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。

(十二) 軟件四層交換
    大家知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是遊刃有餘的。

    一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在很多大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都非常容易。

(十三) 軟件投資問題
    據報導，目前國內除了一些上市企業和特別大知名大公司以外，很少有企業在成本中考慮正版軟件的購置費用。這種思維極有可能給中國互聯網帶來噩夢。如果一些公司真正面臨軟件資金方面的困難，完全可以考慮使用開源世界的LAMP解決方案（Linux＋Apache＋MySQL＋Perl、PHP或者 Python Web編程語言）；否則，隨着我國加入WTO範圍的不斷擴大，盜版打擊必然越來越嚴。因此，“苟且偷生”必將自食其果。

    另外，隨着網絡帶寬日漸提升，WEB 2.0技術必將影響到網絡世界的幾乎每一個角落。因此，如何積聚技術人員進行技術攻關並進一步加強安全防範也成爲一個日益嚴峻的問題，宜儘早納入到公司的議事日程。
  
四、 總結
    中國電子商務真正理性發展的一個標誌，是大量的傳統企業實實在在地開始用互聯網來處理商務、做生意，而現在這樣的浪潮已經開始。北京發行集團，聯合SINA、6688.com等單位共同推出的網上虛擬書店—新新書店就是這樣的一個標誌。

    隨着網絡帶寬日漸提升，隨着網絡理念和WEB 2.0技術的斷深入人心，各種B2B、B2C、C2C等電子商務模式很可能以立體交叉方式整合到各種大型商務網站中來。因此，作爲公司的技術人員，作爲臨危救駕的“白衣騎士”，如何應對海量存儲、海量訪問問題，海量信息檢索的問題，日益嚴峻的安全問題，等等，已經刻不容緩。