響應式微服務 in java 譯 <十三> Stability and Resilience Patterns

Stability and Resilience Patterns

在分佈式系統中，處理失敗是第一要素，你必須與他們一塊兒生活。你的微服務必須意識到它們調用的服務可能因爲許多緣由而失敗。微服務之間的每一次交互均可能會以某種方式失敗，您須要爲這種失敗作好準備，形成失敗多是不一樣的形式，從各類網絡錯誤到語義錯誤。

Managing Failures in Reactive Microservices

響應式微服務有責任負責管理本地故障，他們必須避免將故障傳播到另外一個微服務。換句話說，您不該該將「熱土豆」委託給另外一個微服務。所以，響應式微服務的代碼該考慮到了做爲一流公民的Failures。

Vert.x開發模型使故障成爲中心實體。當使用回調開發模型時，處理程序一般會接收一個 AsyncResult 做爲參數。此結構封裝異步操做的結果。在成功的狀況下，您能夠獲得結果，至於失敗，它包含一個 Throwable描述失敗的緣由：

當使用在 RxJava APIs 時，能夠在 subscribe 方法中進行失敗管理：

若是在一個 observed streams 中產生故障，則調用錯誤處理程序。您還能夠更早地處理故障，避免subscribe 方法中的錯誤處理程序：

管理錯誤並不有趣，但它必須作。reactive microservice 的代碼負責在遇到失敗時作出適當的決定，它還須要準備好看到它對其餘微服務的調用失敗。

 

Using Timeouts

在處理分佈式交互時，咱們常用超時。超時是一個簡單的機制，容許您在您認爲它不會到來時中止等待響應。設置好的超時提供故障隔離，確保失敗僅限於它所影響的微服務，並容許您處理超時並將執行以降級模式進行操做。

超時一般與重試一塊兒使用。當超時發生時，咱們能夠再試一次。當即進行故障診斷後，失敗後有必定迴應，但其中一些效果是有益的。若是因爲調用的microservice中存在一個重大問題而失敗，那麼若是當即重試，它可能再次失敗。然而一些瞬態故障，能夠經過重試來克服，特別是網絡故障，如丟棄消息。您能夠決定是否從新嘗試該操做，以下所示：

在分佈式系統中記住超時並不意味着操做失敗，調用方失敗的緣由不少。讓咱們來看看一個例子，您有兩個microservices，a和b。 a正在向b發送請求，可是響應沒有及時迴應，a會超時。在這種狀況下，可能發生三種類型的失敗：
    1.a和b之間的消息丟失了-操做沒有執行。

    2.b中的操做失敗--操做還沒有完成。

    3.b和a之間的響應消息丟失了-操做已經成功地執行了，可是a沒有獲得響應。

最後一種狀況每每被忽視，並且多是有害的。在這種狀況下，將超時與重試相結合可能會破壞系統的完整性。重試只能與冪等運算一塊兒使用，也就是說，對於運算，您能夠屢次調用，而不會在初始調用以後更改結果。在使用重試以前，始終檢查系統是否可以優雅地處理重試操做。

重試也使得消費者等待更長時間才能獲得響應，這也不是件好事。回退一般比重試操做太屢次數更好。此外，不斷地調用失敗的服務可能無助於它恢復正常。這兩個問題由另外一個彈性模式管理：斷路器（circuit breaker），後續在介紹這個。

未完待續！

原文地址：

https://developers.redhat.com/promotions/building-reactive-microservices-in-java/

有什麼討論的內容，能夠加我微信公衆號：