《Apache Dubbo微服务开发从入门到精通》——服务治理与生态—— 一、 限流降级（上） https://developer.aliyun.com/article/1224020
3. Sentinel基于Dubbo的最佳实践
注：
具体Demo代码请见Dubbo官方示例：https://github.com/apache/dubbo-samples/tree/master/99-integration/dubbo-samples-sentinel-dubbo3
1) Service Provider
注：
对服务提供方的流量控制可分为服务提供方的自我保护能力和服务提供方对服务消费方的请求分配能力两个维度。
Service Provider用于向外界提供服务，处理各个消费者的调用请求。为了保护Provider不被激增的流量拖垮影响稳定性，可以给Provider配置QPS模式的限流，这样当每秒的请求量超过设定的阈值时会自动拒绝多的请求。
限流粒度可以是服务接口和服务方法两种粒度。若希望整个服务接口的QPS不超过一定数值，则可以为对应服务接口资源（resourceName为接口全限定名）配置QPS阈值；若希望服务的某个方法的QPS不超过一定数值，则可以为对应服务方法资源（resourceName为接口全限定名：方法签名）配置QPS阈值。有关配置详情请参考流量控制|Sentinel。
我们看一下这种模式的限流产生的效果。假设我们已经定义了某个服务接口com.alibaba.csp.sentinel.demo.dubbo.FooService，其中有一个方法sayHello(java.lang.String)，Provider端该方法设定QPS阈值为10。在Consumer端在1s之内连续发起15次调用，可以通过日志文件看到Provider端被限流。拦截日志统一记录在~/logs/csp/sentinel-block.log中：
在Provider对应的metrics日志中也有记录：
根据调用方的需求来分配服务提供方的处理能力也是常见的限流方式。比如有两个服务A和B都向Service Provider发起调用请求，我们希望只对来自服务B的请求进行限流，则可以设置限流规则的limitApp为服务B的名称。Sentinel Dubbo Adapter会自动解析Dubbo消费者（调用方）的application name作为调用方名称（origin），在进行资源保护的时候都会带上调用方名称。若限流规则未配置调用方（default），则该限流规则对所有调用方生效。若限流规则配置了调用方则限流规则将仅对指定调用方生效。
注：
Dubbo默认通信不携带对端application name信息，因此需要开发者在调用端手动将application name置入attachment中，provider端进行相应的解析。Sentinel Dubbo Adapter实现了一个Filter用于自动从consumer端向provider端透传application name。若调用端未引入Sentinel Dubbo Adapter，又希望根据调用端限流，可以在调用端手动将application name置入attachment中，key为dubboApplication。
在限流日志中会也会记录调用方的名称，如下面的日志中的demo-consumer即为调用方名称：
2) Service Consumer
注：
对服务提供方的流量控制可分为控制并发线程数和服务降级两个维度。
• 并发线程数限流
Service Consumer作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务A依赖的下游服务B出现了不稳定的情况，服务A请求服务B的响应时间变长，从而服务A调用服务B的线程就会产生堆积，最终可能耗尽服务A的线程数。我们通过用并发线程数来控制对下游服务B的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给Consumer配置线程数模式的限流，来保证自身不被不稳定服务所影响。采用基于线程数的限流模式后，我们不需要再显式地去进行线程池隔离，Sentinel会控制资源的线程数，超出的请求直接拒绝，直到堆积的线程处理完成，可以达到信号量隔离的效果。
我们看一下这种模式的效果。假设当前服务A依赖两个远程服务方法sayHello(java.lang.String)和doAnother()。前者远程调用的响应时间为1s-1.5s之间，后者RT非常小（30 ms左右）。服务A端设两个远程方法thread count为5。然后每隔50 ms左右向线程池投入两个任务，作为消费者分别远程调用对应方法，持续10次。可以看到sayHello方法被限流5次，因为后面调用的时候前面的远程调用还未返回（RT高）；而doAnother()调用则不受影响。线程数目超出时快速失败能够有效地防止自己被慢调用所影响。
• 服务降级
当服务依赖于多个下游服务，而某个下游服务调用非常慢时，会严重影响当前服务的调用。这里我们可以利用Sentinel熔断降级的功能，为调用端配置基于平均RT的降级规则。这样当调用链路中某个服务调用的平均RT升高，在一定的次数内超过配置的RT阈值，Sentinel就会对此调用资源进行降级操作，接下来的调用都会立刻拒绝，直到过了一段设定的时间后才恢复，从而保护服务不被调用端短板所影响。同时可以配合fallback功能使用，在被降级的时候提供相应的处理逻辑。
3) Fallback
从0.1.1版本开始，Sentinel Dubbo Adapter还支持配置全局的fallback函数，可以在Dubbo服务被限流/降级/负载保护的时候进行相应的fallback处理。用户只需要实现自定义的DubboFallback接口，并通过DubboFallbackRegistry注册即可。默认情况会直接将BlockException包装后抛出。同时，我们还可以配合Dubbo的fallback机制来为降级的服务提供替代的实现。
《Apache Dubbo微服务开发从入门到精通》——服务治理与生态—— 一、 限流降级（下） https://developer.aliyun.com/article/1224017
