網站架構優化（轉載）

網站架構（頁面靜態化，圖片服務器分離,負載均衡）方案全解析

文章分類:綜合技術

一、HTML靜態化其實你們都知道，效率最高、消耗最小的就是純靜態化的html頁面，因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。可是對於大量內容而且頻繁更新的網站，咱們沒法所有手動去挨個實現，因而出現了咱們常見的信息發佈系統CMS，像咱們常訪問的各個門戶站點的新聞頻道，甚至他們的其餘頻道，都是經過信息發佈系統來管理和實現的，信息發佈系統能夠實現最簡單的信息錄入自動生成靜態頁面，還能具有頻道管理、權限管理、自動抓取等功能，對於一個大型網站來講，擁有一套高效、可管理的CMS是必不可少的。除了門戶和信息發佈類型的網站，對於交互性要求很高的社區類型網站來講，儘量的靜態化也是提升性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再從新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數據庫查詢可是內容更新很小的應用，能夠考慮使用html靜態化來實現，好比論壇中論壇的公用設置信息，這些信息目前的主流論壇均可以進行後臺管理而且存儲再數據庫中，這些信息其實大量被前臺程序調用，可是更新頻率很小，能夠考慮將這部份內容進行後臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。 二、圖片服務器分離你們知道，對於Web服務器來講，無論是Apache、IIS仍是其餘容器，圖片是最消耗資源的，因而咱們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片服務器，甚至不少臺圖片服務器。這樣的架構能夠下降提供頁面訪問請求的服務器系統壓力，而且能夠保證系統不會由於圖片問題而崩潰，在應用服務器和圖片服務器上，能夠進行不一樣的配置優化，好比apache在配置ContentType的時候能夠儘可能少支持，儘量少的LoadModule，保證更高的系統消耗和執行效率。 三、數據庫集羣和庫表散列大型網站都有複雜的應用，這些應用必須使用數據庫，那麼在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快沒法知足應用，因而咱們須要使用數據庫集羣或者庫表散列。在數據庫集羣方面，不少數據庫都有本身的解決方案，Oracle、Sybase等都有很好的方案，經常使用的MySQL提供的Master/Slave也是相似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施便可。上面提到的數據庫集羣因爲在架構、成本、擴張性方面都會受到所採用DB類型的限制，因而咱們須要從應用程序的角度來考慮改善系統架構，庫表散列是經常使用而且最有效的解決方案。咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高系統的性能而且有很好的擴展性。sohu的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，而後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終能夠在配置文件中進行簡單的配置便能讓系統隨時增長一臺低成本的數據庫進來補充系統性能。 四、緩存緩存一詞搞技術的都接觸過，不少地方用到緩存。網站架構和網站開發中的緩存也是很是重要。這裏先講述最基本的兩種緩存。高級和分佈式的緩存在後面講述。架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了本身的緩存模塊，也可使用外加的Squid模塊進行緩存，這兩種方式都可以有效的提升Apache的訪問響應能力。網站程序開發方面的緩存，Linux上提供的Memory Cache是經常使用的緩存接口，能夠在web開發中使用，好比用Java開發的時候就能夠調用MemoryCache對一些數據進行緩存和通信共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各類語言基本都有本身的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也確定有。 五、鏡像鏡像是大型網站常採用的提升性能和數據安全性的方式，鏡像的技術能夠解決不一樣網絡接入商和地域帶來的用戶訪問速度差別，好比 ChinaNet和EduNet之間的差別就促使了不少網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這裏不闡述太深，有不少專業的現成的解決架構和產品可選。也有廉價的經過軟件實現的思路，好比Linux上的rsync等工具。 六、負載均衡負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。負載均衡技術發展了多年，有不少專業的服務提供商和產品能夠選擇，我我的接觸過一些解決方法，其中有兩個架構能夠給你們作參考。 七、硬件四層交換第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。　第四層交換功能就象是虛 IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其餘協議。這些業務在物理服務器基礎上，須要複雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。在硬件四層交換產品領域，有一些知名的產品能夠選擇，好比Alteon、F5等，這些產品很昂貴，可是物有所值，可以提供很是優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了 。八、軟件四層交換你們知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。可是知足必定量的壓力仍是遊刃有餘的，有人說軟件實現方式其實更靈活，處理能力徹底看你配置的熟悉能力。軟件四層交換咱們可使用Linux上經常使用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提升系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，能夠同時知足多種應用需求，這對於分佈式的系統來講必不可少。一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在不少大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都很是容易。這樣的架構我準備空了專門詳細整理一下和你們探討。對於大型網站來講，前面提到的每一個方法可能都會被同時使用到，我這裏介紹得比較淺顯，具體實現過程當中不少細節還須要你們慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，但願你們一塊兒討論，達到拋磚引玉之效。 用squid作web cache server，而apache在squid的後面提供真正的web服務。固然使用這樣的架構必需要保證主頁上大部分都是靜態頁面。這就須要程序員的配合將頁面在反饋給客戶端以前將頁面所有轉換成靜態頁面。 基本看出sina和sohu對於頻道等欄目都用了相同的技術，即squid來監聽這些IP的80端口，而真正的web server來監聽另一個端口。從用戶的感受上來講不會有任何的區別，而相對於將web server直接和客戶端連在一塊兒的方式，這樣的方式明顯的節省的帶寬和服務器。用戶訪問的速度感受也會更快。 http://www.dbanotes.net/arch/yupoo_arch.html  帶寬：4000M/S (參考)  服務器數量：60 臺左右  Web服務器：Lighttpd, Apache, nginx  應用服務器：Tomcat  其餘：Python, Java, MogileFS 、ImageMagick 等  關於 Squid 與 Tomcat  Squid 與 Tomcat 彷佛在 Web 2.0 站點的架構中較少看到。我首先是對 Squid 有點疑問，對此阿華的解釋是"目前暫時還沒找到效率比 Squid 高的緩存系統，原來命中率的確不好，後來在 Squid 前又裝了層 Lighttpd, 基於 url 作 hash, 同一個圖片始終會到同一臺 squid 去，因此命中率完全提升了" 對於應用服務器層的 Tomcat，如今 Yupoo! 技術人員也在逐漸用其餘輕量級的東西替代，而 YPWS/YPFS 如今已經用 Python 進行開發了。  名次解釋：  · YPWS--Yupoo Web Server YPWS 是用 Python開發的一個小型 Web 服務器，提供基本的 Web 服務外，能夠增長針對用戶、圖片、外鏈網站顯示的邏輯判斷，能夠安裝於任何有空閒資源的服務器中，遇到性能瓶頸時方便橫向擴展。 · YPFS--Yupoo File System 與 YPWS 相似，YPFS 也是基於這個 Web 服務器上開發的圖片上傳服務器。  【Updated: 有網友留言質疑 Python 的效率，Yupoo 老大劉平陽在 del.icio.us 上寫到 "YPWS用Python本身寫的，每臺機器每秒能夠處理294個請求, 如今壓力幾乎都在10％如下"】 圖片處理層  接下來的 Image Process Server 負責處理用戶上傳的圖片。使用的軟件包也是 ImageMagick，在上次存儲升級的同時，對於銳化的比率也調整過了(我我的感受，效果的確好了不少)。」Magickd「 是圖像處理的一個遠程接口服務，能夠安裝在任何有空閒 CPU資源的機器上，相似 Memcached的服務方式。 咱們知道 Flickr 的縮略圖功能原來是用 ImageMagick 軟件包的，後來被雅虎收購後出於版權緣由而不用了（?）；EXIF 與 IPTC Flicke 是用 Perl 抽取的，我是很是建議 Yupoo! 針對 EXIF 作些文章，這也是潛在產生受益的一個重點。 圖片存儲層  原來 Yupoo! 的存儲採用了磁盤陣列櫃，基於 NFS 方式的，隨着數據量的增大，」Yupoo! 開發部從07年6月份就開始着手研究一套大容量的、能知足 Yupoo! 從此發展須要的、安全可靠的存儲系統「，看來 Yupoo! 系統比較有信心，也是滿懷期待的，畢竟這要支撐以 TB 計算的海量圖片的存儲和管理。咱們知道，一張圖片除了原圖外，還有不一樣尺寸的，這些圖片統一存儲在 MogileFS 中。 對於其餘部分，常見的 Web 2.0 網站必須軟件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面採用很多相對比較成熟的開源軟件，一方面也在自行開發定製適合本身的架構組件。這也是一個 Web 2.0 公司所必須要走的一個途徑。 很是感謝一下 Yupoo! 阿華對於技術信息的分享，技術是共通的。下一個能爆料是哪家?  --EOF--  lighttpd+squid這套緩存是放在另一個機房做爲cdn的一個節點使用的，圖中沒描繪清楚，給你們帶來不便了。  squid前端用lighttpd沒用nginx，主要是用了這麼久，沒出啥大問題，因此就沒想其餘的了。  URL Hash的擴展性的確很差，能作的就是不輕易去增減服務器，咱們目前是5臺服務器作一組hash.  咱們如今用Python寫的Web Server，在效率方面，我能夠給個測試數據，根據目前的訪問日誌模擬訪問測試的結果是1臺ypws,平均每秒處理294個請求(加載全部的邏輯判斷)。 在可靠性上，還不沒具體的數據，目前運行1個多月尚未任何異常。  lvs每一個節點上都裝nginx，主要是爲了反向代理及處理靜態內容，不過apache已顯得不是那麼必需，準備逐漸去掉。  咱們處理圖片都是即時的，咱們目前半數以上的服務器都裝了magickd服務，用來分擔圖片處理請求。  http://www.dbanotes.net/review/tailrank_arch.html  天天數以千萬計的 Blog 內容中，實時的熱點是什麼? Tailrank 這個 Web 2.0 Startup 致力於回答這個問題。  專門爆料網站架構的 Todd Hoff 對 Kevin Burton 進行了採訪。因而咱們能瞭解一下 Tailrank 架構的一些信息。每小時索引 2400 萬的 Blog 與 Feed，內容處理能力爲 160-200Mbps，IO 寫入大約在10-15MBps。每月要處理 52T 之多的原始數據。Tailrank 所用的爬蟲如今已經成爲一個獨立產品：spinn3r。 服務器硬件  目前大約 15 臺服務器，CPU 是 64 位的 Opteron。每臺主機上掛兩個 SATA 盤，作 RAID 0。據我所知，國內不少 Web 2.0 公司也用的是相似的方式，SATA 盤容量達，低廉價格，堪稱不二之選。操做系統用的是 Debian Linux 。Web 服務器用 Apache 2.0，Squid 作反向代理服務器。 數據庫  Tailrank 用 MySQL 數據庫，聯邦數據庫形式。存儲引擎用 InnoDB， 數據量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些 多核模式下互斥鎖的問題(This Bug?)。到數據庫的JDBC 驅動鏈接池用 lbpool 作負載均衡。MySQL Slave 或者 Master的複製用 MySQLSlaveSync 來輕鬆完成。不過即便這樣，還要花費 20％的時間來折騰 DB。 其餘開放的軟件  任何一套系統都離不開合適的 Profiling 工具，Tailrank 也不利外，針對 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是開放的。 Tailrank 的一個比較大的競爭對手是 Techmeme，雖然兩者暫時看面向內容的側重點有所不一樣。其實，最大的對手仍是本身，當須要挖掘的信息量愈來愈大，若是精準並及時的呈現給用戶內容的成本會愈來愈高。從如今來看，Tailrank 離預期目標還差的很遠。期待羅馬早日建成 YouTube架構學習  關鍵字: YouTube  原文: YouTube Architecture  YouTube發展迅速，天天超過1億的視頻點擊量，但只有不多人在維護站點和確保伸縮性。  平臺  Apache  Python  Linux(SuSe)  MySQL  psyco，一個動態的Python到C的編譯器  lighttpd代替Apache作視頻查看  狀態  支持天天超過1億的視頻點擊量  成立於2005年2月  於2006年3月達到天天3千萬的視頻點擊量  於2006年7月達到天天1億的視頻點擊量  2個系統管理員，2個伸縮性軟件架構師  2個軟件開發工程師，2個網絡工程師，1個DBA  處理飛速增加的流量  Java代碼  1. while (true)  2. {  3. identify_and_fix_bottlenecks();  4. drink();  5. sleep();  6. notice_new_bottleneck();  7. }  while (true)  {  identify_and_fix_bottlenecks();  drink();  sleep();  notice_new_bottleneck();  }  天天運行該循環屢次  Web服務器  1，NetScaler用於負載均衡和靜態內容緩存  2，使用mod_fast_cgi運行Apache  3，使用一個Python應用服務器來處理請求的路由  4，應用服務器與多個數據庫和其餘信息源交互來獲取數據和格式化html頁面  5，通常能夠經過添加更多的機器來在Web層提升伸縮性  6，Python的Web層代碼一般不是性能瓶頸，大部分時間阻塞在RPC  7，Python容許快速而靈活的開發和部署  8，一般每一個頁面服務少於100毫秒的時間  9，使用psyco(一個相似於JIT編譯器的動態的Python到C的編譯器)來優化內部循環  10，對於像加密等密集型CPU活動，使用C擴展  11，對於一些開銷昂貴的塊使用預先生成並緩存的html  12，數據庫裏使用行級緩存  13，緩存完整的Python對象  14，有些數據被計算出來併發送給各個程序，因此這些值緩存在本地內存中。這是個使用不當的策略。應用服務器裏最快的緩存將預先計算的值發送給全部服務器也花不了多少時間。只需弄一個代理來監聽更改，預計算，而後發送。 視頻服務  1，花費包括帶寬，硬件和能源消耗  2，每一個視頻由一個迷你集羣來host，每一個視頻被超過一臺機器持有  3，使用一個集羣意味着：  -更多的硬盤來持有內容意味着更快的速度  -failover。若是一臺機器出故障了，另外的機器能夠繼續服務  -在線備份  4，使用lighttpd做爲Web服務器來提供視頻服務：  -Apache開銷太大  -使用epoll來等待多個fds  -從單進程配置轉變爲多進程配置來處理更多的鏈接  5，大部分流行的內容移到CDN：  -CDN在多個地方備分內容，這樣內容離用戶更近的機會就會更高  -CDN機器常常內存不足，由於內容太流行以至不多有內容進出內存的顛簸  6，不太流行的內容(天天1-20瀏覽次數)在許多colo站點使用YouTube服務器  -長尾效應。一個視頻能夠有多個播放，可是許多視頻正在播放。隨機硬盤塊被訪問  -在這種狀況下緩存不會很好，因此花錢在更多的緩存上可能沒太大意義。  -調節RAID控制並注意其餘低級問題  -調節每臺機器上的內存，不要太多也不要太少  視頻服務關鍵點  1，保持簡單和廉價  2，保持簡單網絡路徑，在內容和用戶間不要有太多設備  3，使用經常使用硬件，昂貴的硬件很難找到幫助文檔  4，使用簡單而常見的工具，使用構建在Linux裏或之上的大部分工具  5，很好的處理隨機查找(SATA，tweaks)  縮略圖服務  1，作到高效使人驚奇的難  2，每一個視頻大概4張縮略圖，因此縮略圖比視頻多不少  3，縮略圖僅僅host在幾個機器上  4，持有一些小東西所遇到的問題：  -OS級別的大量的硬盤查找和inode和頁面緩存問題  -單目錄文件限制，特別是Ext3，後來移到多分層的結構。內核2.6的最近改進可能讓Ext3容許大目錄，但在一個文件系統裏存儲大量文件不是個好主意  -每秒大量的請求，由於Web頁面可能在頁面上顯示60個縮略圖  -在這種高負載下Apache表現的很是糟糕  -在Apache前端使用squid，這種方式工做了一段時間，可是因爲負載繼續增長而以失敗了結。它讓每秒300個請求變爲20個  -嘗試使用lighttpd可是因爲使用單線程它陷於困境。遇到多進程的問題，由於它們各自保持本身單獨的緩存  -如此多的圖片以至一臺新機器只能接管24小時  -重啓機器須要6-10小時來緩存  5，爲了解決全部這些問題YouTube開始使用Google的BigTable，一個分佈式數據存儲：  -避免小文件問題，由於它將文件收集到一塊兒  -快，錯誤容忍  -更低的延遲，由於它使用分佈式多級緩存，該緩存與多個不一樣collocation站點工做  -更多信息參考Google Architecture，GoogleTalk Architecture和BigTable  數據庫  1，早期  -使用MySQL來存儲元數據，如用戶，tags和描述  -使用一整個10硬盤的RAID 10來存儲數據  -依賴於信用卡因此YouTube租用硬件  -YouTube通過一個常見的革命：單服務器，而後單master和多read slaves，而後數據庫分區，而後sharding方式  -痛苦與備份延遲。master數據庫是多線程的而且運行在一個大機器上因此它能夠處理許多工做，slaves是單線程的而且一般運行在小一些的服務器上而且備份是異步的，因此slaves會遠遠落後於master -更新引發緩存失效，硬盤的慢I/O致使慢備份  -使用備份架構須要花費大量的money來得到增長的寫性能  -YouTube的一個解決方案是經過把數據分紅兩個集羣來將傳輸分出優先次序：一個視頻查看池和一個通常的集羣 2，後期  -數據庫分區  -分紅shards，不一樣的用戶指定到不一樣的shards  -擴散讀寫  -更好的緩存位置意味着更少的IO  -致使硬件減小30%  -備份延遲下降到0  -如今能夠任意提高數據庫的伸縮性  數據中心策略  1，依賴於信用卡，因此最初只能使用受管主機提供商  2，受管主機提供商不能提供伸縮性，不能控制硬件或使用良好的網絡協議  3，YouTube改成使用colocation arrangement。如今YouTube能夠自定義全部東西而且協定本身的契約  4，使用5到6個數據中心加CDN  5，視頻來自任意的數據中心，不是最近的匹配或其餘什麼。若是一個視頻足夠流行則移到CDN  6，依賴於視頻帶寬而不是真正的延遲。能夠來自任何colo  7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時  8，使用BigTable將圖片備份到不一樣的數據中心，代碼查看誰是最近的  學到的東西  1，Stall for time。創造性和風險性的技巧讓你在短時間內解決問題而同時你會發現長期的解決方案  2，Proioritize。找出你的服務中核心的東西並對你的資源分出優先級別  3，Pick your battles。別怕將你的核心服務分出去。YouTube使用CDN來分佈它們最流行的內容。建立本身的網絡將花費太多時間和太多money  4，Keep it simple！簡單容許你更快的從新架構來回應問題  5，Shard。Sharding幫助隔離存儲，CPU，內存和IO，不只僅是得到更多的寫性能  6，Constant iteration on bottlenecks：  -軟件：DB，緩存  -OS：硬盤I/O  -硬件：內存，RAID  7，You succeed as a team。擁有一個跨越條律的瞭解整個系統並知道系統內部是什麼樣的團隊，如安裝打印機，安裝機器，安裝網絡等等的人。With a good team all things are possible。 http://hideto.javaeye.com/blog/130815