springcloud入门——Hystrix服务降级

目录

1.服务雪崩

2.Hystrix是什么

3.服务降级

4.构建服务器忙环境

5.Hystrix之服务降级支付侧fallback 

6.Hystrix之服务降级订单侧fallback 

7.全局服务降级DefaultProperties

8.通配服务降级FeignFallback

1.服务雪崩

分布式系统面临的问题：复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”（即形成了一条调用链A-B-C）。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.
对于高流量的应用来说，单一的后避依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。

2.Hystrix是什么

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

"断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应（FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
目前，Hystric已进入停更阶段。

3.服务降级

服务降级：服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好提示，fallback。

简单来说，就是不让服务器卡死，不会被长时间的占用，显示一个错误页面。

4.构建服务器忙环境

Hystrix支付微服务构建：

首先需要恢复eureka7001单机模式，取消eureka集群。

新建payment-hystric模块。

然后需要修改pom文件，引入Hystrix jar包：

编写业务类，包括调用成功和调用失败的方法，超时方法内设置模拟超时3S：

编写控制类：

6.正常测试

启动eureka7001——>启动cloud-provider-hystrix-payment8001——>访问

success的方法 - http://localhost:8001/payment/hystrix/ok/1
每次调用耗费5秒钟 - http://localhost:8001/payment/hystrix/timeout/1

以上述为根基平台，从正确 -> 错误 -> 降级熔断 -> 恢复

高并发压测：

此处我们使用Jmeter：Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试。 它可以用于测试静态和动态资源，例如静态文件、CGI 脚本、Java 对象、数据库等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能和回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。

具体测试步骤如下：

Jmeter压测结论

上面还是服务提供者8001自己测试，假如此时外部的消费者80也来访问，那消费者只能干等，最终导致消费端80不满意，服务端8001直接被拖慢。

客户端Order调用支付服务出现卡顿：

同理，建立Cloud-consumer-feign-hystrix-order模块。

具体步骤同上：修改pom文件，引入依赖；编写yml文件；新建service接口，使用feign注解调用payment中接口的服务；编写controller类；主启动类；高并发测试。

启用2W个线程压8001，消费端80微服务再去访问正常的Ok微服务8001地址http://localhost/consumer/payment/hystrix/ok/32，消费者80被拖慢。

原因：8001同一层次的其它接口服务被困死，因为tomcat线程池里面的工作线程已经被挤占完毕。

正因为有上述故障或不佳表现才有我们的降级/容错/限流等技术诞生。

对于以上错误：

解决：

• 对方服务(8001)超时了，调用者(80)不能一直卡死等待，必须有服务降级。
• 对方服务(8001)down机了，调用者(80)不能一直卡死等待，必须有服务降级。
• 对方服务(8001)OK，调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者)，自己处理降级。

5.Hystrix之服务降级支付侧fallback 

首先，从8001先从自身找问题：

设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处埋，作服务降级fallback。

编写service类，在此处通过注解指定兜底的方法，并编写该方法；

再通过@HystrixCommand注解的HystrixProperty属性指定多少时间启动兜底方法（此处为3s）

具体如下：

编写主启动类：

测试，结果如下，成功返回兜底页面：

配置服务器异常（比如被除数为0），也可以成功返回兜底方法，具体流程一样。

6.Hystrix之服务降级订单侧fallback 

修改yml文件，使得feign支持hystrix：

修改控制类,在控制类处添加HystrixCommand注解，具体用法与支付端相同：

同理，主启动添加注解@EnableCircuitBreak，再进行测试：

7.全局服务降级DefaultProperties

目前问题：每个业务方法对应一个兜底的方法，代码膨胀

解决方法

1:N除了个别重要核心业务有专属，其它普通的可以通过@DefaultProperties(defaultFallback = “”)统一跳转到统一处理结果页面。通用的和独享的各自分开，避免了代码膨胀，合理减少了代码量

配置方法：

在控制类中通过注解来配置并制定全局的fallback方法：

并在控制类中编写该方法：

在启动该服务兜底方法的方法上添加注解：

通配成功。

8.通配服务降级FeignFallback

通过全局配置fallback后我们又会遇到新的问题：统一和自定义的分开，代码混乱。

未来我们要面对的异常：运行、超时、宕机

本次案例服务降级处理是在客户端80实现完成的，与服务端8001没有关系，只需要为Feign客户端定义的接口（即paymentfeignservice类）添加一个服务降级处理的实现类即可实现解耦.

下面我们模拟服务降级，客户端去调用服务端，碰上服务端宕机或关闭。

1.首先，编写一个业务降级类继承我们的调用接口，用以处理接口调用方法中的异常问题，调用对应的降级方法，如下：

2.接着，我们要在接口类的@Feign注解中指定异常处理的fallback方法的所在类：

再次确定，我们的feign已经支持

最后，我们进行测试，关闭8001服务，页面成功返回fallback方法。

最后

以上就是故意路灯为你收集整理的springcloud入门——Hystrix服务降级的全部内容，希望文章能够帮你解决springcloud入门——Hystrix服务降级所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。