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

為什么要懂分布式架構

系統(tǒng)學習分布式架構設計對于技術人的成長非常關鍵，對于云原生開發(fā)者而言如何設計出符合云原生設計哲學的應用往往離不開分布式系統(tǒng)知識與方法論的運用。如何設計出高彈性、可配置、可分布、高性能、高容錯、更安全、更韌性、快交付的原生應用往往是衡量開發(fā)者水準的重要參考。

然后而分布式系統(tǒng)是一個很大的概念，從架構設計、研發(fā)流程、運維部署、工程效率等多個角度均有很深的知識可以挖掘，學習成本和難道相對較大。近期整理了過去閱讀過的一些和分布式相關書刊和文章，加上自己做分布式開發(fā)的一些的心得分享給大家，本文作為開篇，總體上給出知識概覽，后續(xù)將分篇結合代碼實踐來進行闡述。起草倉促，水平有限，歡迎大家一起學習指正。

分布式系統(tǒng)大圖

一、設計

網關模式，Gateway

功能

• 請求路由，客戶端直接調用 Gateway，Gateway 負責路由轉發(fā)到注冊服務上
• 服務注冊，后端服務將 API 注冊，Gateway 負責路由

• 負載均衡，支持多種負載策略

  • round robin
  • 隨機均衡算法
  • 多權重負載
  • session 粘連
  • 其它
• 安全特性，支持 HTTPS，賬戶鑒權，及其它安全特性支持
• 灰度發(fā)布，可以針對服務版本或者租戶等特性做灰度發(fā)布
• API 聚合，將多個后端接口聚合，減少客戶端調用次數
• API 編排，通過編排來串接多個 API 完成特定業(yè)務

設計要點

• 可用性，必須保證高可用
• 擴展性，可以靈活擴展以支持特定業(yè)務比如特定業(yè)務流控
• 高性能，通常使用異步 IO 模型框架實現，比如 Java netty，Go Channel
• 安全，如加密通信，鑒權，DDOS 防御等

• 運維

  • 應用監(jiān)控，包括容量，性能，異常檢測等
  • 彈性伸縮，具備高彈性能力，以低成本應對高峰值

• 架構

  • 與業(yè)務解耦合，提供擴展擴展機制比如 Plugin，Serverless 的思路支持后端業(yè)務
  • 服務隔離，可以按照后端服務劃分網關，做到不同服務使用不同網關
  • 網關部署靠近后端，保證網絡損耗最小，性能最佳
    

邊車模式，Sidecar

價值

• 分離控制與邏輯，分離業(yè)務邏輯與路由，流控，熔斷，冪等，服務發(fā)現，鑒權等控制組件

• 適用場景

  • 老系統(tǒng)改造擴展，Sidebar 進程與服務進程部署在同一個節(jié)點，通過網絡協(xié)議通訊
  • 多語言混合分布式系統(tǒng)擴展
  • 應用程序由多方提供
    

設計要點

• 標準服務協(xié)議，Sidebar 到 Service，Sidebar 到 Sidebar 協(xié)議盡可能與語言解耦
• 聚合控制邏輯比如流控，熔斷，冪等，重試，減少業(yè)務邏輯
• 不要使用對服務侵入的方式進行進程間通訊如信號量，共享內存，優(yōu)先使用本地網絡通訊的方式比如 TPCP 或者 HTTP
  

服務網格，Service Mesh

新一代微服務架構，本質是服務間通信的基礎設施層。

架構圖

特點

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

主流框架

• Istio
• Linkerd

分布式鎖

解決方案

• Redis分布式鎖，SETNX key value PX expiretime

  • value 生成，最好全局唯一比如TraceID，可以使用/dev/urandom生成
  • expiretime單位是毫秒，過期鎖自動釋放 ，鎖持有者保證過期時間內爭搶資源完成計算
