RPC Dubbo面试题汇总

RPC

RPC 是什么?

RPC（Remote Procedure Call） 即远程过程调用，通过名字我们就能看出 RPC 关注的是远程调用而非本地调用。

为什么要 RPC ？ 因为，两个不同的服务器上的服务提供的方法不在一个内存空间，所以，需要通过网络编程才能传递方法调用所需要的参数。并且，方法调用的结果也需要通过网络编程来接收。但是，如果我们自己手动网络编程来实现这个调用过程的话工作量是非常大的，因为，我们需要考虑底层传输方式（TCP 还是 UDP）、序列化方式等等方面。

RPC 能帮助我们做什么呢？ 简单来说，通过 RPC 可以帮助我们调用远程计算机上某个服务的方法，这个过程就像调用本地方法一样简单。并且！我们不需要了解底层网络编程的具体细节。举个例子：两个不同的服务 A、B 部署在两台不同的机器上，服务 A 如果想要调用服务 B 中的某个方法的话就可以通过 RPC 来做。
一言蔽之：RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单。

RPC的原理是什么？

1. 服务消费端（client）以本地调用的方式调用远程服务；
2. 客户端 Stub（client stub） 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）：RpcRequest；
3. 客户端 Stub（client stub） 找到远程服务的地址，并将消息发送到服务提供端；
4. 服务端 Stub（桩）收到消息将消息反序列化为 Java 对象: RpcRequest；
5. 服务端 Stub（桩）根据RpcRequest中的类、方法、方法参数等信息调用本地的方法；
6. 服务端 Stub（桩）得到方法执行结果并将组装成能够进行网络传输的消息体：RpcResponse（序列化）发送至消费方；
7. 客户端 Stub（client stub）接收到消息并将消息反序列化为 Java 对象:RpcResponse ，这样也就得到了最终结果。over!

有哪些常见的 RPC 框架？

RPC和HTTP的区别

1. 传输方式
   • RPC:可以使用TCP或UDP作为传输协议。
   • HTTP:使用TCP作为传输协议。
2. 编码格式
   网络传输前，需要结构体转化成二进制数据——>序列化
   在HTTP1.1中，序列化协议是JSON。优点：非常的直观；缺点：占的空间大，传输速率较慢。
   在RPC中，序列化协议是protobat。优点：数据包小， 传输速率快，序列化与反序列化效率快
3. 字段
   HTTP1.1
   优点：灵活，可以定义很多字段。
   缺点：包含许多为了适应浏览器的冗余字段，这些字段在内部服务其实是用不到的。
   RPC
   优点：可定制化，自定义必要字段即可；所以可以摒弃HTTP Header中的冗余字段，比如浏览器的各种行为。

RPC的优势与不足
优点：

（1）相较于HTTP1.1，数据包更小，序列化更快，传输速率很高。

（2）基于TCP或HTTP2的自定义RPC协议，网络传输性能比HTTP1.1更快。

（3）适用于微服务架构，微服务集群下，每个微服务指责单一，有利于多团队的分工合作。

缺点：

（1）RPC协议本身无法解决微服务集群的问题，例如：服务发现，服务治理等，需要工具来保障服务的稳定性。

（2）调用方对服务端的RPC接口有很强的依赖性，需要有自动化工具，版本管理工具来保证代码级别的强依赖性。例如，stup桩文件需要频繁更新，否则接口调用方式可能会出错。

Dubbo

什么是Dubbo？为什么要用Dubbo?

Dubbo是一款高性能、轻量级的开源 WEB 和 RPC 框架。

优点：

高性能： Dubbo 在设计上注重性能，采用了简单的远程调用方式和高效的序列化机制。
服务治理： 提供了丰富的服务治理功能，包括负载均衡、容错机制（如熔断、降级）、服务路由等，适合复杂的分布式场景。
支持多协议： Dubbo 支持多种通信协议，如 Dubbo 协议、HTTP、RMI 等，能够灵活适配不同的应用需求。
对中小型公司友好： 简单易用，适合中小型公司快速构建微服务架构。

Dubbo 的核心组件？

• Container： 服务运行容器，负责加载、运行服务提供者。必须。
• Provider： 暴露服务的服务提供方，会向注册中心注册自己提供的服务。必须。
• Consumer： 调用远程服务的服务消费方，会向注册中心订阅自己所需的服务。必须。
• Registry： 服务注册与发现的注册中心。注册中心会返回服务提供者地址列表给消费者。非必须。
• Monitor： 统计服务的调用次数和调用时间的监控中心。服务消费者和提供者会定时发送统计数据到监控中心。 非必须。

Dubbo 支持哪些序列化方式呢？

