網站架構之性能優化(轉)


網站從構建之初的很少有人問津,用戶數量較少,並發量較低,到之后的擁有千萬上億用戶,數萬量級的高並發,之間經歷了怎樣的過程,小型網站架構是怎樣逐步演化的,本文簡單探討下這方面的內容,主要參考《大型網站架構設計》,這本書知識點總結的還是比較全面的。

1. 初始階段

網站開始是沒有太多訪問量的,只需一台服務器就綽綽有余了,應用程序,數據庫,靜態資源等全部都在一台服務器上,一般使用LAMP/LNMP(Linux+Apache/Nginx+MySQL+PHP/Python等)就可以實現自己的網站了,具體架構如下所示:

2. 應用服務與數據服務分離

隨着網站業務的發展,用戶訪問量的增加,存儲數據的增長,單台服務器逐漸不能滿足需求,需要將應用服務與數據服務分離,具體如下圖所示:

由於負責提供的服務不同,每台服務器對硬件資源的需求是不同的,具體如下所示:

不同服務所需資源表
服務器類型 處理業務 所需資源
應用服務器 處理所有業務邏輯 更快、更多CPU
文件服務器 存儲用戶上傳文件或服務自身所需文件資源 更大的磁盤空間
數據庫服務器 做數據緩存以及進行數據檢索 更大的內存以及更快的磁盤

 

 

 

 

 

 

3. 緩存

隨着用戶逐漸增多,數據庫壓力太大,導致訪問延遲,影響用戶體驗,而網站性能優化最優先考慮的就是緩存;

網站訪問特點所遵循的二八定律:80%的業務訪問集中在20%的數據上;

 網站使用緩存又可分為應用服務器本地緩存和遠程分布式緩存,遠程分布式緩存一般可采用集群的方式部署,對服務器內存有比較高的要求,具體如下圖所示:

4. 應用服務器集群部署

隨着訪問量進一步增大,單台應用服務器已逐漸不能應對越來越多的請求連接,單台服務器硬件資源再強,也會逐漸滿足不了業務高峰時的負載壓力;

網站解決高並發、海量數據問題最常用的手段還是使用集群,做橫向擴展,集群可以很好地滿足伸縮性;

負載均衡服務器實現可以有比較多的方案,LVS,Nginx,F5等,可以和HA軟件,如Heartbeat與Keepalived等一起使用;

通過應用服務器集群部署,使用負載均衡調度器,可以將用戶的請求分發到多台應用服務器集群中的任一台機器上,而且根據用戶訪問量的多少,可以很容易增刪服務器,是每台服務器負載都在可接受范圍之內,具體如下圖所示:

5. 數據庫讀寫分離

對於緩存沒命中和緩存過期的數據,仍需要從數據庫中來讀取,並且所有寫操作也都需要訪問數據庫,數據庫壓力還是會隨着訪問量增加而增大;

可采用主從熱備的方案,實現讀寫分離,例如mysql的master-slave模式,當讀操作量級更高時,還可采用一主多從的方式來實現;

應用程序中的數據訪問模塊需要保證數據庫的讀寫分離對應用透明; 

具體如下圖所示:

6. 使用CDN和反向代理加速網站

中國網絡環境復雜,不同地區用戶訪問相同網站,速度差別較大,而網站訪問延時和用戶流失率正相關;

主要加速網站訪問速度,減輕后端服務器負載壓力的方式就是使用CDN和反向代理;

CDN和反向代理的基本原理都是緩存

CDN部署在網絡提供商的機房,緩存網站的一些熱點靜態資源,用戶在請求網站服務時,從距離自己最近的網絡提供商機房獲取數據,如視頻、圖片等;

反向代理部署在網站的中心機房,屬於網站前端架構的一部分,當用戶請求到達中心機房后,首先訪問反向代理服務器,如果緩存着用戶請求的資源(靜態),就直接返回;

反向代理比較成熟的開源軟件:Squid、Varnish,推薦使用Varnish,從穩定性、訪問速度、並發連接數目比較來看,Varnish都更強大一點;

使用緩存的前提條件:
1. 數據訪問熱點不均衡,某些數據會被頻繁訪問;
2. 數據在某個時間段內有效,不會很快過期,否則可能造成緩存數據已經失效,產生臟讀,影響結果正確性

具體如下圖所示:

7. 分布式文件系統和分布式數據庫系統

 隨着業務量的增長,網站最常用的數據庫拆分是按業務分庫,將不同業務的數據庫部署在不同的服務器上;

一般分布式數據庫是網站數據庫拆分的最后手段,只有在單表規模非常龐大的時候才使用;

具體如下圖所示:

8. 使用NoSQL和搜索引擎

全文檢索對於大型網站來說已成為不可或缺的一部分,例如Lucene、Solr等;

對非格式化的數據使用NoSQL存儲更為方便,NoSQL也更適合大數據計算,較為流行的NoSQL數據庫有HBase、MongoDB、CouchDB、Redis、Cassandra等;

不同NoSQL數據庫使用的存儲方式不同,例如Redis,Memcache等采用的是Key/Value鍵值對存儲,MongoDB,CouchDB等采用的是按文檔存儲,一條記錄中所有數據都存儲在文檔中,HBase,Cassandra等采用的是列存儲;

具體如下圖所示:

9. 按業務拆分

網站在發展壯大之后,往往包含了多種復雜的業務場景,使用分而治之的手段將整個網站業務分成不同的產品線,將網站拆分成多個不同的應用,每個應用獨立部署維護,應用之間可以通過超鏈接、消息隊列等關聯起來,具體如下圖所示:

10. 分布式服務

在上面業務拆分的基礎上,將一些公共的業務抽取出來,獨立部署,如給用戶管理、商品管理等,這些可復用的業務連接數據庫,提供公共服務,而應用系統只需管理用戶界面;

具體如下圖所示:

分布式主要還是為了解決高並發問題,但也引入了一些其他問題:
1. 服務調用必須通過網絡,可能會對性能造成較大影響;
2. 服務器越多,故障概率越大,一台服務器宕機可能會導致連鎖反應(滾雪球效應),導致很多應用不可訪問,網站可用性降低,設計時應盡量避免;
3. 數據在分布式環境保持數據一致性也比較困難,分布式事務難以保證,這對網站業務正確性和業務流程可能造成影響;
4. 導致網站依賴錯綜復雜,開發管理維護困難;

簡單總結

驅動網站技術發展的主要力量永遠是網站業務的發展;
網站都是逐漸演化而來的,根據需要靈活應對才是最重要的;
技術是為了業務而服務的,永遠不要為了技術而技術;

轉自:http://www.cnblogs.com/pflee/p/4508232.htm


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com