sentinel针对目前常见的主流框架都做了适配，比如dubbo、Web Servlet、Spring Cloud、Spring WebFlux等。sentinel的适配做到了开箱即用，那么它是通过什么机制来实现的呢？这里大家可以思考下，如果一个框架本身没有扩展机制（这只是举个极端的例子，一般开源框架都是有自身的扩展机制的），那么sentinel是无法进行适配的，更谈不上开箱即用，除非更改框架源码。所以说，如果明白了框架的扩展机制，那么理解sentinel的适配机制就很easy了，比如dubbo 本身有Filter机制（consumer端和provider端都有），Web servlet也有自己的Filter机制可进行自定义扩展。
关于sentinel dubbo的使用示例，因为官方文档已经有详细说明了，这里不再赘述了。下面主要分析sentinel dubbo的实现原理。
因为dubbo提供有Filter机制，默认需要在 META-INFdubboorg.apache.dubbo.rpc.Filter文件中进行配置，sentinel dubbo的配置如下：
代码语言：javascript复制sentinel.dubbo.provider.filter=com.alibaba.csp.sentinel.adapter.dubbo.SentinelDubboProviderFilter
sentinel.dubbo.consumer.filter=com.alibaba.csp.sentinel.adapter.dubbo.SentinelDubboConsumerFilter
dubbo.application.context.name.filter=com.alibaba.csp.sentinel.adapter.dubbo.DubboAppContextFilter此处可见，consumer端和provider端各对应一个filter类，这里以SentinelDubboProviderFilter为例进行分析：
代码语言：javascript复制@Activate(group = "provider")
public class SentinelDubboProviderFilter implements Filter {
@Override
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
// Get origin caller.
String application = DubboUtils.getApplication(invocation, "");
Entry interfaceEntry = null;
Entry methodEntry = null;
try {
// resourceName格式为 "接口:方法(入参1,入参2)"
String resourceName = DubboUtils.getResourceName(invoker, invocation);
String interfaceName = invoker.getInterface().getName();
// Only need to create entrance context at provider side, as context will take effect
// at entrance of invocation chain only (for inbound traffic).
// 以resourceName作为context name
ContextUtil.enter(resourceName, application);
interfaceEntry = SphU.entry(interfaceName, EntryType.IN);
methodEntry = SphU.entry(resourceName, EntryType.IN, 1, invocation.getArguments());
Result result = invoker.invoke(invocation);
if (result.hasException()) {
Throwable e = result.getException();
// Record common exception.
Tracer.traceEntry(e, interfaceEntry);
Tracer.traceEntry(e, methodEntry);
}
return result;
} catch (BlockException e) {
return DubboFallbackRegistry.getProviderFallback().handle(invoker, invocation, e);
} catch (RpcException e) {
Tracer.traceEntry(e, interfaceEntry);
Tracer.traceEntry(e, methodEntry);
throw e;
} finally {
if (methodEntry != null) {
methodEntry.exit(1, invocation.getArguments());
}
if (interfaceEntry != null) {
interfaceEntry.exit();
}
ContextUtil.exit();
}
}
}SentinelDubboProviderFilter中会对两个维度进行SphU.entry操作：
- 接口维度：resouce name为interfaceName；
- 方法维度：resouce name为方法签名，格式为 "接口:方法(入参1,入参2)"。
处理流程是，先获取接口维度的Resource，再获取方法维度的Resource，二者都获取成功之后，再执行后续的dubbo invoker操作，也就是后续的RPC处理。通过接口和方法两个不同维度，在provider端进行流控更加灵活。
看到这块代码时，笔者有一个疑问：
针对dubbo provider端的流控，SentinelDubboProviderFilter.invoke方法中会先对interfaceName做SphU.entry操作，然后在对method签名做SphU.entry操作，二者通过后再执行invoke后续操作。因为二者不是原子的，有可能针对interfaceName的pass，但是针对method签名的blocked，但是这个时候已经增加了interfaceName对应的pass统计值，这样同一个时间窗口内会影响到针对该接口其他方法的dubbo rpc调用。目前从代码来看，sentinel并未处理这种情况，因为目前没有针对资源的统计值做decrement功能。
试下一下，如果需要解决该问题，应该如何做呢？
- 方案一：增加一个统计值decrement功能，如果针对method签名执行SphU.entry操作被blocked时，调用统计值decrement功能，撤销之前相同时间窗口内针对interfaceName的pass值；
- 方案二：像这种需要针对两个resource做SphU.entry操作的场景，可以在判断是否通过pass时同时判断这两个resource对应的统计值是否满足规则限制，让这两个Resource产生关联，一同判断即可。
笔者倾向于方案二的实现，其实现流程和单个Resource的类似（只不过新增个Resource判断条件），而不像方案一那样需要提供新的方法 增加撤销逻辑来满足，严格来讲，方案一在对资源申请和撤销操作之间，也是会暂用一个pass名额的。
