经过前面一段时间的学习，我们对Nginx的知识有了一个基本的了解。我们今天来一起聊聊高并发场景下产生的服务雪崩问题，以及如何去解决该问题。在该篇你会学到如下内容：
- 什么是服务雪崩，产生的原因
- 怎么解决服务雪崩？服务熔断、降级、隔离的含义。
- 实战使用Hystrix进行服务熔断、降级、隔离。
0x01 浅谈服务雪崩
- 什么是服务雪崩？
- 简单来说，服务雪崩就是A服务依赖B服务，但是在高并发场景下，B服务有大量访问堆积，导致B服务资源紧张，处理缓慢，从而导致A服务不可用，然后逐步放大，最后导致整个系统不可用的一种现象。可以简单理解为蝴蝶效应。
- 为什么会产生服务雪崩？
- 请求量增大，资源紧张
- 因为同一台服务器里面的服务访问是在同一个线程池中，我们知道线程池大小是固定的，如果用户大量请求服务，会导致线程池线程不够用，最后都会堆积在阻塞队列，等待处理。这时候，如果用户再访问改服务器的另一个服务时，会因为无线程可用，而导致错误，从而产生服务雪崩。
- 服务内部逻辑bug
- 这个就很好说了。还是拿A、B两个服务来说，同样是A服务调用B服务，如果B服务中内部逻辑有问题，就会导致A一直在等待B服务的返回，而调用A服务的模块，就会一直等待A服务的返回，慢慢堆积，等到了一定程度(资源耗尽)就会产生服务雪崩。
- 请求量增大，资源紧张
- 服务雪崩产生过程
上图为我们的服务关系，由图可得知服务A和服务B依赖于服务C，而服务C又依赖于服务D。假设服务D因为内部原因，即服务故障，导致请求需要2s才能返回给服务C。图如下：
而服务D故障，服务A和服务B是不知道的，服务A和服务B还是会发请求到服务C。因为服务C依赖服务D，而服务D出现故障了，不能及时响应，所以服务A和服务B的请求会堆积在服务C，从而导致服务C运行缓慢，最后不可用。
最后因为C服务出现故障，从而也会导致服务A和服务B不可用。
这就是服务雪崩产生的过程，像蝴蝶效应一样，由点及面，最后造成整个系统不可用。
0x02 如何解决？
既然已经了解了服务雪崩的原理，怎么怎么解决他们呢？
- 服务熔断
- 概念：
- 简单来说，服务熔断就是在服务出现故障的时候，就不让请求再继续调用出故障的服务了，而是直接返回一个由我们定义的内容。就相当于保险丝一样，当电流过大的时候，保险丝就会烧断，从而断电进行保护。服务熔断也是一样，当服务错误率达到一个限定值，就会触发服务熔断，然后对服务进行降级，返回一个自定义提示给调用者，从而不需要让调用者傻傻的等待，提高体验。
- 概念：
- 服务降级
- 概念：
- 简单说，就是在服务熔断后，拒绝请求再对该服务进行访问。
- 概念：
- 服务隔离
- 概念：
- 显而易见，就是把服务进行隔离，使其独立。常见的隔离手段有：线程池隔离、信号量隔离。
- 线程池隔离
- 上面我们说过，产生雪崩的原因有一个是线程资源紧张，而线程池隔离，会为每个服务创建一个独立的线程池，这样就算是A服务所在的线程池资源紧张，也不会影响另一个服务执行。
- 缺点：线程切换开销大
- 信号量隔离
- 使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，当请求进来时先判断计数 器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则通行，这时候计数器+1，请求返 回成功后计数器-1。
- 缺点：不支持异步
- 线程池隔离
- 显而易见，就是把服务进行隔离，使其独立。常见的隔离手段有：线程池隔离、信号量隔离。
- 概念：
- 限流
0x03 使用Hystrix实现服务降级和隔离
- Hystrix简介：
- Hystrix 是一个微服务关于服务保护的框架，是Netflix开源的一款针对分布式系统的延迟和容错解决框架，目的是用来隔离分布式服务故障。它提供线程和信号量隔离，以减少不同服务之间资源竞争带来的相互影响；提供优雅降级机制；提供熔断机制使得服务可以快速失败，而不是一直阻塞等待服务响应，并能从中快速恢复。Hystrix通过这些机制来阻止级联失败并保证系统弹性、可用。
- Hystrix隔离方式：
- 线程池隔离
- 信号量隔离
- 具体Hystrix是怎么进行服务降级和隔离的，等后面学习微服务时再做补充。
0x04 总结
- 这一篇很水，都是概念性的东西，不过通过这一篇我们可以对服务雪崩有个大概的了解，以及如何去解决他们。
- 推荐几篇服务雪崩的文章
评论