前言

本文介紹下 網際網路架構演進的4個階段1、單體架構2、水平分層和麵向服務架構（SOA）3、微服務架構4、服務網格架構(Service Mesh)

在此之前先簡單介紹一個小知識點

redis做分散式鎖弊端

redis實現分散式鎖 哨兵模式下 會導致 一個鎖同時被多個執行緒持有

分散式鎖是CP模型 Redis是AP模型 用AP實現CP完全錯誤的

用ZK實現分散式鎖 有效能問題

推薦使用etcd來實現分散式鎖

網際網路發展pc網際網路

靜態 廣播式

移動網際網路

動態 互動 比如微博關注

物聯網

萬物連線 比如微信群組 將一對一變成一對多 形成了網路

架構演進單體

優點

開發、測試、部署、擴充套件 都很方便

擴充套件

應用場景

功能不復雜 研發人員少創業初期效能要求極其苛刻

效能： 吞吐量、平均響應延遲這裡主要指平均響應延遲 比如股票、高頻交易 需要及時捕捉到股票市場一些波動

缺點

系統耦合性高技術選型單一

比如開發語言單一

開發效率越來越低水平分層

要解決這些問題 咱們先看看資料庫是如何破局的 然後再類比到架構上

資料庫如何解決單體瓶頸

拆分

按業務垂直分庫

比如 使用者庫 商戶庫但還是單表

水平拆分（分表）

比如 模1024 分1024表

db做了拆分 所以要考慮分散式事務

架構同理

水平分層架構設計垂直方向拆分

按業務維度

水平方向拆分

物理分成多個獨立程序

按功能緯度：閘道器層、業務邏輯層、資料訪問層、資料儲存層

每層邏輯解耦

資料訪問層必須拆分出來 可以遮蔽掉分庫分表邏輯和相容不同的資料庫（比如關係型、非關係型、NewSql）

分層設計原則

展示服務和閘道器服務分離舉例

閘道器返回的釋出時間是時間戳格式展示層（APP）將時間戳轉換成具體的日期格式而非閘道器返回具體的日期格式

閘道器層功能資料完整性檢查

app 透過https/http協議 以json字串的格式請求包：1 定長header(uid、sessionId(請求唯一標識、cmd(請求命令號)、body length)) 2 變長body原則：不會對價格欄位做檢查（不會處理具體業務語意）但要做非空檢查（通用邏輯）

請求鑑權 粗粒度：ip白名單細粒度：請求引數中有token，基於過濾器做token驗證

1、登陸鑑權是屬於具體業務 不屬於請求鑑權 放在業務邏輯層2、鑑權規則配置到配置中心 視覺化方式獲取

協議轉換

請求進入閘道器之後 不用短連線

傳輸協議

rpc oven tcp可以提升傳輸效率

資料協議

protobuf google（用json傳輸量大 pb二進位制且壓縮）

負載均衡

閘道器開源元件

簡單解釋：1、Kong基於nginx(Lua) 寫了擴充套件性指令碼2、BIO是阻塞IO模型3、Netty 用的NIO（N是New IO:IO複用）4、epoll （linux具體網路實現,實現NIO）5、AIO 非同步IO模型 （用的不多 業務複雜度很高 效能最好）6、Zuul 已貢獻給 Spring Cloud 推薦Zuul簡單擴充套件：1、國際化 在APP啟動層做2、第三方呼叫的場景用oauth授權  app用oauth意義不大3、多版本號場景 業務邏輯根據不同版本號做差異4、不同業務團隊用一個閘道器 5、閘道器層是無狀態的 每一個部署的模組是對等的 不儲存資料6、selct和poll不用 效能較差 epoll用的更多7、springcloud大公司用的很少   中小型公司用的多    用的是http協議 沒有用rpc   8、服務治理每層都要做9、Zuul儘量少啟動 一啟動連線就丟了 10、app(混合式： 經常變的頁面做成h5(不需要發版本) native)

業務邏輯層功能資料訪問層功能

orm對映 : pb->mysql協議

最難的是Sharding

1 原因：很多情況 sharding不了對商品留言功能 幾十個億 分片不了留言id 留言商品id 留言人 留言時間 留言狀態（有沒有刪除）未分表 只需要建立index就可以分表 parditing key只有一個其他的查詢欄位要遍歷所有表 2 解決方式：透過對映表 基因法3、分庫分表查詢的業務邏輯在業務邏輯層實現

