2019年聲明式自愈系統-高可用分布式系統的設計之道.pdf

1、聲明式自愈系統聲明式自愈系統高可用分布式系統的設計之道高可用分布式系統的設計之道高級技術專家目錄目錄 分布式系統面臨的高可用問題 設計和驗證高可用分布式系統的工具與方法 設計和驗證高可用分布式系統的案例分享 高可用系統的最佳實踐總結無狀態分布式系統的高可用問題無狀態分布式系統的高可用問題處理消息的服務節點可以隨機選擇不必處理數據復制和同步的問題系統容量和高可用能力可以同步提升服務節點可以隨意遷移，不必固定 IP 和存儲有狀態分布式系統的高可用問題有狀態分布式系統的高可用問題一致性一致性可用性可用性分區容錯性分區容錯性PaxosPaxosRaftRaft2PC2PCGossipGossip 處理

2、請求需要特定節點處理請求需要特定節點 必須要考慮數據備份和同步必須要考慮數據備份和同步的問題的問題 容量擴展和高可用需要不同容量擴展和高可用需要不同解決方案解決方案 服務節點不能隨便遷移服務節點不能隨便遷移CAP Is Not Simply 2 out of 3 沒有分區時，可用性和一致沒有分區時，可用性和一致性要兼得性要兼得 經常要考慮的是可用性和一經常要考慮的是可用性和一致性各有一部分致性各有一部分 根據不同設計應用需求有不根據不同設計應用需求有不同的組合同的組合 重要的是系統如何恢復到重要的是系統如何恢復到“最佳狀態最佳狀態”分區容錯性可可用用性性一一致致性性系系統統服服務務等等級級分區

3、容錯性可可用用性性一一致致性性系系統統自自愈愈程程度度Look Distributed System in another WaySafetySomething bad will never happene.g.received message is lostLivenessSomething good will eventually happene.g.is able to receive message目錄目錄 分布式系統面臨的高可用問題 設計和驗證高可用分布式系統的工具與方法 設計和驗證高可用分布式系統的案例分享 高可用系統的最佳實踐總結依據聲明式自愈的理念設計系統依據聲明式自愈的理念設

4、計系統有一個統一的狀態持久化接口，所有有狀態模塊通過統一的接口對應統一的對象模型配置模塊對象只需要包括Desired State每個領域的控制器模塊的邏輯保證自己領域獨立自愈的能力改變狀態的操作必須是冪等的聲明式操作，沒有新聲明時各模塊按照之前的聲明繼續工作控制器模塊對象包括Desired State 和 Realized State聲明式自愈系統的控制器協調循環聲明式自愈系統的控制器協調循環ObserveObserveAnalyzeAnalyzeActionActionu 觀察當前的觀察當前的Realized StateRealized Stateu當前有當前有2 2個正常運行的個正常運行的

5、PodPodu比較比較Desired StateDesired State跟跟Realized StateRealized State的差距的差距u期望期望3 3個個PodPodu實際狀態實際狀態2 2個個PodPodu控制器執行動作協調到控制器執行動作協調到Desired StateDesired Stateu創建創建1 1個新的個新的PodPod Controller觀察特定領域的觀察特定領域的系統狀態系統狀態 協調協調Desired State跟跟Realized State之間的差之間的差距，維持最終一致性距，維持最終一致性 定期處理集群中的事件定期處理集群中的事件 系統必須是冪等的系

6、統必須是冪等的控制器的設計理念控制器的設計理念控制邏輯應該只依賴于當前狀態假設任何錯誤的可能，并做容錯處理盡量避免復雜狀態機，邏輯不要依賴無法監控的內部狀態每個模塊都可以在必要時優雅地降級服務每個模塊都可以在出錯后自動恢復假設任何命令都可能被任何調用對象拒絕，甚至返回錯誤結果聲明式自愈系統聲明式自愈系統的現有框架的現有框架Kubernetes聲明式自愈系統設計理念的回顧聲明式自愈系統設計理念的回顧統一接口和對象模型自愈能力冪等操作和狀態機DS 和 RSDesired State可重用部分可重用部分已完全實現已完全實現要在領域內要在領域內自己實現自己實現如何設計好狀態機和自愈協議？如何設計好狀態

