1.Dubbo是什么？

dubbo官方文档  http://dubbo.apache.org/zh/docs/v2.7/dev/implementation/

Dubbo是阿里巴巴开源的一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring框架无缝集成。

服务治理原因：

过多的服务URL配置困难

负载均衡分配节点压力过大的情况下也需要部署集群

服务依赖混乱，启动顺序不清晰

过多服务导致性能指标分析难度较大，需要监控

2.dubbo底层实现原理？

Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。

客服端一个线程调用远程接口，生成一个唯一的ID(比如一段随机字符串，UUID等)，Dubbo是使用AtomicLong从0开始累计数字的

2.   将打包的方法调用信息(如调用的接口名称，方法名称，参数值列表等)，和处理结果的回调对象callback，全部封装在一起，组成一个对象object

3.   向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object)

4.   将ID和打包的方法调用信息封装成一对象connRequest，使用IoSession.write(connRequest)异步发送出去

5.   当前线程再使用callback的get()方法试图获取远程返回的结果，在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。

6.   服务端接收到请求并处理后，将结果(此结果中包含了前面的ID，即回传)发送给客户端，客户端socket连接上专门监听消息的线程收到消息，分析结果，取到ID，再从前面的ConcurrentHashMap里面get(ID)，从而找到callback，将方法调用结果设置到callback对象里。

7.   监听线程接着使用synchronized获取回调对象callback的锁(因为前面调用过wait()，那个线程已释放callback的锁了)，再notifyAll()，唤醒前面处于等待状态的线程继续执行(callback的get()方法继续执行就能拿到调用结果了)，至此，整个过程结束。

3、dubbo都支持什么协议，推荐用哪种？protocol属性

dubbo： 单一长连接和NIO异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议TCP，异步，Hessian序列化；

rmi： 采用JDK标准的rmi协议实现，传输参数和返回参数对象需要实现Serializable接口，使用java标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议TCP。 多个短连接，TCP协议传输，同步传输，适用常规的远程服务调用和rmi互操作。在依赖低版本的Common-Collections包，java序列化存在安全漏洞；

webservice： 基于WebService的远程调用协议，集成CXF实现，提供和原生WebService的互操作。多个短连接，同步传输，适用系统集成和跨语言调用，走SOAP文本序列化。

http： 基于Http表单提交的远程调用协议，使用Spring的HttpInvoke实现。多个短连接， JSON序列化。

hessian： 集成Hessian服务，基于HTTP通讯，采用Servlet暴露服务，Dubbo内嵌Jetty作为服务器时默认实现，提供与Hession服务互操作。多个短连接，同步HTTP传输，Hessian序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；

redis： 基于redis实现的RPC协议

4、dubbo哪几种节点角色？

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

Monitor: 统计服务的调用次调和调用时间的监控中心。

Container: 服务运行容器。

5、dubbo服务注册与发现的流程？

Provider(提供者)绑定指定端口并启动服务，连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储

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

注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。

Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。

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

6、Dubbo内置了哪几种服务容器？

目前已有的容器实现 Spring Container、Jetty Container、Log4j Container、LogbackContainer。dubbo的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。不需要web容器。

7.dubbo的 SPI扩展

SPI(Service Provider Interface)服务提供商接口，是一种动态替换发现服务实现者的机制。 JDK 为SPI提供了工具类 java.util.ServiceLoader，指定加载resource目录META-INF/services下，文件名就是服务接口的全限定名。缺点：ServiceLoader也算是使用的延迟加载。但是通过遍历获取，接口的实现类全部实例化一遍，不灵活浪费。

Dubbo SPI对JDK SPI进行了扩展，由原来的提供者类的全限定名列表改成了KV形式的列表，这也导致了Dubbo中无法直接使用JDK ServiceLoader，所以，与之对应的，在Dubbo中有ExtensionLoader是扩展点载入器，用于载入Dubbo中的各种可配置组件。Dubbo默认依次扫描META-INF/dubbo/internal/、META-INF/dubbo/、META-INF/services/三个classpath目录下的配置文件。配置文件以具体扩展接口全名命名。

8、Dubbo默认使用什么注册中心，还有别的选择吗？

Zookeeper注册中心： 基于分布式协调系统Zookeeper实现，采用Zookeeper的watcher机制实现数据变更；

redis注册中心： 基于redis实现，采用key/Map存储，住key存储服务名和类型，Map中key存储服务URL，value服务过期时间。基于redis的发布/订阅模式通知数据变更；

Multicast注册中心： Multicast注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现；

9、Dubbo有哪几种配置方式？

1. XML 配置文件方式；

2. properties 配置文件方式(Dubbo 将自动加载 classpath 根目录下的 dubbo.properties)；

3. annotation 配置方式；

4. API 配置方式；

10.在Provider可以配置的属性

timeout，方法调用超时 ，如果消费者也配置了，以消费者为准。

retries，失败重试次数，缺省是2(表示加上第一次调用，会调用3次)

loadbalance，负载均衡算法(有多个Provider时，如何挑选Provider调用)，缺省是随机(random)。

actives，消费者端，最大并发调用限制，即当Consumer对一个服务的并发调用到上限后，新调用会Wait直到超时。

group，针对接口多实现配置

version  接口实现升级版本控制

check=“false”消费者启动不检查是否可用，消费者配置。

以 timeout 为例，显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似

方法级优先，接口级次之，全局配置再次之。

如果级别一样，则消费方优先，提供方次之。

