大型網站及架構演進過程

目錄

• 大型網站及架構演進過程
  • 大型網站的定義
  • 架構演進
  • 關於負載均衡session的解決方案
  • 讀取性能的優化

大型網站及架構演進過程

標籤（空格分隔）： 讀書筆記

---

*經過前面的介紹，咱們已經瞭解了分佈式系統的相關知識，下面看一下大型網站架構演化及怎麼用這個集羣的。

大型網站的定義

看這個的我想都是有些經驗的人了，就不囉嗦了，大型網站就是訪問量&數據量都很大，必須同時具有這兩個條件才能夠，你整一堆靜態頁面 天天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會話管理服務器掛了。整個應用就會受到影響。

讀取性能的優化

數據庫優化

分庫/分表/分區：這裏建議採用分區操做，對sql比較友好，對orm層也沒有變化。分表分庫應爲最後的優化手段，畢竟對數據層代碼有影響。並且會存在分佈式事務這個大麻煩。
讀寫分離：讀庫與寫庫分開，如今各類數據庫都有這種技術，只不過相應的來講，會有必定的延時性。可是性能提高是比較大的。

搜索

對於站內搜索，若是數據量比較大，可使用作一個搜索組件來代替like,畢竟like效率不是很高。

緩存

對於常常須要讀不多改的數據，能夠經過緩存來提升讀取的性能。這部分就不用多說了，主要就是ehcache/redis等各類cache組件。
另外一個緩存的應用就是緩存頁面，把常常訪問的動態頁面緩存起來，直接讀取緩存，減少服務器的開銷。好比ehcahce就能夠緩存頁面。
緩存使用的好很差的一個指標就是：緩存命中率，若是命中率很低，須要調整代碼結構。

總結
總的來講，全部的架構都是經歷了從如下這個階段
1.webapp&database:應用與數據庫在一臺機器上(all in one)。
2.webapp+database:分離數據庫與應用，提升數據讀寫性能。
3.nginx+nwebapp+database：負載均衡+多個應用服務器+數據庫。
4.nginx+nwebapp+cache+database：基於第3次改變，增長緩存設置，提升讀取性能。
5.nginx+nwebapp+cache+ndatabase:添加多個數據庫，實現讀寫分離，提升讀取性能。
6.基於5的基礎上，對數據庫進行改造，包括分表分庫分區或使用第三方的軟件（mycat等）來加強數據庫性能。同時對webapp進行拆分，拆分出多個服務中心，每一個服務中心負責專門的業務。期間涉及到的技術有(包括但不限於):redis/avtivemq(消息中間件)/mycat/zookeeper/nosql等

其實對於大型網站來講，主要問題就是 1.服務的管理：這個比較麻煩，若是服務多了之後各類接口的調用及服務狀態的監控 2.io：對於如今狀況來看，咱們服務的主要瓶頸仍是集中在io層。主要是數據庫的讀寫比較耗費時間，因此解決了這個問題，我想應用的速度是能夠更上一層樓的。包括利用適合ssd的數據庫，記得國外有個這樣的數據庫。還有好的中間件，如今的中間件都有較大的性能損耗（30%）。