dubbo&zookeeper面试题。

其他推荐：

SpringCloud&SpringBoot经典面试题（附加答案）

多线程史上最全面试题&持续更新中

1. Dubbo中zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？

答：可以通信的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用；
注册中心对等集群，任意一台宕机后，将会切换到另一台；注册中心全部宕机后，服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态，任一台 宕机后，不影响使用；服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复；
挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的。

2. dubbo服务负载均衡有哪些策略？

答： l Random LoadBalance
随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。(权重可以在dubbo管控台配置)

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

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

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

3. Dubbo在安全机制方面是如何解决的

答： Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

4. dubbo连接注册中心和直连的区别

答： 在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，服务注册中心，动态的注册和发现服务，使服务的位置透明，并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover， 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外，注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。

5.dubbo通信协议dubbo协议为什么要消费者比提供者个数多

答： 因dubbo协议采用单一长连接，假设网络为千兆网卡(1024Mbit=128MByte)，
根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样，供参考)，理论上1个服务提供者需要20个服务消费者才能压满网卡。

6.dubbo通信协议dubbo协议为什么不能传大包

答： 因dubbo协议采用单一长连接，如果每次请求的数据包大小为500KByte，假设网络为千兆网卡(1024Mbit=128MByte)，每条连接最大7MByte(不同的环境可能不一样，供参考)，单个服务提供者的TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14。如果能接受，可以考虑使用，否则网络将成为瓶颈。

7.dubbo通信协议dubbo协议为什么采用异步单一长连接

答： 因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者多，可能整个网站都在访问该服务，比如Morgan的提供者只有6台提供者，却有上百台消费者，每天有1.5亿次调用，如果采用常规的hessian服务，服务提供者很容易就被压跨，通过单一连接，保证单一消费者不会压死提供者，长连接，减少连接握手验证等，并使用异步IO，复用线程池，防止C10K问题。

8.dubbo通信协议dubbo协议适用范围和适用场景

答： 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用
dubbo协议补充：

连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化

9. RMI协议

答： RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式，Java标准的远程调用协议。

连接个数：多连接
连接方式：短连接
传输协议：TCP
传输方式：同步传输
序列化：Java标准二进制序列化
适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
适用场景：常规远程服务方法调用，与原生RMI服务互操作

10.Thrif

答： Thrift是Facebook捐给Apache的一个RPC框架，当前 dubbo 支持的 thrift 协议是对 thrift 原生协议的扩展，在原生协议的基础上添加了一些额外的头信息，比如service name，magic number等。

11.ZooKeeper是什么？

答： ZooKeeper是一个 分布式 的，开放源码的分布式 应用程序协调服务 ，是Google的Chubby一个开源的实现， 它是 集群的管理者 ， 监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作 。最终，将简单易 用的接口和性能高效、功能稳定的系统提供给用户。 客户端的 读请求 可以被集群中的 任意一台机器处理 ，如果读请求在节点上注册了监听器，这个监听器也是由所 连接的zookeeper机器来处理。对于 写请求 ，这些请求会同 时发给其他 zookeeper 机器并且达成一致后，请 求才会返回成功 。因此，随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降 。 有序性是zookeeper中非常重要的一个特性，所有的 更新都是全局有序的 ，每个更新都有一个 唯一的时间戳 ， 这个时间戳称为 zxid （ Zookeeper Transaction Id ） 。而 读请求只会相对于更新有序 ，也就是读请求的返回 结果中会带有这个 zookeeper 最新的 zxid 。

12.ZooKeeper提供了什么？

答： 1、 文件系统 2、 通知机制

13.Zookeeper文件系统

答： Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是，这些节点 都可以设置 关联的数据 ，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延 迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper 不能用于存放大量的数据 ，每个节点的存 放数据上限为 1M 。

14. 四种类型的znode

答：
1、 PERSISTENT- 持久化目录节点 客户端与zookeeper断开连接后，该节点依旧存在
2、 PERSISTENT_SEQUENTIAL- 持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3、 EPHEMERAL- 临时目录节点
客户端与zookeeper断开连接后，该节点被删除
4、 EPHEMERAL_SEQUENTIAL- 临时顺序编号目录节点客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号。

15.Zookeeper通知机制

