一、HTML靜態化
我(wo)們(men)都知道(dao)，效(xiao)率(lv)更高、消耗最小的(de)(de)就(jiu)是純(chun)靜(jing)態化的(de)(de)HTML頁面(mian)(mian)，所以(yi)我(wo)們(men)盡可能(neng)使網站上的(de)(de)頁面(mian)(mian)采(cai)用靜(jing)態頁面(mian)(mian)來(lai)實現(xian)。
二、圖片服務器分離
大家知道，對于Web服務器來(lai)說，不(bu)(bu)管是(shi)Apache、IIS還是(shi)其他(ta)容器，圖(tu)片(pian)是(shi)最消耗資源的(de)(de)(de)，于是(shi)我(wo)們有(you)必(bi)要將圖(tu)片(pian)與(yu)頁面進行分離，這是(shi)基本上大型(xing)網(wang)站都會采用的(de)(de)(de)策略，他(ta)們都有(you)獨立(li)的(de)(de)(de)、甚至很多(duo)臺的(de)(de)(de)圖(tu)片(pian)服務器。這樣的(de)(de)(de)架構可以(yi)降低提供頁面訪問請求的(de)(de)(de)服務器系統(tong)壓力(li)，并且(qie)可以(yi)保證系統(tong)不(bu)(bu)會因為圖(tu)片(pian)問題而崩潰。
在應用服務器和圖片服務器上，可(ke)以(yi)(yi)進(jin)行不同(tong)的配(pei)置(zhi)優化，比(bi)如apache在配(pei)置(zhi)ContentType的時候可(ke)以(yi)(yi)盡量少支(zhi)持、盡可(ke)能(neng)少的LoadModule，保證(zheng)更高(gao)的系統消耗和執(zhi)行效(xiao)率。
三、數據(ju)庫集群(qun)、庫表散列
大型(xing)網站(zhan)都有(you)復(fu)雜的應用，這些應用必須使用數(shu)據(ju)庫，那(nei)么在(zai)面對大量(liang)訪問(wen)的時候，數(shu)據(ju)庫的瓶頸很快就能(neng)顯現出來(lai)，這時一臺數(shu)據(ju)庫將很快無法滿(man)足(zu)應用，于是我們需(xu)要使用數(shu)據(ju)庫集群或者庫表(biao)散(san)列。
在數據庫(ku)集(ji)群(qun)方(fang)面，很(hen)多數據庫(ku)都(dou)(dou)有自(zi)己的(de)(de)解(jie)決(jue)方(fang)案(an)，Oracle、Sybase等都(dou)(dou)有很(hen)好的(de)(de)方(fang)案(an)，常用的(de)(de)MySQL提供的(de)(de)Master/Slave也(ye)是(shi)類(lei)似的(de)(de)方(fang)案(an)，您(nin)使用了什么樣的(de)(de)DB，就參考相應的(de)(de)解(jie)決(jue)方(fang)案(an)來(lai)實施即可。??上面提到(dao)的(de)(de)數據庫(ku)集(ji)群(qun)由于在架構(gou)、成本(ben)、擴張性方(fang)面都(dou)(dou)會(hui)受到(dao)所采用DB類(lei)型的(de)(de)限制，于是(shi)我們需要從應用程序的(de)(de)角度(du)來(lai)考慮改善系統架構(gou)，庫(ku)表散列是(shi)常用并且最有效的(de)(de)解(jie)決(jue)方(fang)案(an)。
我們(men)在應用程序(xu)中(zhong)安裝業務和應用或者(zhe)功能模(mo)塊(kuai)將數(shu)據(ju)庫(ku)進(jin)(jin)行(xing)分離，不同的(de)(de)模(mo)塊(kuai)對應不同的(de)(de)數(shu)據(ju)庫(ku)或者(zhe)表，再按照(zhao)一(yi)定的(de)(de)策略(lve)對某個頁面或者(zhe)功能進(jin)(jin)行(xing)更(geng)小的(de)(de)數(shu)據(ju)庫(ku)散(san)(san)列，比(bi)如(ru)用戶表，按照(zhao)用戶ID進(jin)(jin)行(xing)表散(san)(san)列，這樣就能夠低成(cheng)本的(de)(de)提升系統的(de)(de)性能并(bing)且有很好的(de)(de)擴(kuo)展性。
sohu的(de)論壇(tan)(tan)就是采用(yong)了這樣的(de)架構，將論壇(tan)(tan)的(de)用(yong)戶(hu)、設置、帖子等信息進(jin)(jin)行(xing)(xing)(xing)數(shu)據(ju)庫分離，然(ran)后對帖子、用(yong)戶(hu)按照(zhao)板塊和(he)ID進(jin)(jin)行(xing)(xing)(xing)散列數(shu)據(ju)庫和(he)表，最終可以在(zai)配置文件中進(jin)(jin)行(xing)(xing)(xing)簡(jian)單的(de)配置便能讓系統隨時增加一(yi)臺低(di)成(cheng)本的(de)數(shu)據(ju)庫進(jin)(jin)來補(bu)充系統性能。
四、緩存
緩存一詞搞(gao)技術的(de)(de)(de)都接觸過(guo)，很(hen)多地方(fang)用到緩存。網站架構(gou)和網站開(kai)發中(zhong)的(de)(de)(de)緩存也(ye)是非常重要。這里先講述最基本(ben)的(de)(de)(de)兩種(zhong)緩存。和分(fen)布(bu)式的(de)(de)(de)緩存在后面講述。
架構方面的緩存，對Apache比(bi)較熟悉的人都能(neng)知道Apache提供了自己的緩存模(mo)塊，也可以(yi)使(shi)用外加的Squid模(mo)塊進行緩存，這兩種方式(shi)均可以(yi)有效的提高Apache的訪問(wen)響(xiang)應(ying)能(neng)力(li)。
網站程(cheng)序開(kai)(kai)(kai)發(fa)(fa)(fa)方面的(de)緩存，Linux上提供的(de)MemoryCache是(shi)常(chang)用(yong)的(de)緩存接口，可(ke)以(yi)在web開(kai)(kai)(kai)發(fa)(fa)(fa)中使用(yong)，比(bi)如用(yong)Java開(kai)(kai)(kai)發(fa)(fa)(fa)的(de)時(shi)候(hou)就(jiu)可(ke)以(yi)調用(yong)MemoryCache對一些數據進行緩存和(he)通訊共享，一些大型社區使用(yong)了(le)這(zhe)樣的(de)架構。另(ling)外(wai)，在使用(yong)web語(yu)言開(kai)(kai)(kai)發(fa)(fa)(fa)的(de)時(shi)候(hou)，各(ge)種語(yu)言基本都有自己的(de)緩存模(mo)塊和(he)方法，PHP有Pear的(de)Cache模(mo)塊，Java就(jiu)更多(duo)了(le)，.net不(bu)是(shi)很熟悉，相信也肯定有。
五、鏡像
鏡像是大(da)型網(wang)站(zhan)(zhan)常采(cai)用的(de)(de)(de)提高性能和數據安全性的(de)(de)(de)方式，鏡像的(de)(de)(de)技術(shu)可以解(jie)決不同網(wang)絡(luo)接入(ru)商(shang)和地域(yu)帶來的(de)(de)(de)用戶訪問速度差異，比(bi)如(ru)ChinaNet和EduNet之間的(de)(de)(de)差異就促使(shi)了很多網(wang)站(zhan)(zhan)在教育網(wang)內(nei)搭建鏡像站(zhan)(zhan)點，數據進行定時(shi)更(geng)新或者實(shi)時(shi)更(geng)新。在鏡像的(de)(de)(de)細節(jie)技術(shu)方面(mian)，這(zhe)里不闡述太深(shen)，有很多**的(de)(de)(de)現成的(de)(de)(de)解(jie)決架構和產品(pin)可選。也(ye)有廉價的(de)(de)(de)通過軟(ruan)件實(shi)現的(de)(de)(de)思路，比(bi)如(ru)Linux上的(de)(de)(de)rsync等工具。
六、負載均衡
負(fu)載均衡將是大型網站解(jie)決高負(fu)荷訪問和大量并(bing)發(fa)請求(qiu)采用的高端解(jie)決辦(ban)法。
負載均衡技術發展了多(duo)年，有很多(duo)**的(de)服務提供商和產品可以選擇(ze)，我個人接觸過一些解決(jue)方法，其(qi)中有兩個架構(gou)可以給(gei)大家做參考。
（1）、硬(ying)件四層交(jiao)換(huan)
第四(si)(si)層交換使用(yong)第三層和第四(si)(si)層信息包的(de)報頭信息，根(gen)據應用(yong)區間識(shi)別業務(wu)流，將整個區間段的(de)業務(wu)流分配到合適的(de)應用(yong)服務(wu)器進行處理。
第四層交(jiao)(jiao)換功能(neng)(neng)就(jiu)像是虛IP，指向物(wu)理服(fu)務器(qi)。它傳輸(shu)的(de)業(ye)務服(fu)從的(de)協議多種(zhong)多樣，有(you)(you)HTTP、FTP、NFS、Telnet或其(qi)他協議。這些業(ye)務在(zai)物(wu)理服(fu)務器(qi)基礎上，需要復雜的(de)載(zai)量平(ping)衡算法。在(zai)IP世界(jie)，業(ye)務類(lei)型由(you)終端(duan)TCP或UDP端(duan)口地址(zhi)來決定(ding)，在(zai)第四層交(jiao)(jiao)換中(zhong)的(de)應用區(qu)間則由(you)源(yuan)端(duan)和終端(duan)IP地址(zhi)、TCP和UDP端(duan)口共同決定(ding)。??在(zai)硬件(jian)四層交(jiao)(jiao)換產品領域(yu)，有(you)(you)一些知名(ming)的(de)產品可以選(xuan)擇，比如Alteon、F5等(deng)，這些產品很昂貴(gui)，但是物(wu)有(you)(you)所值(zhi)，能(neng)(neng)夠提供(gong)非常的(de)性能(neng)(neng)和很靈活的(de)管理能(neng)(neng)力(li)。“Yahoo中(zhong)國”當初接近2000臺服(fu)務器(qi)，只(zhi)使(shi)用了三、四臺Alteon就(jiu)搞(gao)定(ding)了。
（2）、軟件四層(ceng)交換
大家知(zhi)道(dao)了硬件(jian)四層(ceng)交(jiao)換機的原(yuan)理(li)后，基于OSI模型(xing)來(lai)實(shi)現(xian)的軟(ruan)件(jian)四層(ceng)交(jiao)換也就應運而生，這樣的解(jie)決方(fang)案實(shi)現(xian)的原(yuan)理(li)一致(zhi)，不過(guo)性能稍差(cha)。但是(shi)滿(man)足一定量的壓(ya)力(li)還是(shi)游刃有(you)余的，有(you)人(ren)說軟(ruan)件(jian)實(shi)現(xian)方(fang)式其實(shi)更(geng)靈活，處理(li)能力(li)完(wan)全看你配置的熟悉能力(li)。
軟(ruan)件四層交換我(wo)們可(ke)以(yi)使用(yong)Linux上(shang)常用(yong)的(de)LVS來(lai)解決，LVS就是(shi)Linux VirtualServer，他提供了(le)基(ji)于(yu)心跳線heartbeat的(de)實(shi)時災(zai)難(nan)應(ying)(ying)對(dui)解決方案，提高系(xi)統(tong)(tong)的(de)強壯性，同時可(ke)供了(le)靈活的(de)虛擬(ni)VIP配置和管理功能，可(ke)以(yi)同時滿足多種應(ying)(ying)用(yong)需求，這對(dui)于(yu)分(fen)布式的(de)系(xi)統(tong)(tong)來(lai)說必不(bu)可(ke)少(shao)。
一個典(dian)型的使用負載(zai)均衡的策(ce)略就是，在軟(ruan)件(jian)或者(zhe)硬件(jian)四層交換(huan)的基(ji)礎(chu)上(shang)搭建squid集群，這(zhe)種思路在很多大型網站包括搜(sou)索(suo)引擎上(shang)被(bei)采用，這(zhe)樣的架構低成(cheng)本、高性能還(huan)有很強(qiang)的擴(kuo)張(zhang)性，隨(sui)時往架構里面增減節點都非常(chang)容易。
對(dui)于大型網(wang)站來說，前(qian)面提到的(de)每個(ge)方法可能都會被同時使用到，這里介(jie)紹得比較淺顯(xian)，具體(ti)實現過程中(zhong)很(hen)多細節還需要大家慢(man)慢(man)熟悉(xi)和體(ti)會。有(you)時一(yi)個(ge)很(hen)小的(de)squid參數(shu)或(huo)者apache參數(shu)設置，對(dui)于系統(tong)性能的(de)影響就(jiu)會很(hen)大。
蘇公網安備32030302000492號
