1、微服务故障背景
假设Tomcat线程池有100个线程, 每次有新的用户请求过来,Tomcat就会从中找出一个空闲的线程去执行, 抛开那些琐碎的小细节,这些请求其实非常简单, 无非就是这么几件事:
- 根据用户ID调用用户服务, 获取用户对象。
- 获取该用户的推荐商品
- 获取该用户的积分。
- 把这些信息组合起来,返回给浏览器。
有意思的是前三件事情全是HTTP调用,需要调用某个地方的所谓“微服务”:
比如线程A执行到“推荐服务”时,推荐服务没有立刻返回,导致推荐服务挂起,随着新用户请求的增加,线程池被耗完,那么Tomcat只能“系统繁忙、暂停营业”。虽然重启可能暂时解决问题,但问题可能还会重现。
2 隔离
怎么把一个微服务的故障给隔离起来呢?让他们互不影响呢?
Netflix的程序员们想了一个点子, 对每个微服务,都分配一个线程池,像这样:
比如说调用“推荐服务”的时候,就会从“推荐服务线程池” (假设有5个线程)中找到一个线程执行。如果这个HTTP系统调用迟迟没有返回,那这个线程就会一直等待,新的请求就需用使用池中别的线程。
如果5个“推荐服务”线程被耗光,可以人为这个服务不可用,需立即返回。
这些新的线程池,是一种隔离的手段, 一个微服务一旦出了问题,很快就会被识别出来。
3 熔断
所以Netflix的程序员又想了一个办法:使用熔断器(也叫断路器),注意:当这个熔断器关闭的时候,外面的请求可以直接调用,如果打开,就把外界的请求给阻断了。
具体的做法:系统会检测请求失败的比率(失败数/总请求数), 一旦这个比率达到一个阈值的时候,熔断器就开启, 直接拒绝执行用户请求。然后休眠一段时间,尝试放过一部分流量(比如一个请求),如果调用成功,熔断器闭合,恢复到正常状态,否则继续进行休眠周期。
熔断机制状态转移图如下:
主要在三种状态中转换:
关闭状态 :当熔断器处于关闭状态时,请求是可以被放行的;
当熔断器统计的失败次数触发开关时,转为打开状态。
打开状态 :当熔断器处于打开状态时,所有请求都是不被放行的,直接返回失败;
只有在经过一个设定的时间窗口周期后,熔断器才会转换到半开状态
半开状态 :当熔断器处于半开状态时,当前只能有一个请求被放行;
这个被放行的请求获得远端服务的响应后,假如是成功的,熔断器转换为关闭状态,否则转换到打开状态。