[译]Hystrix的简单介绍

标签: | 发表时间:2015-10-14 00:10 | 作者:supercrsky
出处:http://blog.csdn.net/supercrsky
最近几天我直在探索Netflix Hystrix library,领会到了这个优秀类库提供的特性。

引用Hystrix网站的原话:
   Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, 
services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where 
failure is inevitable.
   Hystrix通过控制那些访问远程系统、服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力,阻止故障的连锁反应

,并允许你快速失败并迅速恢复。

这里有很多要分析的关键词,然而体验Hystrix的最佳方式就是亲手做一个例子来试试。

一个不可预测的服务

考虑一个服务,一个携带json结构信息并且返回一个确认的奇怪服务。
{
    "id":"1",
    "payload": "Sample Payload",
    "throw_exception":false,
    "delay_by": 0
}

这个服务有一个payload属性,但是额外多带了两个属性。
delay_by 在延迟到达指定的毫秒数后返回一个确认响应。
throw_exceptions 在指定的延迟后导致异常

下面是响应例子:
{
 "id":"1",
 "received":"Sample Payload",
 "payload":"Reply Message"
}

这里是我的 github地址,可以下载示例代码。在这个例子中我用到了 Netflix Karyon2 ,示例代码处理请求的部分非常简洁。来看看
这个类库用在这是多好用吧:

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来进行调用,这是另一个很棒的类库,需通过注解方式来使用:
package aggregate.service;


import aggregate.domain.Message;
import aggregate.domain.MessageAcknowledgement;
import feign.RequestLine;


public interface RemoteCallService {
    @RequestLine("POST /message")
    MessageAcknowledgement handleMessage(Message message);
}

在这几行中,它创建了一个代理,其实现了使用配置的接口。

RmoteCallService 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的例子

在第一个例子中,考虑不用Hystrix来调用这个远程服务,如果我尝试以以下方式调用
http://localhost:8888/noHystrix?message=Hello&delay_by=5000&throw_exception=false或 
http://localhost:8888/noHystrix?message=Hello&delay_by=5000&throw_exception=true,
在这两种实例中用户对服务的请求都会在等待5秒后才会收到响应。

有些事情在这里就立即很明显了:

1.如果服务响应缓慢,那么客户对服务的请求就会被强制等待到服务返回。

2.在高负载下,很有可能所有处理用户请求的线程资源被耗竭,而不能响应用户的进一步请求。

3.如果服务抛出异常,客户端不能很好的处理。


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秒延迟,在到了75%的时候,延迟竟然达到了25秒。现在来看一下用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控制台视图。

这里的前10个请求已经超时,任何超过Hystrix默认时间1秒的,一但前10个交易失败后,命令就会堵塞其他客户对远程服务的请求。
,因此会有较低的响应时间。为什么这些交易没有显示失败呢,这是因为这里会有一个反馈,优雅的告诉用户请求失败了。
作者:supercrsky 发表于2015/10/13 16:10:46 原文链接
阅读:6 评论:0 查看评论

相关 [hystrix] 推荐:

Hystrix 使用与分析

- - ITeye博客
 转载请注明出处哈:http://hot66hot.iteye.com/admin/blogs/2155036. 一:为什么需要Hystrix?. 在大中型分布式系统中,通常系统很多依赖(HTTP,hession,Netty,Dubbo等),如下图:. 在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢,资源繁忙,暂时不可用,服务脱机等..

[译]Hystrix的简单介绍

- - 上善若水 厚德载物
最近几天我直在探索Netflix Hystrix library,领会到了这个优秀类库提供的特性. 引用Hystrix网站的原话:.    Hystrix通过控制那些访问远程系统、服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力,阻止故障的连锁反应. ,并允许你快速失败并迅速恢复. 这里有很多要分析的关键词,然而体验Hystrix的最佳方式就是亲手做一个例子来试试.

使用Hystrix提高系统可用性

- - Juven Xu
今天稍微复杂点的互联网应用,服务端基本都是分布式的,大量的服务支撑起整个系统,服务之间也难免有大量的依赖关系,依赖都是通过网络连接起来. (图片来源:https://github.com/Netflix/Hystrix/wiki). 然而任何一个服务的可用性都不是 100% 的,网络亦是脆弱的. 当我依赖的某个服务不可用的时候,我自身是否会被拖死.

隔离术之使用 Hystrix 实现隔离

- - IT瘾-dev
本篇摘自《亿级流量网站架构核心技术》第三章 隔离术 部分内容,全文. 商品详情页系统的Servlet3异步化实践. Hystrix是Netflix开源的一款针对分布式系统的延迟和容错库,目的是用来隔离分布式服务故障. 它提供线程和信号量隔离,以减少不同服务之间资源竞争带来的相互影响;提供优雅降级机制;提供熔断机制使得服务可以快速失败,而不是一直阻塞等待服务响应,并能从中快速恢复.

使用hystrix保护你的应用 - Kris的博客 | Kris' Blog

- -
凡是可能出错的事必定会出错. hystrix([hɪst'rɪks])是豪猪的意思. 豪猪是一种哺乳动物,全身是刺用以更好的保护自己. netflix使用这畜生来命名这框架实在是非常的贴切,意味着hystrix能够像豪猪的刺一样保护着你的应用. 本文专门探讨netflix的hystrix框架. 首先会说明在一次请求中调用多个远程服务时可能会出现的雪崩问题,然后提出几个解决这些问题的办法,从而引出了hystrix框架;之后我们会给出一个简单的例子试图说明hystrix是如何解决上述问题的;文章主要探讨了线程池隔离技术、信号量隔离技术、优雅降级、熔断器机制.

使用Hystrix完成熔断、限流和降级 - Blog of Kami Wan

- -
2.2 雪崩效应形成的原因. 2.2.1 服务提供者不可用原因. 2.2.3 服务调用者不可用. 3.2 Hystrix在spring boot中的使用. 为了保证系统不被突发流量击垮,进行容量保障是十分有必要的. 从架构的稳定性角度看,在有限资源的情况下,所能提供的单位时间服务能力也是有限的. 假如超过承受能力,可能会带来整个服务的停顿,应用的Crash,进而可能将风险传递给服务调用方造成整个系统的服务能力丧失,进而引发雪崩.

Hystrix熔断器技术解析-HystrixCircuitBreaker - 简书

- -
一、熔断器(Circuit Breaker)介绍. 熔断器,现实生活中有一个很好的类比,就是家庭电路中都会安装一个保险盒,当电流过大的时候保险盒里面的保险丝会自动断掉,来保护家里的各种电器及电路. Hystrix中的熔断器(Circuit Breaker)也是起到这样的作用,Hystrix在运行过程中会向每个commandKey对应的熔断器报告.

Hystrix使用入门手册(中文) - 简书

- -
导语:网上资料(尤其中文文档)对hystrix基础功能的解释比较笼统,看了往往一头雾水. 为此,本文将通过若干demo,加入对. 官网How-it-Works的理解和翻译,力求更清晰解释hystrix的基础功能. 官网How-To-Use进行了二次修改,见. Hystrix是Netflix开源的一款容错系统,能帮助使用者码出具备强大的容错能力和鲁棒性的程序.