响应式微服务 in java 译 <十三> Stability and Resilience Patterns

摘要: 响应式微服务 in java

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/


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