7、機和自愈協議？Writing Correct Software Is Hard!Math and Thinking Can Help Us!TLA+是用來給（軟件或硬件）系統建模的語言TLA+強調排除特定編程語言（軟件或硬件）的影響驗證系統設計TLA+由 Paxos 協議的發明人 Leslie Lamport 發明使用使用 TLA+定義和驗證系統設計定義和驗證系統設計Why TLA+For quite a while,Ive been disturbed by the emphasis on language in computer science.One result of that emp

8、hasis is programmers who are C+experts but cant write programs that do what theyre supposed to.I believe that the best way to get better programs is to teach programmers how to think better.Thinking is not the ability to manipulate language;its the ability to manipulate concepts.Leslie LamportLeslie

9、 LamportLanguage vs.ConceptWhorfian syndrome沃爾夫綜合沃爾夫綜合征征Computer scientists collectively suffer from what I call the Whorfian syndrome1the confusion of language with reality.Since these devices are described in different languages,they must all be different.In fact,they are all naturally described a

10、s state machines.Leslie LamportLeslie LamportLanguage vs.RealityFunctions vs.State MachinesYet computer scientists are so focused on the languages used to describe computation that they are largely unaware that those languages are all describing state machines.Leslie LamportLeslie LamportTLA+試圖用狀態機而

11、不是計算過程描述系統試圖用狀態機而不是計算過程描述系統更加關注系統的非正常輸入更加關注系統的穩定性可用性等特性而不是系統輸出分布式系統環境下沒有單一的輸入輸出TLA+是一種適合定義狀態機的語言是一種適合定義狀態機的語言定義一個狀態機需要：1.定義所有可能的初始狀態2.定義在特定狀態下可能有哪些狀態轉換一個程序可以用狀態機描述一個程序可以用狀態機描述定義一個狀態機需要：1.定義變量2.定義所有可能的初始狀態3.定義在特定狀態下可能有哪些狀態轉換計算 100/x 的程序：x=100/x;TLA+的應用場景的應用場景驗證系統設計的正確性驗證系統設計的正確性TLA+工具會遍歷所有可能的狀態驗證系統的正

12、確性分布式系統中有哪些異常情況需要模擬？分布式系統中有哪些異常情況需要模擬？運行時可能出現的異常運行時可能出現的異常ApplicationsApplicationsRuntimesRuntimesMiddlewareMiddlewareOSOSVirtualizationVirtualizationStorageStorageNetworkingNetworkingDataData啟動異常啟動異常進程被殺進程被殺服務器假死服務器假死斷電斷電啟動異常啟動異常超賣超賣進程死鎖進程死鎖負載均衡失效負載均衡失效業務線程池滿業務線程池滿監控錯誤監控錯誤流控不合理流控不合理心跳異常心跳異常緩存熱點緩存熱點

13、緩存限流緩存限流數據庫熱點數據庫熱點數據庫宕機數據庫宕機數據庫延遲數據庫延遲CPU CPU 搶占搶占內存搶占內存搶占內存錯亂內存錯亂上下文切換上下文切換磁盤滿磁盤滿磁盤壞磁盤壞網絡抖動網絡抖動網卡慢網卡慢斷網斷網DNS DNS 故障故障系統單點系統單點異步阻塞異步阻塞依賴超時依賴超時內存溢出內存溢出不可讀寫不可讀寫目錄目錄 分布式系統面臨的高可用問題 設計和驗證高可用分布式系統的工具與方法 設計和驗證高可用分布式系統的案例分享 高可用系統的最佳實踐總結一個分布式消息系統的概念模型一個分布式消息系統的概念模型ProducerProducer X X Topic AQueue A0Queue A1

14、Server Group 0Server Group 0Topic BQueue A2Queue A0Server Group 1Server Group 1ProducerProducer Y YConsumerConsumer A1 A1消費組消費組A AConsumerConsumer A2 A2ConsumerConsumer B1 B1消費組消費組B BConsumerConsumer B2 B2Topic A分布式消息系統的部署模型分布式消息系統的部署模型ProducerProducer Discovery Service ClusterDiscovery Service Clus

15、terConsumerConsumerConsumerConsumerConsumerConsumerProducerProducer ProducerProducer Server Group 0Server Group 0Server Group 1Server Group 1分布式消息系統在分布式消息系統在 Kubernetes 下的部署運維下的部署運維ServerServerMasterMasterPod-0-0Pod-0-0ServerServerSlaveSlavePod-0-1Pod-0-1ServerServerSlaveSlavePod-0-2Pod-0-2Server Gr

