Q：也談大型高負載的網(wǎng)站的體系結構
A：從事發(fā)布系統(web publish system)的研究和開(kāi)發(fā)快兩年了，從小型應用到中型應用，基本上沒(méi)有參與大型應用(千萬(wàn)pv/day)的部署，網(wǎng)絡(luò )上這種技術(shù)的探討都不是特別全面，有的提及發(fā)布系統對分布式部署，以及海量負載，有的干脆只從網(wǎng)絡(luò )層面進(jìn)行講解，我感覺(jué)這是個(gè)系統工程，不僅要考慮到應用層面(user layer or app layer)，也要考慮到系統層面(kernel layer or system layer)，還要考慮到數據庫層面(database layer)，否則可能有失偏頗。
我現在從三個(gè)層面就我的理解說(shuō)一些我的一些看法，礙于知識和實(shí)踐的局限性，也會(huì )相當有限。
所謂應用層面指的是前端應用，因為對網(wǎng)站來(lái)說(shuō)，網(wǎng)友接觸最多的就是前端頁(yè)面，影響負載的很大程度上也是每天上千萬(wàn)的page view帶來(lái)的visit，對web1.0的網(wǎng)站來(lái)說(shuō)，前端頁(yè)面往往都是靜態(tài)化的，即html化的，這也是為了降低負載，因為web應用服務(wù)器解析html頁(yè)面的速度是最快的，而頁(yè)面的靜態(tài)化一般都是由web級的(主要)和桌面局域網(wǎng)級別的(很少)發(fā)布平臺發(fā)布的，基于分布式的考慮，發(fā)布系統*能夠分發(fā)產(chǎn)生的html頁(yè)，分發(fā)到光纖或者高速局域網(wǎng)中的不同host上，以便分散訪(fǎng)問(wèn)壓力。當然也可以使用系統層的同步工具完成這個(gè)工作，注意要對頁(yè)面的域名對應信息進(jìn)行保存，防止產(chǎn)生404 error。我個(gè)人比較喜歡系統層的網(wǎng)絡(luò )同步，速度比較快，穩定性也比較高。應用層的分發(fā)一般借助ftp的方式，速度不是特別快，容易產(chǎn)生擁塞，穩定性自然下降。
如果分布式的分發(fā)靜態(tài)頁(yè)面仍然存在瓶頸，怎么辦？國內大型的門(mén)戶(hù)網(wǎng)站往往采取可緩存的反向代理方式部署的負載均衡技術(shù)來(lái)解決，一般都是squid做前端cache和反向代理。負載均衡也有軟件級的(dns 輪詢(xún))負載均衡和硬件上的負載均衡甚至兩者的結合進(jìn)行實(shí)現，具體實(shí)施細則將在下一篇中進(jìn)行闡述。說(shuō)到靜態(tài)化，也不只是web1.0的傳統新聞門(mén)戶(hù)采用，web2.0的應用前端也可靜態(tài)化，或者部分靜態(tài)化，比如：社區型門(mén)戶(hù)，帖子就可以靜態(tài)化，可以采取即時(shí)靜態(tài)或者異步靜態(tài)的方式，也可以觸發(fā)靜態(tài)化。這種靜態(tài)化可以降低數據庫層的壓力，數據庫服務(wù)器如果始終工作在大負載的訪(fǎng)問(wèn)壓力下，很容易崩潰，盡可能的將經(jīng)常用到的數據靜態(tài)化，緩存起來(lái)會(huì )極大的降低壓力。（貓撲、網(wǎng)易、搜狐等社區都是采用的這種方式）
上文提到了靜態(tài)化能減輕數據庫服務(wù)器的壓力，可是卻影響了更新的即時(shí)性，有些應用需要數據的即時(shí)顯示，不允許緩存或者靜態(tài)化，這就需要對數據庫服務(wù)器的結構進(jìn)行合理部署。除了要在設計應用之初，很好的設計數據庫結構，使用好的模式之外，還要對數據庫服務(wù)器進(jìn)行分布式部署甚至庫表散列。在數據庫集群(database culuster)方面，很多數據庫都有不錯的解決方案，包括Oracle、Sybase甚至mysql，只不過(guò)mysql采用的是master+slave的結構，選用了何種數據庫，就參照相應的解決方案進(jìn)行部署。除了在數據庫選擇上進(jìn)行負載均衡之外，也可以在單數據庫本身進(jìn)行考慮，比如庫表的散列，根據應用的特點(diǎn)，將大的、影響性能的數據庫或者數據庫的單表進(jìn)行散列、拆分。比如：按用戶(hù)id進(jìn)行散列，按分類(lèi)進(jìn)行散列，或者按地區進(jìn)行散列。
說(shuō)到系統層，可能就是OS和Web Server了，大型應用的OS基本都是Unix(包括freebsd或者HP Unix等)或者類(lèi)Unix(各種linux版本，redhat居多)，這不是說(shuō)Microsoft的OS就不合理了，合理的應用也可部署大型應用，只不過(guò)效能會(huì )很受限制。Web Server層面，還是apache當家，尤其是靜態(tài)頁(yè)和圖片，當然也可以根據具體的需求，根據內容的特殊性選擇Lighttpd(比較適合做純靜態(tài)、圖片服務(wù)器、視頻服務(wù)器等)、甚至iis（windows下用的居多），系統層的web服務(wù)器的配置還是很有講究的，比如對cache的配置，反向代理的配置等。比較好的web加速和代理服務(wù)器有：Squid、Nginx、HAProxy、Lighttpd，這四個(gè)可能是用的比較多的了。其中業(yè)內比較出名的Flickr、tudou用的是lighttpd，sina和51.com使用了，至少部分使用了Nginx。
緩存系統對高負載的重要性是不言而喻的，前面提到的靜態(tài)化，需要進(jìn)行有效緩存，經(jīng)常用到的查詢(xún)和結果需要進(jìn)行緩存，只要設定好更新緩存的規則，對性能的提升是n個(gè)數量級的。Linux下，有內存級別的緩存，高速緩存，很多應用都是用tmpfs來(lái)進(jìn)行數據中轉，php上用的最多的是memcached，apache有文件系統級別的cache，squid也是做前端cache的主要手段。騰訊、網(wǎng)易等都是用了squid做前端cache server。
前面提到的負載均衡，有軟件級別的，比如LVS、HAProxy、Linux-HA項目等，硬件層面的諸如：f5的BigIp、3DNS，alton的解決方案，北電的方案等，都是比較成熟的，不過(guò)都需要付出相當可觀(guān)的￥。
A：從事發(fā)布系統(web publish system)的研究和開(kāi)發(fā)快兩年了，從小型應用到中型應用，基本上沒(méi)有參與大型應用(千萬(wàn)pv/day)的部署，網(wǎng)絡(luò )上這種技術(shù)的探討都不是特別全面，有的提及發(fā)布系統對分布式部署，以及海量負載，有的干脆只從網(wǎng)絡(luò )層面進(jìn)行講解，我感覺(jué)這是個(gè)系統工程，不僅要考慮到應用層面(user layer or app layer)，也要考慮到系統層面(kernel layer or system layer)，還要考慮到數據庫層面(database layer)，否則可能有失偏頗。
我現在從三個(gè)層面就我的理解說(shuō)一些我的一些看法，礙于知識和實(shí)踐的局限性，也會(huì )相當有限。
所謂應用層面指的是前端應用，因為對網(wǎng)站來(lái)說(shuō)，網(wǎng)友接觸最多的就是前端頁(yè)面，影響負載的很大程度上也是每天上千萬(wàn)的page view帶來(lái)的visit，對web1.0的網(wǎng)站來(lái)說(shuō)，前端頁(yè)面往往都是靜態(tài)化的，即html化的，這也是為了降低負載，因為web應用服務(wù)器解析html頁(yè)面的速度是最快的，而頁(yè)面的靜態(tài)化一般都是由web級的(主要)和桌面局域網(wǎng)級別的(很少)發(fā)布平臺發(fā)布的，基于分布式的考慮，發(fā)布系統*能夠分發(fā)產(chǎn)生的html頁(yè)，分發(fā)到光纖或者高速局域網(wǎng)中的不同host上，以便分散訪(fǎng)問(wèn)壓力。當然也可以使用系統層的同步工具完成這個(gè)工作，注意要對頁(yè)面的域名對應信息進(jìn)行保存，防止產(chǎn)生404 error。我個(gè)人比較喜歡系統層的網(wǎng)絡(luò )同步，速度比較快，穩定性也比較高。應用層的分發(fā)一般借助ftp的方式，速度不是特別快，容易產(chǎn)生擁塞，穩定性自然下降。
如果分布式的分發(fā)靜態(tài)頁(yè)面仍然存在瓶頸，怎么辦？國內大型的門(mén)戶(hù)網(wǎng)站往往采取可緩存的反向代理方式部署的負載均衡技術(shù)來(lái)解決，一般都是squid做前端cache和反向代理。負載均衡也有軟件級的(dns 輪詢(xún))負載均衡和硬件上的負載均衡甚至兩者的結合進(jìn)行實(shí)現，具體實(shí)施細則將在下一篇中進(jìn)行闡述。說(shuō)到靜態(tài)化，也不只是web1.0的傳統新聞門(mén)戶(hù)采用，web2.0的應用前端也可靜態(tài)化，或者部分靜態(tài)化，比如：社區型門(mén)戶(hù)，帖子就可以靜態(tài)化，可以采取即時(shí)靜態(tài)或者異步靜態(tài)的方式，也可以觸發(fā)靜態(tài)化。這種靜態(tài)化可以降低數據庫層的壓力，數據庫服務(wù)器如果始終工作在大負載的訪(fǎng)問(wèn)壓力下，很容易崩潰，盡可能的將經(jīng)常用到的數據靜態(tài)化，緩存起來(lái)會(huì )極大的降低壓力。（貓撲、網(wǎng)易、搜狐等社區都是采用的這種方式）
上文提到了靜態(tài)化能減輕數據庫服務(wù)器的壓力，可是卻影響了更新的即時(shí)性，有些應用需要數據的即時(shí)顯示，不允許緩存或者靜態(tài)化，這就需要對數據庫服務(wù)器的結構進(jìn)行合理部署。除了要在設計應用之初，很好的設計數據庫結構，使用好的模式之外，還要對數據庫服務(wù)器進(jìn)行分布式部署甚至庫表散列。在數據庫集群(database culuster)方面，很多數據庫都有不錯的解決方案，包括Oracle、Sybase甚至mysql，只不過(guò)mysql采用的是master+slave的結構，選用了何種數據庫，就參照相應的解決方案進(jìn)行部署。除了在數據庫選擇上進(jìn)行負載均衡之外，也可以在單數據庫本身進(jìn)行考慮，比如庫表的散列，根據應用的特點(diǎn)，將大的、影響性能的數據庫或者數據庫的單表進(jìn)行散列、拆分。比如：按用戶(hù)id進(jìn)行散列，按分類(lèi)進(jìn)行散列，或者按地區進(jìn)行散列。
說(shuō)到系統層，可能就是OS和Web Server了，大型應用的OS基本都是Unix(包括freebsd或者HP Unix等)或者類(lèi)Unix(各種linux版本，redhat居多)，這不是說(shuō)Microsoft的OS就不合理了，合理的應用也可部署大型應用，只不過(guò)效能會(huì )很受限制。Web Server層面，還是apache當家，尤其是靜態(tài)頁(yè)和圖片，當然也可以根據具體的需求，根據內容的特殊性選擇Lighttpd(比較適合做純靜態(tài)、圖片服務(wù)器、視頻服務(wù)器等)、甚至iis（windows下用的居多），系統層的web服務(wù)器的配置還是很有講究的，比如對cache的配置，反向代理的配置等。比較好的web加速和代理服務(wù)器有：Squid、Nginx、HAProxy、Lighttpd，這四個(gè)可能是用的比較多的了。其中業(yè)內比較出名的Flickr、tudou用的是lighttpd，sina和51.com使用了，至少部分使用了Nginx。
緩存系統對高負載的重要性是不言而喻的，前面提到的靜態(tài)化，需要進(jìn)行有效緩存，經(jīng)常用到的查詢(xún)和結果需要進(jìn)行緩存，只要設定好更新緩存的規則，對性能的提升是n個(gè)數量級的。Linux下，有內存級別的緩存，高速緩存，很多應用都是用tmpfs來(lái)進(jìn)行數據中轉，php上用的最多的是memcached，apache有文件系統級別的cache，squid也是做前端cache的主要手段。騰訊、網(wǎng)易等都是用了squid做前端cache server。
前面提到的負載均衡，有軟件級別的，比如LVS、HAProxy、Linux-HA項目等，硬件層面的諸如：f5的BigIp、3DNS，alton的解決方案，北電的方案等，都是比較成熟的，不過(guò)都需要付出相當可觀(guān)的￥。
