*1梯码、HTML 靜態(tài)化
其實大家都知道，效率最高粗恢、消耗最小的就是純靜態(tài)化的 html 頁面薇正，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實現(xiàn)片酝，這個最簡單 的方法其實也是最有效的方法囚衔。但是對于大量內(nèi)容并且頻繁更新的網(wǎng)站，我們無 法全部手動去挨個實現(xiàn)雕沿，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng) CMS练湿，像我們常 訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道审轮，都是通過信息發(fā)布系統(tǒng) 來管理和實現(xiàn)的肥哎，信息發(fā)布系統(tǒng)可以實現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面， 還能具備頻道管理疾渣、權限管理篡诽、自動抓取等功能，對于一個大型網(wǎng)站來說榴捡，擁有 一套高效杈女、可管理的 CMS 是必不可少的。除了門戶和信息發(fā)布類型的網(wǎng)站吊圾，對 于交互性要求很高的社區(qū)類型網(wǎng)站來說达椰， 盡可能的靜態(tài)化也是提高性能的必要手 段，將社區(qū)內(nèi)的帖子项乒、文章進行實時的靜態(tài)化啰劲，有更新的時候再重新靜態(tài)化也是 大量使用的策略，像 Mop 的大雜燴就是使用了這樣的策略板丽，網(wǎng)易社區(qū)等也是如 此呈枉。同時趁尼，html 靜態(tài)化也是某些緩存策略使用的手段埃碱，對于系統(tǒng)中頻繁使用數(shù) 據(jù)庫查詢但是內(nèi)容更新很小的應用，可以考慮使用 html 靜態(tài)化來實現(xiàn)酥泞，比如論 壇中論壇的公用設置信息砚殿， 這些信息目前的主流論壇都可以進行后臺管理并且存 儲再數(shù)據(jù)庫中，這些信息其實大量被前臺程序調用芝囤，但是更新頻率很小似炎，可以考 慮將這部分內(nèi)容進行后臺更新的時候進行靜態(tài)化， 這樣避免了大量的數(shù)據(jù)庫訪問 請求悯姊。

*2羡藐、圖片服務器分離
大家知道，對于 Web 服務器來說悯许，不管是 Apache仆嗦、IIS 還是 其他容器，圖片是最消耗資源的先壕，于是我們有必要將圖片與頁面進行分離瘩扼，這是 基本上大型網(wǎng)站都會采用的策略谆甜，他們都有獨立的圖片服務器，甚至很多臺圖片 服務器集绰。這樣的架構可以降低提供頁面訪問請求的服務器系統(tǒng)壓力规辱，并且可以保 證系統(tǒng)不會因為圖片問題而崩潰，在應用服務器和圖片服務器上栽燕，可以進行不同 的配置優(yōu)化罕袋，比如 apache 在配置 ContentType 的時候可以盡量少支持，盡可能 少的 LoadModule纫谅，保證更高的系統(tǒng)消耗和執(zhí)行效率炫贤。

*3、數(shù)據(jù)庫集群和庫表散列
大型網(wǎng)站都有復雜的應用付秕，這些應用必須使用數(shù)據(jù)庫兰珍， 那么在面對大量訪問的時候，數(shù)據(jù)庫的瓶頸很快就能顯現(xiàn)出來询吴，這時一臺數(shù)據(jù)庫 將很快無法滿足應用掠河，于是我們需要使用數(shù)據(jù)庫集群或者庫表散列。在數(shù)據(jù)庫集 群方面猛计，很多數(shù)據(jù)庫都有自己的解決方案唠摹，Oracle、Sybase 等都有很好的方案奉瘤， 常用的 MySQL 提供的 Master/Slave 也是類似的方案勾拉，您使用了什么樣的 DB，就 參考相應的解決方案來實施即可盗温。上面提到的數(shù)據(jù)庫集群由于在架構藕赞、成本、擴 張性方面都會受到所采用 DB 類型的限制卖局，于是我們需要從應用程序的角度來考 慮改善系統(tǒng)架構斧蜕，庫表散列是常用并且最有效的解決方案。我們在應用程序中安 裝業(yè)務和應用或者功能模塊將數(shù)據(jù)庫進行分離砚偶， 不同的模塊對應不同的數(shù)據(jù)庫或 者表批销，再按照一定的策略對某個頁面或者功能進行更小的數(shù)據(jù)庫散列，比如用戶 表染坯，按照用戶 ID 進行表散列均芽，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好 的擴展性。sohu 的論壇就是采用了這樣的架構单鹿，將論壇的用戶掀宋、設置、帖子等 信息進行數(shù)據(jù)庫分離，然后對帖子布朦、用戶按照板塊和 ID 進行散列數(shù)據(jù)庫和表囤萤， 最終可以在配置文件中進行簡單的配置便能讓系統(tǒng)隨時增加一臺低成本的數(shù)據(jù) 庫進來補充系統(tǒng)性能。

