聊聊微服务架构中的雪崩效应及其解决方案

网站雪崩根本原因

在大型互联网站建设过程中，网站的性能都是受服务器主机性能约束的，比如CPU、GPU、RAM等硬件设备。由于当前计算机硬件技术的支持有限，高性能服务器的成本巨大，我们在网站搭建过程中，需要通过软件手段来控制网站雪崩效应，Hystrix可以帮我们保护服务，实现网站的高可用性。

高并发场景示例

比如同时有10000个用户提交订单，由订单服务order的submitOrder()去处理，订单服务order所在的服务器主机配置很低，tomcat线程池最大数设置为20。每个请求占用一个线程，使用完毕后才会释放，那么线程池的线程会被全部占用，剩下的请求进入缓存队列，排队等待线程分配。如果这种等待时间过长，会产生如下可能问题：

• 订单服务order的submitOrder()如果调用了其他服务会员服务、商品服务等，也可能会导致其他服务的线程池用尽，导致整个相关联的服务都不可使用

• 服务器主机的CPU会长时间的高负载运行，产生物理发热，最后操作系统可能会为了保护主机硬件，杀掉服务进程或者操作系统自身运行也会处于等待过程而发生卡死现象，导致订单服务order无法运行，从而发生服务宕机

  
  
  高并发场景示例图.png

高并发雪崩效应解决方案

我们一定要明白，服务性能的瓶颈在于硬件设备，所有软件手段，只能帮助我们尽可能的高效的使用服务器主机资源，比如提升CPU使用率等。
我们知道能量守恒定律，软件手段不可能完美的解决高并发问题，肯定伴随了一些其他的牺牲。比如下面的解决方案，总会伴随着一些其他的牺牲，以少换多，以少换稳，符合道德标准，是人们可以接受的方案。

• 服务隔离
  现在我们了解了服务等待的直接原因是因为一个tomcat线程被占用完后，其他请求需要进入队列排队等候。在不考虑服务器主机性能瓶颈的情况下，我们可以给订单服务order的submitOrder服务和otherServer单独创建线程池，当submitOrder出现高并发时，otherServer拥有自己对立的线程池，不受submitOrder线程用尽的影响。
  方式：创建独立线程池是最常用的服务隔离技术，另一种信号量的方式用的较少
  注意：创建独立线程池，必须在部署服务启动时创建出来
• 服务熔断
  当服务出现高并发时，为了保护服务，避免雪崩，服务会拒绝请求访问
• 服务降级
  当服务熔断后，为了提升用户体验，走降级fallback方法，给用户一个友好提示，如：xx走神了，请稍后再试
• 服务限流
  大量请求同时请求一个服务时，需要做服务限流，满足规则的允许访问，否则走服务熔断降级。使用场景比如秒杀系统（系统主动提供的高并发访问服务），网站攻击（被动接收大量请求）。
  常用的限流解决方案有两种：
  1 代码层面：算法有计数器、令牌桶、漏桶
  2 应用层nginx解决限流