常用失敗控制模式

本文內容主要翻譯自Reactive Systems Architecture。

在分散式系統中，有元件發生故障造成對應服務失敗是很平常的一件事。這裡簡單闡述一下在發生這些錯誤時的一些常用處理模式。

失敗控制(failure control)的一個目標是在系統或他的一部分失敗的情況下如何實現期望的一致性和傳遞保證。在部分系統失敗的情況下，不影響到系統其他部分的穩定性。

但通常工程師不會意識到失敗是很自然的一件事。 - 只是記錄異常log 如果log不被人處理就一直保持失敗 - 一個服務持續的失敗可能導致來自於其他服務的過度重試，導致該服務被壓垮，也可能造成依賴他的服務的級聯失敗。 - 每個服務都有效能限制，過度訪問會造成服務失敗(DoS).

下面簡單介紹一下一些失敗處理的方式

隔離和擋板(Isolation and bulkheading)

隔離失敗 讓失敗不影響到其他系統
系統元件不要過度耦合
Hystrix

背壓Backpressure

生產者根據消費者的消費步調來調整自己的生產速度
一般採用消費者(伺服器)去獲取內容(佇列裡面拿請求) 而不是生產者(客戶端)去推送到消費者(伺服器)
Akka Streams
Apache Spark Streaming
簡單點的做法是用限流(RateLimiter)的方式 丟棄多餘的請求

監督者（Supervision)

模組都會有一個監督者
元件掛了對應的監督者會收到通知 監督者會應用指定的策略去處理失敗
Akka

斷路器(Circuit breaker)

• 關閉狀態:呼叫失敗或超時會讓失敗計數增加 成功的呼叫置零計數器 當達到最大的失敗次數時 斷路器切換為開啟狀態

• 開啟狀態:所有呼叫立即返回失敗(斷路) 避免給掛了的服務增加額外壓力，造成聯機(比如大量呼叫超時 浪費客戶端資源)失敗。在經過配置時間之後 切換為半開狀態

• 半開狀態:放開一個呼叫檢視是否成功 成功了切換至關閉狀態。

部分執行(Partial execution)

呼叫幾個方法完成指定工作，其中有幾個呼叫失敗的情況。
事務保證: Atomic Broadcast 2PC
日誌保證:journalling或write ahead log
事務補償

服務降級(Service level degradation control)

系統出錯時大多數工程師會返回錯誤，這常常會導致服務的不可用。
通過提供部分的服務可用可以降低服務直接不可用的開銷。
fallback策略