架構的變遷

1、背景

    目前正在作的事大部分與數據處理、機器學習、天然語言處理相關，一直想對web進行一些總結，一是想回顧一下這些年web架構的變遷，二是想記錄下來方便往後查看。

2、架構的變遷

    軟件架構有C/S和B/S之分。C/S即client/server，用客戶端與服務端來交互，咱們用到大部分桌面軟件都是c/s模式的。B/S即browser/server，用瀏覽器與服務端進行交互，咱們經過瀏覽器訪問的網站基本都是b/s模式的，如淘寶網、百度等等。c/s模式因爲升級維護不方便，因此大部分大型應用都會採用b/s架構。下面來談談b/s架構的變遷。

    一、靜態網頁

    網頁的組成都是靜態的html，用戶量也不大，網站的發佈也不須要web容器，前面加一個http代理就能夠了，靜態網頁內容固定，數據固定，要變動內容必須從新編寫，知足不了業務的日益增加。

    二、單節點動態網頁

    動態網頁本質上就是根據數據來動態拼裝web頁面，這種模式可讓web系統適應複雜多變的業務。因而用web容器和數據庫構成了以下的架構：

   

    三、web集羣

    隨着應用受到用戶的喜好，用戶量也增多了，訪問量持續增大，一個web節點支撐不了訪問量，因而就有了web集羣，固然web集羣須要解決一些問題，如session共享、定時job集羣等問題。那麼架構就變成了負載均衡後面跟着多個web節點的這種模式。

  

    四、cache緩衝

    web節點增長了，能夠抵禦大部分流量了，但是咱們又發現數據庫這一層扛不住了，因而就有了緩衝方案，在db與應用節點之間加一個單節點cache，去緩存一些不隨意變更且訪問量大的熱數據，緩存沒命中，才走數據庫查詢，優秀的cache服務有memcache、redis等等，因而架構進一步演變。

    

    五、分佈式cache

    隨後發現大量請求涌向這個單節點cache，數據存取比較快，IOPS也上去了，可是有帶來了新的問題，這個cache節點的網卡吃不消了，那麼怎麼辦呢？加機器，橫向擴展唄，分佈式唄，分而治之。怎麼個加法，因而有一致性hash，那麼架構就是這樣子。

       

    六、線程內緩存

    隨着請求量的持續增大，最後仍是發現cache節點的網卡又爆了，那麼就出現了二級緩存，緊貼着web容器作一層線程內緩存，優秀的線程內緩存有ehcache等，圖就不畫了。

    七、讀寫分離

    隨着用戶數的激增，單節點數據庫最終仍是敗下陣來，可是咱們會發現，讀的請求會比寫請求要多的多，這種場景下，咱們是否是也能夠效仿web集羣橫向擴展呢，這時橫向擴展會有點不同，一臺主節點負責寫請求，多臺從節點負責讀請求，從節點同步主節點的數據，因而讀寫分離就產生了，架構就變成了這樣。

     

    八、分庫分表

    隨着應用的龐大，用戶量持續增大，數據庫的數據量急速增加，單表數據量爆增，B+樹的索引性能直線降低，查詢速度急劇降低，儘管咱們會放棄範式，對字段進行單表冗餘，最終仍是敵不過數據的激增。那麼接下來採用的方案是分庫分表，把一張大表拆成多個小表。分庫分表的思路不少：

    （1）、service層硬編碼，這種方式侵入性很強，業務關聯緊密，開發量大

    （2）、Dao層實現，相比service層實現少了業務關聯，可是大量sql要改寫、開發量依然巨大

    （3）、JDBC層實現，這種方式基於ORM層之下，攔截SQL解析改寫，多線程執行，而後歸併結果集。這種方式對開發透明，開發改造量不多，比較推薦的是這種方式。基於jdbc的分庫分表框架有當當的sharding-jdbc等等。

    因而架構演變成以下的模式。

    

    九、SOA化

    業務的規模已經讓融合在一塊兒的工程變得十分臃腫，build一次要幾分鐘，開發變成了很大問題，另外業務應該抽象出來，變成獨立的服務，精細化的分工，能夠更容易的有的放矢的抵禦更大的流量。因此便有了面向服務的架構。各個業務之間以遠程服務的方式調用。服務器實現的方式不少，如RMI、Rest、Http等等，優秀的服務化框架如dubbo、Spring Cloud等等。經過這些優秀的框架，應用就能夠被拆成小服務，服務於服務之間經過網絡相互調用。服務化框架要解決的問題有不少，如序列化（枚舉、數組怎麼序列化）、傳輸協議、負載均衡、IO模式選擇等等。圖這裏就略去了。

    十、關於數據

    第8點中，提到放棄範式作冗餘，當數據量大到索引都失效的時候，咱們惟一能夠查詢的就是主鍵了，那麼就產生了HBase這種列式存儲的解決方案，只提供一種基於rowkey的查詢，而後數據分region存儲，只有rowkey設計合理，也能夠很好的知足業務。

    還有，當B+樹索引失效的時候，咱們會把目光更多的轉向倒排索引，如Lucene，還有基於Lucene的Solr或者elasticsearch。

3、結束語

    從應用到緩存再到數據庫，抵禦大流量高併發，解決問題的終極思想是「分而治之」，因此最終構成一個大型應用的各個部分都走向了分佈式……

 

快樂源於分享。

此博客乃做者原創， 轉載請註明出處