https://www.processon.com/view/link/61ed757ce401fd06afba2168
极其简单
Dubbo RPC 流程图
整个RPC调用流程概述(服务发布略过)
protocal封装RPC需要的条件，比如url invoker,参数这些.
- 解析Dubbo的注册信息，配置文件，注解信息。
- 根据注解生成代理类，Dubbo有自己的类文件生成技术
- 请求发起之前需要选择合适的Cluster（因为肯定会会有调用失败的情况，默认的SPI上的注解是failover),
这里会根据用户的配置选择合适的Cluster策略. - 根据负载均衡算法，默认是LoadBalance方法区选择策略. 默认是 Random,其他有类似权重，轮训，最小活跃数，一致性Hash等。
- Zk中配置的路径是 /dubbo/service/com.xx.User/json(urls). Type是接口，根据Type接口负载均衡取url链接
- 接下来是调用Dubbo所有的请求都是通过Invoke包装的，那这里也是一样，同时Dubbo提供了Filter,比如Cache,限流，统计Filter等
帮助我们进行发起调用前的一些过滤和准备工作。 - Dubbo的通信默认是dubbo协议，基于hessian作为序列化协议.
当然也有其他的websocket,http,protocal等协议. - 根据type类型从zk或者本地缓存列表中根据负载的url地址
- 请求肯定会有监控，所以会经过monitor层.
- 正式调用肯定要经过网络，所以要经过code,serialization. 远程的调用会统一包装成Protocal,构造方法中会有Invoker传入。
默认是DubboProtocal。 这里会有很多的协议，比如私有的协议，供我们选择. - 调用方这里会有AsyncResult做调用的等待返回， Dubbo高版本的异步操作用compatableFuture
- Server方有ThreadPool.CachedThreadPool接收用户请求.
Server端有Export解析请求，解析请求后同样也会经过很多层的Filter.
也会经过很多层的Wrapper，最终剥离开来找到target目标类. - 最终调用到目标服务类. 可能是jdk动态代理生成的类，也可能是通过Javassist生成的类.
总体流程无非就是：
根据配置信息，约定的接口，传参，负载，监控，所有的调用都会包装成Invoker，同时也有自己的IOC,setXX方法，Wrapper (AOP做增强，最终剥开来，根据传参选择目标接口，目标是实现类，完成调用,通过Netty通信，CompatableFuture，CacheThreadPool等手段提高通信效率.
Export是导出，导出url，注册服务。 导出启动Server供调用.
Ref:
Jack 咕泡5.周振宇的笔记.
网友评论