網(wǎng)站架構(gòu)（頁面靜態(tài)化，圖片服務器分離,負載均衡）方案全解析

CevenCheng 2011-04-19

展開全文

網(wǎng)站架構(gòu)（頁面靜態(tài)化，圖片服務器分離,負載均衡）方案全解析
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)頁面，還能具備頻道管理、權(quán)限管理、自動抓取等功能，對于一個大型網(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ù)庫中，這些信息其實大量被前臺程序調(diào)用，但是更新頻率很小可以考慮將這部分內(nèi)容進行后臺更新的時候進行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫訪問請求。
2、圖片服務器分離大家知道，對于Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進行分離，這是基本上大型網(wǎng)站都會采用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構(gòu)可以降低提供頁面訪問請求的服務器系統(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ù)庫集群由于在架構(gòu)、成本、擴張性方面都會受到所采用DB類型的限制，于是我們需要從應用程序的角度來考慮改善系統(tǒng)架構(gòu)，庫表散列是常用并且最有效的解決方案。我們在應用程序中安裝業(yè)務和應用或者功能模塊將數(shù)據(jù)庫進行分離，不同的模塊對應不同的數(shù)據(jù)庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數(shù)據(jù)庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴展性。sohu的論壇就是采用了這樣的架構(gòu)，將論壇的用戶、設置、帖子等信息進行數(shù)據(jù)庫分離，然后對帖子、用戶按照板塊和ID進行散列數(shù)據(jù)庫和表，最終可以在配置文件中進行簡單的配置便能讓系統(tǒng)隨時增加一臺低成本的數(shù)據(jù)庫進來補充系統(tǒng)性能。
4、緩存緩存一詞搞技術(shù)的都接觸過，很多地方用到緩存。網(wǎng)站架構(gòu)和網(wǎng)站開發(fā)中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在后面講述。架構(gòu)方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。網(wǎng)站程序開發(fā)方面的緩存，Linux上提供的Memory Cache是常用的緩存接口，可以在web開發(fā)中使用，比如用Java開發(fā)的時候就可以調(diào)用MemoryCache對一些數(shù)據(jù)進行緩存和通訊共享，一些大型社區(qū)使用了這樣的架構(gòu)。另外，在使用web語言開發(fā)的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
5、鏡像鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術(shù)可以解決不同網(wǎng)絡接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內(nèi)搭建鏡像站點，數(shù)據(jù)進行定時更新或者實時更新。在鏡像的細節(jié)技術(shù)方面，這里不闡述太深，有很多專業(yè)的現(xiàn)成的解決架構(gòu)和產(chǎn)品可選。也有廉價的通過軟件實現(xiàn)的思路，比如Linux上的rsync等工具。
6、負載均衡負載均衡將是大型網(wǎng)站解決高負荷訪問和大量并發(fā)請求采用的終極解決辦法。負載均衡技術(shù)發(fā)展了多年，有很多專業(yè)的服務提供商和產(chǎn)品可以選擇，我個人接觸過一些解決方法，其中有兩個架構(gòu)可以給大家做參考。
7、硬件四層交換第四層交換使用第三層和第四層信息包的報頭信息，根據(jù)應用區(qū)間識別業(yè)務流，將整個區(qū)間段的業(yè)務流分配到合適的應用服務器進行處理?！〉谒膶咏粨Q功能就象是虛 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)站包括搜索引擎上被采用，這樣的架構(gòu)低成本、高性能還有很強的擴張性，隨時往架構(gòu)里面增減節(jié)點都非常容易。這樣的架構(gòu)我準備空了專門詳細整理一下和大家探討。對于大型網(wǎng)站來說，前面提到的每個方法可能都會被同時使用到，我這里介紹得比較淺顯，具體實現(xiàn)過程中很多細節(jié)還需要大家慢慢熟悉和體會，有時一個很小的squid參數(shù)或者apache參數(shù)設置，對于系統(tǒng)性能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。

