hystrix熔断简介_Hystrix简介

hystrix熔断简介

在过去的几天里，我一直在探索Netflix Hystrix库，并欣赏了这个出色的库所提供的功能。

引用Hystrix网站上的内容：

Hystrix是一个延迟和容错库，旨在隔离对远程系统，服务和第三方库的访问点，停止级联故障，并在不可避免发生故障的复杂分布式系统中实现弹性。

这里有很多关键字可以解析，但是在我看来，体验Hystrix的最佳方法是尝试一个示例用例。

不可预测的服务

考虑一个服务，一个奇怪的服务，它接受具有以下结构的json消息并返回确认：

{"id":"1","payload": "Sample Payload","throw_exception":false,"delay_by": 0
}

该服务接收有效负载，但另外还接收两个字段：delay_by使服务在延迟（以毫秒为单位）后确认响应，而“ throw_exceptions”字段将在指定的延迟后导致异常！

这是一个示例响应：

{"id":"1","received":"Sample Payload","payload":"Reply Message"
}

如果您一直遵循，这是该示例的 github存储库，本示例已使用Netflix Karyon 2 ，并且可以通过以下方式非常简洁地表达处理请求的代码–了解如何放置rx-java库在这里很好地利用：

import com.netflix.governator.annotations.Configuration;
import rx.Observable;
import service1.domain.Message;
import service1.domain.MessageAcknowledgement;import java.util.concurrent.TimeUnit;public class MessageHandlerServiceImpl implements MessageHandlerService {@Configuration("reply.message")private String replyMessage;public Observable<MessageAcknowledgement> handleMessage(Message message) {logger.info("About to Acknowledge");return Observable.timer(message.getDelayBy(), TimeUnit.MILLISECONDS).map(l -> message.isThrowException()).map(throwException -> {if (throwException) {throw new RuntimeException("Throwing an exception!");}return new MessageAcknowledgement(message.getId(), message.getPayload(), replyMessage);});}}

在这一点上，我们有一个很好的候选服务，可以使其响应任意延迟和失败。

服务的客户

现在转到此服务的客户端。我正在使用Netflix Feign进行此调用，这是另一个很棒的库，它所需要的只是用以下方式注释的Java接口：

package aggregate.service;import aggregate.domain.Message;
import aggregate.domain.MessageAcknowledgement;
import feign.RequestLine;public interface RemoteCallService {@RequestLine("POST /message")MessageAcknowledgement handleMessage(Message message);
}

它使用以下几行的配置来创建实现此接口所需的代理：

RemoteCallService remoteCallService = Feign.builder().encoder(new JacksonEncoder()).decoder(new JacksonDecoder()).target(RemoteCallService.class, "http://127.0.0.1:8889");

我有多个终结点，这些终结点将呼叫委派给该远程客户端，所有这些终结点都沿以下方式显示url模式– http：// localhost：8888 / noHystrix？message = Hello＆delay_by = 0＆throw_exception = false ，第一个是终结点的示例不使用Hystrix。

没有Hystrix案例

作为第一个示例，如果我尝试调用http：// localhost：8888 / noHystrix？message = Hello＆delay_by = 5000＆throw_exception = false或说http：// localhost：8888 / ，请考虑在没有Hystrix的情况下调用Remote服务。 noHystrix？message = Hello＆delay_by = 5000＆throw_exception = true ，在这两种情况下，用户对端点的请求只会在响应之前挂起5秒钟。

这里应该立即显示一些事情：

如果服务响应缓慢，则客户端对服务的请求将被迫等待响应返回。
在高负载下，处理用户流量的所有线程很可能会用尽，从而使进一步的用户请求失败。
如果服务抛出异常，则客户端将无法正常处理该异常。

显然，需要像Hystrix这样的东西来处理所有这些问题。

Hystrix命令包装远程调用

我在前一个案例中使用了50个用户负载进行了一次小负载测试，结果如下：

================================================================================
---- Global Information --------------------------------------------------------
> request count                                         50 (OK=50     KO=0     )
> min response time                                   5007 (OK=5007   KO=-     )
> max response time                                  34088 (OK=34088  KO=-     )
> mean response time                                 17797 (OK=17797  KO=-     )
> std deviation                                       8760 (OK=8760   KO=-     )
> response time 50th percentile                      19532 (OK=19532  KO=-     )
> response time 75th percentile                      24386 (OK=24386  KO=-     )
> mean requests/sec                                  1.425 (OK=1.425  KO=-     )

从服务中延迟5秒实质上会导致25秒的第75个百分位时间！，现在考虑使用Hystrix命令包装服务调用进行相同的测试：

================================================================================
---- Global Information --------------------------------------------------------
> request count                                         50 (OK=50     KO=0     )
> min response time                                      1 (OK=1      KO=-     )
> max response time                                   1014 (OK=1014   KO=-     )
> mean response time                                    22 (OK=22     KO=-     )
> std deviation                                        141 (OK=141    KO=-     )
> response time 50th percentile                          2 (OK=2      KO=-     )
> response time 75th percentile                          2 (OK=2      KO=-     )
> mean requests/sec                                 48.123 (OK=48.123 KO=-     )

奇怪的是，现在第75个百分位数的时间是2毫秒！这是怎么可能的，使用Hystrix提供的出色工具，答案变得显而易见，这是此测试的Hystrix仪表板视图：

Hystrix-Remote失败