最好的方式是不分片

將分表邏輯下推到db層

資料庫進化史

rdbms

1、單機關係型資料庫 2、08年之前3、比如mysql oracle

nosql

1、資料量大 網際網路事務要求不高 (acid) 分散式非關係型資料庫 2、解決了分庫分表3、一致性解決不好 比如mongodb redis hive hbase4、mongodb 3.0之前事務性不好 4.0及以後支援事務

newsql

1、金融電信銀行 資料量大 事務要求很高 2、分散式關係型資料庫3、比如國內tidba、tidb是強一致性的 支援事務acid對一致性要求不高的 不用關係型資料庫也可以 比如用redisb、tidb用的是mysql協議 業務不需要升級c、單機mysql資料儲存的下的話 tidb比mysql慢 因為tidb是分散式的d、異構儲存 一致性很難保證4、用newsql 線上單表 1200多億 查詢只需要4毫秒

同步架構

非同步架構

1、為什麼用mq做非同步mq順序寫入磁碟 append 追加 效率高db隨機寫寫磁碟2、mq要放在閘道器和業務邏輯層之間變成非同步3、非同步目的提升吞吐量4、推薦使用rocketmq5、讀請求不能用mq    寫請求可以用mq      資料一致性要求強:充值 不能用非同步 吞吐量不高 低併發資料一致性要求弱:發朋友圈 社交 可以用非同步 吞吐量高 高併發寫場景是非同步讀場景不是非同步發朋友圈 快取到本地 讀從本地讀 不是從閘道器->業務邏輯層->資料儲存層->db發好了直接看 解決自己看問題就好了 好多秒之後再看 就已經入DB了但非同步也不定寫成功到db微信怎麼辦的 有未傳送成功的訊息

層次劃分個數

過多

1、請求路徑變長2、平均響應延遲變高3、定位問題複雜 分散式請求跟蹤系統4、運維成本增加

過少

單體

適中

缺點

每層粒度過粗

擴充套件

1、reacter 模型 本質是非同步架構 是一個實現手段2、app和閘道器長連線 失敗了會推給app若http必須長輪詢3、使用nginx\f5\lvs意義會使請求更加健壯 因為閘道器會頻繁重啟 4、nginx反向代理 ip限流5、mq不適合用udp協議（高效能udp） mq要保證資料可靠性

同步水平分層架構

dns解析 ->靜態資源獲取->動態資源獲取

1、路由器虛擬化 NetGW2、物件儲存    a、fastdfs(規模小)    b、ceph(規模大 運維壓力大 快儲存、掛硬碟)

面向服務SOA

垂直拆分

1、多個獨立服務（每個服務都是單體）2、透過ESB互動 對ESB依賴嚴重3、SOA不是微服務架構

微服務架構

垂直和水平都拆分

1、獨立程序2、圍繞業務建模能力3、獨立部署4、去中心化管理 （閘道器、業務邏輯資料訪問、儲存層 都可以用各種語言寫 但會帶來很多問題）

1、用zk、consul做註冊中心不行 eurka 可以2、配置中心推薦 appllo 攜程開源；不要用disconf(springcloud的生態)3、交易系統是同步分層架構4、註冊中心不知道哪個服務掛掉 透過熔斷可以知道5、forupdate併發鎖 粒度大 量大不行6、同層之間不呼叫

本質

兩個拆分

垂直（業務）拆分比較難繼續拆分 讀、寫微服務（按功能拆分 （api））

業務架構

微服務架構是業務架構 不是系統架構

組織架構

事業部制  公司->房產(產品、研發、銷售) 招聘(產品、研發、銷售) 二手車(產品、研發、銷售) 效率高公司->產品、研發、銷售 效率低

應用場景

需求層面

變化頻繁 比如內部OA系統 ERP系統 不頻繁 微服務意義不大

效能層面

1、吞吐量變高 平均響應延遲變高2、高頻交易 量化交易 不合適微服務

資料一致性層面

一致性分為：   強一致性   和最終一致性（用微服務其實解決這個問題）多個db 分散式事務解決強一致性問題 效能就沒了往往最終一致性 （分為同步、非同步場景）

目的

快速迭代、持續交付降本（人力、機器）提效（開發、運維、測試）

後記

後續會介紹服務網格架構ServiceMesh