分佈式架構的發展演進

負載均衡算法

1. 輪詢
2. 加權輪詢
3. 隨機算法
4. 最小鏈接數
5. hash 根據客戶端ip計算出hash值，hash%2取模來決定分發目標

數據庫演變

1. 數據庫性能提高

• 數據庫如何同步
• 數據源如何路由

1.1 方案1: 引入搜索引擎：

• 提升檢索速度
• 減輕讀數據庫的壓力
• lucence，solr，elk
• 索引構建：
  基於原始數據構建索引
  全量構建->第一次構建
  增量構建->增量同步
  非實時(異步/定時任務)、實時

1.2 方案2：緩存

• 緩存: 爲了下降低速設備和高速設備間的差別。
• Nosql存儲或其餘存儲方式
  Nosql：hbase、mongoDB、Redis....
  其餘緩存：瀏覽器緩存、應用緩存、db緩存、cpu緩存，文件存儲,etc

---

2.分佈式數據庫

2.1 事務的做用？

2.2 分佈式數據庫:

經過分庫分表實現數據庫拆分：
根據服務特性（業務量、類型etc）分別配置數據庫性能

---

應用的演變

傳統單應用的問題：

1. 部署和維護困難
2. 業務耦合度很高
3. 性能瓶頸

4. 測試

   1. 應用根據功能模塊拆分：

   1.1 如：會員服務、交易服務、商品服務

RPC在分佈式中的做用？

1.2 服務分塊

優點:

• 專人維護專門服務
• 根據不一樣的吞吐量要求，作針對性的擴容

劣勢：

• 運維成本增高
• 團隊人員增多

---

高可用方案

1. 單點故障

1.1 多機房部署

---

監控

1. 鏈路監控

• zipkin
• traceID

2.硬件監控
cpu、內架構存、磁盤

---

架構的發展過程

1. SOA-ESB

• 客戶端一、客戶端2....
• ESB:
  服務的通訊、發現
  協議轉化
  安全
  限流
• 服務端集羣

2. 微服務
註冊中心：eureka、zookeeper、consoul

3. 容器+k8s調度

4. serviceMesh（服務網格） sidecar解決了：服務熔斷、調用、發現，負載均衡