大型網站技術架構探討

本文內容主要來自於浩東2011年6月的ppt。

目錄：

    一、大型網站架構的目標與挑戰

    二、網站架構演變及其技術脈絡

    三、架構設計理論與原則

 

何爲「大型」網站？

    沒有統一的判斷標準，流量大小是一個重要指標（日均流量至少IP>1,000,000纔算大型網站）

1、大型網站架構的目標與挑戰

每一個目標背後面臨着技術、設計、維護等諸多方面的挑戰； 而目標自己的指望值也會根據實際狀況進行調整，這也意味着網站架構建設是個不斷調整的過程。

2、網站架構演變及其技術脈絡

一、Web動靜態資源分離及其與DB物理分離

-->優勢：「簡單」、安全性提升

-->缺點：存在單點，談不上高可用性（high availability架構目標）

-->技術點：應用設計要保證可擴展（framework很重要Spring/Beetle）、Web Server動/靜態資源分離

               Web Server（Apache\Nginx\IIS\JBoss…）、

               Database Server（Mysql\Oracle\Redis…）

注意：通常地，本文提到的物理服務器都是泛指pc級物理服務器；Web Server泛指HTTP服務器和應用服務器綜合體對於一個試水性網站來講爲了節約成本，Web Server和DB Server都放在同一臺pc Server服務器上是常見的事情。當網站訪問量增大，cpu處理能力是瓶頸的時候，經過把web Server和Db Server簡單物理分開的，效果明顯！

web動靜態資源分離：

-->img,doc,js,css等靜態資源使用單獨的Web HTTP Server處理請求

-->動態頁面靜態化處理                                                

二、採起緩存處理

訪問量持續增大，頁面響應愈來愈慢。考慮到網站還處在試水性成長階段，節約成本，硬件不動，着重應用自己優化。採起緩存處理機制是個必然的選擇。

-->優勢：簡單有效、維護方便

-->缺點：依然存在單點

-->技術點：客戶端（瀏覽器）緩存、前端頁面緩存、頁面片斷緩存、本地數據緩存/數據庫緩存

    (1) 客戶端（瀏覽器）緩存

          可以讓瀏覽器緩存的數據必定要緩存；瀏覽器可以處理的運算，決不放在服務器端來處理。

         （1.1）根據HTTP協議特性，修改Header參數（Cache-Control、Expires、Pragma、Last-Modified、Etag），讓瀏覽器來緩存頁面（一些優秀開發框架會對此作透明的封裝，例如：Beetle） http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

         （1.2）使用HTTP1.1協議，因爲http pipelining技術特性，可以使用get請求的決不採起post請求

         （1.3）爲了節約帶寬，壓縮頁面（Content-Encoding: gzip）；頁面各個元素能「小」即「小」，例如：js包壓縮，js合併，圖片壓縮等

         （1.4）會話狀態信息採起Cookie代替傳統使用服務器Sessions對象存儲習慣作法；使用Ajax實現頁面局部刷新

         （1.5）若是可能，可採起瀏覽器插件技術突破瀏覽器功能限制，將本來在服務器端運算，儘可能遷到瀏覽器端。ActiveX/Applet/Flash/….HTML5   （ 最值得期待，她的出現一定改變整個Web世界）

    （2）前端頁面緩存

    訪客向網站發出訪問請求,由前端頁面緩存器負擔原服務器的處理進程作出響應,獲取原服務器的相應網頁內容,將其儲存在自身的內存中,與 此同時,傳送給訪客這一緩存的內容;若有另外一訪客也請求訪問以前的相同內容,前端頁面緩存器毋須再次獲取原服務器上的相應內容,而直接從自身的內存中獲取,將這一內容傳送給訪客。反之,前端頁面緩存器也可緩存訪客的GET和POST請求。　　    訪客實際面對的是前端頁面緩存器,與網站之間的通信徹底由前端頁面緩存器反向代理,而非原服務器直接響應訪客,這將大大加快訪客上網流暢度,有效提高訪問量,顯著下降帶寬佔用,減輕原始服務器的繁忙度,加快響應速度,毋須不停地購置大內存,大硬盤,擴容電力設施爲服務器端節省成本。

注意：採用具有緩存功能的http反向代理服務器做前端頁面緩存器，Varnish\Squid\Ncache\AiCache(商業)…【硬件F5】

    （3）頁面片斷緩存ESI(Edge Side Includes)

ESI是一個基於XML的標記語言，目的是在HTTP中組裝各類資源。在實際環境中，一個動態生成的頁面，當中可能只有少許的內容是頻繁變化的或是個性化的，對於傳統的Cache服務器來講，爲了可以保證頁面的時效性，卻因爲頁面中這些少許的動態內容而沒法將整個頁面進行緩存。ESI經過使用簡單的標記語言來對那些能夠緩存和不能緩存的網頁中的內容片段進行描述，每一個網頁都被劃分紅不一樣的小部分分別賦予不一樣的緩存控制策略，使Cache服務器能夠根據這些策略在將完整的網頁發送給用戶以前將不一樣的小部分動態地組合在一塊兒。經過這種控制，能夠有效地減小從服務器抓取整個頁面的次數，而只用從原服務器中提取少許的不能緩存的片段，所以能夠有效下降原服務器的負載，同時提升用戶訪問的響應時間。

