Day5 Dubbo RPC调用 SPI

https://www.processon.com/view/link/61ed757ce401fd06afba2168

极其简单
Dubbo RPC 流程图

整个RPC调用流程概述(服务发布略过)

protocal封装RPC需要的条件，比如url invoker,参数这些.

1. 解析Dubbo的注册信息，配置文件，注解信息。
2. 根据注解生成代理类，Dubbo有自己的类文件生成技术
3. 请求发起之前需要选择合适的Cluster（因为肯定会会有调用失败的情况，默认的SPI上的注解是failover),
   这里会根据用户的配置选择合适的Cluster策略.
4. 根据负载均衡算法，默认是LoadBalance方法区选择策略. 默认是 Random,其他有类似权重，轮训，最小活跃数，一致性Hash等。
5. Zk中配置的路径是 /dubbo/service/com.xx.User/json(urls). Type是接口，根据Type接口负载均衡取url链接
6. 接下来是调用Dubbo所有的请求都是通过Invoke包装的，那这里也是一样，同时Dubbo提供了Filter,比如Cache,限流，统计Filter等
   帮助我们进行发起调用前的一些过滤和准备工作。
7. Dubbo的通信默认是dubbo协议，基于hessian作为序列化协议.
   当然也有其他的websocket,http,protocal等协议.
8. 根据type类型从zk或者本地缓存列表中根据负载的url地址
9. 请求肯定会有监控，所以会经过monitor层.
10. 正式调用肯定要经过网络，所以要经过code,serialization. 远程的调用会统一包装成Protocal,构造方法中会有Invoker传入。
    默认是DubboProtocal。 这里会有很多的协议，比如私有的协议，供我们选择.
11. 调用方这里会有AsyncResult做调用的等待返回， Dubbo高版本的异步操作用compatableFuture
12. Server方有ThreadPool.CachedThreadPool接收用户请求.
    Server端有Export解析请求，解析请求后同样也会经过很多层的Filter.
    也会经过很多层的Wrapper，最终剥离开来找到target目标类.
13. 最终调用到目标服务类. 可能是jdk动态代理生成的类，也可能是通过Javassist生成的类.

总体流程无非就是：

根据配置信息，约定的接口，传参，负载，监控，所有的调用都会包装成Invoker，同时也有自己的IOC,setXX方法，Wrapper (AOP做增强，最终剥开来，根据传参选择目标接口，目标是实现类，完成调用,通过Netty通信，CompatableFuture，CacheThreadPool等手段提高通信效率.

Export是导出，导出url，注册服务。 导出启动Server供调用.

Ref:

Jack 咕泡5.周振宇的笔记.