39.dubbo面试题

39.dubbo面试题

dubbo工作原理:

第一层：service层，接口层，给服务提供者和消费者来实现的

第二层：config层，配置层，主要是对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支持哪些通信协议？支持哪些序列化协议？

（1）dubbo支持不同的通信协议

 

1）dubbo协议

 

dubbo://192.168.0.1:20188

 

默认就是走dubbo协议的，单一长连接，NIO异步通信，基于hessian作为序列化协议

 

适用的场景就是：传输数据量很小（每次请求在100kb以内），但是并发量很高

 

为了要支持高并发场景，一般是服务提供者就几台机器，但是服务消费者有上百台，可能每天调用量达到上亿次！此时用长连接是最合适的，就是跟每个服务消费者维持一个长连接就可以，可能总共就100个连接。然后后面直接基于长连接NIO异步通信，可以支撑高并发请求。

 

否则如果上亿次请求每次都是短连接的话，服务提供者会扛不住。

 

而且因为走的是单一长连接，所以传输数据量太大的话，会导致并发能力降低。所以一般建议是传输数据量很小，支撑高并发访问。

 

2）rmi协议

 

走java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用

 

3）hessian协议

 

走hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用

 

4）http协议

 

走json序列化

 

5）webservice

 

走SOAP文本序列化

 

（2）dubbo支持的序列化协议

 

所以dubbo实际基于不同的通信协议，支持hessian、java二进制序列化、json、SOAP文本序列化多种序列化协议。但是hessian是其默认的序列化协议。

 

dubbo负载均衡策略和集群容错策略都有哪些？动态代理策略呢？

负载均衡策略，集群容错策略，动态代理策略：dubbo跑起来的时候一些功能是如何运转的，怎么做负载均衡？怎么做集群容错？怎么生成动态代理？

（1）dubbo负载均衡策略

 

1）random loadbalance

 

默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。

 

2）roundrobin loadbalance

 

还有roundrobin loadbalance，这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。

 

跟运维同学申请机器，有的时候，我们运气，正好公司资源比较充足，刚刚有一批热气腾腾，刚刚做好的一批虚拟机新鲜出炉，配置都比较高。8核+16g，机器，2台。过了一段时间，我感觉2台机器有点不太够，我去找运维同学，哥儿们，你能不能再给我1台机器，4核+8G的机器。我还是得要。

 

3）leastactive loadbalance

 

这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求

 

4）consistanthash loadbalance

 

一致性Hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。

 

（2）dubbo集群容错策略

 

1）failover cluster模式

 

失败自动切换，自动重试其他机器，默认就是这个，常见于读操作

 

1. failfast cluster模式

一次调用失败就立即失败，常见于写操作

 

3）failsafe cluster模式

 

出现异常时忽略掉，常用于不重要的接口调用，比如记录日志

 

4）failbackc cluster模式

 

失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种

 

5）forking cluster

 

并行调用多个provider，只要一个成功就立即返回

 

6）broadcacst cluster

 

逐个调用所有的provider

 

（3）dubbo动态代理策略

 

默认使用javassist动态字节码生成，创建代理类

 

但是可以通过spi扩展机制配置自己的动态代理策略