turbine

1：SpringCloud中使用： 1.1：加入依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> </dependency> 1.2：启动类上添加 @SpringBootApplication @EnableHystrixDashboard @EnableCircuitBreaker //@EnableHystrix 1.3：Controller上配置 在Controller的方法上添加Hystrix的配置，形如： @HystrixCommand(fallbackMethod = "error

一:为什么需要Hystrix? 在大中型分布式系统中，通常系统很多依赖(HTTP,hession,Netty,Dubbo等)，如下图: 在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等. 如下图：QPS为50的依赖 I 出现不可用，但是其他依赖仍然可用. 当依赖I 阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性.如下图: 在复杂的分布式架构的应用程 序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。 例如: 一个依赖30个SOA服务的系统,每个服务99.99%可用。 99.99%的30次方 ≈ 99.7% 0.3% 意味着一亿次请求 会有 3,000,00次失败 换算成时间大约每月有2个小时服务不稳定. 随着服务依赖数量的变多，服务不稳定的概率会成指数性提高. 解决问题方案:对依赖做隔离,Hystrix就是处理依赖隔离的框架,同时也是可以帮我们做依赖服务的治理和监控. Netflix 公司开发并成功使用Hystrix,使用规模如下: The Netflix API processes 10+ billion HystrixCommand executions per day using thread

阅读源码的过程，就像是在像武侠小说里阅读武功秘籍一样，分析高手的一招一式，提炼出精髓，来增强自己的内力。 之前的帖子说了一下 微服务的雪崩效应和常见的解决方案 ，太水，没有上代码怎么叫解决方案。 github 上有很多开源的库来解决 雪崩问题 ，比较出名的是 Netflix 的开源库 hystrix 。集 流量控制 、 熔断 、 容错 等于一身的 java 语言的库。今天分析的源码库是 hystrix-go ，他是 hystrix 的的 go 语言版，应该是说简化版本，用很少的代码量实现了主要功能。很推荐朋友们有时间读一读。 使用简单 hystrix 的使用是非常简单的，同步执行，直接调用 Do 方法。 err := hystrix.Do("my_command", func() error { // talk to other services return nil }, func(err error) error { // do this when services are down return nil }) 异步执行 Go 方法,内部实现是启动了一个 gorouting ，如果想得到自定义方法的数据，需要你传 channel 来处理数据，或者输出。返回的 error 也是一个 channel output := make(chan bool, 1) errors :=

问题一、请求 /hystrix.stream 报错，我这里以端口9001为例 　　请求 http://localhost:9001/hystrix.stream 报404 　　 　 　是因为Srping Boot 2.0以后仪表盘的默认路径不在是 /hystrix.stream，这时就需要我们自己去设置，在主类中添加以下代码： 　　@Bean public ServletRegistrationBean getServlet() { HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet(); ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet); registrationBean.setLoadOnStartup( 1 ); registrationBean.addUrlMappings( "/hystrix.stream" ); registrationBean.setName( "HystrixMetricsStreamServlet" ); return registrationBean; } 　　 重启项目，访问 http://localhost:9001

之前我们引入过dashboard 配置项，暴露正常可以访问的安全的端口， 启动类，之前加的dashBoard的注解 如果想用集群监控就必须继承Turbine。Hystrix的监控弊端比较大，所以一般来讲，微服务里面，我们绝大多数不会用Hystrix去做监控，实在是很麻烦的一件事情。 所以这给大家演示一下， 开始在加载一次数据了，监控还是比较耗性能的。 我们用postman多访问几次请求 页面就开始有数据了 随着点击，数字在增加 nowPage传比较正常的 dashboard的图的意思 强调这两个 理论上系统的峰值大概就是99这个级别。 在互联网项目里，这三个数是非常重要的指标。 当你的请求越多，这个圈就会越大，请求里面错误数越多，就会偏向于红色，全红的时候就是全错。 Hystrix里面默认就是2分钟之内的监控，我们正式的系统一般都是需要一个长期的监控，例如我希望能看到历史数据。看到告警，应该怎么处理，为什么出现告警，这些都是我们需要反向去排查的 东西，例如双11这种情况，你2分钟之内的监控还能有用。 结束 来源： oschina 链接： https://my.oschina.net/u/4369262/blog/4267757