Dubbo概述–其他
写在前面
本文参考了Dubbo官方手册结合Dubbo2.6.1版本源码分析。推荐先阅读官方手册。
鉴于个人水平有限，如有不正确的地方请指出，欢迎一起讨论，谢谢！
其他
监听机制
监听机制包含两层，一层是Provider、Consumer与Registry的监听，另一层是业务层监听。第一层监听依赖具体的Registry，例如Zookeeper的Watch机制等。此处主要描述业务层监听。
业务层监听可以通过实现ExporterListener和InvokerListener接口并通过服务扩展机制注入的方式实现添加。通过ProtocolListenerWrapper类实例化的ListenerExporterWrapper和ListenerInvokerWrapper进行通知监听的操作。
过滤机制
过滤机制类似Web应用中Filter对Request的过滤。Dubbo中通过ProtocolFilterWrapper将Filter接口的服务扩展类包装为Invoker并组装为过滤链(先加载的先过滤)进行过滤处理。
集群相关
Dubbo里的集群指的是Consumer端从同一个Registry订阅到的多个相同服务Provider组成的集群。所以集群的概念只在Consumer端有意义。
Dubbo中集群相关的概念包括：
- Cluster，集群的顶级抽象，用于描述、实现集群调用方式。
| name | invokerClassName | desc |
|---|---|---|
| failover | FailoverClusterInvoker | 转移调用。调用失败后，根据重试次数尝试调用其他Provider |
| available | AvailableCluster匿名内部类 | 可用调用。调用第一个可用的Provider，不重试 |
| broadcast | BroadcastClusterInvoker | 广播调用。调用所有的Provider返回最后一个调用的返回值或最后一个异常 |
| failback | FailbackClusterInvoker | 失败恢复。调用失败后，使用定时线程池重试调用 |
| failfast | FailfastClusterInvoker | 快速失败。调用一个失败后，立刻返回 |
| failsafe | FailsafeClusterInvoker | 安全调用。调用失败后，例如日志，但不会抛出异常，返回空对象 |
| forking | ForkingClusterInvoker | 并发调用。使用线程池并发调用多个Provider，返回第一个完成调用的Provider的返回值或异常 |
| mergeable | MergeableClusterInvoker | 合并调用。使用线程池并发调用多个Provider，将所有Provider的返回值、异常合并后返回。会用到Merger扩展点。 |
* Directory，Cluster中存储Provider Proxy Invoker的列表，可以根据订阅动态更新本地的Invoker。
Router，用于从Directory中获取Provider Proxy Invoker列表时，根据路由规则过滤Invoker。
LoadBalance，在根据Router获取了可用的Provider Proxy Invoker列表后，根据LoadBalance获得负载策略处理后的具体某个Provider Proxy Invoker。
请求分发
请求分发指Provider端接收到请求后，使用何种策略来进行请求处理。通过Dispatcher扩展点指定的dispatcherHandler指定。默认为AllDispatcher指定的AllChannelHandler进行分发。
在请求分发时，分发的不只是请求Request，还有相关的传输事件，例如打开、断开、异常。
| name | handler | desc |
|---|---|---|
| all | AllChannelHandler | 将所有请求、事件都分发到ThreadPool扩展点指定的线程池中，如果ThreadPool指定的线程池已关闭或不存在则使用默认的一个cached线程池 |
| connection | ConnectionOrderedChannelHandler | 将所有请求、异常都分发到ThreadPool扩展点指定的线程池中。而事件发送到只有一个工作线程的线程池内按调用接收顺序逐个执行 |
| direct | 无 | 不使用多线程，在当前的接收线程(IO线程)上直接处理所有事件、请求 |
| execution | ExecutionChannelHandler | 将所有请求、事件都分发到ThreadPool扩展点指定的线程池中 |
| message | MessageOnlyChannelHandler | 只将所有请求都分发到ThreadPool扩展点指定的线程池中，事件直接由接收线程(IO线程)处理 |
URL参数
URL在Dubbo中不只是串联Provider和Consumer，更是Provider或Consumer内部服务扩展注入、业务逻辑处理等方面的重要依赖条件。URL的结构为：protocol://ip:port?name1=value1&…&nameN=valueN。根据URL参数的作用分为外部参数和内部参数，外部参数用于Provider、Consumer、Registry、Monitor之间的数据传输，内部参数用于组件内部的逻辑处理或确定扩展服务的具体服务类。
默认扩展类
默认扩展类实现是指ExtensionLoader.createAdaptiveExtensionClassCode()方法返回的、在运行时动态生成、根据内部方法参数(一般为URL)确定返回具体扩展服务的类，全类名为：扩展点$Adaptive。
| 扩展点 | 内部逻辑 |
|---|---|
| com.alibaba.dubbo.cache.CacheFactory | 根据Invocation的methodName返回值，从URL中获取methedName.cache参数的值，获取实际的CacheFactory并调用CacheFactory的对应方法，默认为LruCacheFactory |
| com.alibaba.dubbo.validation.Validation | 根据URL中的validation参数获取实际的Validation并调用实际Validation的对应方法，默认为JValidation |
| com.alibaba.dubbo.rpc.ProxyFactory | 根据URL中的proxy参数获取实际的ProxyFactory并调用实际ProxyFactory的对应方法，默认为JavassistProxyFactory |
| com.alibaba.dubbo.registry.RegistryFactory | 根据URL属性中的Protocol获取实际的Protocol并调用实际的Protocol的对应方法，默认为DubboProtocol |
| com.alibaba.dubbo.rpc.Protocol | 根据URL属性中的Protocol获取实际的RegistryFactory并调用实际的RegistryFactory的对应方法，默认为DubboRegistryFactory |
| com.alibaba.dubbo.remoting.Transporter | 根据URL中的client/server参数获取实际的Transporter并调用实际Transporter的对应方法，默认为NettyTransporter(不是Netty4的) |
| com.alibaba.dubbo.remoting.Dispatcher | 根据URL中的dispather参数获取实际的Dispatcher并调用实际Dispatcher的对应方法，默认为AllDispatcher |
| com.alibaba.dubbo.common.threadpool.ThreadPool | 根据URL中的threadpool参数获取实际的ThreadPool并调用实际ThreadPool的对应方法，默认为FixedThreadPool |
| com.alibaba.dubbo.remoting.zookeeper.ZookeeperTransporter | 根据URL中的client参数获取实际的ZookeeperTransporter并调用实际ZookeeperTransporter的对应方法，默认为CuratorZookeeperTransporter |
| com.alibaba.dubbo.rpc.cluster.Cluster | 根据URL中的cluster参数获取实际的Cluster并调用实际Cluster的对应方法，默认为FailoverCluster |
| com.alibaba.dubbo.rpc.cluster.RouterFactory | 根据URL属性中的Protocol获取实际的RouterFactory并调用实际的RouterFactory的对应方法，无默认 |
| com.alibaba.dubbo.rpc.cluster.ConfiguratorFactory | 根据URL属性中的Protocol获取实际的RouterFactory并调用实际的RouterFactory的对应方法，无默认 |