• 悲觀鎖，先獲取鎖，再進行操作，吞吐量底
• 樂觀鎖，使用版本號方式實現，吞吐量高，可能出現鎖異常，適用于多讀情況
• CAS，修改共享數據源的場景可以代替分布式鎖
  

設計要點

• 排他性，任意條件只有一個client可以獲取鎖
• 鎖有自動釋放方式，比如超時釋放
• 鎖必須高可用，且持久化
• 鎖必須非阻塞且可重入
• 避免死鎖，client最終一定可以獲取鎖，不存在異常情況鎖無法釋放的情況
• 集群容錯性，集群部分機器故障，鎖操作仍然可用
  

配置中心

• 靜態(tài)配置，環(huán)境及軟件啟動配置
• 動態(tài)配置，運行時動態(tài)調整的配置如流控開關，熔斷開關等
  

異步通訊

• 請求響應式，發(fā)送方直接向接收方發(fā)送請求

  • 發(fā)送方主動輪詢
  • 發(fā)送方注冊一個回調函數，接收方處理完成后回調發(fā)送方

• 事件驅動設計（EDA）

  • 消息訂閱，發(fā)送方發(fā)布消息，接收方訂閱并消費消息
  • Broker 中間人，發(fā)送方向Broker發(fā)布消息，接收方向Broker訂閱消息，彼此解耦,比如中間件RocketMQ

  • 事情驅動設計優(yōu)勢

    • 服務間依賴解除
    • 服務隔離程度高

冪等性

• 本質是一個操作，無論執(zhí)行多少次，執(zhí)行結果總是一致的

• 冪等核心是全局唯一ID，鏈路依據全局ID做冪等，依據業(yè)務復雜度可以選取多種實現方式

  • 數據庫自增長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模型
  

數據庫擴展

• 數據庫分片

  • 垂直分片

    • 字段拆分，將變化頻率不同的字段拆分到不同表

  • 水平分片

    • 哈希算法來分，數據離散度高，降低熱點可能性
    • 通過時間范圍分片，保證數據連續(xù)性
    • 按照業(yè)務種類劃分，比如數據分類，租戶分離等

  • 分片設計要點

    • 分片要預留足夠空間，避免重新分片
    • 分片聚合要并行去做
    • 業(yè)務盡可能不去做跨分片的事務
      

三、容錯

?

系統(tǒng)可用性

• MTTF, Mean Time To Failure，系統(tǒng)平均運行多長時間才發(fā)生故障，越長越好
• MTTR,Mean Time To Recover, 故障平均修復時間，越短越好
• 可用性計算公式， Availability= MTTF /（MTTF+MTTR）

服務降級

• 降低一致性

  • 強一致性，將所有的同步一致性，切換為最終一致性，提高吞吐量
  • 弱一致性，必要時候犧牲一致性換取服務整體可靠性

• 關閉次要服務

  • 不同應用，關閉次要應用，釋放物理資源
  • 相同應用，關閉應用次要功能，更多資源給到核心功能

• 簡化服務功能

  • 如簡化業(yè)務流程，減少通訊數據等

服務限流

• 限流目的

  • SLA保證方式之一
  • 應對突發(fā)峰刺流量，一定程度節(jié)約容量規(guī)劃成本
  • 租戶隔離策略之一，避免某些用戶占用其它用戶的資源，導致服務大范圍不可用

• 限流方式

  • 服務降級
  • 服務拒絕

• 解決方案

  • 服務權重劃分，多租戶環(huán)境將資源按權重劃分，保證重要客戶的資源
  • 服務延時處理，加入服務緩沖隊列延緩服務壓力，用于削峰
  • 服務彈性伸縮，依賴服務監(jiān)控，彈性伸縮容

