服務的容災與容錯

• 2020 年 3 月 17 日
• 筆記

引子

先介紹幾個概念，同步一下認知：

容災：是指系統冗餘部署，當一處由於意外停止工作，整個系統應用還可以正常工作。

容錯：是指在運行中出現錯誤（如上下游故障或概率性失敗）仍可正常提供服務。

可用性：描述的是系統可提供服務的時間長短。用公式來說就是A=MTBF/(MTBF+MTTR)，即正常工作時間/(正常工作時間+故障時間)。

可靠性：描述的是系統指定時間單位內無故障的次數。比如：一年365天，以天為單位來衡量。有天發生了故障，哪怕只有1秒，這天算不可靠。其他沒有故障的是可靠的。

穩定性：這個業界沒有明確的定義，我的理解是：在受到各種干擾時仍然能夠提供符合預期的服務的能力。

從要求的嚴格程度上：可用性<可靠性<穩定性。

可用性和可靠性更側重於容災，而對穩定性同時包含容災和容錯。

服務的容災

服務容災的解決方案就是冗餘。多幾個備份來切換。常用的有N+1容災和兩地三中心。N和中心實際上都是機房的意思。所謂中心就是數據中心。N是數據中心的電力配置部分。電力配置有市電和備用發動機供電，但是一般互聯網公司是不支援備用發動機供電的。所以一般一個機房就是一個N。

N+1容災就是要多出一個機房做容災。而兩地三中心，是提高了安全級別，除了同城兩個中心外，在異地再多出來一個中心。如果整個地區市電都不供電了，還有個備份。

這個備份的冷備和熱備不同於資料庫的冷備和熱備。資料庫的冷備是離線備份，就是不接收新流量的情況下備份。熱備是一邊接收流量一邊備份。

而通常服務的冷備是服務還沒有接收流量。而熱備是指備份數據也在接收流量，比如負載均衡或者master-slave模式的slave承擔讀流量的副本。這些熱備由於一直在運行所以避免了要切換前的服務檢查等步驟，可以快速切換。

服務的容錯

道

Everything fails!

法

服務容錯的難點在於存在未知和不可預測。所以對服務容錯要處理兩個問題：發現和解決。

可以自下而上和自上而下兩個角度來發現問題。自下而上主要是根據海因法則，從根本上解決遇到的每一個問題，以避免引起更大的問題。自上而下是系統化的思考，根據已知和可預測的，推演出未知和不可預測的。

在解決問題方面，衍生出很多派系。比如調研到阿里那邊更傾向於從流程上做把控：

術

隔離術

風險巡檢術

慢查詢

超時治理

依賴治理：消除依賴、弱化依賴、控制依賴

系統破窗戶

廢棄程式碼資源治理

系統異常治理

告警治理

數據一致性治理

穩定性設計術

請參考《穩定性三十六計》

器

超時重試：推薦spring-retryer

熔斷：推薦hystrix

限流：推薦Guava RateLimiter

spring cloud提供了超時重試、熔斷、限流的綜合解決方案