11.Dubbo服务之间的调用是阻塞的吗？

默认是同步等待结果阻塞的，支持异步调用。

Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对象。

12.Dubbo的管理控制台能做什么？

管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。

13.在使用过程中都遇到了些什么问题？

Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议。

14、Dubbo 停止维护了吗？

Dubbo 2014 年开始停止维护过几年，17 年开始重新维护，并进入了 Apache 项目。

Dubbox 是继 Dubbo 停止维护后，当当网基于 Dubbo 做的一个扩展项目，如加了服务可 Restful 调用，更新了开源组件等。

15、说说 Dubbo 服务暴露的过程。

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

基于 dubbo.jar 内的 META-INF/spring.handlers 配置，Spring 在遇到 dubbo 名称空间时，会回调 DubboNamespaceHandler。

所有 dubbo 的标签，都统一用 DubboBeanDefinitionParser 进行解析，基于一对一属性映射，将 XML 标签解析为 Bean 对象。

在 ServiceConfig.export() 或 ReferenceConfig.get() 初始化时，将 Bean 对象转换 URL 格式，所有 Bean 属性转成 URL 的参数。

然后将 URL 传给 协议扩展点，基于扩展点的 扩展点自适应机制，根据 URL 的协议头，进行不同协议的服务暴露或引用。

ServiceBean 同时也是service标签解析之后的bean之一，继承ServiceConfig

该Bean实现了很多spring接口，关于InitializingBean，DisposableBean，ApplicationContextAware，BeanNameAware。

Spring初始化完成Bean的组装，会调用InitializingBean的afterPropertiesSet方法，在Spring容器加载完成，会接收到事件ContextRefreshedEvent，调用ApplicationListener的onApplicationEvent方法。

在afterPropertiesSet中，和onApplicationEvent中，会调用export()，在export()中，会暴露dubbo服务，具体区别在于是否配置了delay属性，是否延迟暴露，如果delay不为null，或者不为-1时，会在afterPropertiesSet中调用export()暴露dubbo服务，如果为null,或者为-1时，会在Spring容器初始化完成，接收到ContextRefreshedEvent事件，调用onApplicationEvent，暴露dubbo服务。

17、如何解决服务调用链过长的问题？

Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 实现分布式服务追踪，当然还有其他很多方案。可以结合zipkin实现分布式服务追踪。

18、注册了多个同一样的服务，如果测试指定的某一个服务呢？

可以配置环境点对点直连，绕过注册中心。Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

19、Dubbo 和 Spring Cloud 有什么区别？

1)通信方式不同，Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。

2)组成部分不同

20、dubbo集群负载均衡策略？loadbalance 属性

随机，按权重设置随机概率(默认)。

轮询，按公约后的权重设置轮询比率

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。

一致性 Hash，相同参数的请求总是发到同一提供者。

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

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

21.dubbo隐士传参数

有些参数需要RPC带着传递，但是又不想写入到业务代码里。比如实现dubbo调用链。可是使用dubbo的隐式传参，可以通过 RpcContext (ThreadLocal 实现)上的 setAttachment 和 getAttachment 在服务消费方和提供方之间进行参数的隐式传递。实现filter 接口。

RpcContext.getContext().setAttachment("index","1");//隐式传参，后面的远程调用都会隐式将这些参数发送到服务器端，类似cookie，用于框架集成，不建议常规业务使用

20、dubbo 熔断限流降级

21、服务提供者能实现失效踢出是什么原理？

服务失效踢出基于 zookeeper 的临时节点原理。

22、Dubbo的集群容错方案有哪些？

Failover Cluster  失败自动切换，重试 共3次，通常用于读操作。默认的

Failfast Cluster    只发起一次调用，失败即报错。用于写入记录。

Failsafe Cluster   失败安全，出现异常忽略。用于写日志等。

Failback Cluster  失败后，后台记录失败请求，定时重发。用于消息通知。

Forking Cluster  并行调用多个服务器，成功一个即返回，通过forks="N" 设置并行数。

Broadcast Cluster 广播调用模式，逐个调用，任意一台报错即报错。用于刷新缓存

23、Zookeeper是什么框架？

ZAB协议

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

zk集群 至少需要 集群规则为2N+1台，N>0，即至少3台。主要是为了选举算法。

Zookeeper分布式锁

基于 zookeeper的一致性文件系统 实现的分布式锁，性能开销比较高。因为其需要动态产生、销毁瞬时节点来实现锁功能。

实现原理在zookeeper上的与该功能对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。直接采用zookeeper第三方库curator即可方便地实现分布式锁。

1)zookeeper是一个开源的分布式协调服务框架。

2)应用场景：分布式通知/协调、负载均衡、配置中心、分布式锁、分布式队列等。

3)使用ZAB协议。

4)Paxos算法。

5)选举算法及流程。

6)节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。

7)不是永久的，一次性的，需要借助第三方工具实现重复注册。

8)部署模式：单机模式、伪集群模式、集群模式。

9)集群角色：leader、foller、observer。

10)集群规则为2N+1台，N>0，即3台。

11)集群需要一半以上的机器可用，所以，3台挂掉1台还能工作，2台不能。

12)3.5版本开始支持动态扩容。

13)java客户端：zk自带的zkclient及Apache开源的Curator。

14)chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。

15)常用命令：ls get set create delete等。

Zookeeper 的节点？

zookeeper节点分两种(持久节点Persistent、临时节点Ephemeral)，如果严谨的话还需要加上时序节点