*4是趴、緩存
緩存一詞搞技術的都接觸過涛舍，很多地方用到緩存。網(wǎng)站架構和網(wǎng)站開發(fā) 中的緩存也是非常重要唆途。這里先講述最基本的兩種緩存富雅。高級和分布式的緩存在 后面講述。架構方面的緩存肛搬，對 Apache 比較熟悉的人都能知道 Apache 提供了自 己的緩存模塊没佑，也可以使用外加的 Squid 模塊進行緩存，這兩種方式均可以有效 的提高 Apache 的訪問響應能力温赔。網(wǎng)站程序開發(fā)方面的緩存蛤奢，Linux 上提供的 Memory Cache 是常用的緩存接口，可以在 web 開發(fā)中使用陶贼，比如用 Java 開發(fā)的 時候就可以調用 MemoryCache 對一些數(shù)據(jù)進行緩存和通訊共享啤贩， 一些大型社區(qū)使 用了這樣的架構。另外拜秧，在使用 web 語言開發(fā)的時候痹屹，各種語言基本都有自己的 緩存模塊和方法， PHP 有 Pear 的 Cache 模塊枉氮， Java 就更多了志衍， .net 不是很熟悉， 相信也肯定有聊替。

*5楼肪、鏡像
鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術可 以解決不同網(wǎng)絡接入商和地域帶來的用戶訪問速度差異佃牛，比如 ChinaNet 和 EduNet 之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內(nèi)搭建鏡像站點淹辞，數(shù)據(jù)進行定時 更新或者實時更新医舆。在鏡像的細節(jié)技術方面俘侠，這里不闡述太深，有很多專業(yè)的現(xiàn) 成的解決架構和產(chǎn)品可選蔬将。也有廉價的通過軟件實現(xiàn)的思路爷速，比如 Linux 上的 rsync 等工具。

*6霞怀、負載均衡
負載均衡將是大型網(wǎng)站解決高負荷訪問和大量并發(fā)請求采用的終極 解決辦法惫东。 負載均衡技術發(fā)展了多年， 有很多專業(yè)的服務提供商和產(chǎn)品可以選擇， 我個人接觸過一些解決方法廉沮，其中有兩個架構可以給大家做參考颓遏。

*7、硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息滞时，根據(jù)應用 區(qū)間識別業(yè)務流叁幢，將整個區(qū)間段的業(yè)務流分配到合適的應用服務器進行處理。 第四層交換功能就象是虛 IP坪稽，指向物理服務器曼玩。它傳輸?shù)臉I(yè)務服從的協(xié)議多種 多樣，有 HTTP窒百、FTP黍判、NFS、Telnet 或其他協(xié)議篙梢。這些業(yè)務在物理服務器基礎上顷帖， 需要復雜的載量平衡算法。在 IP 世界渤滞，業(yè)務類型由終端 TCP 或 UDP 端口地址來 決定窟她，在第四層交換中的應用區(qū)間則由源端和終端 IP 地址、TCP 和 UDP 端口共 同決定蔼水。在硬件四層交換產(chǎn)品領域震糖，有一些知名的產(chǎn)品可以選擇，比如 Alteon趴腋、 F5 等吊说，這些產(chǎn)品很昂貴，但是物有所值优炬，能夠提供非常優(yōu)秀的性能和很靈活的 管理能力颁井。Yahoo 中國當初接近 2000 臺服務器使用了三四臺 Alteon 就搞定了 。

*8蠢护、軟件四層交換
大家知道了硬件四層交換機的原理后雅宾，基于 OSI 模型來實現(xiàn) 的軟件四層交換也就應運而生， 這樣的解決方案實現(xiàn)的原理一致葵硕， 不過性能稍差眉抬。 但是滿足一定量的壓力還是游刃有余的，有人說軟件實現(xiàn)方式其實更靈活懈凹，處理 能力完全看你配置的熟悉能力蜀变。軟件四層交換我們可以使用 Linux 上常用的 LVS 來解決，LVS 就是 Linux Virtual Server介评，他提供了基于心跳線 heartbeat 的實 時災難應對解決方案库北，提高系統(tǒng)的魯棒性爬舰，同時可供了靈活的虛擬 VIP 配置和管 理功能，可以同時滿足多種應用需求寒瓦，這對于分布式的系統(tǒng)來說必不可少情屹。一個 典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建 squid 集群杂腰，這種思路在很多大型網(wǎng)站包括搜索引擎上被采用屁商，這樣的架構低成本、高 性能還有很強的擴張性颈墅，隨時往架構里面增減節(jié)點都非常容易蜡镶。這樣的架構我準 備空了專門詳細整理一下和大家探討。對于大型網(wǎng)站來說恤筛，前面提到的每個方法 可能都會被同時使用到官还，我這里介紹得比較淺顯，具體實現(xiàn)過程中很多細節(jié)還需 要大家慢慢熟悉和體會毒坛，有時一個很小的 squid 參數(shù)或者 apache 參數(shù)設置望伦，對 于系統(tǒng)性能的影響就會很大，希望大家一起討論煎殷，達到拋磚引玉之效屯伞。 用 squid 做 web cache server，而 apache 在 squid 的后面提供真正的 web 服務豪直。 當然使用這樣的架構必須要保證主頁上大部分都是靜態(tài)頁面劣摇。 這就需要程序員的 配合將頁面在反饋給客戶端之前將頁面全部轉換成靜態(tài)頁面。 基本看出 sina 和 sohu 對于頻道等欄目都用了相同的技術弓乙， squid 來監(jiān)聽這些 即 IP 的 80 端口末融，而真正的 web server 來監(jiān)聽另外一個端口。從用戶的感覺上來 說不會有任何的區(qū)別暇韧，而相對于將 web server 直接和客戶端連在一起的方式勾习， 這樣的方式明顯的節(jié)省的帶寬和服務器。用戶訪問的速度感覺也會更快懈玻。