易波动或者对波动比较敏感;容易影响整体的;不能预测上游行为,或者不能预测下游行为,依赖的上下游有不可预测的行为体。要不要做熔断降级的核心点在于是否可控,有没有不可控因素。
对于通用性或者有多个上游的服务,往往需要做好资源分配,以保障隔离
逻辑有错,积压,负载高等
不要随意为了解决问题而在任意节点熔断限流,要评估对数据的影响,是否会引起数据错误或者熔断后能不能做补偿恢复;
考虑其他接口未来的占用和需要预留的容量,不同系统预留的容量不一样。为了保证稳定,核心系统一般至少预留出3倍的容量,也就是正常不使用超过30%的资源。
阈值 = 分配的资源容量能达到的量 * 预留倍数
设置根据的是实际需要和能分配的资源量,而不是根据压测的实际数量来。
总体思路为估算,链路上涉及资源的平均消耗来除以总量来进行计算。 每秒接口处理时间总耗时 = qps * 平均响应时间
js复制代码175qps * 32ms = 5.6s
CPU 100%利用率每秒接口总处理时长 = 每秒实际时长 / CPU利用率
js复制代码5.6s / 15%(cpu usage) = 37s
最大吞吐实际所需线程数 = CPU 100%利用率每秒接口总处理时长
js复制代码= 37 < 200(默认大小)
平均CPU : IO等非CPU耗时 = 核数:CPU 100%利用率每秒接口总处理时长
js复制代码2/37s (cpu核数)= 1:19
CPU实际能达到的最大吞吐 = CPU 100%利用率每秒接口总处理时长 / 平均响应时间
js复制代码= 37 / 0.032 = 1100qps
目前假设线程数为25,最大吞吐为 = 线程数 / 平均响应时间
js复制代码= 25 / 0.032 = 781
781 < 1100 , 线程数构成CPU瓶颈;
假设有连接数据库,共10个连接,每个接口平均耗时数据库请求20ms(或者用平均请求次数(sql总qps/接口请求次数)和sql平均耗时算); 则数据库连接吞吐为=资源总数/平均耗时
js复制代码= 10 / 20ms = 500qps
500 < 781 ,则数据库连接又构成线程的瓶颈; 在2核,25线程,10连接的情况下最终最大吞吐 = min(cpu,线程数,连接数) = 500 反向计算,从允许的资源推出允许的阈值
Fegin和Dubbo等默认不走网关,而且现在所有的项目都已经有sentinel相关配置,因此做到对应服务上即可。
对不同的来源设置不同的限流规则。默认只支持ip,服务名称,接入方等需要扩展返回来源的API;
根据参数位置,将对应参数的不同值单独统计限流。如果不能从参数取值,而是在上下文之类的地方可以通过Sphu.entry来设置。目前nacos存的数据和监听获取的数据格式不一致,暂未解决。
CPU、RT、QPS等,目前有功能但是不好使。未定位到问题
根据重要程度对接口进行划分,故障时优先保障核心功能。
对某一类接口限流,通过配置成同名的资源实现。可实现核心和非核心的区分,通过降级非核心来保证核心。
及时做好流量预估、扩容和优化,保证正常使用,避免出现需要熔断降级的情况。熔断降级是非正常情况下的手段。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文系转载,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。