浅谈微服务中限流熔断降级的方法论

2023-05-17 16:47:38 浏览数 (1)

一、确定范围

1.1 限流

易波动或者对波动比较敏感；容易影响整体的；不能预测上游行为，或者不能预测下游行为，依赖的上下游有不可预测的行为体。要不要做熔断降级的核心点在于是否可控，有没有不可控因素。

1.1.1 需要提前做限流的接口

  • 1、容易出问题的，比如经常性能有大波动的；
  • 2、速度慢的，速度慢会导致资源长时间不能释放；
  • 3、单次请求消耗的资源多的；
  • 4、请求量大占用总资源多的；
  • 5、涉及到容易构成瓶颈的资源，比如会导致串行，避免长事务；
    • 事务内调用了外部接口，为了避免连接不能释放应提前做好熔断，比如响应时间设置；
    • 需要请求一个公共的锁，导致大量排队
  • 6、请求量波动很大的，比如搞活动的接口；
  • 7、提供给外部系统的接口，主要是难以预测变化的；
  • 8、容易积压的业务，积压后会导致影响其他业务；
  • 9、下游行为不能预测或者下游依赖性能波动大服务 需要自我做限流熔断，比如依赖的是大数据，公共数据服务；
    • 依赖大数据的接口，大数据性能波动大的业务；
    • 需要往公共数据服务里写数据；
    • 查了下游提供的ES数据，通用时不能预知会发生什么；
    • 调用了第三方的接口

1.1.2 资源分配流控

对于通用性或者有多个上游的服务，往往需要做好资源分配，以保障隔离

  • 1、通用的公共组件对外提供接口、ES等；
  • 2、服务于多个业务方，避免连锁反应

1.2、熔断

逻辑有错，积压，负载高等

1.2.1 熔断

  • 1、影响数据准确性，多一个请求多一条脏数据；
  • 2、逻辑存在错误，引发其他系统数据错误；
  • 3、接口过慢，引发连锁反应；
  • 4、本系统负载已经过高，已经有积压；

1.2.2 注意事项

不要随意为了解决问题而在任意节点熔断限流，要评估对数据的影响，是否会引起数据错误或者熔断后能不能做补偿恢复；

二、阈值设置

2.1 需要满足两方面

  • 1、需求目标期望值；
  • 2、资源允许资源占用的量 不要从系统有多少资源来设置；

考虑其他接口未来的占用和需要预留的容量，不同系统预留的容量不一样。为了保证稳定，核心系统一般至少预留出3倍的容量，也就是正常不使用超过30%的资源。

阈值 = 分配的资源容量能达到的量 * 预留倍数

设置根据的是实际需要和能分配的资源量，而不是根据压测的实际数量来。

2.2 设置依据

  • 1、压测
  • 2、历史监控观测结果
  • 3、估算 设置阈值时，因为并不总是有条件进行压测，就需要进行估算，此时应该先评估接口各类资源的大致平均消耗，计算得出不同资源允许的占用量能达到的请求数。

2.2.1 容量评估计算

总体思路为估算，链路上涉及资源的平均消耗来除以总量来进行计算。 每秒接口处理时间总耗时 = qps * 平均响应时间

代码语言：javascript复制
js复制代码175qps * 32ms = 5.6s

CPU 100%利用率每秒接口总处理时长 = 每秒实际时长 / CPU利用率

代码语言：javascript复制
js复制代码5.6s / 15%(cpu usage) = 37s

最大吞吐实际所需线程数 = CPU 100%利用率每秒接口总处理时长

代码语言：javascript复制
js复制代码= 37 < 200(默认大小)

平均CPU : IO等非CPU耗时 = 核数：CPU 100%利用率每秒接口总处理时长

代码语言：javascript复制
js复制代码2/37s （cpu核数）= 1:19

CPU实际能达到的最大吞吐 = CPU 100%利用率每秒接口总处理时长 / 平均响应时间

代码语言：javascript复制
js复制代码= 37 / 0.032 = 1100qps

目前假设线程数为25，最大吞吐为 = 线程数 / 平均响应时间

代码语言：javascript复制
js复制代码= 25 / 0.032 = 781

781 < 1100 , 线程数构成CPU瓶颈；

假设有连接数据库，共10个连接，每个接口平均耗时数据库请求20ms（或者用平均请求次数（sql总qps/接口请求次数）和sql平均耗时算）； 则数据库连接吞吐为=资源总数/平均耗时

代码语言：javascript复制
js复制代码= 10 / 20ms = 500qps

500 < 781 ，则数据库连接又构成线程的瓶颈; 在2核，25线程，10连接的情况下最终最大吞吐 = min(cpu，线程数，连接数) = 500 反向计算，从允许的资源推出允许的阈值

三、Sentinel支持的功能

Fegin和Dubbo等默认不走网关，而且现在所有的项目都已经有sentinel相关配置，因此做到对应服务上即可。

  • 1、区分来源限流

对不同的来源设置不同的限流规则。默认只支持ip，服务名称，接入方等需要扩展返回来源的API；

  • 2、针对热点参数限流

根据参数位置，将对应参数的不同值单独统计限流。如果不能从参数取值，而是在上下文之类的地方可以通过Sphu.entry来设置。目前nacos存的数据和监听获取的数据格式不一致，暂未解决。

  • 3、系统性能指标

CPU、RT、QPS等，目前有功能但是不好使。未定位到问题

  • 4、接口分级和批量降级

根据重要程度对接口进行划分，故障时优先保障核心功能。

对某一类接口限流，通过配置成同名的资源实现。可实现核心和非核心的区分，通过降级非核心来保证核心。

四、建议

及时做好流量预估、扩容和优化，保证正常使用，避免出现需要熔断降级的情况。熔断降级是非正常情况下的手段。

后端

0 人点赞