[分佈式設計] 認識故障和彈力設計

為了讓你更深入地瞭解分佈式系統,在接下來的幾期中,我想談談分佈式系統中一些比較關鍵的設計模式,其中包括容錯、性能、管理等幾個方面。

容錯設計又叫彈力設計,其中著眼於分佈式系統的各種“容忍”能力,包括容錯能力(服務隔離、異步調用、請求冪等性)、可伸縮性(有 / 無狀態的服務)、一致性(補償事務、重試)、應對大流量的能力(熔斷、降級)。可以看到,在確保系統正確性的前提下,系統的可用性是彈力設計保障的重點。

管理篇會講述一些管理分佈式系統架構的一些設計模式,比如網關方面的,邊車模式,還有一些剛剛開始流行的,如 Service Mesh 相關的設計模式。

性能設計篇會講述一些緩存、CQRS、索引表、優先級隊列、業務分片等相關的架構模式。

我相信,你在掌握了這些設計模式之後,無論是對於部署一個分佈式系統,開發一個分佈式的業務模塊,還是研發一個新的分佈式系統中間件,都會有所裨益。

系統可用性測量

對於分佈式系統的容錯設計,在英文中又叫 Resiliency(彈力)。意思是,系統在不健康、不順,甚至出錯的情況下有能力 hold 得住,挺得住,還有能在這種逆境下力挽狂瀾的能力。

要做好一個設計,我們需要一個設計目標,或是一個基準線,通過這個基準線或目標來指導我們的設計,否則在沒有明確基準線的指導下,設計會變得非常不明確,並且也不可預測,不可測量。可測試和可測量性是軟件設計中非常重要的事情。

我們知道,容錯主要是為了可用性,那麼,我們是怎樣計算一個系統的可用性的呢?下面是一個工業界裡使用的一個公式:


[分佈式設計] 認識故障和彈力設計

根據上面的這個公式,為了提高可用性,我們要麼提高系統的無故障時間,要麼減少系統的故障恢復時間。然而,我們要明白,我們運行的是一個分佈式系統,對於一個分佈式系統來說,要不出故障簡直是太難了。

故障原因

老實說,我們很難計算我們設計的系統有多少的可用性,因為影響一個系統的因素實在是太多了,除了軟件設計,還有硬件,還有第三方服務(如電信聯通的寬帶 SLA),當然包括“建築施工隊的挖掘機”。

所以,正如 SLA 的定義,這不只是一個技術指標,而是一種服務提供商和用戶之間的 contract 或契約。這種工業級的玩法,就像飛機一樣,並不是把飛機造出來就好了,還有大量的無比專業的配套設施、工具、流程、管理和運營。

簡而言之,SLA 的幾個 9 就是能持續提供可用服務的級別。不過,工業界中,會把服務不可用的因素分成兩種:一種是有計劃的,一種是無計劃的。

無計劃的

日常任務:備份,容量規劃,用戶和安全管理,後臺批處理應用。運維相關:數據庫維護、應用維護、中間件維護、操作系統維護、網絡維護。升級相關:數據庫、應用、中間件、操作系統、網絡,包括硬件升級。

有計劃的

日常任務:備份,容量規劃,用戶和安全管理,後臺批處理應用。運維相關:數據庫維護、應用維護、中間件維護、操作系統維護、網絡維護。升級相關:數據庫、應用、中間件、操作系統、網絡,包括硬件升級。

我們再給它們歸個類。

網絡問題。網絡鏈接出現問題,網絡帶寬出現擁塞……性能問題。數據庫慢 SQL、Java Full GC、硬盤 IO 過大、CPU 飆高、內存不足……安全問題。被網絡攻擊,如 DDoS 等。運維問題。系統總是在被更新和修改,架構也在不斷地被調整,監控問題……管理問題。沒有梳理出關鍵服務以及服務的依賴關係,運行信息沒有和控制系統同步……硬件問題。硬盤損壞、網卡出問題、交換機出問題、機房掉電、挖掘機問題……

[分佈式設計] 認識故障和彈力設計

故障是正常的,而且是常見的。


分享到:


相關文章: