dubbo常见面试题整理

一、dubbo调用服务超时怎么解决

dubbo调用失败默认是重复调用两次，这时就会有2种情况

1）调用返回超时。可能存在的问题，比如发短信或邮件，会存在重复发送的问题

2）连接超时

1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
全局配置实例
<!-- 延迟到Spring初始化完成后，再暴露服务,服务调用超时设置为6秒,超时不重试-->
<dubbo:provider delay="-1" timeout="6000" retries="0"/>
细化配置
@Reference(retries = -1)

当然Dubbo的重试机制其实是非常好的QOS保证，它的路由机制，是会帮你把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。但是请一定要综合线上的访问情况，给出综合的评估。

二、Dubbo支持哪些序列化方式

• Hessian 序列化：是修改过的 hessian lite，默认启用
• json 序列化：使用 FastJson 库
• java 序列化：JDK 提供的序列化，性能不理想
• dubbo 序列化：未成熟的高效 java 序列化实现，不建议在生产环境使

三、Dubbo和SpringCloud的关系

SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式；

服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

四、Dubbo的架构设计，一共划分了哪些层

• 服务接口层(Service)：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现
• 配置层(Config)：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心
• 服务代理层(Proxy)：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton
• 服务注册层(Registry)：封装服务地址的注册与发现，以服务 URL 为中心
• 集群层(Cluster)：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心
• 监控层(Monitor)：RPC 调用次数和调用时间监控
• 远程调用层(Protocol)：封将 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocol、Invoker、Exporter
• 信息交换层(Exchange)：封装请求响应模式，同步转异步，以 Request 和 Response 为中心
• 网络传输层(Transport)：抽象 mina 和 netty 为统一接口，以 Message 为中心

五、Dubbo的默认集群容错方案？

Failover Cluster

失败自动切换，当出现失败，重试其它服务器。(缺省)
通常用于读操作，但重试会带来更长延迟。
可通过retries="2"来设置重试次数(不含第一次)。正是文章刚开始说的那种情况.

Failfast Cluster

快速失败，只发起一次调用，失败立即报错。
通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

失败安全，出现异常时，直接忽略。
通常用于写入审计日志等操作。

Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。
通常用于消息通知操作。

Forking Cluster

并行调用多个服务器，只要一个成功即返回。
通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
可通过forks="2"来设置最大并行数。

Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)
通常用于通知所有提供者更新缓存或日志等本地资源信息。
重试次数配置如：(failover集群模式生效)
<dubbo:serviceretries="2"/>
或：<dubbo:referenceretries="2"/>
或：<dubbo:reference>
             <dubbo:methodname="findFoo"retries="2"/>
     </dubbo:reference>

集群模式配置如：
<dubbo:servicecluster="failsafe"/>
或：<dubbo:referencecluster="failsafe"/>
dubbo负载均衡策略：
        在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。

RandomLoadBalance

随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

 ConsistentHashLoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

    Dubbo的集群容错和负载均衡同样也是Dubbo本身的高级特性.正如我们在说自定义扩展的时候一样,这两个特征同样也可以进行自定义扩展,用户可以根据自己实际的需求来扩展他们从而满足项目的实际需求.

 六、Dubbo使用的是什么通信框架

默认使用 Netty 作为通讯框架。

七、 dubbo主要应用场景

1.RPC分布式服务

当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。

比如：为了适用不断变化的市场需求，以及多个垂直应用之间数据交互方便，我们把公共的业务抽取出来作为独立的模块，为其他的应用提供服务，系统逐渐依赖于抽象和rpc远程服务调用。

2.配置管理

当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

3.服务依赖

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

4.服务扩容

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等……

在遇到这些问题时，都可以用Dubbo来解决。

八、Dubbo服务注册与发现的流程？流程说明

Provider(服务提供者)绑定指定端口并启动服务--注册中心：Zookeeper

• Provider 注册服务地址 

Provider 连接注册中心，将本机 IP、端口、应用信息和提供服务信息发送至注册中心存储

• Consumer 订阅服务地址

Consumer(服务消费者)，连接注册中心 ，发送应用信息、所求服务信息至注册中心

• 服务订阅或变更时，推送服务地址列表

注册中心根据 Consumer 请求的服务信息匹配对应的 Provider 列表，并发送至 Consumer 应用缓存

Provider 状态变更会实时通知注册中心、在由注册中心实时推送至 Consumer

• 随机调用一个服务地址，失败重试另外一个服务地址

Consumer 在发起远程调用时，选择基于缓存的 Provider 列表中的一个 Provider 的地址，发起调用

• 后台定时采集服务调用次数和调用时间等信息

九、dubbo四大组件

1、Provider：服务提供者

2、Registry：服务注册与发现的注册中心

3、Consumer：服务消费者

4、Monitor：统计服务的调用次数和调用时间的监控中心

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

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

默认使用dubbo协议

十一、Dubbo的核心功能有哪些？

• Remoting：网络通信框架，提供对多种 NIO 框架抽象封装，包括多种线程模型、序列化、同步转异步和请求-响应模式的信息交换方式
• Cluster：集群容错，提供基于接口方法的透明远程过程调用，包括多协议支持、软负载均衡、失败容错、地址路由、动态配置等集群支持
• Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器

十二、Dubbo的注册中心集群挂掉，发布者和订阅者之间还能通信么？ 

可以的，消费者在启动时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用，无法从注册中心去同步最新的服务列表，短期的注册中心挂掉是不要紧的，但一定要尽快修复。