[熔断的参数请教] 具体应该根据服务器哪些状况来设置？

[woduzibue]

想了解一下大厂的大佬们 这些指标是如何实践的，感谢大佬们赐教 最近在服务上想上一个 sentinel 的熔断规则，不太清楚里面那些具体参数有没有什么最佳实践 熔断降级支持慢调用比例、异常比例、异常数三种熔断策略

1. 这三种策略怎么选择？
2. 下面这些参数应该怎么选择数值
   • 服务主要是对外提供查询类的接口，当前用的是慢调用比例，
   • 最大 RT 、当前是用 7 天内的最大 RT 作为参数
   • 比例阈值、慢调用占所有的调用的比率，网上找到的是 0.5/0/6
   • 熔断时长、在这段时间内发生熔断、拒绝所有请求 网上找到的是 30/60s
   • 最小请求数、即允许通过的最小请求数，在该数量内不发生熔断 这个参数没看到有具体的值，公司其他服务看到的大部分都是默认值 5 ，这个对于查询接口来说是不是太小了

[opengps]

这些问题显然需要有个参考，这个参考就来自于压力测试

[woduzibue]

@opengps 是的，最近也在做一些压测，不过没有专门的压测人员，当服务压力上来 应该以哪个节点作为 瓶颈设置熔断点呢？
是 tps 开始下降的那个点还是 保证哪个时间点的数值

[opengps]

压测结果是极限值，而且测试时候过于单一，没法等于实际业务负载值。所以参考也仅仅是参考，具体业务适合多少，可能得凭借运维人员的经验了，比如单独压测接口 1 的 tps 能 200 ，在实际总共的 100 个接口可能只占用十分之一的实际调用比例，这时候单个接口可能得用 20 作为严重预警了

[dlmy]

把项目的流量录制下来，然后重放并扩大 10 倍、20 倍、30 倍。。。

通过这种方式，你可以观测到项目运行中的各种极限指标，再以这个作为参考，并逐步调整 Sentinel 配置，这样反复测个几次，就差不多了

Sentinel 具体参数配置，可以根据公司内部的业务指标和技术指标作为参考，让项目能满足验收条件即可

别迷信网上的 "最佳实践"，这世上压根就没有最佳实践

[wudaye]

本小厂的小弟觉得这玩意不会有最佳实践。比如熔断时长，你们的生产环境的某一个核心接口熔断 30 秒和熔断 60 秒分别会发生哪些后果，不直接上故障演练是很难预见得到的

[woduzibue]

@dlmy 确实 我也没找到这块相关的实践，非常感谢大佬

[woduzibue]

@opengps 是的 我真的实践起来压测 也有这个疑问 如何确定哪些接口是必须得压到的，非常 感谢大佬的回复

[woduzibue]

@wudaye 不算是非常核心的服务，只是希望异常情况下有个兜底，感谢大佬的回复

[sampeng]

经验之谈。先拍脑袋写一个。然后再以事故为导向

[woduzibue]

@sampeng 哈哈哈哈 ，从我上班到现在 不只一个大佬这么跟我说过，能用就行，出了问题再说
好像也确实没啥问题

[sampeng]

@woduzibue 事实就是这样的，世界就是一群草台班子组成的。除了极个别大公司有足够的资源正儿八经的去验证得到一个正儿八经的值。这个道理很简单，图啥啊？原先没有就一点事都没。现在有了，那我只要保证在现在没问题就好了。。

[woduzibue]

@sampeng 确实是，问了一圈没人支持一下压测，没有资源搞一套跟生产一样的环境来压测，老板只是想加一个限流的功能

[MoYi123]

个人建议别熔断, 做这种事情就是纯背锅的.

[woduzibue]

@MoYi123 为啥呢 有啥场景会背锅么？ 参数放宽很多 ，正常情况下根本不会走到熔断的逻辑里
不过也确实很好奇 这块网络上能找到的实战经验分享很少

[sampeng]

@woduzibue 如果是领导要求的，就要文档写清楚。这是拍脑袋的，请领导同意。领导同意了，锅就不会在你头上

[woduzibue]

@sampeng 嗯嗯 这肯定会有的，感谢大佬的回复