作者| 楊澤強（竹澗）阿里雲技術專家
關注分佈式系統架構公衆號，回覆關鍵字“分佈式”下載清晰分佈式系統大圖。
我們身處於一個充斥着分佈式系統解決方案的計算機時代，無論是支付寶、微信這樣頂級流量產品、還是區塊鏈、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
服務網格，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
持續交付
總結及學習建議
分佈式系統在阿里巴巴經濟體有着廣泛的應用，以筆者所在的彈性計算技術團隊爲例，當業務足夠規模化後，最終面臨的技術問題都是通過踐行分佈式系統架構的設計理念和方法論得以解決，可以說分佈式系統架構的知識與方法論是當前互聯網應用規模化後的通用解決方案。
學習分佈式系統設計也不是一蹴而就，需要不斷汲取理論知識，然後將理論不斷付諸實踐，最終通過一次次的調優來將知識的價值最大化。
筆者最後的建議是先理論、後實踐、重實踐、不妥協，所謂紙上得來終覺淺，絕知此事要躬行，與君共勉。
