熔断机制：预防一个服务故障导致整个系统崩掉

问题导读


1.什么是熔断？
2.雪崩效应的原因是什么？
3.雪崩效应该如何解决？


对于“熔断”一词，大家应该都不会陌生，在中国股市，就曾经在2016年1月1日至2016年1月8日期间，实施过两次熔断机制。在微服务架构中,服务熔断本质上与股市的熔断机制并无差异，其出发点都是为了更好地控制风险。

服务熔断也称服务隔离或过载保护。在微服务应用中，服务存在一定的依赖关系，形成一定的依赖链，如果某个目标服务调用慢或者有大量超时，造成服务不可用，间接导致其他的依赖服务不可用，最严重的可能会阻塞整条依赖链，最终导致业务系统崩溃（又称雪崩效应）。此时，对该服务的调用执行熔断，对于后续请求，不再继续调用该目标服务，而是直接返回，从而可以快速释放资源。等到目标服务情况好转后，则可恢复其调用。


一、引言
一个系统通常包含多个服务，服务之间的数据顺利交互，是整个系统能够正常工作的基本要求。

但实际应用中，不少人会经常遇到某个服务异常工作后，整个系统随之崩掉的情况，这种情况我们应该如何预防和处理呢？本章节的内容希望能够给你带来些启发。

二、场景介绍
2.1 接口简述
一个新零售架构系统中 ，有一个通用用户服务，很多页面都会使用，它包含两个接口。

第一个接口：用户态接口
接口功能：返回用户车辆所在位置。
使用业务：在用户信息展示页面会使用到，比如客服系统中的用户信息页面。
数据来源：对接第三方系统，由第三方返回，然后接口再返回给接口调用者。

第二个接口：用户可操作权限列表
接口功能：返回用户一个可操作的权限列表，包含一个通用权限，也包含用户定制权限。
使用业务：每次用户打开APP时都会使用。
数据来源：从缓存中或者数据库读取。

2.2 接口遇到的问题
第一个接口遇到的问题：请求慢

服务间的关系调用具体流程分为3个步骤：
1）APP访问User API；
2）UserAPI 访问基础数据服务的接口 /currentCarLocation;
3）基础服务与第三方系统交互，获取数据。

问题：第三方响应速度很慢且有时还会抽风，导致响应时间更长，接口经常出现超时报错。

第二个接口遇到的问题：流量洪峰缓存超时

服务间的关系调用具体流程分为以下3个步骤：
1）APP方位UserAPI；
2）UserAPI访问基础数据服务的接口 /commonAccess；
3）基础数据服务提供一个通用权限列表。因为权限列表对所有用户都一样，所以我们把数据存放在Redis中，如果通用权限在Redis中找不到 ，我们再去数据库中查找。

问题：

在流量高峰期时Redis的通用权限列表超时了，那一瞬间所有的线程都需要去数据库中读取数据，导致DB中的CPU立马飙到100%。
DB 挂后，紧接着 Basic Data Service 也挂了，因所有的线程堵塞了，我们获取不到数据库连接，导致 Basic Data Service 无法接受新的请求。
而 User API 因调用了 Basic Data Service 的线程出现了堵塞，以至于 User API 服务的所有线程也出现堵塞，即 User API 也挂了，导致 App 上的所有操作都不能使用。

三、解决思路
为了解决上述两个问题，需要满足下面两个条件：

（1）线程隔离

针对第一个问题，希望的处理方式是：User API中每个服务配置的最大连接数是1000，每次API调用BasicDataService的/currentCarLocation的速度就会很慢。

因此，希望可以控制/currentCarLocation的调用请求数，保证不超过50条，以此保证至少还有 950 条的连接可用来处理常规请求。如果 /currentCarLocation 的调用请求数超过 50 条，我们就设计一些备用逻辑进行处理，比如在界面上给用户进行提示。

（2）熔断

针对第二个问题，因那时 DB 没有死锁，流量洪峰缓存超时单纯是因为压力太大，此时我们可以使用 Basic Data Service 暂缓一点儿时间，让它不接受新的请求，这样 Redis 的数据会被补上，数据库的连接也会降下来，我们的服务也就没事了。

简单概括该解决技术需要实现以下2点需求：
1）发现近期某个接口的请求老出异常，先别访问接口的服务；
2）发现某个接口的请求老超时，先判断接口的服务是否不堪重负，如果不堪重负，先别访问它。
————————————————

最新经典文章，欢迎关注公众号

原文链接：https://blog.csdn.net/locahuang/article/details/123935849