熔断
上篇讲了微服务的全链路日志问题,本篇就来谈谈所有微服务会遇到的第二个问题——熔断。
可能你有个疑问:熔断不是流量大时才会出现吗?前面所讲场景的流量并不大,应该不用考虑熔断的问题吧?其实不是的,这里存在一定误区。
先介绍一下业务场景。
业务场景:如何预防一个服务故障影响整个系统
在一个新零售架构系统中,有一个通用用户服务(很多页面都会使用),它包含两个接口。
1)第一个是用户状态接口,包含用户车辆所在位置。它在用户信息展示页面都会用到,比如客服系统中的用户信息页面。
2)第二个接口用于返回给用户一个可操作的权限列表,它包含一个通用权限,也包含用户定制权限,而且每次用户打开App时都会使用它。
而这两个接口各自会碰到相应的问题,下面分别讨论。
第一个问题:请求慢
用户状态的接口、服务间的调用关系如图10-1所示。
在Basic Data Service(基础数据服务)中,接口/currentCarLocation需要调用第三方系统的数据,但第三方响应速度很慢,而且有时还会发生故障,导致响应时间更长,接口经常出现超时报错。
有一次,用户反馈App整体运行速度慢到无法接受的程度。运维人员通过后台监控查看了几个Thread Dump(线程转储),发现User API与Basic DataService的线程请求数接近极限值,且所有的线程都在访问第三方接口(3rdLocation API)。因为连接数满了,其他页面便不再受理User API的请求,最终导致App整体出现卡顿。
• 图10-1 涉及第三方接口的调用示意图
之前运维人员针对这个问题做过相关处理,考虑响应时间长,就把超时时间设置得很长,这样虽然超时报错少了,其他页面也保持正常,但是会导致客服后台查看用户信息的页面响应时间长。
第二个问题:流量洪峰缓存超时
用户权限的接口、服务间的调用关系与上面类似,如图10-2所示。
服务间的调用流程具体分为以下3个步骤。
1)APP访问User API。
2)User API访问Basic Data Service接口/commonAccesses。
3)Basic Data Service提供一个通用权限列表。因为权限列表对所有用户都一样,所以把它放在了Redis中,如果通用权限在Redis中找不到,再去数据库中查找。
接下来聊聊服务间的调用流程中笔者遇到过的一些问题。
有一次,因为历史代码的原因,在流量高峰时Redis中的通用权限列表超时了,那一瞬间所有的线程都需要去数据库中读取数据,导致数据库的CPU使用率升到了100%。
数据库崩溃后,紧接着Basic Data Service也停了,因为所有的线程都堵塞了,获取不到数据库连接,导致Basic Data Service无法接收新的请求。
而User API因调用Basic Data Service的线程而出现了堵塞,以至于UserAPI服务的所有线程都出现堵塞,即User API也停止工作,使得App上的所有操作都不能使用,后果比较严重。
• 图10-2 涉及缓存的服务调用示意图
覆盖场景
为了解决以上两个问题,需要引入一种技术,这种技术还要满足以下两个条件。
1.线程隔离
首先针对第一个问题进行举例说明。假设User API中每个服务配置的最大连接数是1000,每次API调用Basic Data Service的/currentCarLocation时速度会很慢,所以调用/currentCarLocation的线程就会很慢,一直不释放。那么 原 因 可 能 是 , User API 这 个 服 务 中 的 1000 个 连 接 线 程 全 部 都 在 调用/currentCarLocation这个服务。
因此,希望控制/currentCarLocation的调用请求数,保证不超过50条,以此保证至少还有950条连接可用于处理常规请求。如果/currentCarLocation的调用请求数超过50条,就设计一些备用逻辑进行处理,比如在页面上给用户提示。
2.熔断
针对第二个问题,因为此时数据库并没有死锁,流量洪峰缓存超时只是因为压力太大,所以可以使Basic Data Service暂缓服务、不接收新的请求,这样Redis的数据会被补上,数据库的连接也会降下来,服务也就没问题了。
总结一下,这个技术应能实现以下两点需求。
1)发现近期某个接口的请求经常出现异常时,先不访问接口的服务。
2)发现某个接口的请求总是超时时,先判断接口的服务是否不堪重负,
如果是,就先别访问它。
了解了这个技术需要满足的条件后,就可以有针对性地进行选型了。
Sentinel和Hystrix
目前可以解决以上需求的比较流行的开源框架有两个:一个是Netflix开源的Hystrix,Spring Cloud默认使用这个组件;另一个是阿里开源的Sentinel。两者的对比见表10-1。
表10-1 Sentinel和Hystrix的对比
这两个框架都能满足需求,但项目组最终使用了Hystrix,具体原因如下。
1)满足需求。
2)团队里有人用过Hystrix,并通读了它的源代码。
3)它是Spring Cloud默认自带的,项目组很多人都看过相关文档。