大型網站及架構演進過程

JeannetteKQ 8年前發布 | 14K 次閱讀 軟件架構 數據庫

來自: http://www.cnblogs.com/-10086/p/5179307.html

 

*通過前面的介紹,我們已經了解了分布式系統的相關知識,下面看一下大型網站架構演化及怎么用這個集群的。

大型網站的定義

看這個的我想都是有些經驗的人了,就不啰嗦了,大型網站就是 訪問量&數據量 都很大,必須同時具備這兩個條件才可以,你整一堆靜態頁面 每天1000000000000000000000個人訪問也不能稱之為大型網站。只有當以上兩個條件都具備的情況下,你才會有高并發的問題,才需要一個集群來支撐你的業務。

架構演進

這方面的文章確實不少,給大家介紹幾個比較不錯的演進過程

宜人貸: http://www.jianshu.com/p/410250e006cb

精品博客(包含很多案例): http://www.hollischuang.com/archives/1036

關于負載均衡session的解決方案

關于負載均衡session問題的解決方案:

1.使用無狀態(cookie)的會話請求

缺點是

安全性:畢竟cookie是可見的。如果要實現安全的cookie就要在技術上改進,比如加密或每次生成一個token等方式來規避不安全問題。

cookie長度限制:這個無解

帶寬消耗及性能影響:每次請求都帶有session數據,還要解密及設置新token,相對來說肯定對性能有一定影響。

如果對安全性要求不是很高,還是可以選用這種方式。

2.ngxin使用ip輪詢的方式(不穩定)

缺點是當使用ip輪詢方式式,假如某一ip訪問的機器掛了。把這個ip定位到其他機器上,就沒有session了。以及nginx會變成一個有狀態的節點,內存消耗會更大(不過可以加內存嘛),但是容災會更麻煩。

3.session同步

現在主流的容器都有session同步功能,比如tomcat。

同步session造成網絡帶寬消耗,機器越多,消耗越大,相對來說性能也越差。

每臺機器都需要保存全部機器的session.這樣session數據占用的內容會很嚴重。

4.使用會話集中管理,如membercache來集中管理回話。

這種是比較常見的實現方式。比以上3種方式都要好,但是也有一定的缺點,比如session存儲需要遠程讀取,會有延時及不穩定性,不過一般我們集群都是部署在內網的,這點可以忽略。另一個問題就是要相應的做好session集中會話管理服務器的容災工作。假如沒有容災,session會話管理服務器掛了。整個應用就會受到影響。

</div>

讀取性能的優化

數據庫優化

分庫/分表/分區:這里建議采用分區操作,對sql比較友好,對orm層也沒有變化。分表分庫應為最后的優化手段,畢竟對數據層代碼有影響。而且會存在分布式事務這個大麻煩。讀寫分離:讀庫與寫庫分開,現在各種數據庫都有這種技術,只不過相應的來說,會有一定的延時性。但是性能提升是比較大的。

搜索

對于站內搜索,如果數據量比較大,可以使用做一個搜索組件來代替like,畢竟like效率不是很高。

緩存

對于經常需要讀很少改的數據,可以通過緩存來提高讀取的性能。這部分就不用多說了,主要就是ehcache/redis等各種cache組件。

另一個緩存的應用就是緩存頁面,把經常訪問的動態頁面緩存起來,直接讀取緩存,減小服務器的開銷。比如ehcahce就可以緩存頁面。

緩存使用的好不好的一個指標就是:緩存命中率,如果命中率很低,需要調整代碼結構。

總結

總的來說,所有的架構都是經歷了從以下這個階段

1.webapp&database:應用與數據庫在一臺機器上(all in one)。

2.webapp+database:分離數據庫與應用,提高數據讀寫性能。

3.nginx+n

webapp+database:負載均衡+多個應用服務器+數據庫。

webapp+cache+database:基于第3次改變,增加緩存設置,提高讀取性能。

5.nginx+n webapp+cache+n database:添加多個數據庫,實現讀寫分離,提高讀取性能。

6.基于5的基礎上,對數據庫進行改造,包括分表分庫分區或使用第三方的軟件(mycat等)來增強數據庫性能。同時對webapp進行拆分,拆分出多個服務中心,每個服務中心負責專門的業務。期間涉及到的技術有(包括但不限于):redis/avtivemq(消息中間件)/mycat/zookeeper/nosql等

</div>

</div>

其實對于大型網站來說,主要問題就是

1.服務的管理:這個比較麻煩,如果服務多了以后各種接口的調用及服務狀態的監控

2.io:對于現在情況來看,我們服務的主要瓶頸還是集中在io層。主要是數據庫的讀寫比較耗費時間,所以解決了這個問題,我想應用的速度是可以更上一層樓的。包括利用適合ssd的數據庫,記得國外有個這樣的數據庫。還有好的中間件,現在的中間件都有較大的性能損耗(30%)。

 本文由用戶 JeannetteKQ 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!