微服务熔断问题的业务场景：如何预防一个服务故障影响整个系统？

熔断

上篇讲了微服务的全链路日志问题，本篇就来谈谈所有微服务会遇到的第二个问题——熔断。

可能你有个疑问：熔断不是流量大时才会出现吗？前面所讲场景的流量并不大，应该不用考虑熔断的问题吧？其实不是的，这里存在一定误区。

先介绍一下业务场景。

业务场景：如何预防一个服务故障影响整个系统

在一个新零售架构系统中，有一个通用用户服务（很多页面都会使用），它包含两个接口。

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默认自带的，项目组很多人都看过相关文档。

本文给大家讲解的内容是基于常见组件的微服务场景实战，熔断，业务场景：如何预防一个服务故障影响整个系统+覆盖场景+Sentinel和Hystrix