dubbo-1

╰+哭是因爲堅強的太久メ 2022-01-06 01:39 169阅读 0赞

ExtensionLoader：某接口多实现，在某目录（classpath下的三个位置）的某文件（接口的全限定名）寻找这些实现的映射  
1 提供name-实现 的映射，我们可以按name取对应实现  
2 默认实现：接口上SPI注解的值，可以没有  
3 Adaptive实现：  
3.1 **实现类**上有Adaptive注解  
3.2 接口方法上有Adaptive注解，某个代理实例，可以没有（接口上没有方法有Adaptive注解），调用无Adaptive注解方法抛异常，有Adaptive注解方法根据URL（方法参数或方法参数的getter方法获取）的某个参数值（可定义多个参数名称，先根据参数A获取，获取不到根据参数B，若注解未定义参数名称，举例：LoadBalance为load.balance）在运行时动态选择实现，实在获取不到取默认实现，调用实现的此方法，特殊：若参数名为protocol，则直接调用url.getProtocol()  
4 Activate实现：可有多个，每个实现类带Activate注解，根据传入的URL和group是否匹配Activate注解的值来决定是否选择此实现，注解的before，after，order用于排序

某些实现类（wrapperClass）存在以接口为参数的constructor，假设我们获取dubbo的protocol，获取到的是DubboProtocol被wrapper多次的实例  
ExtensionFactory：Adaptive实例包含Spi和Spring实例，用于对实现类进行依赖注入（setter方法），每wrap一次依赖注入一次

Protocol: 生成客户端调用的Invoker和服务端暴露的Exporter  
三类Protocol：普通，如DubboProtocol生成DubboInvoker  
RegistryProtocol：通过Cluster.join(Directory) 生成ClusterInvoker  
ProtocolFilterWrapper和ProtocolListenerWrapper：wrapperClass，在内部Protocol生成的Invoker上附加了一些功能（Filter，InvokerListener）

1 本地调用：调用本jvm暴露的服务，scope=local或injvm=true，特殊：未指定直连地址且本jvm有暴露的话优先本地调用  
2 处理直连地址（可能是多个provider和reqister center地址的混合）  
3 无直连地址则使用注册中心地址（可多个）  
4 最后，有一个地址（可直连或reqister center）按此地址生成wrap后的普通Invoker或ClusterInvoker，多地址（可能混合）先按单个地址逐一生成Invoker，再所有Invoker放入StaticDirectory生成ClusterInvoker，多注册中心两次route和loadBalance

ProxyFactory生成代理，默认Javassist，代理接口：EchoService，本身接口（若generic泛化，替换成GenericSerivice）

调用代理方法：封装RpcInvocation，调用Invoker.invoke方法，调用返回的RpcResult的recreate方法

生成DubboInvoker：生成ExchangeClient，URL的connections参数未配置，即可共享连接（一jvm可暴露多服务，不同Invoker可使用同一ExchangeClient(连接)），维护host+port到ExchangeClient的映射Map，使用ReferenceCountExchangeClient封装原始ExchangeClient，按connections数量生成ExchangeClient

URL含lazy=true生成LazyConnectExchangeClient（延迟连接，调用发起时，再Exchanger生成内部的(Header)ExchangeClient）  
Exchanger（默认且也只有HeaderExchanger）生成(Header)ExchangeClient：**此时连接建立**

Dubbo和Thrift才有ExchangeClient和底层的Netty，Mina这一套，这一套使用长连接（连接在HeaderExchangeClient创建时就建立，连接可进行不同服务的多次请求和响应和心跳），Thrift没有延迟连接和共享连接，Http，Redis等完全不走这一套

生成HeaderExchangeClient时：Transporter生成Client（client，transporter两参数选择Transporter，默认NettyTransporter生成NettyClient），下面统一用NettyClient，生成HeaderExchangeChannel并传入NettyClient，客户端需要心跳，定时调度心跳任务（两参数heartbeat，heartbeat.timeout）

生成NettyClient时：Codec2的确定：用于封装解析协议头部，并调用Serialization（只有dubbo,thrift不用这个）进行body的序列化反序列化，很明显，Protocol生成Invoker时对URL加了codec参数，此时可设置正确的Codec2，设置timeout，connect.timeout等参数，open并connect（在不同Client内实现不同），此时长连接建立了

open：设置三ChannelHandler，decoder，encoder和最终的NettyHandler  
connect：发起连接建立，并等待连接建立完成（不超过connect.timeout）

ChannelHandler：dubbo自己定义了连接处理器接口，其含在连接上发生各种事件的处理逻辑，ChannelHandler在不同层次被多次封装，其逻辑是组装的  
ExchangeHandlerAdapter：最内层，Protocol内生成  
HeaderExchangeHandler封装：Exchanger层封装  
DecodeHandler封装：Exchanger层封装  
Dispatcher封装：NettyClient内封装，但其实是固定逻辑  
HeartbeatHandler封装：NettyClient内封装，但其实是固定逻辑  
MultiMessageHandler封装：NettyClient内封装，但其实是固定逻辑  
NettyClient封装：Transporter层（即NettyClient）内封装  
NettyHandler封装：此为netty的ChannelHandler，Transporter内封装

