阿裡巴巴雲原生公衆号釋出， 雲原生時代，分布式系統設計必備知識圖譜
前言
我們身處于一個充斥着分布式系統解決方案的計算機時代，而分布式系統是一個很大的概念，從架構設計、研發流程、運維部署、工程效率等多個角度均有很深的知識可以挖掘。
近期整理了過去閱讀過的一些和分布式相關書刊和文章，對分布式系統技術做一個系統性介紹，起草倉促，水準有限，歡迎大家一起學習指正。
版本曆史
| 版本 | 更新日期 | 說明 |
| 1.0 | 2018.07.25 | 初稿 |
| 1.1 | 2018.08.01 | 增加一些架構圖 |
| 1.2 | 2019.09.25 | 增加引用内容的說明 |
分布式系統大圖
一、設計
網關模式，Gateway
- 功能
-
- 請求路由，用戶端直接調用Gateway，Gateway負責路由轉發到注冊服務上
- 服務注冊，後端服務将API注冊，Gateway負責路由
- 負載均衡，支援多種負載政策
-
-
- round robin
- 随機均衡算法
- 多權重負載
- session粘連
- 其它
-
-
- 安全特性，支援HTTPS，賬戶鑒權，及其它安全特性支援
- 灰階釋出，可以針對服務版本或者租戶等特性做灰階釋出
- API聚合，将多個後端接口聚合，減少用戶端調用次數
- API編排，通過編排來串接多個API完成特定業務
- 設計要點
-
- 可用性，必須保證高可用
- 擴充性，可以靈活擴充以支援特定業務比如特定業務流控
- 高性能，通常使用異步IO模型架構實作，比如Java netty，Go Channel
- 安全，如加密通信，鑒權，DDOS防禦等
- 運維
-
-
- 應用監控，包括容量，性能，異常檢測等
- 彈性伸縮，具備高彈性能力，以低成本應對高峰值
-
-
- 架構
-
-
- 與業務解耦合，提供擴充擴充機制比如Plugin，Serverless的思路支援後端業務
- 服務隔離，可以按照後端服務劃分網關，做到不同服務使用不同網關
- 網關部署靠近後端，保證網絡損耗最小，性能最佳
-
邊車模式，Sidecar
- 價值
-
- 分離控制與邏輯，分離業務邏輯與路由，流控，熔斷，幂等，服務發現，鑒權等控制元件
- 适用場景
-
-
- 老系統改造擴充，Sidebar程序與服務程序部署在同一個節點，通過網絡協定通訊
- 多語言混合分布式系統擴充
- 應用程式由多方提供
-
-
- 标準服務協定，Sidebar到Service，Sidebar到Sidebar協定盡可能與語言解耦
- 聚合控制邏輯比如流控，熔斷，幂等，重試，減少業務邏輯
- 不要使用對服務侵入的方式進行程序間通訊如信号量，共享記憶體，優先使用本地網絡通訊的方式比如TPCP或者HTTP
服務網格，Service Mesh
- 新一代微服務架構，本質是服務間通信的基礎設施層
- 架構圖
圖檔來源于網絡，若有侵權請聯系作者删除
- 特點
-
- 應用間通訊中間層
- 輕量級網絡代理
- 解耦應用程式
- 應用程式無感覺
- 主流架構
-
- Istio
- Linkerd
分布式鎖
- 解決方案
-
- Redis分布式鎖，SETNX key value PX expiretime
-
-
- value 生成，最好全局唯一比如TraceID，可以使用/dev/urandom生成
- expiretime機關是毫秒，過期鎖自動釋放 ，鎖持有者保證過期時間内争搶資源完成計算
-
-
- 悲觀鎖，先擷取鎖，再進行操作，吞吐量底
- 樂觀鎖，使用版本号方式實作，吞吐量高，可能出現鎖異常，适用于多讀情況
- CAS，修改共享資料源的場景可以代替分布式鎖
-
- 排他性，任意條件隻有一個client可以擷取鎖
- 鎖有自動釋放方式，比如逾時釋放
- 鎖必須高可用，且持久化
- 鎖必須非阻塞且可重入
- 避免死鎖，client最終一定可以擷取鎖，不存在異常情況鎖無法釋放的情況
- 叢集容錯性，叢集部分機器故障，鎖操作仍然可用
配置中心
- 靜态配置，環境及軟體啟動配置
- 動态配置，運作時動态調整的配置如流控開關，熔斷開關等
異步通訊
- 請求響應式，發送方直接向接收方發送請求
-
- 發送方主動輪詢
- 發送方注冊一個回調函數，接收方處理完成後回調發送方
- 事件驅動設計（EDA）
-
- 消息訂閱，發送方釋出消息，接收方訂閱并消費消息
- Broker 中間人，發送方向Broker釋出消息，接收方向Broker訂閱消息，彼此解耦,比如中間件RocketMQ
- 事情驅動設計優勢
-
-
- 服務間依賴解除
- 服務隔離程度高
-
幂等性
- 本質是一個操作，無論執行多少次，執行結果總是一緻的
- 幂等核心是全局唯一ID，鍊路依據全局ID做幂等，依據業務複雜度可以選取多種實作方式
-
- 資料庫自增長ID
- 本地生成uuid
- Redis生産id
- Twitter開源算法 Snowflake
- HTTP幂等性，除POST外，HEAD，GET，OPTIONS，DELETE，PUT均滿足幂等
二、性能
分布式緩存
- 緩存更新模式
-
- Cache Aside，常用模式，應用要維護緩存的失效，命中，更新等動作
- Read/Write Through，緩存代理更新資料庫操作，應用視角隻有一份存儲
- Write Behind Cache，IO加速方式之一，更新操作隻在内測完成，異步進行批量更新資料庫
異步處理
- Push模型，中心排程，複雜度高
- Pull模型，無中心排程，複雜度底
- Push+Pull模型
資料庫擴充
- 資料庫分片
-
- 垂直分片
-
-
- 字段拆分，将變化頻率不同的字段拆分到不同表
-
-
- 水準分片
-
-
- 雜湊演算法來分，資料離散度高，降低熱點可能性
- 通過時間範圍分片，保證資料連續性
- 按照業務種類劃分，比如資料分類，租戶分離等
-
-
- 分片設計要點
-
-
- 分片要預留足夠空間，避免重新分片
- 分片聚合要并行去做
- 業務盡可能不去做跨分片的事務
-
三、容錯
系統可用性
- MTTF, Mean Time To Failure，系統平均運作多長時間才發生故障，越長越好
- MTTR,Mean Time To Recover, 故障平均修複時間，越短越好
- 可用性計算公式， Availability= MTTF /（MTTF+MTTR）
服務降級
- 降低一緻性
-
- 強一緻性，将所有的同步一緻性，切換為最終一緻性，提高吞吐量
- 弱一緻性，必要時候犧牲一緻性換取服務整體可靠性
- 關閉次要服務
-
- 不同應用，關閉次要應用，釋放實體資源
- 相同應用，關閉應用次要功能，更多資源給到核心功能
- 簡化服務功能
-
- 如簡化業務流程，減少通訊資料等
服務限流
- 限流目的
-
- SLA保證方式之一
- 應對突發峰刺流量，一定程度節約容量規劃成本
- 租戶隔離政策之一，避免某些使用者占用其它使用者的資源，導緻服務大範圍不可用
- 限流方式
-
- 服務拒絕
-
- 服務權重劃分，多租戶環境将資源按權重劃分，保證重要客戶的資源
- 服務延時處理，加入服務緩沖隊列延緩服務壓力，用于削峰
- 服務彈性伸縮，依賴服務監控，彈性伸縮容
- 流控算法
-
- 計數器
-
-
- 單機或者叢集儲存某使用者某時間段請求數，達到門檻值則觸發流控
-
-
- 隊列算法
-
-
- FIFO隊列
-
-
-
-
- 請求速度波動，消費速度均勻，隊列滿則流控
-
-
-
-
- 權重隊列
-
-
-
-
- 按服務劃分優先級隊列，不同隊列權重不同
-
-
-
-
- 隊列算法設計關鍵：隊列長度的預設非常關鍵
-
-
-
-
- 隊列太長，流控未生效，服務已經被打死
- 隊列太短，流控被頻繁觸發，體驗差
-
-
-
- 漏鬥算法
-
-
- 本質上是隊列+限流器實作，限流器保證消費速度均勻類TCP sync backlog
- 轉發速度均勻
-
-
- 令牌桶
-
-
- 中間人已恒定速率向桶裡發放令牌，服務請求拿到token則開始服務，否則不處理
- 轉發速度不均勻，流量小時積累，流量大時消費
-
-
- 動态流控
-
-
- 實時計算服務能力如QPS，對比服務RT如果RT過大，則減少QPS
-
-
- 手動開關，主動運維和應急使用
- 監控通知，限流發生時幹系人要清楚
- 使用者感覺，如傳回特定錯誤資訊（錯誤code/錯誤提示）
- 鍊路辨別，RPC鍊路加入限流辨別友善上下遊業務識别限流場景做不同處理
熔斷設計
- 場景
-
- 過載保護，系統負載過高情況為防止故障産生，而采取的一種保護措施
- 防止應用程式不斷嘗試可能會失敗的操作
- 三個狀态
-
- Closed，閉合狀态，正常狀态，系統需要一個基于時間線到錯誤計數器，如果錯誤累計達到門檻值則切換至Open狀态
- Open，斷開狀态，所有對服務對請求立即傳回錯誤，不用調用後端服務進行計算
- Half-Open，半開狀态，允許部分請求流量進入并處理，如果請求成功則按照某種政策切換到Closed狀态
-
- 定義觸發熔斷的錯誤類型
- 所有觸發熔斷的錯誤請求必須要有統一的日志輸出
- 熔斷機制必須有服務診斷及自動恢複能力
- 最好為熔斷機制設定手動開關用于三種狀态的切換
- 熔斷要切分業務，做到業務隔離熔斷
補償事務
- CAP
-
- 一緻性(Consistence)、可用性(Availability)、分區容忍性(Partition Tolerance)
- BASE
-
- Basic Availabillity，基本可用
- Soft State，軟狀态
- Eventual Consistency，最終一緻性
- Design For Failure
- Exponential Blackoff，指數級退避
四、DevOps
部署
- 基礎設施
-
- 雲
-
-
- 公有雲
- 私有雲
- 混合雲
-
-
- 容器技術
-
-
- Docker
- Kubernetes
-
- 部署政策
-
- 停機部署
- 滾動部署
- 藍綠部署
- 灰階部署
- A/B 測試
配置管理
- Ansible
- Puppet
- Shippable
監控
- Nagios
- DynaTrace
CI與CD
五、工程效率
靈活管理
- Scrum
持續內建
- Jenkins
- CodeShip
持續傳遞
寫在最後
ECS最為阿裡雲的核心産品，無論是産品還是技術都有前所未有的機遇與挑戰；作為ECS的管控系統，我們天然有着分布式架構的基因與場景，未來可能是雲計算領域頂層最大的分布式叢集，歡迎有志之士加入！