用squid做web cache server，而apache在squid的后面提供真正的web服務。當然使用這樣的架構(gòu)必須要保證主頁上大部分都是靜態(tài)頁面。這就需要程序員的配合將頁面在反饋給客戶端之前將頁面全部轉(zhuǎn)換成靜態(tài)頁面。
基本看出sina和sohu對于頻道等欄目都用了相同的技術(shù)，即squid來監(jiān)聽這些IP的80端口，而真正的web server來監(jiān)聽另外一個端口。從用戶的感覺上來說不會有任何的區(qū)別，而相對于將web server直接和客戶端連在一起的方式，這樣的方式明顯的節(jié)省的帶寬和服務器。用戶訪問的速度感覺也會更快。
帶寬：4000M/S (參考)
服務器數(shù)量：60 臺左右
Web服務器：Lighttpd, Apache, nginx
應用服務器：Tomcat
其他：Python, Java, MogileFS 、ImageMagick 等
關(guān)于 Squid 與 Tomcat
Squid 與 Tomcat 似乎在 Web 2.0 站點的架構(gòu)中較少看到。我首先是對 Squid 有點疑問，對此阿華的解釋是"目前暫時還沒找到效率比 Squid 高的緩存系統(tǒng)，原來命中率的確很差，后來在 Squid 前又裝了層 Lighttpd, 基于 url 做 hash, 同一個圖片始終會到同一臺 squid 去，所以命中率徹底提高了" 對于應用服務器層的 Tomcat，現(xiàn)在 Yupoo! 技術(shù)人員也在逐漸用其他輕量級的東西替代，而 YPWS/YPFS 現(xiàn)在已經(jīng)用 Python 進行開發(fā)了。
名次解釋：
· YPWS--Yupoo Web Server YPWS 是用 Python開發(fā)的一個小型 Web 服務器，提供基本的 Web 服務外，可以增加針對用戶、圖片、外鏈網(wǎng)站顯示的邏輯判斷，可以安裝于任何有空閑資源的服務器中，遇到性能瓶頸時方便橫向擴展。
· YPFS--Yupoo File System 與 YPWS 類似，YPFS 也是基于這個 Web 服務器上開發(fā)的圖片上傳服務器。

