测试面试题集-Dubbo常见面试题
13
2020-11
今天距2021年48天
这是ITester软件测试小栈第175次推文
点击上方蓝字“ITester软件测试小栈“关注我，每周一、三、五早上 08:30准时推送，每月不定期赠送技术书籍。
微信公众号后台回复“资源”、“测试工具包”领取测试资源，回复“微信群”一起进群打怪。
本文5289字，阅读约需15分钟
水往低处流，人想往高处走，怎么能不懂 Dubbo？
Dubbo作为国内最出名的分布式服务框架，是Java程序员必备必会的框架之一，更是中高级测试面试过程中经常会问的技术，无论你是否用过，你都必须熟悉。以下总结一些 Dubbo常见的的面试题，希望对大家能有所帮助。
Dubbo是阿里巴巴公司开源的一个高性能分布式服务框架。其核心部分包含：
集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
生产者（Provider）：暴露服务的提供方，可以通过jar或者容器的方式启动服务；
消费者（Consumer）：调用远程服务的服务消费方；
注册中心（Registry）：服务注册中心和发现中心；
监控中心（Monitor）：统计服务和调用次数，调用时间监控中心；
服务容器（Container）：服务运行的容器，负责启动、加载，运行服务；
流程：首先生产者将服务注册到注册中心（zk），使用zk持久节点进行存储，消费订阅zk节点，一旦有节点变更，zk通过事件通知传递给消费者，消费可以调用生产者服务。服务与服务之间进行调用，都会在监控中心中，存储一个记录。
服务启动的时候，Provider和Consumer根据配置信息，连接到注册中心Register，分别向注册中心注册和订阅服务；
register根据服务订阅关系，返回Provider信息到Consumer，同时Consumer会把Provider信息缓存到本地。如果信息有变更，Consumer会收到来自Register的推送；
Consumer生成代理对象，同时根据负载均衡策略，选择一台Provider，同时定时向Monitor记录接口的调用次数和时间信息，拿到代理对象之后，Consumer通过代理对象发起接口调用；
Provider收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现；
从大的范围来说，Dubbo分为3层：Business业务逻辑层由我们自己来提供接口和实现还有一些配置信息，RPC层就是真正的RPC调用的核心层，封装整个RPC的调用过程、负载均衡、集群容错、代理，Remoting层则是对网络传输协议和数据转换的封装。
划分到更细的层面，就是10层模式，整个分层依赖由上至下，除开business业务逻辑之外，其他的几层都是SPI机制。10层模式如下：
服务接口层（Service）：与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过Spring解析配置生成配置类。服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。
1.dubbo默认协议：
单一 TCP 长连接，Hessian 二进制序列化和 NIO 异步通讯；
适合于小数据包大并发的服务调用和服务消费者数远大于服务提供者数的情况；
不适合传送大数据包的服务；
2.rmi协议：
采用 JDK 标准的 java.rmi.* 实现，阻塞式短连接和 JDK 标准序列化方式；
如果服务接口继承了 java.rmi.Remote 接口，可以和原生 RMI 互操作；
因反序列化漏洞，需升级 commons-collections3 到 3.2.2版本或 commons-collections4 到 4.1 版本；
对传输数据包不限，消费者和传输者个数相当；
3.hessian协议：
底层 Http 通讯，Servlet 暴露服务，Dubbo 缺省内嵌 Jetty 作为服务器实现；
可与原生 Hessian 服务互操作；
通讯效率高于 WebService 和 Java 自带的序列化；
参数及返回值需实现 Serializable 接口，自定义实现 List、Map、Number、Date、Calendar 等接口；
适用于传输数据包较大，提供者比消费者个数多，提供者压力较大；
4.http协议：
基于 http 表单的远程调用协议，短连接，json 序列化；
对传输数据包不限，不支持传文件；
适用于同时给应用程序和浏览器 JS 使用的服务；
5.webservice协议：
基于Apache CXF 的frontend-simple和transports-http 实现，短连接，SOAP文本序列化；
可与原生WebService服务互操作；
适用于系统集成、跨语言调用；
6.thrift协议：
对 thrift 原生协议的扩展添加了额外的头信息；
使用较少，不支持传 null 值；
7.redis协议:
redis在TCP端口6379上监听到来的连接，客户端连接到来时，Redis服务器为此创建一个TCP连接 ;
redis接收由不同参数组成的命令。一旦收到命令，将会立刻被处理，并回复给客户端;
8.memcached协议:
客户端使用TCP链接与服务器通讯，一个运行中的memcached服务器监视一些端口，客户端连接这些端口，发送命令到服务器，读取回应，最后关闭连接;
memcached协议中发送的数据分为文本行和自由数据两种；
核心配置有：
| 配置 | 说明 |
| dubbo:service/ | 服务配置 |
| dubbo:reference/ | 引用配置 |
| dubbo:argument/ | 参数配置 |
| dubbo:protocol/ | 协议配置 |
| dubbo:registry/ | 注册中心配置 |
| dubbo:application/ | 应用配置 |
| dubbo:provider/ | 提供方配置 |
| dubbo:consumer/ | 消费方配置 |
| dubbo:method/ | 方法配置 |
| dubbo:module/ | 模块配置 |
| dubbo:monitor/ | 监控中心配置 |
在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。具体的集群容错方案有：
| 集群容错方案 | 说明 |
| Failover Cluster | 失败自动切换，自动重试其他服务器（默认） |
| Failfast Cluster | 快速失败，立即报错，只发起一次调用 |
| Failsafe Cluster | 失败安全，出现异常时，直接忽略 |
| Failback Cluster | 失败自动恢复，记录失败请求，定时重发 |
| Forking Cluster | 并行调用多个服务器，只要一个成功即返回 |
| Broadcast Cluster | 广播逐个调用所有提供者，任意一个报错则报错 |
Dubbo内置了4种负载均衡策略：
| 负载均衡策略 | 说明 |
| RandomLoadBalance | 随机负载均衡，按权重设置随机概率（默认） |
| RoundRobinLoadBalance | 轮询负载均衡，按公约后的权重设置轮询比率 |
| LeastActiveLoadBalance | 最少活跃调用数，相同活跃数的随机 |
| ConsistentHashLoadBalance | 一致性Hash负载均衡，相同参数的请求总是发到同一个提供者 |
工厂模式：Provider在export服务时，会调用ServiceConfig的export方法，实现类的获取采用了JDK SPI的机制，想要扩展实现，只需要在classpath下增加文件即可，代码零侵入；
装饰器模式：Dubbo在启动和调用阶段都大量使用了装饰器模式，如ClassLoaderFilter在主功能上添加功能，更改当前线程的ClassLoader是典型的装饰器模式；
观察者模式：Dubbo的Provider启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，采用了观察者模式；
动态代理模式：Dubbo扩展JDK SPI的类ExtensionLoader的Adaptive实现是典型的动态代理实现，Dubbo需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪个实现类，所以采用先生成代理类的方法，做到灵活的调用。
9
Multicast 注册中心：Multicast 注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现,基于网络中组播传输实现。
Zookeeper 注册中心：基于分布式协调系统 Zookeeper 实现，采用 Zookeeper 的 watch 机制实现数据变更。
Redis 注册中心：基于 Redis 实现，采用 key/map 存储，key 存储服务名和类型，map 中 key 存储服务 url，value 服务过期时间。基于 Redis 的发布/订阅模式通知数据变更。
Simple 注册中心：Simple 注册中心本身就是一个普通的 Dubbo 服务，可以减少第三方依赖，使整体通讯方式一致。
Spring Container；
Jetty Container；
Log4j Container；
XML 配置文件方式；
properties 配置文件方式；
annotation 配置方式；
API 配置方式；
回复"资源"取干货个人微信：Cc2015123
添加请注明来意 :)