答： client端会对某个znode建立一个watcher 事件 ，当该znode发生变化时，这些client会收到zk的通知， 然后client可以根据znode变化来做出业务上的改变等。

16.Zookeeper做了什么？

答： 1、命名服务 2、配置管理 3、集群管理 4、分布式锁 5、队列管理

17.zk的命名服务（文件系统）

答： 命名服务是指通过指定的名字来 获取资源 或者 服务的地址 ，利用zk创建一个全局的路径，即是 唯一 的路径，这 个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

18.zk的配置管理（文件系统、通知机制）

答： 程序分布式的部署在不同的机器上，将程序的配置信息放在zk的znode 下，当有配置发生改变时，也就是 znode发生变化时，可以通过改变zk中某个目录节点的内容，利用 watcher 通知给各个客户端，从而更改配置。

19.Zookeeper集群管理（文件系统、通知机 制）

答： 所谓集群管理无在乎两点： 是否有机器退出和加入、选举 master 。 对于第一点，所有机器约定在父目录下 创建临时目录节点 ，然后监听父目录节点的子节点变化消息。一旦有机 器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除， 所有其他机器都收到通知：某个 兄弟目录被删除 ，于是，所有人都知道：它上船了。 新机器加入也是类似， 所有机器收到通知：新兄弟目录加入 ，highcount又有了，对于第二点，我们稍微改变 一下， 所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为 master 就好。

20.Zookeeper分布式锁（文件系统、通知 机制）

答： 有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是 保持独占 ，另一个是 控 制时序 。 对于第一类，我们将zookeeper上的一个 znode 看作是一把锁 ，通过createznode的方式来实现。所有客户 端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点就释放出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选 master一样， 编号最小的获得锁 ，用完删除，依次方便。

21.获取分布式锁的流程

答： 在获取分布式锁的时候在locker节点下创建临时顺序节点，释放锁的时候删除该临时节点。客户端调用 createNode方法在locker下创建临时顺序节点， 然后调用getChildren(“locker”)来获取locker下面的所有子节点，注意此时不用设置任何Watcher。客户 端获取到所有的子节点path之后，如果发现自己创建的节点在所有创建的子节点序号最小，那么就认为该客户 端获取到了锁。如果发现自己创建的节点并非locker所有子节点中最小的，说明自己还没有获取到锁，此时客 户端需要找到 比自己小的那个节点 ，然后对其调用 exist() 方法，同时对其注册事件监听器。之后，让这个被关 注的节点删除，则客户端的Watcher会收到相应通知，此时再次判断自己创建的节点是否是locker子节点中 序号最小的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。当前这个过程中还需要许多的逻辑判断。
代码的实现主要是基于互斥锁，获取分布式锁的重点逻辑在于BaseDistributedLock ，实现了基于Zookeeper实现分布式锁的细节。

22…Zookeeper队列管理（文件系统、通知 机制）

答： 两种类型的队列： 1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。 2、队列按照 FIFO 方式进行入队和出队操作。 第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。 第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
在特定的目录下创建 PERSISTENT_SEQUENTIAL 节点，创建成功时 Watcher 通知等待的队列，队列删除 序列号最小的节点 用以 消费。此场景下Zookeeper的znode用于消息存储，znode存储的数据就是消息队列中的消息内容， SEQUENTIAL序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以 不必担心队列消息的 丢失问题 。

23.Zookeeper数据复制

答： Zookeeper作为一个集群提供一致的数据服务，自然，它要在 所有机器间 做数据复制。数据复制的好处：
1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
3、提高性能：让 客户端本地访问就近的节点，提高用户访问速度 。
从客户端读写访问的透明度来看，数据复制集群系统分下面两种：
1、 写主 (WriteMaster) ：对数据的 修改提交给指定的节点 。读无此限制，可以读取任何一个节点。这种情况下 客户端需要对读与写进行区别，俗称 读写分离 ；
2、 写任意 (Write Any)：对数据的 修改可提交给任意的节点 ，跟读一样。这种情况下，客户端对集群节点的角 色与变化透明。
对zookeeper来说，它采用的方式是 写任意 。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而 写，随着机器的增多吞吐能力肯定下降（这也是它建立observer的原因），而响应能力则取决于具体实现方 式，是 延迟复制保持最终一致性 ，还是 立即复制快速响应 。

24.Zookeeper工作原理

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