consumer不会把URL传到provider处，只会传Invocation,provider的URL承载的是服务端的配置，服务端可从Invocation的attachments取到客户端的配置

Cluster.join生成Invoker：由于MockClusterWrapper是wrapperClass，获取的Cluster是MockClusterWrapper封装一原始Cluster，join得到的是MockClusterInvoker封装一原始ClusterInvoker

客户端invoke调用流程：  
1 MockClusterInvoker：URL含mock：为force直接mock，其它正常调用异常再mock，mock逻辑(若directory.list后无可用Invoker，则创建一个MockInvoker进行调用，MockInvoker内含底层mock逻辑)  
2 ClusterInvoker：先调用directory的list（内部route），再调用LoadBalance，最后调用确定的Invoker，各类ClusterInvoker在调用失败等处理不一样  
3 ProtocolFilterWrapper生成的Invoker：Invoker和Filter交替执行的方式，Invoker1执行Filter1，Filter1执行Invoker2，Invoker2执行Filter2如此传递  
客户端执行哪些Filter：Activate匹配上的Filter（group传consumer）和URL的reference.filter指定的  
实际上，很多逻辑都是在Filter这里扩展的  
ValidationFilter：客户端服务端两侧，URL含validation，Validation获取（根据URL从内部缓存取或创建）Validator，调用Validator的validate方法，注意Validation是通过SpiExtensionFactory注入的adaptive实例  
TpsLimitFilter：provider端URL含tps，来进行限流  
TokenFilter：provider端URL含token，服务端验证客户端发送来的token是否和自己一致，令牌验证，客户端token需由注册中心下发，避免客户端绕过注册中心  
TimeoutFilter：provider端，服务端记录下调用时间超过自己配置的timeout参数的调用  
MonitorFilter：两侧，若自己这端URL含monitor调用完成或异常数据提给监控中心，相关接口：MonitorFactory，Monitor  
GenericImplFilter：consumer端，URL含generic，对泛化调用进行检查，如不符合要求异常  
GenericFilter：provider端，对泛化调用进行处理，重新封装RpcInvocation，如参数中取出方法名找到接口对应方法  
FutureFilter：consumer端，对oninvoke，onreturn，onthrow进行处理，此时可调用某bean的某方法，考虑同步异步，异步将逻辑放在future的callback内  
ExecuteLimitFilter：provider端URL含executes，限制某服务的某方法同时执行的次数，通过Semaphore  
EchoFilter：provider端，方法名为$echo且只有一个参数，直接返回此参数  
ContextFilter：provider端，设置RpcContext且调用完成移除RpcContext  
ConsumerContextFilter：consumer端，设置RpcContext且调用完成移除Context内attachments  
ClassLoaderFilter：provider端，线程contextClassLoader设为接口的类加载器，调用完成恢复  
AccessLogFilter：provider端URL含accesslog，日志记录  
ActiveLimitFilter：consumer端URL含actives，限制某服务的某方法同时执行的次数  
CacheFilter：两侧，URL含cache，CacheFactory获取（根据URL从内部缓存取或创建）Cache，Cache根据key获取结果，  
URL含地址+接口+方法名，key含方法参数值，获取的是一次完全相同的调用的结果，实现：threadlocal，lru等

4 ListenerInvokerWrapper：3，4的顺序暂时不确定，在此Invoker创建时和摧毁时调用各InvokerListener的referred和destroyed方法，此时invoke无逻辑  
5 底层Invoker如DubboInvoker：选择ExchangeClient调用（多个轮询）  
Oneway：没有future，返回空的结果  
异步：RpcContext设置future，返回空的结果  
同步：不设置future，直接在future上等待结果  
6 HeaderExchangeClient的request或send方法：调用下层  
7 HeaderExchangeChannel：封装Request对象，生成ID，若request方法则创建future，调用下层  
8 NettyClient：找到自己连接（Netty的原生Channel）对应的NettyChannel（第一次调用则创建），调用NettyChannel相关方法  
9 NettyChannel：调用Netty的原生Channel的write方法，这里我觉得有点问题，原生Channel和NettyChannel（含原生Channel，第一次服务调用时创建NettyChannel时的URL，ChannelHandler）存在映射  
10 write肯定由tail向head传递，在encoder这个ChannelHandler处有编码，获取NettyChannel（根据原生Channel），调用Codec2的encode方法，如Dubbo则为DubboCountCodec，写入header并序列化Request对象

数据写到连接的缓存区域，由Processor线程flush，flush的时候可能几个Request一起发出了