面试官：为什么需要 Hystrix？.docxVIP

面试官：为什么需要 Hystrix？ 为什么需要hystrix Hystrix 官网地址 Github：/Netflix/Hystrix/ Hystrix同样是netfix公司在分布式系统中的贡献。同样的也进入的不维护阶段。不维护不代表被淘汰。只能说明推陈出新技术在不断迭代。曾今的辉煌曾经的设计还是值得我们去学习的。 在分布式环境中，服务调度是特色也是头疼的一块。在服务治理章节我们介绍了服务治理的功能。前一课我们也介绍了ribbon、feign进行服务调用。现在自然的到了服务监控管理了。hystrix就是对服务进行隔离保护。以实现服务不会出现连带故障。导致整个系统不可用 hystrix 对服务进行隔离保护 如上图所示，当多个客户端进行服务调用Aservice时，而在分布式系统中Aservice存在三台服务，其中Aservice某些逻辑需要Bservice处理。Bservice在分布式系统中部署了两台服务。这个时候因为网络问题导致Aservice中有一台和Bservice的通信异常。如果Bservice是做日志处理的。在整个系统看来日志丢了和系统宕机比起来应该无所谓了。但是这个时候因为网络通信问题导致Aservice整个服务不可用了。有点得不尝试。 系统雪崩 在看上图 。A--B--C--D 。此时D服务宕机了。C因为D宕机出现处理异常。但是C的线程却还在为B响应。这样随着并发请求进来时，C服务线程池出现爆满导致CPU上涨。在这个时候C服务的其他业务也会受到CPU上涨的影响导致响应变慢。 特色功能 Hystrix是一个低延迟和容错的第三方组件库。旨在隔离远程系统、服务和第三方库的访问点。官网上已经停止维护并推荐使用resilience4j：/resilience4j/resilience4j。?但是国内的话我们有springcloud alibaba。 Hystrix 通过隔离服务之间的访问来实现分布式系统中延迟及容错机制来解决服务雪崩场景并且基于hystrix可以提供备选方案(fallback)。 对网络延迟及故障进行容错 阻断分布式系统雪崩 快速失败并平缓恢复 服务降级 实时监控、警报 上面试官网给出的一个统计。在30台服务中每台出现异常的概览是0.01%。一亿个请求就会有300000失败。这样换算下每个月至少有2小时停机。这对于互联网系统来说是致命的。 服务雪崩的场景 上图是官网给出的两种情况。和我们上章节的类似。都是介绍服务雪崩的场景。 项目准备 在openfeign专题中我们就探讨了基于feign实现的服务熔断当时说了内部就是基于hystrix。当时我们也看了pom内部的结构在eureka中内置ribbon的同时也内置了hystrix模块。 引入hystrix 虽然包里面包含了hystrix 。我们还是引入对应的start开启相关配置吧。这里其实就是在openfeign专题中的列子。在那个专题我们提供了PaymentServiceFallbackImpl、PaymentServiceFallbackFactoryImpl两个类作为备选方案。不过当时我们只需指出openfeign支持设置两种方式的备选方案。今天我们  org.springframework.cloud spring-cloud-starter-netflix-hystrix 演示下传统企业没有备选方案的情况会发生什么灾难。 openfeign 使用 接口调用 接口测试 首先我们对payment#createByOrder接口进行测试。查看下响应情况 接口响应情况 在测试payment#getTimeout/id方法。 postman接口调用 jmeter压测 tomcat最大线程数测试 spring中默认的tomcat的最大线程数是200.为了保护我们辛苦的笔记本。这里我们将线程数设置小点。这样我们更容易复现线程被打满的情况。线程满了就会影响到payment#createByOrder接口。 现在我们用jmeter来压测payment#getTimeOut/id这个接口。一位需要4S等待会照成资源消耗殆尽问题。这个时候我们的payment#createByOrder也会被阻塞。 上面我们压测的是payment的原生接口。如果压测的是order模块。如果没有在openfeign中配置fallback。那么order服务就会因为payment#getTimeOut/id接口并发导致线程满了从而导致order模块响应缓慢。这就是雪崩效应。下面我们从两个方面来解决雪崩的发生。 业务隔离 上面的场景发生是因为payment#createByOrder 和payment#getTimeOut/id同属于payment服务。一个payment服务实