文章目录
- Dubbo篇
-
-
- zookeeper和dubbo的关系
- 知道什么是SPI嘛?
- 为什么Dubbo不用JDK的SPI而是要自己实现?
- Dubbo 动态代理策略有哪些?
- RPC框架需要解决的问题?
- RPC的实现基础?
- RPC使用了哪些关键技术?
- RPC和Http有什么区别 ? / 既然有 HTTP 请求,为什么还要用 RPC 调用?
- RPC 与 REST
- 如何实现一个 RPC 框架?
- 说一下Dubbo的一次服务请求流程?
- 为什么不能传大包?
- 为什么采用异步单一长连接?
- dubbo 默认使用什么序列化框架,你知道的还有哪些?
- 什么是本地暴露和远程暴露,他们的区别
- 注册中心挂了,consumer 还能不能调用 provider?
- 怎么实现动态感知服务下线的呢?
- Dubbo 负载均衡策略?
-
Dubbo篇
zookeeper和dubbo的关系
ZooKeeper注册中心:在Dubbo架构中,ZooKeeper作为注册中心,为Dubbo提供了服务注册和发现的功能,而Dubbo则利用这些功能实现了服务间的远程调用和通信。
Dubbo则担任高性能RPC(远程过程调用)框架的一个角色,Dubbo提供了远程过程调用、负载均衡和服务治理等核心能力。
知道什么是SPI嘛?
SPI 是 Service Provider Interface,主要用于框架中,框架定义好接口,不同的使用者有不同的需求,因此需要有不同的实现,而 SPI 就通过定义一个特定的位置,Java SPI 约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件,然后文件里面记录的是此 jar 包提供的具体实现类的全限定名。所以就可以通过接口找到对应的文件,获取具体的实现类然后加载即可,做到了灵活的替换具体的实现类。
为什么Dubbo不用JDK的SPI而是要自己实现?
因为 Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化,假设一个实现类初始化过程比较消耗资源且耗时,但是你的代码里面又用不上它,这就产生了资源的浪费。
因此 Dubbo 就自己实现了一个 SPI,给每个实现类配了个名字,通过名字去文件里面找到对应的实现类全限定名然后加载实例化,按需加载。
Dubbo 动态代理策略有哪些?
默认使用 javassist 动态字节码生成,创建代理类,但是可以通过 SPI 扩展机制配置自己的动态代理策略。
RPC框架需要解决的问题?
- 如何确定客户端和服务端之间的通信协议?
- 如何更高效地进行网络通信?
- 服务端提供的服务如何暴露给客户端?
- 客户端如何发现这些暴露的服务?
- 如何更高效地对请求对象和响应结果进行序列化和反序列化操作?
RPC的实现基础?
- 需要有非常高效的网络通信,比如一般选择Netty作为网络通信框架;
- 需要有比较高效的序列化框架,比如谷歌的Protobuf序列化框架;
- 可靠的寻址方式(主要是提供服务的发现),比如可以使用Zookeeper来注册服务等等;
- 如果是带会话(状态)的RPC调用,还需要有会话