微服务模式(三):断路

我是兽兽,从事云计算的健身萌妹纸,不定期更新5G&IoT内容,更多好货可关注公号:5G物联网世界。

除了超时和回退之外,断路也是一种有用的微服务模式。当整个系统或其中的给定服务处于压力之下时,这一切都是关于快速失败和提供一种自动处理功能的方法。想象一个断路器。当一切正常时,断路器关闭,车流正常;然而,当事情发生故障时,断路器打开,交通被分流。现在想象一下在您的微服务体系结构中实现的概念。

微服务模式(三):断路

这是关于微服务模式的系列文章的第三部分。第1部分讨论了事件处理如何通过使用消息队列来解耦微服务。第2部分探索了帮助您处理服务集群转移的服务发现工具。在深入研究断路微服务模式(本系列最后一篇文章(目前)的主题)之前,让我们先研究几个模式,它们将帮助我们更好地理解断路模式。

微服务模式:超时

在与其他服务或数据存储进行通信时,超时是一种非常有用的模式。其思想是为服务的响应时间设置一个限制。如果在允许的时间内没有收到响应,则可以求助于编写的用于处理此故障的业务逻辑,例如重试或将故障消息发送回上游服务。超时可能是检测下游服务故障的唯一方法。然而,服务没有回复并不意味着服务没有接收和处理消息,或者它不存在。超时的关键特性是快速失败,并将此失败通知调用者。

这是一种很好的做法,原因有很多,不仅仅是从尽早返回客户端和不让他们无限期等待的角度来看。从负载和容量的角度来看,这也很有帮助。超时在大型分布式系统中是一个有效的卫生因素,在大型分布式系统中,一个服务的许多小实例通常是集群的,以实现高吞吐量和冗余。如果这些实例中的一个发生故障,而您连接到它,这可能会阻塞整个功能性服务。正确的方法是等待给定时间的响应;如果在此期间没有响应,则取消调用并尝试列表中的下一个服务。对于应该将超时设置为多长时间这个问题,没有简单的答案。我们还需要考虑网络请求中可能出现的不同类型的超时。您可能会有以下超时:

  • 连接超时——打开到服务器的网络连接所需的时间。
  • 请求超时——服务器处理请求所需的时间。

请求超时几乎总是这两种超时中持续时间最长的。我建议在服务的配置中定义超时。虽然您最初可能将其设置为任意值,比如10秒,但是您可以在系统在生产环境中运行之后以及在您有足够的事务时间数据集要查看之后修改它。

微服务模式:回退

通常,一旦连接失败,您不希望立即重试,以避免请求充斥网络或服务器。为了实现这一点,有必要在重试策略中实现回退方法。在第一次失败后重试之前,backoff算法将等待一段设置的时间。这将随着后续故障的增加而增加,直到设置的最大持续时间。

在客户端调用的API中使用这种策略可能不可取,因为它违背了快速失败的要求。但是,如果我们有一个只处理消息队列的worker进程,那么这可能正是为系统添加一点保护的正确策略。

微服务模式:断路

我们已经了解了一些模式,如超时和回退,它们有助于保护系统在停机时避免级联故障。然而,现在是时候引入另一种模式来补充这两种模式了。断路就是快速地失败。这是一种在系统处于压力下自动降级功能的方法。

让我们考虑一个前端web应用程序的示例,该应用程序依赖于下游服务来为用户可用的服务提供建议。由于此调用与主页加载同步,所以web服务器在成功返回建议之前不会返回数据。现在您已经为失败进行了设计,并为这个调用引入了5秒的超时。然而,由于推荐系统存在问题,一个通常需要20毫秒的调用现在需要5000毫秒才能失败。

每个查看服务的用户等待的时间都比平常长5秒;您的应用程序处理请求和释放资源的速度没有正常情况下快,并且它的容量显著降低。此外,由于处理单个页面请求所需的时间较长,到主网站的并发连接数量也有所增加。这就给前端增加了负载,而前端的速度开始变慢。如果推荐服务没有开始响应,那么整个站点将面临停机。

有一个简单的解决方案:停止尝试调用推荐服务,让网站恢复正常运行速度,并稍微降低服务页面的功能。这有三个影响:

  1. 将浏览体验还原给站点上的其他用户。
  2. 稍微降低一个领域的经验。
  3. 直接影响系统的业务,这就是为什么在实现电路中断模式之前必须与涉众进行对话的原因。

假设推荐增加了1%的转化率;但是,缓慢的页面加载会减少90%。降级1%而不是90%不是更好吗?这个例子很简单,但是如果下游服务是一个库存检查系统呢?如果有可能你没有库存来完成订单,你应该接受吗?

断路是如何工作的?

在正常运行情况下,就像你的电开关盒里的断路器一样,断路器是关闭的,车流正常。然而,一旦超过预定的错误阈值,断路器就进入打开状态,所有请求立即失败,甚至没有尝试。一段时间后,进一步的请求将被允许,电路进入半开放状态。在这种状态下,无论错误阈值是多少,失败都会立即返回到open状态。一旦一些请求被处理没有任何错误,电路再次返回到关闭状态,只有当失败的数量超过错误阈值,电路才会再次打开。

错误行为不是软件工程可以自己回答的问题;所有业务涉众都需要参与这个决策。在计划系统设计时,将失败作为非功能性需求的一部分进行讨论。提前决定当下游服务失败时要做什么。


分享到:


相關文章: