阿里开源框架Dubbo原理分析和手写实现
Java在一个进程中,服务间的类或者方法的调用比较简单方便。
那么大家有没有想一想,如何实现不同进程之间的服务进行调用呢?
其实核心就是拿到被调用的类及方法。
可能实现的途径如下:
- Copy一份被调用的服务到调用方。但无实际意义。
- 打包成jar包,发布到Maven库里,调用方进行引用。基本思路同上。
- 借助网络传输。即–远程服务调用或者远程过程调用。Socket、HTTP应用层协议、TCP/UDP协议等实现。
结论:
第一阶段:远程远端调用class方法 - 有一个网络传输通道 Socket
- Java对象的序列化/反序列
- 要支持多线程
第二阶段:
好事之者:Remote Method Invocation RMI针对Java语言进行封装调用方法的方法。
第三阶段(跨语言): - 有一个网络传输通道 http协议
- 对象的序列化/反序列 XML文件
第四阶段:http+json 轻量级
最终的目的:远程服务调用。RPC->Remote Procedure Call。
RPC框架:Dubbo、Dubbox、Motan、grpc、thrift等。
一个场景:
服务提供方:集群模式,多节点。
服务调用方:集群模式,多节点,且需要调用多个服务方。
服务注册、发现,维护每一个服务的节点信息(包括IP、服务名称方法等)。
服务通信。
服务监控,monitor。出错或容错机制。
上述提到的内容需要框架来实现。
Dubbo官方架构:
我们手写注册中心是否可行?
1 | |
但没必要,可以用zk、nacos等完成心跳保持。
需求:
Consumer
Provider
启动zk。
./zkServer.sh start
./zkCli.sh 启动zk客户端
ls / 查看节点
ls /xx/xx/xx 查看节点中的子节点内容
实现:
- 服务注册,基于zk完成。
- 服务发现,(订阅subscribe/notify)-基于ZK完成。
- 服务间通信,使用传统的IO Socket,在高并发下效率低,使用nio->netty完成。
阿里开源框架Dubbo原理分析和手写实现
https://leehoward.cn/2022/06/05/阿里开源框架Dubbo原理分析和手写实现/
