背景
分佈式架構理論的誕生互聯網的高速發展，歸納要點如下：
- 高配置的服務器成本太高。
- 應用規模變大，變的複雜起來。
- 性能問題越來越迫切，嚴重影響了用戶的體驗，互聯網平臺是注重用戶體驗，用戶至上。
- 單體應用軟件維護成本太高。
- 部署效率低下。
- 代碼複用程度低。
定義與術語
分佈式架構是指由多個能獨立部署的子系統基於網絡通訊協議，相互協同來完成業務流程的架構模式。
網絡具有三種狀態：成功、失敗、超時。
面臨的技術挑戰
業務場景需求：
- 多份相同的數據，在一處修改，保證多份一致。
- 一個業務變更多份不同的數據，要保持一致，要成功都成功，要失敗都失敗。
傳統的單體架構中，應用之間不存在基於網絡通訊的問題，集羣是無狀態的，除了會話狀態，而分佈式架構中，高併發的場景下，保證各節點數據的一致性比較複雜，複雜的原因：
- 節點規模大
- 節點之間相互通訊
- 節點管理要求高
- 一致性難度
針對此問題，提出了以下解決思路：
時鐘
- 原子鐘
- 向量時鐘
- 邏輯時鐘
通過時鐘解決時間的一致性，再通過時間的一致性來保證執行的順序性。
網絡模式
- 同步網絡
- 節點同步執行
- 消息延遲低
- 全局鎖
- 半同步網絡
- 節點同步執行
- 消息延遲中
- 全局鎖條件放寬
- 異步網絡
- 節點獨立執行
- 無全局鎖
- 消息延遲高
理論與算法
理論
- 分佈式一致性：CAP理論
- 弱一致性：BASE理論
- 強一致性：ACID理論
- 二階段協議：2P理論
- 三階段協議：3P理論
算法
- Paxos
- Raft
核心技術
註冊中心
- eureka
- consul
- nacos
配置中心
- config
- nacos
網關中心
- zuul
- gate way
- soul
負載均衡
- ribbon
- nginx
分佈式跟蹤
- skywalking
熔斷降級 限流
- hystrix
- turbine
- ribbon
- sentinel
監與控日誌
- Telegraf+InfluxDB+Grafana+SLS
調度
- xxl-job
安全
- SpringSecurity+Oauth2+Jwt
持續集成
- maven+Git+teamcity+ansible+docker+k8s
全棧中間件
數據庫
- 關係數據庫
- MySQL
- 時序數據庫
- Influxdb
- Druid
- 列數據庫
- hbase
- 文檔數據庫
- elasticsearch
- mongodb
消息隊列
- rabbitmq
- activemq
- kafka
- pulsar
緩存
- redis
- couchbase
計算
- hadoop
- spark
- flink
架構原則
高可用
1.負載 2.限流 3.降級 4.熔斷 5.隔離 6.重試 7.回滾 8.壓測
高併發
1.緩存 2.隊列 3.異步 4.池化 5.拆分