• 流控算法

  • 計數器

    • 單機或者集群保存某用戶某時間段請求數，達到閾值則觸發(fā)流控

  • 隊列算法

    • FIFO隊列

      • 請求速度波動，消費速度均勻，隊列滿則流控

    • 權重隊列

      • 按服務劃分優(yōu)先級隊列，不同隊列權重不同

    • 隊列算法設計關鍵：隊列長度的預設非常關鍵

      • 隊列太長，流控未生效，服務已經被打死
      • 隊列太短，流控被頻繁觸發(fā)，體驗差

  • 漏斗算法

    • 本質上是隊列+限流器實現，限流器保證消費速度均勻類TCP sync backlog
    • 轉發(fā)速度均勻

  • 令牌桶

    • 中間人已恒定速率向桶里發(fā)放令牌，服務請求拿到token則開始服務，否則不處理
    • 轉發(fā)速度不均勻，流量小時積累，流量大時消費

  • 動態(tài)流控

    • 實時計算服務能力如QPS，對比服務RT如果RT過大，則減少QPS

• 設計要點

  • 手動開關，主動運維和應急使用
  • 監(jiān)控通知，限流發(fā)生時干系人要清楚
  • 用戶感知，如返回特定錯誤信息（錯誤code/錯誤提示）
  • 鏈路標識，RPC鏈路加入限流標識方便上下游業(yè)務識別限流場景做不同處理

熔斷設計

• 場景

  • 過載保護，系統(tǒng)負載過高情況為防止故障產生，而采取的一種保護措施
  • 防止應用程序不斷嘗試可能會失敗的操作

• 三個狀態(tài)

  • Closed，閉合狀態(tài)，正常狀態(tài)，系統(tǒng)需要一個基于時間線到錯誤計數器，如果錯誤累計達到閾值則切換至Open狀態(tài)
  • Open，斷開狀態(tài)，所有對服務對請求立即返回錯誤，不用調用后端服務進行計算
  • Half-Open，半開狀態(tài)，允許部分請求流量進入并處理，如果請求成功則按照某種策略切換到Closed狀態(tài)

• 設計要點

  • 定義觸發(fā)熔斷的錯誤類型
  • 所有觸發(fā)熔斷的錯誤請求必須要有統(tǒng)一的日志輸出
  • 熔斷機制必須有服務診斷及自動恢復能力
  • 最好為熔斷機制設置手動開關用于三種狀態(tài)的切換
  • 熔斷要切分業(yè)務，做到業(yè)務隔離熔斷

補償事務

• CAP

  • 一致性(Consistence)、可用性(Availability)、分區(qū)容忍性(Partition Tolerance)

• BASE

  • Basic Availabillity，基本可用
  • Soft State，軟狀態(tài)
  • Eventual Consistency，最終一致性
• Design For Failure
• Exponential Blackoff，指數級退避

四、DevOps

?

部署

• 基礎設施

  • 云

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

  • 容器技術

    • Docker
    • Kubernetes

• 部署策略

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

配置管理

• Ansible
• Puppet
• Shippable

監(jiān)控

• Nagios
• DynaTrace

CI與CD

?

五、工程效率

?

敏捷管理

• Scrum

持續(xù)集成

• Jenkins
• CodeShip

持續(xù)交付

寫在最后

分布式系統(tǒng)在阿里巴巴經濟有著廣泛的應用，以筆者所在的彈性技術團隊為例，當業(yè)務足夠規(guī)模化后，最終面臨的技術問題都是通過踐行分布式系統(tǒng)架構的設計理念和方法輪得以解決，可以說分布式系統(tǒng)架構的知識與方法論是當前互聯(lián)網應用規(guī)模化后的通用解決方案。

學習分布式系統(tǒng)設計也不是一蹴而就，需要不斷汲取理論知識，然后將理論不斷付諸實踐，最終通過一次次的調優(yōu)來將知識的價值最大化。筆者最后的建議是先理論、后實踐、重實踐、不妥協(xié)，所謂紙上得來終覺淺，絕知此事要躬行，與君共勉。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的云原生时代|分布式系统设计知识图谱（内含22个知识点）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。