浅谈微服务中限流熔断降级的方法论
一、确定范围
1.1 限流
易波动或者对波动比较敏感；容易影响整体的；不能预测上游行为，或者不能预测下游行为，依赖的上下游有不可预测的行为体。要不要做熔断降级的核心点在于是否可控，有没有不可控因素。
1.1.1 需要提前做限流的接口
容易出问题的，比如经常性能有大波动的；
速度慢的，速度慢会导致资源长时间不能释放；
单次请求消耗的资源多的；
请求量大占用总资源多的；
涉及到容易构成瓶颈的资源，比如会导致串行，避免长事务；
事务内调用了外部接口，为了避免连接不能释放应提前做好熔断，比如响应时间设置；
需要请求一个公共的锁，导致大量排队
请求量波动很大的，比如搞活动的接口；
提供给外部系统的接口，主要是难以预测变化的；
容易积压的业务，积压后会导致影响其他业务；
下游行为不能预测或者下游依赖性能波动大服务 需要自我做限流熔断，比如依赖的是大数据，公共数据服务；
依赖大数据的接口，大数据性能波动大的业务；
需要往公共数据服务里写数据；
查了下游提供的 ES 数据，通用时不能预知会发生什么；
调用了第三方的接口
1.1.2 资源分配流控
对于通用性或者有多个上游的服务，往往需要做好资源分配，以保障隔离
通用的公共组件对外提供接口、ES 等；
服务于多个业务方，避免连锁反应
1.2、熔断
逻辑有错，积压，负载高等
1.2.1 熔断
影响数据准确性，多一个请求多一条脏数据；
逻辑存在错误，引发其他系统数据错误；
接口过慢，引发连锁反应；
本系统负载已经过高，已经有积压；
1.2.2 注意事项
不要随意为了解决问题而在任意节点熔断限流，要评估对数据的影响，是否会引起数据错误或者熔断后能不能做补偿恢复；
二、阈值设置
2.1 需要满足两方面
需求目标期望值；
资源允许资源占用的量 不要从系统有多少资源来设置；
考虑其他接口未来的占用和需要预留的容量，不同系统预留的容量不一样。为了保证稳定，核心系统一般至少预留出 3 倍的容量，也就是正常不使用超过 30%的资源。
阈值 = 分配的资源容量能达到的量 * 预留倍数
设置根据的是实际需要和能分配的资源量，而不是根据压测的实际数量来。
2.2 设置依据
压测
历史监控观测结果
估算
设置阈值时，因为并不总是有条件进行压测，就需要进行估算，此时应该先评估接口各类资源的大致平均消耗，计算得出不同资源允许的占用量能达到的请求数。
2.2.1 容量评估计算
总体思路为估算，链路上涉及资源的平均消耗来除以总量来进行计算。每秒接口处理时间总耗时 = qps * 平均响应时间
CPU 100%利用率每秒接口总处理时长 = 每秒实际时长 / CPU 利用率
最大吞吐实际所需线程数 = CPU 100%利用率每秒接口总处理时长
平均 CPU : IO 等非 CPU 耗时 = 核数：CPU 100%利用率每秒接口总处理时长
CPU 实际能达到的最大吞吐 = CPU 100%利用率每秒接口总处理时长 / 平均响应时间
目前假设线程数为 25，最大吞吐为 = 线程数 / 平均响应时间
781 < 1100 , 线程数构成 CPU 瓶颈；
假设有连接数据库，共 10 个连接，每个接口平均耗时数据库请求 20ms（或者用平均请求次数（sql 总 qps/接口请求次数）和 sql 平均耗时算）；则数据库连接吞吐为=资源总数/平均耗时
500 < 781 ，则数据库连接又构成线程的瓶颈;在 2 核，25 线程，10 连接的情况下最终最大吞吐 = min(cpu，线程数，连接数) = 500 反向计算，从允许的资源推出允许的阈值
三、Sentinel 支持的功能
Fegin 和 Dubbo 等默认不走网关，而且现在所有的项目都已经有 sentinel 相关配置，因此做到对应服务上即可。
区分来源限流
对不同的来源设置不同的限流规则。默认只支持 ip，服务名称，接入方等需要扩展返回来源的 API；
针对热点参数限流
根据参数位置，将对应参数的不同值单独统计限流。如果不能从参数取值，而是在上下文之类的地方可以通过 Sphu.entry 来设置。目前 nacos 存的数据和监听获取的数据格式不一致，暂未解决。
系统性能指标
CPU、RT、QPS 等，目前有功能但是不好使。未定位到问题
接口分级和批量降级
根据重要程度对接口进行划分，故障时优先保障核心功能。
对某一类接口限流，通过配置成同名的资源实现。可实现核心和非核心的区分，通过降级非核心来保证核心。
四、建议
及时做好流量预估、扩容和优化，保证正常使用，避免出现需要熔断降级的情况。熔断降级是非正常情况下的手段。
作者：cafebabe
链接：https://juejin.cn/post/7216915438298677306
来源：稀土掘金
还未添加个人签名 2021-07-28 加入
公众号：该用户快成仙了
评论