25.zookeeper是如何保证事务的顺序一致性的？

答： zookeeper采用了 递增的事务 Id 来标识，所有的proposal（提议）都在被提出的时候加上了zxid，zxid实际 上是一个64位的数字，高32位是epoch（时期; 纪元; 世; 新时代）用来标识leader是否发生改变，如果有 新的leader产生出来，epoch会自增， 低 32 位用来递增计数 。当新产生proposal的时候，会依据数据库的 两阶段过程，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就 会开始执行。

26.Zookeeper 下 Server工作状态

答： 每个Server在工作过程中有三种状态： LOOKING：当前Server 不知道 leader 是谁 ，正在搜寻 LEADING：当前Server即为选举出来的leader FOLLOWING：leader已经选举出来，当前Server与之同步。

27.zookeeper是如何选取主leader的？（zookeeper选举）

答： 当leader崩溃或者leader失去大多数的follower，这时zk进入恢复模式，恢复模式需要重新选举出一个新的 leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现 的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为 fast paxos 。
1、Zookeeper选主流程(basic paxos)
（1）选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的 Server；
（2）选举线程首先向所有Server发起一次询问(包括自己)；
（3）选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存 储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投 票记录表中；
（4）收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次 要投票的Server；
（5）线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状 态，否则，继续这个过程，直到leader被选举出来。 通过流程分析我们可以得出：要使Leader获得多数 Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1. 每个Server启动后 都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。

2、Zookeeper选主流程(basic paxos)
fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提 议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。

28.Zookeeper同步流程

答： 选完Leader以后，zk就进入状态同步过程。
1、Leader等待server连接；
2、Follower连接leader，将最大的zxid发送给leader；
3、Leader根据follower的zxid确定同步点；
4、完成同步后通知follower 已经成为uptodate状态；
5、Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

29.分布式通知和协调

答： 对于系统调度来说：操作人员发送通知实际是通过控制台 改变某个节点的状态 ， 然后 zk 将这些变化发送给注册了这个节点的 watcher 的所有客户端 。 对于执行情况汇报：每个工作进程都在某个目录下 创建一个临时节点 。 并携带工作的进度数据 ，这样 汇总的进程可以监控目录子节点的变化获得工作进度的实时的全局情况 。

30.机器中为什么会有leader？

答： 在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行， 其他的机器可以共享这个结果 ，这样可 以大大 减少重复计算 ， 提高性能 ，于是就需要进行leader选举。

31.zk节点宕机如何处理？

答： Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他 节点会继续提供服务。 如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不 会丢失； 如果是一个Leader宕机，Zookeeper会选举出新的Leader。 ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不 到一半节点能工作，集群才失效。 所以 3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5) 2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1) 。

32.zookeeper负载均衡和nginx负载均衡区别

答： zk的负载均衡是可以调控，nginx只是能调权重，其他需要可控的都需要自己写插件；但是nginx的吞吐量比 zk大很多，应该说按业务选择用哪种方式。

33.zookeeper watch机制

答： Watch机制官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时 候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。 Zookeeper机制的特点：
1、一次性触发数据发生改变时，一个watcher event会被发送到client，但是client
只会收到一次这样的信息 。
2、watcher event异步发送watcher的通知事件从server发送到client是 异步 的，这就存在一个问题，不同 的客户端和服务器之间通过socket进行通信，由于 网络延迟或其他因素导致客户端在不通的时刻监听到事件 ， 由于Zookeeper本身提供了 ordering guarantee ，即客户端监听事件后，才会感知它所监视 znode 发生了变化 。所以我们使用Zookeeper不能期望能够监控到节点每次的变化。Zookeeper 只能保证最终的一致性， 而无法保证强一致性 。
3、数据监视Zookeeper有数据监视和子数据监视getdata() and exists()设置数据监视，getchildren()设置了 子节点监视。
4、注册watcher getData 、 exists 、 getChildren。
5、触发watcher create 、 delete 、 setData。
6、 setData() 会触发znode上设置的data watch（如果set成功的话）。一个成功的 create() 操作会触发被 创建的znode上的数据watch，以及其父节点上的child watch。而一个成功的 delete() 操作将会同时触发一 个znode的data watch和child watch（因为这样就没有子节点了），同时也会触发其父节点的child watch。
7、当一个客户端 连接到一个新的服务器上时，watch将会被以任意会话事件触发。当 与一个服务器失去连接的时候，是无法接收到watch的。而当client 重新连接时，如果需要的话，所有先前注册过的watch，都会被重 新注册。通常这是完全透明的。只有在一个特殊情况下， watch 可能会丢失 ：对于一个未创建的znode的 exist watch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这 个watch事件可能会被丢失。
8、Watch是轻量级的，其实就是本地JVM的 Callback ，服务器端只是存了是否有设置了Watcher的布尔类型。

