dubbo-2

矫情吗；* 2021-12-23 07:07 172阅读 0赞

对端处理接收到的数据：  
1 Processor线程处理读事件，head-tail，先decoder这个ChannelHandler，Codec2解码（如多个Request解码成MultiMessage对象）  
2 走到NettyHandler（在NettyServer内生成的和在NettyClient内的基本是一致，细微差别），在MultiMessageHandler处判断  
若为MultiMessage则对象分解开交由下层handler  
3 HeartbeatHandler判断为心跳请求给与应答，为心跳响应不处理，其它交由下层handler  
4 Dispatcher生成的Handler：处理移交到其他线程了（线程池），direct不移交，all全部移交，message只对接收到数据事件进行移交，内部线程池由ThreadPool 生成（根据URL参数），客户端一个连接一个ChannelHandler一个线程池（默认使用的是cached），服务端accept的连接的ChannelHandler是同一个，每个连接有自己的pipeline，但是最终引用了相同的ChannelHandler（使用fixed线程池）  
5 DecodeHandler：接收到的Request或Response内数据实现了Decodeable，或接收到一个Decodeable，调用其decode方法  
6 HeaderExchangeHandler：接收到Request，调用下层处理，封装Response并发送给对端（twoWay），接收到Response，  
根据ID找到future，设置future内的应答，唤醒等待线程（若有），调用callback（若有），移除相应数据，接收到String，调用下层telnet方法，结果发给对端  
7 底层Handler：找到Protocol内的Exporter（根据serviceKey：如dubbo.DemoService:8010），调用Exporter内的Invoker的invoke方法，考虑stubService（传来的dubbo.stub.event为true）和callbackService（非stub且自己是客户端）

服务暴露：可能向多个注册中心注册和多个协议下暴露（一个协议暴露需一个port），如2注册中心2协议，那么ServiceConfig应该有4个Exporter  
同时Protocol内部维护了serviceKey-Exporter的映射，方便服务端找到Exporter进行调用  
举例：某服务在A协议维护了1个底层Exporter，在B协议维护了1个底层Exporter，2注册中心情况下，ServiceConfig应该有4个Exporter(DestroyableExporter，通过RegistryProtocol获得，封装了底层Exporter)  
创建服务端的Invoker（通过ProxyFactory），通过protocol的export方法创建Exporter（封装Invoker）  
本地暴露(injvm protocol 本地refer本地export的服务)，这种没有端口

RegistryFactory根据URL找到（没有创建） Registry（RegistryService），可向Registry进行register和unregister和subscribe和unsubscribe操作，提供者需注册自己，提供者需订阅override数据，消费者需注册自己，消费者需订阅providers，routers，configurators信息，订阅需要传入NotifyListener作为接收到订阅消息后的callback，RegistryDirectory本身就是NotifyListener

像loadbalance这样的参数客户端和服务端都可以配置，客户端获取到服务端配置（NotifyListener），ClusterUtils.mergeUrl方法合并客户端和服务端配置，放在InvokerDelegate内（providerUrl代表服务端原始配置，url代表合并后配置）

客户端没有接口可以泛化调用，服务端没有接口可以泛化实现

隐式传参：RpcContext的attachments放参数，封装进RpcInvocation传递过去（AbstractInvoker内），对端取出attachments放到自己的RpcContext内（ContextFilter内）

服务默认本地暴露（除非scope为none或remote），引用服务默认优先引用本地服务(只要InjvmProtocol含此服务的Exporter)

callback：服务端调用客户端（类似客户端暴露服务了）  
stub  
accepts：控制服务端每个如NettyServer能接收的连接上限，AbstractServer.connected方法判断新加此连接后总连接是否超过accepts，超过关闭此新连接  
路由：客户端订阅了category为routers的内容，当注册中心配置了路由规则后，客户端接收到相应URL,通过RouterFactory创建Router，如将rule参数解析为ConditionRouter内的规则，常见的条件路由通过=>分隔consumer和provider的匹配条件，还有脚本，标签路由  
容器：我们自己启动应用就自己写个类启动ApplicationContext并保证主线程阻塞，其实还可以通过dubbo的Main类启动，传入参数表明需要启动的容器（默认spring容器，加载classpath\*:META-INF/spring/\*.xml的配置），还可以传入log4j等  
ReferenceConfigCache 用于缓存ReferenceConfig，避免在API编程时重复创建ReferenceConfig  
ThreadPool生成的线程池自定义了AbortPolicyWithReport，拒绝任务时会通过jstack导出线程堆栈  
DubboProtocol的optimizeSerialization方法可以看到：optimizer参数指定了SerializationOptimizer的类名，SerializationOptimizer含很多可序列化类，这些类可以注册进SerializableClassRegistry，用dubbo协议并使用Kryo, FST进行序列化时，会加入SerializableClassRegistry所含类以优化序列化性能

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tvYmV4emY_size_16_color_FFFFFF_t_70]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tvYmV4emY_size_16_color_FFFFFF_t_70]: /images/20211223/59e96af577944695a40dd83221c1c0de.png