hystrix停止维护_深入了解Hystrix弹性维护

最新推荐文章于 2024-04-22 12:22:44 发布

danpu0978

最新推荐文章于 2024-04-22 12:22:44 发布

阅读量837

点赞数

文章标签：网络 java 多线程 linux 分布式

原文链接：https://www.javacodegeeks.com/2017/09/deep-dive-hystrix-resiliency-maintenance.html

版权

hystrix停止维护

在我之前的《微服务教程》中，我展示了如何将Hystrix用作断路器，以及如何使我们的服务有喘息的空间来恢复自我。

在本教程中，我们将深入研究Hystrix架构，最终我们将了解它如何管理复杂系统中的弹性。

假设在一个复杂的系统中有100多个微服务，要执行任何业务功能或多或少，它取决于5-10个基础微服务（大约）。

通常，在上述基于微服务的体系结构中发现三种类型的服务：

核心服务
聚合服务
边缘服务

Edge服务从UI /客户端接收请求的地方，将其转发到Aggregator服务。然后，聚合器服务将请求散开，并将调用发送到核心服务，最终从核心服务收集响应，然后发送回边缘服务，该服务实际上将响应发送到UI /客户端。

想象一下，我们有一个复杂的基于微服务的系统，其中单个传入请求将分发超过10个相关服务。一个请求拆分为10个内部请求（扇出）并转到单个核心服务。在高峰时间内，每秒钟有100个并发请求。

因此，每秒将创建100 * 10 = 10000个内部请求。考虑一下系统的负载。甚至一分钟的核心服务延迟响应都会造成瓶颈，因为在Web服务器（Tomcat，Jetty）中，线程池中的线程数是固定的。

60 * 100 * 1 = 6000个请求正在等待单个服务一分钟。因此，即使您有99.99％的服务正常运行时间，我们也可以假设失败是不可避免的，因为当我们进行服务调用时，我们必须依赖于两个外部实体Network和Socket，而可悲的是，对网络的控制不在开发人员手中。为了使系统具有弹性，我们必须应对这种现象并根据其进行计划。

现在，让我们看看解决上述情况所需的选项。

非阻塞请求：如果不管服务是否可用，请求都没有在等待服务，则只有所有请求都将被服务或拒绝。如果我们遵循此方法，则等待队列中将没有请求，就好像该服务不可用或没有立即延迟响应一样，该请求将被拒绝，并且回退/默认响应将提供给调用方服务。

因此，请求已短路，并且调用了回退路径-依赖服务获得了恢复自身的机会。我们知道Hystrix会为我们做这些事情。但这并不是一件容易的事。在内部，Hystrix维护了复杂的流程以提供弹性微服务架构。

我们现在将讨论该工作流程。

深入了解Hystrix工作流程

ThreadPool： Hystrix维护线程池，以便当服务调用另一个服务时-该调用将分配给该线程池中的一个线程。基本上，要处理并发性，它提供了辅助线程。每个线程都有一个超时限制。如果在提到的“线程超时”之内未返回响应，则该请求将被视为失败，并将调用后备路径。

网络和套接字超时：当服务调用另一个服务时，发生了两件事：数据通过网络传输，服务通过套接字相互通信。当数据通过网络传输时，它必须跨越多个跃点，因此，如果跃点变慢或变慢，我们就会感觉网络变慢。因此，我们必须计算请求/响应行程时间的平均时间以及Socket读/写时间，才能以最佳方式计算线程超时。

Hystrix工作流程：

当服务调用相关服务时，Hystrix介入并检查Hystrix电路是否打开。如果它是打开的，则返回到后备路径。
如果Circuit未打开，则Hystrix会检查池中是否所有工作线程都在使用中。如果是这样，它将立即返回并调用后备路径。
如果线程在池中可用，则它将分配一个空闲线程，并等待相关服务的响应。如果响应时间大于线程超时，则它将再次调用后备路径。
如果一切顺利，则实际响应将返回给呼叫者服务。
如果在一定时间内（默认为10秒），请求的50％失败，则Hystrix断开电路。

明智地选择“线程池”和“线程超时”非常重要，除非出现必要的影响。如果线程池数很大，则可以说它大于数据库连接线程池，那么尽管有hystrix，所有Connection仍被服务再次占用。如果线程池数较少，则我们不能同时处理许多请求，因为这可能会导致性能下降。因此，请根据您的系统配置选择线程池计数。

超时也是如此。如果超时很大，则队列中将有更多传入请求。但是，如果超时很短，那么即使您的服务运行良好，所有呼叫也都将超时，因为服务的平均响应时间大于超时。

结论

如今，无论您为项目选择哪种体系结构（微服务/独占），弹性都是最重要的标准。拥有它不是一个很好的附加功能，现在是一等公民。

因此，复原力是必不可少的-在计划和开发项目时，还请考虑一下复原力。想想如何提供弹性架构。有许多策略可以实现弹性，例如请求超时，最大重试次数，失败率等。因此，在开发项目时，请识别资源密集型区域，尝试以这种方式进行构建，以免发生资源浪费。另外，提供回退机制，这样您就可以避免级联故障并最终获得一个可靠的系统。