33.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 协议。

34.Dubbo 超时时间怎样设置？

答： 　Dubbo 超时时间设置有两种方式：

1. 服务提供者端设置超时时间，在 Dubbo 的用户文档中，推荐如果能在服务 端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。
2. 服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端 为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消 费方超时，服务端线程不会定制，会产生警告。

35.Dubbo 有些哪些注册中心？

• Multicast 注册中心： Multicast 注册中心不需要任何中心节点，只要广播地 址，就能进行服务注册和发现。基于网络中组播传输实现；
• Zookeeper 注册中心： 基于分布式协调系统 Zookeeper 实现，采用 Zookeeper 的 watch 机制实现数据变更；
• redis 注册中心： 基于 redis 实现，采用 key/Map 存储，住 key 存储服务名 和类型，Map 中 key 存储服务 URL，value 服务过期时间。基于 redis 的发 布/订阅模式通知数据变更；
• Simple 注册中心

36.Dubbo 集群的负载均衡有哪些策略

答： Dubbo 提供了常见的集群策略实现，并预扩展点予以自行实现。

1. Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权 重。截面碰撞率高，调用次数越多，分布越均匀；
2. RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请 求累积的问题；
3. LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的 请求；
4. ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求总是发 到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避 免引起提供者的剧烈变动

37.Dubbo是什么？

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

38.Dubbo的主要应用场景？

1. 透明化的远程方法调用，就像调用本地方法一样调用远程方法，
   只需简单配置，没有任何API侵入。
2. 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，
   降低成本，减少单点。
3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心
   基于接口名查询服务提供者的IP地址，并且能够平滑添加或删
   除服务提供者。

39.Dubbo的核心功能？

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

40.Dubbo的核心组件？

41.Dubbo服务注册与发现的流程？

1. Provider(提供者)绑定指定端口并启动服务
2. 指供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息
   发送至注册中心存储
3. Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信
   息至注册中心
4. 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至
   Consumer 应用缓存。
5. Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调
   用。
6. Provider 状态变更会实时通知注册中心、在由注册中心实时推送至
   Consumer

42.Dubbo的架构设计？

答： Dubbo框架设计一共划分了如下几层：

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

43.dubbo推荐用什么协议？

• 默认使用dubbo协议

44.为什么需要服务治理？

• 过多的服务URL配置困难
• 负载均衡分配节点压力过大的情况下也需要部署集群
• 服务依赖混乱，启动顺序不清晰
• 过多服务导致性能指标分析难度较大，需要监控

45. Dubbo与Spring的关系？

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

46.Dubbo使用的是什么通信框架?

• 默认使用NIO Netty框架。

47.Dubbo的集群容错方案有哪些？

• Failover Cluster ：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但
  重试会带来更长延迟。
• Failfast Cluster ：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
• Failsafe Cluster ：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
• Failback Cluster ：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
• Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较
  高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。
• Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。

48.Dubbo的默认集群容错方案？

• Failover Cluster

49.Dubbo支持哪些序列化方式？

• 默认使用Hessian序列化，还有Duddo、FastJson、Java自带序列
  化。

50.Dubbo超时时间怎样设置？

• 服务提供者端设置超时时间，在Dubbo的用户文档中，推荐如果能在服务端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。
• 服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会定制，会产生警告。

51.服务调用超时问题怎么解决？

• dubbo在调用服务不成功时，默认是会重试两次的。

52.Dubbo在安全机制方面是如何解决？

• Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

53.Dubbo 和 Dubbox 之间的区别？

• dubbox 基于 dubbo 上做了一些扩展，如加了服务可 restful 调用，更新了开源组件等。

54.Dubbo和Spring Cloud的关系？

• Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。

55.Dubbo和Spring Cloud的区别？

• 最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。
• 而SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。