ESI須要服務器端支持，常見apache(mod_esi)、WebLogic、JSP標籤庫(JESI)等。

    （4）本地數據緩存

          （4.1）關係數據庫系統（如：Oracle\MySql）Query Cache策略：通常以sql爲key來緩存查詢結果，儘可能不要拼sql，使用PreparedStatement的「？」模式sql；Query Cache大小要根據數據庫系統具體狀況合理設置，過大隻會浪費內存，參考值：128M

          （4.2）關係數據庫系統Data Buffer策略：就是數據庫數據內存緩存器，其訪問命中率決定數據庫性能，可根據實際物理內存大小適量增大，如：MySql建議buffer值爲物理內存60-80%

          （4.3）應用服務器Cache包括：對象緩存（例如：對象線程安全，作成單例），更新頻率不大數據考慮緩存（如：基表數據、配置文件信息），考慮使用線程池，對象池，鏈接池等

          （4.4）常見java解決方案：map\OSCache\EHCache等

注意：一、須要從數據庫系統和Web應用服務器兩個層面考慮緩存優化

         二、常見緩存算法：（貝萊蒂算法、最近最少使用算法、最近最頻繁使用算法、僞LRU算法）

三、增長機器作HA、數據庫讀寫分離

-->優勢：增長服務器和HA機制，系統性能及可用性獲得保證

-->缺點：讀寫分離，增長程序難度，架構變複雜，維護難度增長

-->技術點：負載均衡、DAL、數據庫讀寫分離

   （1）負載均衡

LVS（LVS集羣採用IP負載均衡技術和基於內容請求分發技術。調度器具備很好的吞吐率，將請求均衡地轉移到不一樣的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，並且無需修改客戶端和服務器端的程序）

       （2）數據庫讀寫分離及DAL

各個關係數據庫廠商針對dal及replication都有本身方案

獨立的DAL Proxy服務器（MySQL: mysqlproxy,Amoeba；PostgreSQL: PL/Proxy ）

DAL API（Java: Hibernate Shard,Ibatis Shard,HiveDB,Guzz；Python: Pyshards）

 

四、CDN、分佈式緩存、分庫

網站業務發展迅速，數據量大幅增大是當前最大的挑戰，用戶分散各地區，某些地方用戶訪問響應很慢，影響體驗和業務發展；同時，因爲數據量過大，數據緩存在本地內存已經不現實，分佈式緩存是必然選擇了

-->優勢：異地緩存有效解決不一樣地方用戶訪問過慢的問題；分庫策略帶來網站性能總體提高

-->缺點：成本大幅增長，架構進一步複雜化，也維護難度進一步增大，架構開始臃腫了

-->技術點：CDN、分佈式緩存、Shard分庫

 

    （1）CDN

CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是經過在現有的Internet中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡"邊緣"，使用戶能夠就近取得所需的內容，解決 Internet網絡擁擠的情況，提升用戶訪問網站的響應速度。從技術上全面解決因爲網絡帶寬小、用戶訪問量大、網點分佈不均等緣由所形成的用戶訪問網站響應速度慢的問題。 (也就是一個服務器的內容，平均分部到多個服務器上，服務器智能識別，讓用戶獲取離用戶最近的服務器，提升速度。

   （2）分佈式緩存

-->本地緩存性能優秀，但容量有限，無伸縮性

-->採用分佈式緩存方案突破容量限制，具有良好伸縮性；但分佈式涉及遠程網絡通訊消耗其性能本地緩存來得優秀，並可涉及節點狀態維護及數據複製問題，其穩定性和可靠性是個挑戰。

-->目前流行分佈式緩存方案：memcached、membase、redis等，基本上當前的NoSQL方案均可以用來作分佈式緩存方案

 

    （3）分庫

垂直分區和水平分區兩種。

垂直分庫後，各模塊數據之間如何關聯查詢？垂直分庫前提是良好的鬆耦合的模塊化設計

水平分區中，Shard是分佈式解決方案，與數據庫集中式的表空間分區是兩個不一樣方案（分片Key識別（劃分檢索依據）是關鍵）

 

五、多個數據中心，向分佈式存儲和計算的架構體系邁進

-->優勢：多數據中心，帶來更高質量區域服務體驗；分佈式存儲及計算架構有效解決pb級數據量存儲、檢索及計算性能問題

-->缺點：架構複雜、數據同步、一致性及系統維護、技能要求等成本十分高

-->技術點：分佈式文件系統、Map/Reduce、Key-Value存儲

 

    （1）分佈式存儲計算解決方案[DFS、Map/Reduce、Key-Value DB]

DFS提供了一個全局命名空間的高可用（經過跨機器（和跨機架）的文件數據複製來達到高可用性，免受傳統文件存儲系統沒法避免的許多失敗的影響）文件系統，解決高容量數據高效、可靠存儲問題；Map/Reduce的計算框架，它與DFS緊密協做，幫助處理收集到的海量數據;Key-Value DB代替傳統的數據庫，經過一些主鍵來組織海量數據，並實現高效的查詢。

-->DFS分佈式文件系統，如：Lustre\HDFS\GFS\TFS\FreeNas等

-->Map/Reduce算法（計算框架），基本上現有NoSQL數據庫中都支持此算法。

-->Key-Value DB，也做爲NoSQL解決方案，如：BigTable\Tair\Hbase\ HyperTable等

-->提供完整解決方案：

   Google(GFS|Map/Reduce|BigTable)

   Apache Hadoop(HDFS|Map/Reduce|HBase)

 

3、架構設計理論與原則

一、關於數據一致性—ACID vs BASE

-->ACID（ Atomicity 、 Consistency 、 Isolation 、 Durability ）是關係型數據庫的最基本原則，遵循ACID原則強調一致性，對成本要求很高，對性能影響很大。

-->BASE（ Basically Available 、 Soft state 、 Eventually consistent ）策略(注意：ACID原則適用於互聯網應用嗎？可用性彷佛比一致性重要些；BASE策略與ACID不一樣，其基本思想就是經過犧牲強一致性，以得到更好的可用性或可靠性)

二、關於分佈式系統—CAP理論

CAP理論指出，一個分佈式系統只能知足如下兩個指標

三、ED-SOA架構

四、架構進化與退化