llg___的博客

会调用CircuitBreaker的onRequestComplete方法。OPEN到HALF_OPEN切换在。这里以异常比例熔断为例来看，进入。

在demo工程的order-service服务中，将的首先处理下依赖与配置

这个类基于责任链模式来设计，将不同的功能（限流、降级、系统保护）封装为一个个的Slot，请求进入后逐个执行即可。此时，对于资源/goods，可使用DeafultNode对两个链路分别做限流，也可以直接用ClusterNode来对这个资源做统一的统计和整体的限流。就是希望被Sentinel保护的业务，例如项目中定义的controller方法就是默认被Sentinel保护的资源。所有的节点都可以记录对资源的访问统计数据，所以都是StatisticNode的子类。，实现默认模式、关联模式的限流规则。

举个例子：如上图，比如1250ms有个请求进来，则1250-1000=250，250ms之后的第一个时区则是500到1000区间，1250ms自身所在时区为1000到1500ms，所以对应的滑动窗口就是500到1500ms这个时区。再往后，2100ms，则计算后，滑动窗口在1500到2500ms（紫色虚线），未达QPS阈值，但看1250ms到2100ms这850ms的时间，不到一个窗口时间跨度Interval，却有4个请求 > 3。当然，不管这个区间多小，总有可能有卡边界前后请求导致QPS超过的情况。

这是实现push方式：push模式即控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端去监听Nacos，获取配置变更的推送消息后完成本地配置更新。

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方，而直接抛出异常信息，对用户很不友好，因此需要自定义异常的返回结果。/*** 处理请求被限流、降级、授权拦截时抛出的异常：BlockException而BlockException包含很多个子类，分别对应不同的场景：接下来在调用方order-service中定义类，实现BlockExceptionHandler接口，并借助instanceof来String msg = "未知异常";msg = "请求被限流了！

上一节整理了Sentinel的限流，限流可以降低微服务的负载，避免因为高并发而故障，进而传递给其他相关服务而引发服务雪崩。以上仅为避免服务故障，而当某个服务真正故障时，如何处理才能防止服务雪崩？⇒ Sentinel支持隔离和降级两种方案。

如上图，预计等待时间线上排队着一个个请求，最后一个绿点的预计等待时间刚好为2000ms == timeout，此时再来一个需求，预计等待时间就大于了timeout，这个需求就会被拒绝。但此时有个问题，比如商品001没人看，商品002火爆，现在限制商品id相同的请求，每秒不能大于5个，则001，002都没一竿子打死了，001的QPS用不完，002的QPS不够用。例如，我设置QPS的threshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.

阿里开源的流量控制组件承接了阿里双十一大促流量的核心场景，如秒杀、消息削峰填谷、集群流量控制、实时熔断下游不可用应用实时监控集群的汇总运行情况。

服务A要等待服务D的结果，而服务D已经不能正常响应了，此时服务A内部阻塞，不会释放tomcat的连接（此时服务A依赖于服务B的业务还是不受影响）。比如到服务A–服务D的这个请求，访问了三次，两次失败，即66%异常，阈值如果设为50%，则此时发生熔断，后续再有这个请求过来直接拦截，快速失败，立刻释放资源，从而解决雪崩问题。即某个服务故障，最终导致了依赖它的某个服务也故障了。这只能缓解雪崩问题，而不能彻底根除，因为比如设置等待1s就释放1个连接，但一秒钟之内进来了2个请求，终有一天，服务A的资源也可能被耗尽。