Smile
Smile I'm a Java developer.

Dubbo面试大纲


Dubbo面试大纲

Dubbo

简介

本篇文章不是进行详细的Dubbo实现以及原理分析的文章,适用于用过Dubbo,对Dubbo有一定了解准备面试的小伙伴阅读。下面列的一些点,如果能在面试时候说到,那面试官肯定觉得不错了。

服务暴露

1.从xml读取ServiceBean配置,订阅了spring容器上下文刷新事件进行export动作
2.暴露过程中,如果是延迟暴露,则启动一个线程,延迟delay时长在进行doExport动作
3.会遍历所有的协议,所有的url进行暴露。(这也就是dubbo支持多协议多注册中心)
4.接下来就是一系列的构建url操作(获取ip,端口,提供方法等)
5.将bean进行一个代理(最终调用就不是通过反射调用)换成一个Invoker对象
6.将Invoker对象去注册中心上进行export动作

  • 本地进行暴露,主要就是根据传输层协议扩展点启动一个netty服务,监听一个端口,返回一个exporter对象
  • 将提供者url信息注册到zookeeper,并且监听provider下目录数据的变化
服务引用

1.从xml读取ReferenceBean配置,ReferenceBean实现了FactoryBean接口,会调用getObject进行引用ref
2.通过注册中心想provider目录下的consumers目录下注册本机消费者地址,同时订阅provider下providers、configurators、routers目录数据变化
3.通过获取到provider的url,将提供者的url列表转换成invoker列表
– 转换的过程中,每一个url会初始化创建一个netty新连接,以及开启心跳

4.最终将多个invoker,封装成一个invoker对外使用,封装出来的invoker就继承了集群,负载均衡,容错等功能
5.最后将ReferenceBean进行一个代理,传入上面获取的invoker

服务调用
  • 消费方调用provider方法,会进入到invoker.invoke方法,判断是否走mock,以及集群,容错,负载,在经过一系列的filter,最终调用到具体的一个invoker对象。通过ref时候的client连接向服务端发送一个请求。
    consumer :
    MockClusterInvoker->FailoverClusterInvoke->ListenerInvokerWrapper->ProtocolFilterWrapper-><br></br>ConsumerTraceFilter->InvokeResultLogFilter->FutureFilter->MonitorFilter->DubboInvoker
  • 提供方接受到请求后,进行消息解码,消息转换成Invocation对象,从exporterMap中获取到exporter和Invoker对象,根据方法名调用provider方法,得到返回结果返回

SPI

1.普通扩展点
2.自适应扩展点
3.wrapper扩站点
4.自动激活扩展点

负载均衡-LoadBalance

  • 基于权重的随机(默认负载均衡策略)。首先判断权重是否都相同,如果都相同则直接随机选取,如果权重不一样,则根据权重得到一个总和,遍历来确定某个提供者
  • 基于权重的轮询。同样的首先判断权重是否都相同,如果都相同则根据序号取模轮询,如果不同则序号对最大权重取模得到当前权重,遍历获得比当前权重大的集合在轮询
  • 最少活跃连接数。为每个提供者维护了一个活跃连接数值,获得最少的活跃连接数列表,然后随机取值。
  • 一致性hash。默认一个提供者对应的160个虚拟节点

集群-Cluster

  • 失败转移/失败重试(failover)默认策略)。当调用失败后,根据配置重试次数重新选取另一个提供者进行调用,直至成功或者最大重试次数
  • 可用(available)。遍历所有提供者,只要一个可用就返回
  • 广播(broadcast)。遍历所有提供者,所有都调用一次
  • 失败降级(failback)。调用失败降级,后台记录失败请求,定时重发,适用消息通知操作
  • 快速失败(failfast)。调用失败后,直接报错
  • 失败安全(failsafe)。调用失败后,降级,只记录失败日志,可用户写入审计日志
  • 并行调用(forking)。并行调用,只要有一个成功就返回,通常适用于实时性要求较高场景,但会浪费更多服务资源

使用dubbo过程中遇到的坑

  • 使用(2.5.3)时候,异步调用存在传递,A调B异步调用,B里面去调用C的时候也变成异步调用,拿到是NULL
    解决:在B里面手动调用从RpcContext attachements里面删除异步调用key
    新版本解决这个问题,ContextFilter里面删除了异步调用KEY
  • 版本:(2.6.5)dubbo优雅关闭,spring容器关闭了,dubbo可能还未关闭,造成dubbo请求去获取redis连接时候报连接池已经关闭,报错。
    解决:利用spring关闭提供的Lifecycle接口start, stop钩子,执行时机在spring关闭destroyBean之前,这样等dubbo关闭了spring在关闭
    利用spring关闭提供的ContextCloseEvent事件
  • 使用(2.5.3)时候,Provider方在ContextFilter之前如果自己设置参数到RpcContext#attachements中,到后面就没有了,经过ContextFilter就被覆盖了

2.6.5相较于2.5.3 diff

1.替换zkClient为Apache Curator
2.增加QOS模块
3.外部化配置
4.ServiceConfig hostToRegistry

不好的点

  • 很多兼容的代码,和很多重复的判断,可以去掉精简

使用到设计模式:

1.模版模式
2.代理模式
3.装饰器模式

1.SPI ExtensionLoader
2.ServiceConfig export服务暴露
2.ReferenceConfig refer服务引用
3.服务一次调用过程

provider接收请求处理类流程:
NettyHandler->MultiMessageHandler->HeartbeatHandler->AllChannelHandler->DecodeHandler->HeaderExchangeHandler->DubboProtocol(requestHandler)

consumer filter:
MockClusterInvoker->FailoverClusterInvoke->ListenerInvokerWrapper->ProtocolFilterWrapper->ConsumerTraceFilter->InvokeResultLogFilter->FutureFilter->MonitorFilter->DubboInvoke

comments powered by Disqus