雲原生時代，分散式系統設計必備知識圖譜（內含22個知識點）

作者| 楊澤強（竹澗）阿里雲技術專家

我們身處於一個充斥著分散式系統解決方案的計算機時代，無論是支付寶、微信這樣頂級流量產品、還是區塊鏈、IOT 等熱門概念、抑或如火如荼的容器生態技術如 Kubernetes，其背後的技術架構核心都離不開分散式系統。

為什麼要懂分散式架構設計

閘道器模式，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

架構圖（圖片來源於網路，若有侵權請聯絡作者刪除）

特點

• 應用間通訊中間層
• 輕量級網路代理
• 解耦應用程式
• 應用程式無感知

• 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，指數級退避

部署

基礎設施

• 雲

• 公有云
• 私有云
• 混合雲

• 容器技術

• Docker
• Kubernetes

部署策略

• 停機部署
• 滾動部署
• 藍綠部署
• 灰度部署
• A/B 測試

配置管理

• Ansible
• Puppet
• Shippable

監控

• Nagios
• DynaTrace

CI 與 CD

敏捷管理

• Scrum

持續整合

• Jenkins
• CodeShip

分散式系統在阿里巴巴經濟體有著廣泛的應用，以筆者所在的彈性計算技術團隊為例，當業務足夠規模化後，最終面臨的技術問題都是透過踐行分散式系統架構的設計理念和方法論得以解決，可以說分散式系統架構的知識與方法論是當前網際網路應用規模化後的通用解決方案。

學習分散式系統設計也不是一蹴而就，需要不斷汲取理論知識，然後將理論不斷付諸實踐，最終透過一次次的調優來將知識的價值最大化。

筆者最後的建議是先理論、後實踐、重實踐、不妥協，所謂紙上得來終覺淺，絕知此事要躬行，與君共勉。