响应式微服务 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/

有什么讨论的内容，能够加我微信公众号：