彈力設計又叫容錯設計，其中着眼於分佈式系統的各種“容忍”能力，包括容錯能力（服務隔離、異步調用、請求冪等性）、可伸縮性（有 / 無狀態的服務）、一致性（補償事務、重試）、應對大流量的能力（熔斷、降級）。可以看到，在確保系統正確性的前提下，系統的可用性是彈力設計保障的重點。
系統可用性測量
對於分佈式系統的容錯設計，在英文中又叫 Resiliency（彈力）。意思是，系統在不健康、不順，甚至出錯的情況下有能力 hold 得住，挺得住，還有能在這種逆境下力挽狂瀾的能力。
要做好一個設計，我們需要一個設計目標，或是一個基準線，通過這個基準線或目標來指導我們的設計，否則在沒有明確基準線的指導下，設計會變得非常不明確，並且也不可預測，不可測量。可測試和可測量性是軟件設計中非常重要的事情。
我們知道，容錯主要是爲了可用性，那麼，我們是怎樣計算一個系統的可用性的呢？下面是一個工業界裏使用的一個公式：
Availability= MTTF / (MTTF+MTTRMTT)
其中，
MTTF 是 Mean Time To Failure，平均故障前的時間，即系統平均能夠正常運行多長時間才發生一次故障。系統的可靠性越高，MTTF 越長。（注意：從字面上來說，看上去有 Failure 的字樣，但其實是正常運行的時間。）
MTTR 是 Mean Time To Recovery，平均修復時間，即從故障出現到故障修復的這段時間，這段時間越短越好。
這個公式就是計算系統可用性的，也就是我們常說的，多少個 9。
根據上面的這個公式，爲了提高可用性，我們要麼提高系統的無故障時間，要麼減少系統的故障恢復時間。
然而，我們要明白，我們運行的是一個分佈式系統，對於一個分佈式系統來說，要不出故障簡直是太難了。
故障原因
老實說，我們很難計算我們設計的系統有多少的可用性，因爲影響一個系統的因素實在是太多了，除了軟件設計，還有硬件，還有第三方服務（如電信聯通的寬帶 SLA），當然包括“建築施工隊的挖掘機”。
所以，正如 SLA 的定義，這不只是一個技術指標，而是一種服務提供商和用戶之間的 contract 或契約。這種工業級的玩法，就像飛機一樣，並不是把飛機造出來就好了，還有大量的無比專業的配套設施、工具、流程、管理和運營。
簡而言之，SLA 的幾個 9 就是能持續提供可用服務的級別。不過，工業界中，會把服務不可用的因素分成兩種：一種是有計劃的，一種是無計劃的。
無計劃的
系統級故障，包括主機、操作系統、中間件、數據庫、網絡、電源以及外圍設備。
數據和中介的故障，包括人員誤操作、硬盤故障、數據亂了。
還有自然災害、人爲破壞，以及供電問題等。
有計劃的
日常任務：備份，容量規劃，用戶和安全管理，後臺批處理應用。
運維相關：數據庫維護、應用維護、中間件維護、操作系統維護、網絡維護。
升級相關：數據庫、應用、中間件、操作系統、網絡，包括硬件升級。
我們再給它們歸個類。
1、網絡問題。網絡鏈接出現問題，網絡帶寬出現擁塞……
2、性能問題。數據庫慢 SQL、Java Full GC、硬盤 IO 過大、CPU 飆高、內存不足……
3、安全問題。被網絡攻擊，如 DDoS 等。
4、運維問題。系統總是在被更新和修改，架構也在不斷地被調整，監控問題……
5、管理問題。沒有梳理出關鍵服務以及服務的依賴關係，運行信息沒有和控制系統同步……
6、硬件問題。硬盤損壞、網卡出問題、交換機出問題、機房掉電、挖掘機問題……
故障不可避免
管理好一個分佈式系統是一件非常難的事。對於大規模的分佈式系統，出現故障基本上就是常態，甚至還有些你根本就不知道會出問題的地方。在今天來說，一個分佈式系統的故障已經非常複雜了，因爲故障是分佈式的、多米諾骨牌式的。
所以，要充分地意識到下面兩個事。
故障是正常的，而且是常見的。
故障是不可預測突發的，而且相當難纏。
因爲我們要乾的事兒就是想盡一切手段來降低 MTTR——故障的修復時間。
這就是爲什麼我們把這個設計叫做彈力（Resiliency）。
一方面，在好的情況下，這個事對於我們的用戶和內部運維來說是完全透明的，系統自動修復不需要人的干預。
另一方面，如果修復不了，系統能夠做自我保護，而不讓事態變糟糕。
這就是所謂的“彈力”——能上能下。