Dubbo 支持多种序列化方式：JDK 自带的序列化、hessian2、JSON、Kryo、FST、Protostuff，ProtoBuf 等等。
Dubbo 默认使用的序列化方式是 hessian2。

一般我们不会直接使用 JDK 自带的序列化方式。
主要原因有两个：

• 不支持跨语言调用 : 如果调用的是其他语言开发的服务的时候就不支持了。
• 性能差：相比于其他序列化框架性能更低，主要原因是序列化之后的字节数组体积较大，导致传输成本加大。
  JSON 序列化由于性能问题，我们一般也不会考虑使用。像 Protostuff，ProtoBuf、hessian2 这些都是跨语言的序列化方式，如果有跨语言需求的话可以考虑使用。Kryo 和 FST 这两种序列化方式是 Dubbo 后来才引入的，性能非常好。不过，这两者都是专门针对 Java 语言的。Dubbo 官网的一篇文章中提到说推荐使用 Kryo 作为生产环境的序列化方式。

Dubbo 集群提供了哪些负载均衡策略？

1、 Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；
2、 RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题；
3、 LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；
4、ConsistentHash LoadBalance 一致性 Hash 策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动；
缺省时为 Random 随机调用

Dubbo 和 Spring Cloud 的区别？

这是很多面试官喜欢问的问题，本人认为其实他们没什么关联之处，但是硬是要问区别，那就说
说 吧。
回答的时候主要围绕着四个关键点来说：通信方式、注册中心、监控、断路器，其余像 Spring 分
布 式配置、服务网关肯定得知道。

• 通信方式
  Dubbo 使用的是 RPC 通信；Spring Cloud 使用的是 HTTP RestFul 方式。
• 注册中心
  Dubbo 使用 ZooKeeper（官方推荐），还有 Redis、 Multicast、Simple 注册中心，但不推荐。
  Spring Cloud 使用的是 Spring Cloud Netflix Eureka。
• 监控
  Dubbo 使用的是 Dubbo-monitor ；Spring Cloud 使用的是 Spring Boot admin。
• 断路器
  Dubbo 在断路器这方面还不完善，Spring Cloud 使用的是 Spring Cloud Netflix Hystrix。
  分布式配置、网关服务、服务跟踪、消息总线、批量任务等。
  Dubbo 目前可以说还是空白，而 Spring Cloud 都有相应的组件来支撑。

Dubbo 支持哪些协议，每种协议的应用场景，优缺点？

1、 dubbo： 单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步，Hessian 序列化；
2、 rmi： 采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象需要实现 Serializable 接口，使用 java 标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议 TCP。 多个短连接，TCP 协议传输，同步传输，适用常规的远程服务调用和 rmi 互操作。在依赖低版本的 Common-Collections
包，java 序列化存在安全漏洞；
3、 webservice： 基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生WebService 的互操作。多个短连接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用；
4、 http： 基于 Http 表单提交的远程调用协议，使用 Spring 的HttpInvoke 实现。多个短连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器 JS 调用；
5、 hessian： 集成 Hessian 服务，基于 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 内嵌 Jetty 作为服务器时默认实现，提供与 Hession 服务互操作。多个短连接，同步 HTTP 传输，Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；
6、 memcache： 基于 memcached 实现的 RPC 协议
7、 redis： 基于 redis 实现的 RPC 协议

注册中心挂了，Consumer 还能不能调用 Provider？

可以。因为刚开始初始化的时候， consumer 会将需要的所有提供者的地址等信息拉取到本地
缓 存，所以注册中心挂了可以继续通信。但是 provider 挂了，那就没法调用了。

说说Dubbo的工作原理？

工作原理分 10 层：
第一层：service 层，接口层，给服务提供者和消费者来实现的（留给开发人员来实现）；
第二层：config 层，配置层，主要是对 Dubbo 进行各种配置的，Dubbo 相关配置；
第三层：proxy 层，服务代理层，透明生成客户端的 stub 和服务单的 skeleton，调用的
是接 口，实现类没有，所以得生成代理，代理之间再进行网络通讯、负责均衡等；
第四层： registry 层，服务注册层，负责服务的注册与发现；
第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合
成一 个服务；
第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监
控； 第七层：protocol 层，远程调用层，封装 rpc 调用；
第八层： exchange 层，信息交换层，封装请求响应模式，同步转异步；
· 第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口；
第十层：serialize 层，数据序列化层。

工作流程：

1）第一步，provider向注册中心去注册
2）第二步，consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务
3）第三步，consumer调用provider
4）第四步，consumer和provider都异步的通知监控中心

Dubbo和Feign的区别