怎樣設計大型網站， 確保海量併發下仍能夠穩定運行？
一個小型的網站， 比如個人網站， 可以使用最簡單的html靜態頁面就實現了， 配合一些圖片達到美化效果， 所有的頁面均存放在一個目錄下， 這樣的網站對系統架構、性能的要求都很簡單， 隨著互聯網業務的不斷豐富， 網站相關的技術經過這些年的發展， 已經細分到很細的方方面面， 尤其對於大型網站來說， 所採用的技術更是涉及面非常廣， 從硬體到軟體、程式設計語言、資料庫、WebServer、防火牆等各個領域都有了很高的要求， 已經不是原來簡單的html靜態網站所能比擬的。
大型網站， 比如門戶網站。 在面對大量用戶訪問、高併發請求方面， 基本的解決方案集中在這樣幾個環節：使用高性能的伺服器、高性能的資料庫、高效率的程式設計語言、還有高性能的Web容器。 但是除了這幾個方面， 還沒法根本解決大型網站面臨的高負載和高併發問題。
上面提供的幾個解決思路在一定程度上也意味著更大的投入， 並且這樣的解決思路具備瓶頸， 沒有很好的擴展性， 下面我從低成本、高性能和高擴張性的角度來說說我的一些經驗。
1、HTML靜態化
其實大家都知道， 效率最高、消耗最小的就是純靜態化的html頁面， 所以我們盡可能使我們的網站上的頁面採用靜態頁面來實現， 這個最簡單的方法其實也是最
有效的方法。 但是對於大量內容並且頻繁更新的網站， 我們無法全部手動去挨個實現， 於是出現了我們常見的資訊發佈系統CMS， 像我們常訪問的各個門戶網站的
新聞頻道， 甚至他們的其他頻道， 都是通過資訊發佈系統來管理和實現的， 資訊發佈系統可以實現最簡單的資訊錄入自動生成靜態頁面， 還能具備頻道管理、許可權管理、自動抓取等功能， 對於一個大型網站來說， 擁有一套高效、可管理的CMS是必不可少的。
除了門戶和資訊發佈類型的網站， 對於交互性要求很高的社區類型網站來說， 盡可能的靜態化也是提高性能的必要手段， 將社區內的帖子、文章進行即時的靜態化， 有更新的時候再重新靜態化也是大量使用的策略，
同時， html靜態化也是某些緩存策略使用的手段， 對於系統中頻繁使用資料庫查詢但是內容更新很小的應用，
可以考慮使用html靜態化來實現， 比如論壇中論壇的公用設置資訊， 這些資訊目前的主流論壇都可以進行後臺管理並且存儲再資料庫中， 這些資訊其實大量被前
台程式調用， 但是更新頻率很小， 可以考慮將這部分內容進行後臺更新的時候進行靜態化， 這樣避免了大量的資料庫訪問請求。
2、圖片伺服器分離
大家知道， 對於Web伺服器來說， 不管是Apache、IIS還是其他容器， 圖片是最消耗資源的， 於是我們有必要將圖片與頁面進行分離， 這是基本上大型網
站都會採用的策略， 他們都有獨立的圖片伺服器， 甚至很多台圖片伺服器。 這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力， 並且可以保證系統不會因為圖
片問題而崩潰， 在應用伺服器和圖片伺服器上， 可以進行不同的配置優化， 比如apache在配置ContentType的時候可以儘量少支援， 盡可能少的
LoadModule， 保證更高的系統消耗和執行效率。
3、資料庫集群和庫表散列
大型網站都有複雜的應用， 這些應用必須使用資料庫， 那麼在面對大量訪問的時候， 資料庫的瓶頸很快就能顯現出來， 這時一台資料庫將很快無法滿足應用， 於是我們需要使用資料庫集群或者庫表散列。
在資料庫集群方面， 很多資料庫都有自己的解決方案，
上面提到的資料庫集群由於在架構、成本、擴張性方面都會受到所採用DB類型的限制， 於是我們需要從應用程式的角度來考慮改善系統架構， 庫表散列是常用並且
最有效的解決方案。 我們在應用程式中安裝業務和應用或者功能模組將資料庫進行分離， 不同的模組對應不同的資料庫或者表， 再按照一定的策略對某個頁面或者功
能進行更小的資料庫散列， 比如使用者表， 按照用戶ID進行表散列， 這樣就能夠低成本的提升系統的性能並且有很好的擴展性。 sohu的論壇就是採用了這樣的架
構， 將論壇的用戶、設置、帖子等資訊進行資料庫分離， 然後對帖子、用戶按照板塊和ID進行散列資料庫和表，最終可以在設定檔中進行簡單的配置便能讓系統
隨時增加一台低成本的資料庫進來補充系統性能。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這裡先講述最基本的兩種緩存。高級和分散式的緩存在後面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模組，也可以使用外加的Squid模組進行緩存，這兩種方式均可以有效的提高Apache的訪問回應能力。
網站程式開發方面的緩存，Linux上提供的Memory Cache是
常用的緩存介面，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些資料進行緩存和通訊共用，一些大型社區使用了
這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模組和方法，PHP有Pear的Cache模組，Java就更多了，.net
不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網站常採用的提高性能和資料安全性的方式，鏡像的技術可以解決不同網路接
入商和地域帶來的用戶存取速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網站在教育網內搭建鏡像網站，資料進行定時更新或者即時更
新。在鏡像的細節技術方面，這裡不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如Linux上的rsync等工
具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供者和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
硬體四層交換
第四層交換使用第三層和第四層資訊包的報頭資訊，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。 第四層交換功能就像是虛 IP，
指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上，需要複雜的載量平
衡演算法。在IP世界，業務類型由終端TCP或UDP埠位址來決定，在第四層交換中的應用區間則由源端和終端IP位址、TCP和UDP埠共同決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000台伺服器使用了三四台Alteon就搞定了。
軟體四層交換
大家知道了硬體四層交換機的原理後，基於OSI模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是遊刃有餘的，有人說軟體實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟體四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux
VirtualServer，他提供了基於心跳線heartbeat的即時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功
能，可以同時滿足多種應用需求，這對於分散式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜尋引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。
對於大型網站來說，前面提到的每個方法可能都會被同時使用到，我這裡介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，希望大家一起討論，達到抛磚引玉之效
然後對帖子、用戶按照板塊和ID進行散列資料庫和表，最終可以在設定檔中進行簡單的配置便能讓系統隨時增加一台低成本的資料庫進來補充系統性能。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這裡先講述最基本的兩種緩存。高級和分散式的緩存在後面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模組，也可以使用外加的Squid模組進行緩存，這兩種方式均可以有效的提高Apache的訪問回應能力。
網站程式開發方面的緩存，Linux上提供的Memory Cache是
常用的緩存介面，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些資料進行緩存和通訊共用，一些大型社區使用了
這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模組和方法，PHP有Pear的Cache模組，Java就更多了，.net
不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網站常採用的提高性能和資料安全性的方式，鏡像的技術可以解決不同網路接
入商和地域帶來的用戶存取速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網站在教育網內搭建鏡像網站，資料進行定時更新或者即時更
新。在鏡像的細節技術方面，這裡不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如Linux上的rsync等工
具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供者和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
硬體四層交換
第四層交換使用第三層和第四層資訊包的報頭資訊，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。 第四層交換功能就像是虛 IP，
指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上，需要複雜的載量平
衡演算法。在IP世界，業務類型由終端TCP或UDP埠位址來決定，在第四層交換中的應用區間則由源端和終端IP位址、TCP和UDP埠共同決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000台伺服器使用了三四台Alteon就搞定了。
軟體四層交換
大家知道了硬體四層交換機的原理後，基於OSI模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是遊刃有餘的，有人說軟體實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟體四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux
VirtualServer，他提供了基於心跳線heartbeat的即時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功
能，可以同時滿足多種應用需求，這對於分散式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜尋引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。
對於大型網站來說，前面提到的每個方法可能都會被同時使用到，我這裡介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，希望大家一起討論，達到抛磚引玉之效