16、oup Server Group 0 0StatefulSet-0StatefulSet-0ServerServerMasterMasterPod-1-0Pod-1-0ServerServerSlaveSlavePod-0-1Pod-0-1ServerServerSlaveSlavePod-0-2Pod-0-2Server Group Server Group 1 1StatefulSet-1StatefulSet-1ServerServerMasterMasterPod-N-0Pod-N-0ServerServerSlaveSlavePod-N-1Pod-N-1ServerServerSla

17、veSlavePod-N-2Pod-N-2Server Group Server Group N NStatefulSet-2StatefulSet-2Storage Service ClusterStorage Service ClusterDiscoveryDiscoveryServiceServicePod-0Pod-0DiscoveryDiscoveryServiceServicePod-1Pod-1DiscoveryDiscoveryServiceServicePod-2Pod-2Discovery Service ClusterDiscovery Service Cluster使用

18、使用 TLA+驗證系統自愈特性驗證系統自愈特性目標狀態目標狀態DesiredDesired State State使用使用 TLA+驗證系統自愈特性驗證系統自愈特性實際狀態實際狀態Realized Realized StateState設計實現聲明式自愈系統的工具與方法設計實現聲明式自愈系統的工具與方法架構選型選擇基礎狀態持久化框架參考系統：Kubernetes高可用系統設計設計并驗證高可用分布式系統參考工具：TLA+Toolkit系統實現實現高可用系統的控制模塊參考模式：Kubernetes Operator系統測試測試分布式高可用系統的自愈能力參考工具：Jepsen目錄目錄 分布式系統面臨

19、的高可用問題 設計和驗證高可用分布式系統的工具與方法 設計和驗證高可用分布式系統的案例分享 高可用系統的最佳實踐總結最佳實踐分享最佳實踐分享有關 TLA+的使用 分布式系統設計 80%的重點工作在與設計安全性原則 目前 TLA+工具已經有云服務上線，但只支持檢查安全性 單機版的 TLA+工具支持系統活性的檢查，但是性能比較差 活性檢查的性能瓶頸在于系統狀態圖中強連通圖算法的實現 TLA+中實現的卡殼（Stutter）等價能力，即對所有狀態保持不變也是合法狀態最佳實踐分享最佳實踐分享有關分布式系統統一 API 的設計 所有API應該是聲明式的 高層API以操作意圖為基礎設計 低層 API 根據高

20、層 API 的控制需要設計 API 對象是彼此互補而且可組合的 盡量避免簡單封裝,不要有隱藏的內部 API API 操作復雜度與對象數量成正比 API 對象狀態不依賴于連接狀態 針對全局狀態設計自愈容錯機制最佳實踐分享最佳實踐分享有關系統設計和運營 分開設計理想狀態和實際狀態 Desired State Realized State 利用隊列解耦系統 盡量不要依賴 DNS 做高可用 監控負載不均的情況 避免Self DoS最佳實踐分享最佳實踐分享有關微服務架構的典型模式 限流 Throttling 超時 Timeouts 熔斷器 Circuit Breaker 壁艙 Bulkheads 快速失

21、敗 Fail Fast 背壓模式 Backpressure最佳實踐分享最佳實踐分享有關遵循快速回復的原則 快速報錯 Fail Fast 復雜操作拆分成簡單原子操作，在界面和 CLI 做組合 注意設置超時 盡量避免用全局事物 注意慢操作可能造成的客戶端沖突問題最佳實踐分享最佳實踐分享有關緩存的使用 緩存的內容：服務發現應答，DNS 結果，元數據，數據，之前的請求 邏輯正確性不能依賴緩存，寫操作服務端必須有校驗而且冪等，沒有緩存情況下系統仍可服務 錯誤回復緩存，過期時間不能太長，而且有清晰的修復建議 數據庫更新與緩存失效的策略最佳實踐分享最佳實踐分享有關配置文件 集群使用統一的配置來源 定義正常的默認配置，滿足讀取不到配置的正常運行 支持可擴展的配置命令格式 盡量支持更改配置不需要重啟服務 注意配置項之間的關聯性