系统降级-接口级别

最新推荐文章于 2024-10-17 18:51:02 发布

转载最新推荐文章于 2024-10-17 18:51:02 发布 · 3.2k 阅读

文章标签：

#系统降级

杂谈专栏收录该内容

8 篇文章

订阅专栏

导致接口级故障的原因

内部原因

程序bug导致死循环
某个接口导致数据库慢查询
程序逻辑不完善导致耗尽内存等

外部原因

黑客攻击、促销或者抢购引入了超出平时几倍甚至几十倍的用户
第三方系统大量请求
第三方系统响应缓慢等

解决接口故障的核心思想

优先保证核心业务和优先保证绝大部分用户
丢车保帅，优先保证核心业务

降级

降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能

案例

双11，订单暂时不允许修改收货地址
论坛，降级为只能看帖子，不能发帖子
App的日志上传接口，可以完全停掉一段时间，这段时间内APP都不能上传日志

常见的实现降级的方式有：

系统后门降级

例如，系统提供一个降级URL，当访问这个URL时，就相当于执行降级指令，具体的降级指令通过URL的参数传入即可
缺点：安全隐患，服务器数量多，需要一台一台去操作

独立降级系统

将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能。其基本架构如下：
在这里插入图片描述熔断

降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况

案例

A服务的X功能依赖B服务的某个接口，当B服务的接口响应很慢的时候，A服务的X功能响应肯定被拖慢，进一步导致A服务的线程都被卡在X功能处理上，此时A服务的其他功能都会被卡住或者响应非常慢
加入熔断机制后，A服务不再请求B服务这个接口，A服务内部只要发现是请求B服务的这个接口就立即返回错误，从而避免A服务整个被拖慢甚至拖死

实现

关键是需要有一个统一的API调用层，由API调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了
另一个关键是阈值的设计，例如1分钟内30%的请求响应时间超过1秒就熔断，这个策略的“1分钟”“30%”“1秒”都对最终的熔断效果有影响
实践中一般都是先根据分析再确定阈值，然后上线观察效果，再进行调优

限流

降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障
限流指只允许系统能够承受的流量进来，超出系统访问能力的请求将被丢弃

常见的限流方式

基于请求限流
是指从外部访问的请求角度考虑限流

常见方式：限制总量、限制时间量
限制总量：限制某个指标的累积上限
例如，某个直播间限制总用户数上限为100万，超过后无法进入；抢购活动商品数量100个，限制参与用户1万个，超过1万个后直接拒绝
限制时间量：限制一段时间内某个指标的上限
例如，1分钟内只允许10000个用户访问，每秒请求峰值最高为10万
缺点：阈值难于确定

基于资源限流
是指从系统内部考虑的，找到系统内部影响性能的关键资源，对其使用上限进行限制

常见的内部资源：连接数、文件句柄、线程数、请求队列等
例如，采用Netty来实现服务器，每个进来的请求都先放入一个队列，业务线程再从队列读取请求进行处理，队列长度最大值为10000，队列满了就拒绝后面的请求；也可以根据CPU的负载或者占用率进行限流，当CPU的占用率超过80%的时候就开始拒绝新的请求

缺点：难于确定关键资源及其阈值
实现方案：逐步调优，开始时先根据推断选择某个关键资源和阈值，然后测试验证，再上线观察，不合理再优化。

排队