服務的容災與容錯

引子

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

容災：是指系統冗餘部署，當一處因爲意外中止工做，整個系統應用還能夠正常工做。

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

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

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

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

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

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

 

服務的容災

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

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

這個備份的冷備和熱備不一樣於數據庫的冷備和熱備。數據庫的冷備是離線備份，就是不接收新流量的狀況下備份。熱備是一邊接收流量一邊備份。

而一般服務的冷備是服務尚未接收流量。而熱備是指備份數據也在接收流量，好比負載均衡或者master-slave模式的slave承擔讀流量的副本。這些熱備因爲一直在運行因此避免了要切換前的服務檢查等步驟，能夠快速切換。

 

服務的容錯

道

Everything fails!

法

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

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

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

術

隔離術

1>領域拆分解耦

    ACL防止損壞層

    有界上下文

    提煉核心、支撐和通用域

    分層架構

     CRUD增刪改查簡單架構

    CQRS命令查詢隔離

    依賴消弱控

2>服務部署隔離

    環境拆分

    機房隔離

    通道隔離

    單元化

    泳道

    熱點隔離

    讀寫隔離

    容器隔離

    拆庫拆表

    動靜隔離

    非核心流量隔離

3>服務間交互隔離

    熔斷降級

4>服務內資源隔離

    線程池隔離

    信號量隔離

風險巡檢術

慢查詢

超時治理

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

系統破窗戶

廢棄代碼資源治理

系統異常治理

告警治理

數據一致性治理

穩定性設計術

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

 

器

超時重試：推薦spring-retryer

熔斷：推薦hystrix

限流：推薦Guava RateLimiter

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