分佈式思惟概述

軟件-互聯網的發展史

大型主機優勢:

集中式的計算機系統，高的穩定性和安全性。

大型主機缺點:

1. 很是貴,通常的小企業用不起。
2. 比較複雜，培養人才的成本比較高。
3. 單點一旦故障,整個系統停轉,損失很是大。
4. 我的PC電腦的性能愈來愈高,成本也愈來愈低。

在這裏插入圖片描述

Web時代

c/s時代：

富客戶端方案。賣軟件可賺錢。qq、影音、遊戲。早期流行。

Web 1. 0

特點

主要是單向信息的發佈，即信息門戶---> 廣大瀏覽器客戶端互聯網內容是由少數編輯人員（或站長）定製的。 表明:三大門戶，新浪/網易/搜狐。新浪以新聞+廣告爲主，網易拓展遊戲爲主，搜狐延伸門戶矩陣。

通常的雛型以下圖，用戶經過瀏覽器輸入網址進行域名解析，而後從CDN上得到靜態資源，從後臺服務器得到HTML文件，這些信息拼裝組成顯示的網頁。

Web 2.0

特點

注重用戶的交互。每一個人都是內容的供稿者。 RSS訂閱扮演一個很重要的做用。 表明：博客、播客、維基、P2P下載、社區、分享服務

集羣跟分佈式

橫向複製的集羣跟縱向切分的分佈式環境。

架構演進史

1. 早期雛形

特徵：

應用程序主要作靜態文件讀取，返回內容給瀏覽器。 瀏覽器加載本地的若干資源 跟 瀏覽器解析從服務器獲取到的資源是同樣的！

2. 數據庫開發（LAMP特長）

Linux + Apache + MySQL + PHP 特徵：

應用程序主要主要讀取數據表值，填充html模塊。業務邏輯簡單，寫sql處理。

3. JavaWeb雛型

特徵：

tomcat + servlet + jsp + mysql。一個war包打天下 項目結構：ssh/ssm三層結構。

4. JavaWeb的集羣發展

特徵：

在3的基礎上進行多個war包的複製啓動 。 硬件機器的橫向複製，對整個項目結構無影響。

在這裏插入圖片描述

5. JavaWeb分佈式

特徵：

將Service層單獨分離出去，成爲一個單獨的項目jar。單獨運行。 Web服務器經過rpc框架，對分離出去的service進行調用。分佈式是按照組件拆分。

在這裏插入圖片描述

6. JavaWeb微服務

特徵：

從業務角度，細分業務爲微服務，每個微服務是一個完整的服務（從http請求到返回）。在微服務內部，將須要對外提供的接口，包裝成rpc接口，對外部開放。微服務按照 業務拆分。

在這裏插入圖片描述

後端問題

後端的不斷演進就會致使出現服務治理需求的出現。

1. 跨系統的RPC： RMI、webservice、Http請求，
2. dubbo的引入， SpringCloud
3. 服務器集羣的負載路由，服務的註冊跟發現 ZooKeeper
4. 數據量超級大時引起的

1. 分庫/分表，須要修改業務sql語句，有侵入型，MyCat的引入。
2. 分區，對sql語句是沒有侵入性的，可是對庫是沒辦法減輕壓力的。
3. 單庫的MySQL承載容量通常在 700W左右。

在這裏插入圖片描述

前端發展史

1. 整頁提交

特徵：

瀏覽器請求皆爲頁面級請求，每次請求都是一次頁面跳轉/刷新。

在這裏插入圖片描述

2. 頁面+ ajax

特徵：

瀏覽器請求主要爲頁面級請求，有局部刷新使用ajax刷新，頁面體驗更好。

在這裏插入圖片描述

3. mvvm模式

MVVM是Model-View-ViewModel的簡寫。它本質上就是MVC 的改進版 特徵：

1. 首次請求返回頁面html，後續請求皆爲restful返回 json。
2. 前端人員將js/css/img 資源開發完畢後 打包到apache或者nginx上，供瀏覽器訪問 3 瀏覽器 訪問靜態資源服務器，得到HTML資源。
3. HTML頁面JS發起·ajax·請求後臺服務器，獲得業務數據 而後進行渲染整個頁面。跨域問題可用nginx解決。

在這裏插入圖片描述

架構思路及常看法決方案

一、緩存（list/redis/memached） 二、橫向拓展（集羣負載） 三、拆分高負載服務，獨立爲一模塊 四、大表數據切片（ mysql分庫分區分表） 五、使用搜索中間件： solr/elasticsearch 六、全局性網站搜索跟mysql指定型搜索不同，只能用上面的中間件搞定 like 搜索。 七、tomcat通常在500如下爲好。 八、mysql單表通常700萬之內。

在這裏插入圖片描述

session跨域共享

cookie、session、token 形象說， 跨域問題：

方案1：負載使用 hash（ip） 方案2：使用redis共享session 方案3: tomcat 插件實現共享 方案4: spring session 實現共享

在這裏插入圖片描述

常看法決方案

1. 緩衝方案

Redis 的引入。 通常緩存方案

一、先到緩存中查，有值直接返回 二、無值（緩存穿透、擊穿）則調用接口或者查庫，並將值補入緩存區 三、緩存區數據與db中可能不一致，使用過時時間調節 四、若緩存區數據集中在某一短時刻失效，將致使大量的緩存擊穿（雪崩）

永不過時方案

一、不設置過時時間，數據永久有效，避免雪崩 二、須要額外機制來實現數據的同步更新（參照數據同步）

在這裏插入圖片描述

2. 消息中間件

Kafka，RocketMQ，RabbitMQ，ActiveMQ

一、每一個應用啓動時，主動註冊隊列 二、後續收/發信息，只管收/發隊列中數據 三、隊列中數據的路由策略， 由mq管理者來配置，跟應用程序無關。相似傳話筒

在這裏插入圖片描述

3. 同步異步

同步調度：

一、調度期間，主調和被調線程被同時佔用。 二、被調執行完成前，主調等待。 三、程序內部的調度，則爲一單線程。

異步調度：

一、主調與被調只是一次消息發送，信息到達即返回。 二、被調執行完成後，回調一次主調方，發送結果回來。 三、程序內部的調度，則回調函數是由被調線程執行。

在這裏插入圖片描述

4. 同步轉異步

同步轉異步：空間換時間，JDK Future Task模式

5. 數據切片

實現集羣的動態擴容，Redis/es/fastdfs，將數據按片切分：

一、切成6個片，每一個片存儲總量1/6數據 二、則兩個庫每一個庫分擔三個片 三、若三個庫，則每一個庫只須要承擔兩個片 四、路由管理，只記錄數據與片柱的關係

在這裏插入圖片描述

本文使用 mdnice 排版