【Updated: 有網(wǎng)友留言質(zhì)疑 Python 的效率，Yupoo 老大劉平陽在 del.icio.us 上寫到 "YPWS用Python自己寫的，每臺機器每秒可以處理294個請求, 現(xiàn)在壓力幾乎都在10％以下"】
圖片處理層
接下來的 Image Process Server 負責處理用戶上傳的圖片。使用的軟件包也是 ImageMagick，在上次存儲升級的同時，對于銳化的比率也調(diào)整過了(我個人感覺，效果的確好了很多)?！盡agickd“ 是圖像處理的一個遠程接口服務，可以安裝在任何有空閑 CPU資源的機器上，類似 Memcached的服務方式。
我們知道 Flickr 的縮略圖功能原來是用 ImageMagick 軟件包的，后來被雅虎收購后出于版權(quán)原因而不用了（?）；EXIF 與 IPTC Flicke 是用 Perl 抽取的，我是非常建議 Yupoo! 針對 EXIF 做些文章，這也是潛在產(chǎn)生受益的一個重點。
圖片存儲層
原來 Yupoo! 的存儲采用了磁盤陣列柜，基于 NFS 方式的，隨著數(shù)據(jù)量的增大，”Yupoo! 開發(fā)部從07年6月份就開始著手研究一套大容量的、能滿足 Yupoo! 今后發(fā)展需要的、安全可靠的存儲系統(tǒng)“，看來 Yupoo! 系統(tǒng)比較有信心，也是滿懷期待的，畢竟這要支撐以 TB 計算的海量圖片的存儲和管理。我們知道，一張圖片除了原圖外，還有不同尺寸的，這些圖片統(tǒng)一存儲在 MogileFS 中。
對于其他部分，常見的 Web 2.0 網(wǎng)站必須軟件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用不少相對比較成熟的開源軟件，一方面也在自行開發(fā)定制適合自己的架構(gòu)組件。這也是一個 Web 2.0 公司所必需要走的一個途徑。
非常感謝一下 Yupoo! 阿華對于技術(shù)信息的分享，技術(shù)是共通的。下一個能爆料是哪家?
--EOF--
lighttpd+squid這套緩存是放在另外一個機房作為cdn的一個節(jié)點使用的，圖中沒描繪清楚，給大家?guī)聿槐懔恕?nbsp;
squid前端用lighttpd沒用nginx，主要是用了這么久，沒出啥大問題，所以就沒想其他的了。
URL Hash的擴展性的確不好，能做的就是不輕易去增減服務器，我們目前是5臺服務器做一組hash.
我們現(xiàn)在用Python寫的Web Server，在效率方面，我可以給個測試數(shù)據(jù)，根據(jù)目前的訪問日志模擬訪問測試的結(jié)果是1臺ypws,平均每秒處理294個請求(加載所有的邏輯判斷)。
在可靠性上，還不沒具體的數(shù)據(jù)，目前運行1個多月還沒有任何異常。
lvs每個節(jié)點上都裝nginx，主要是為了反向代理及處理靜態(tài)內(nèi)容，不過apache已顯得不是那么必需，準備逐漸去掉。
我們處理圖片都是即時的，我們目前半數(shù)以上的服務器都裝了magickd服務，用來分擔圖片處理請求。
每天數(shù)以千萬計的 Blog 內(nèi)容中，實時的熱點是什么? Tailrank 這個 Web 2.0 Startup 致力于回答這個問題。
專門爆料網(wǎng)站架構(gòu)的 Todd Hoff 對 Kevin Burton 進行了采訪。于是我們能了解一下 Tailrank 架構(gòu)的一些信息。每小時索引 2400 萬的 Blog 與 Feed，內(nèi)容處理能力為 160-200Mbps，IO 寫入大約在10-15MBps。每個月要處理 52T 之多的原始數(shù)據(jù)。Tailrank 所用的爬蟲現(xiàn)在已經(jīng)成為一個獨立產(chǎn)品：spinn3r。
服務器硬件
目前大約 15 臺服務器，CPU 是 64 位的 Opteron。每臺主機上掛兩個 SATA 盤，做 RAID 0。據(jù)我所知，國內(nèi)很多 Web 2.0 公司也用的是類似的方式，SATA 盤容量達，低廉價格，堪稱不二之選。操作系統(tǒng)用的是 Debian Linux 。Web 服務器用 Apache 2.0，Squid 做反向代理服務器。
數(shù)據(jù)庫
Tailrank 用 MySQL 數(shù)據(jù)庫，聯(lián)邦數(shù)據(jù)庫形式。存儲引擎用 InnoDB，數(shù)據(jù)量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些多核模式下互斥鎖的問題(This Bug?)。到數(shù)據(jù)庫的JDBC 驅(qū)動連接池用 lbpool 做負載均衡。MySQL Slave 或者 Master的復制用 MySQLSlaveSync 來輕松完成。不過即使這樣，還要花費 20％的時間來折騰 DB。
其他開放的軟件
任何一套系統(tǒng)都離不開合適的 Profiling 工具，Tailrank 也不利外，針對 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是開放的。
Tailrank 的一個比較大的競爭對手是 Techmeme，雖然二者暫時看面向內(nèi)容的側(cè)重點有所不同。其實，最大的對手還是自己，當需要挖掘的信息量越來越大，如果精準并及時的呈現(xiàn)給用戶內(nèi)容的成本會越來越高。從現(xiàn)在來看，Tailrank 離預期目標還差的很遠。期待羅馬早日建成。