dubbo-0x09-关于进程间通信协议

就我自己的理解,服务提供方和服务消费方的通信,不管是不是在同一台机器,本质都是两进程通信
进程通信的常用方法无非就是
- 共享内存
- 网络通信
- 本地unix局域网
- 远程网络
作为一个rpc框架,如果我认为http协议足够我应该就选用http就好了吧,我认为http协议太重,那么我就在tcp传输层基础上包装个专门的协议。
看到Protocol的基类我就感觉头晕目眩了,当然了就看默认基于netty的dubbo实现就行了
1 Protocol的动态
1 |
|
在dubbo中看到这种就要找对就的运行时实现是什么dubbo-0x05-SPI机制
Protocol接口类
- export方法用了@Adaptive注解,没指定url中key
- 类用了@SPI(“dubbo”)注解
所以运行时候就会
- 去wrapperInvoker中
getUrl
- protocol特殊处理通过
url.getProtocol()
方法拿到的结果作别名是registry - 用registry作为实现的别名用ExtensionLoader去找到对应的类反射出来实现就是RegistryProtocol
2 RegistryProtocol

它相当于是装饰器,并没有什么实质性逻辑,要做的事情有两个
- 在本地开放端口服务
- 把自身服务信息写到远程注册中心
2.1 开放服务
1 |
|
2.2 写注册中心
1 |
|
3 DubboProtocol在本机开放端口服务

这个就是配置给SPI去发现加载的,那么怎么加载到,前面dubbo-0x05-SPI机制讲过,SPI发现全靠URL的配置,所以可以看到dubbo在遍地复制URL,目的就是为了做动态发现
3.1 改URL的协议为dubbo加载出DubboProtocol
1 |
|
3.2 启动netty
加载出DubboProtocol后,后面又是一顿封装,兜兜转转最终终于见到了熟悉的netty
1 |
|
4 自身服务信息写到注册中心
上面服务提供者已经在本地开启了网络服务,这个时候就坐等别人来连接,这个别人是谁,是dubbo封装的服务消费方的代理请求。所以这个时候提供方要把自身服务信息暴露到注册中心去。
1 |
|
具体用哪个注册中心看dubbo-0x02-注册中心
5 消费端的网络通信
在dubbo-0x01-源码阅读规划就已经设想过肯定要在服务端对提供方的服务做代理实现的
但是服务端比较复杂,复杂在哪儿,网络通信不是单点对单点的,要考虑负载和重试,所以这整个网络通信的周边就不看了,也没必要。
核心就是把整个网络通信这一层封装起来创建个代理invoker,它从注册中心去拿到服务提供方的连接信息,用netty连接。
1 |
|
有了这个代理就已经解决了进程间通信的问题,现在要解决是怎么让消费方无调用,让它像自己在调用本地方法一样
6 本地方法代理
答案依然是代理,把上面的代理对象修饰一下,再套一层代理就行
1 |
|
至此,dubbo的骨干脉络就结束了