dubbo是什么

dubbo是一个分布式框架，远程服务调用的分布式框架，其核心部分包含：

集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

远程通讯： 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

?

dubbo能做什么

1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3.服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

?

在 Provider 上可以配置的 Consumer 端的属性有哪些？

1）timeout：方法调用超时

2）retries：失败重试次数，默认重试 2 次

3）loadbalance：负载均衡算法，默认随机

4）actives 消费者端，最大并发调用限制

?

Dubbo支持服务多协议吗？

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

?

当一个服务接口有多种实现时怎么做？

当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。

?

服务上线怎么兼容旧版本？

可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。

?

Dubbo可以对结果进行缓存吗？

可以，Dubbo 提供了声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。

?

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

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

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

?

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

可以通信的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用；

注册中心对等集群，任意一台宕机后，将会切换到另一台；注册中心全部宕机后，服务的提供者和消费者仍能通过本地缓存通讯。服务提供者无状态，任一台 宕机后，不影响使用；服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复；

挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的。

?

dubbo服务负载均衡策略？

l Random LoadBalance

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

l RoundRobin LoadBalance

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

?

l LeastActive LoadBalance

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

l ConsistentHash LoadBalance

一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。缺省只对第一个参数Hash，如果要修改，请配置

?

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

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

?

dubbo的调用流程

Provider

第 0 步，start 启动服务。

第 1 步，register 注册服务到注册中心。

Consumer

第 2 步，subscribe 向注册中心订阅服务。

注意，只订阅使用到的服务。

再注意，首次会拉取订阅的服务列表，缓存在本地。

【异步】第 3 步，notify 当服务发生变化时，获取最新的服务列表，更新本地缓存。

invoke 调用

Consumer 直接发起对 Provider 的调用，无需经过注册中心。而对多个 Provider 的负载均衡，Consumer 通过 cluster 组件实现。

count 监控

【异步】Consumer 和 Provider 都异步通知监控中心。

?

Dubbo 可以对调用结果进行缓存吗?

Dubbo 通过 CacheFilter 过滤器，提供结果缓存的功能，且既可以适用于 Consumer 也可以适用于 Provider 。

通过结果缓存，用于加速热门数据的访问速度，Dubbo 提供声明式缓存，以减少用户加缓存的工作量。

Dubbo 目前提供三种实现：

lru ：基于最近最少使用原则删除多余缓存，保持最热的数据被缓存。

threadlocal ：当前线程缓存，比如一个页面渲染，用到很多 portal，每个 portal 都要去查用户信息，通过线程缓存，可以减少这种多余访问。

jcache ：与 JSR107 集成，可以桥接各种缓存实现。

?

服务提供方的优雅停机过程

首先，从注册中心中取消注册自己，从而使消费者不要再拉取到它。

然后，sleep 10 秒( 可配 )，等到服务消费，接收到注册中心通知到该服务提供者已经下线，加大了在不重试情况下优雅停机的成功率。

之后，广播 READONLY 事件给所有 Consumer 们，告诉它们不要在调用我了！！！【很有趣的一个步骤】并且，如果此处注册中心挂掉的情况，依然能达到告诉 Consumer ，我要下线了的功能。

再之后，sleep 10 毫秒，保证 Consumer 们，尽可能接收到该消息。

再再之后，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。

再再再之后，关闭心跳线程。

最后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。

最最后，关闭服务器。

?

Dubbo Consumer 只能调用从注册中心获取的 Provider 么？

不是，Consumer 可以强制直连 Provider 。

在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。

?

Dubbo 支持哪些通信协议？

对应【protocol 远程调用层】。

Dubbo 目前支持如下 9 种通信协议：

【重要】dubbo:

【重要】rest:

webservice:

redis:

http:

?

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

dubbo在调用服务不成功时，默认是会重试两次的。这样在服务端的处理时间超过了设定的超时时间时，就会有重复请求，比如在发邮件时，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据，那么怎么解决超时问题呢？如下

1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。

2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理

全局配置实例

<dubbo:provider delay="-1" timeout="6000" retries="0"/>??

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

?

默认使用什么序列化框架，还有其他的吗？

Dubbo默认使用的是Hessian序列化。hessian是一个采用二进制格式传输的服务框架，相对传统soap web service，更轻量，更快速。

?

遇到的问题

场景描述：客户端远程异步调用ServiceA，ServiceA在处理客户端请求的过程中需要远程同步调用ServiceB，ServiceA从ServiceB的响应中取数据时，得到的是null。

对于上面的问题，解决办法有三个：

1.方法调用两次

ServiceA调用ServiceB的地方写两次一样的调用，这个方法原理就像ServiceB调用ServiceC一样，即清除attachements。

这个方法最简单，但是可能对不了解的人来说，这块业务代码写重复了，会不小心删除掉，而且从写代码的角度来说，这个很鸡肋，所以不推荐。

2.修改Dubbo源码

?

修改AbstractInvoker第137行，改成每次都对async进行实际赋值，

boolean isAsync = getUrl().getMethodParameter(invocation.getMethodName(), Constants.ASYNC_KEY, false);

invocation.setAttachment(Constants.ASYNC_KEY, String.valueOf(isAsync));

3.自定义Filter

?

实现com.alibaba.dubbo.rpc.Filter，在RpcContext中清除这个async，

@Activate(group = {Constants.PROVIDER})

??public class AsyncFilter implements Filter {

@Override

public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {

?????RpcContext.getContext().getAttachments().remove(Constants.ASYNC_KEY);

return invoker.invoke(invocation);

}

}

同时在src/main/resources/META-INF/dubbo/下添加com.alibaba.dubbo.rpc.Filter文件，内容文件如下：

asyncFilter=com.abc.filter.AsyncFilter

?

Zookeeper是什么框架

分布式开源框架，提供分布式协调服务，解决了分布式一致性问题。原本是Hadoop、HBase的一个重要组件。

?

应用场景

结合实际工作中，Zookeeper主要是用于dubbo框架的注册中心。Dubbo框架的提供者会向Zookeeper下的provider目录注册自己的URL。消费者订阅提供者的注册URL，并在consumer下注册自己的URL,以便在后续执行中调用提供者。消费者获取到URL之后，netty调用提供者提供的服务。提供者若发生了变化会主动通过zookeeper推送给消费者。

?

Paxos算法&Zookeeper使用协议

Paxos算法是分布式选举算法，Zookeeper使用的 ZAB协议（Zookeeper原子广播）

相同点：

比如都有一个Leader，用来协调N个Follower的运行；Leader要等待超半数的Follower做出正确反馈之后才进行提案

?

?

Zookeeper有哪几种节点类型

持久：创建之后一直存在，除非有删除操作，创建节点的客户端会话失效也不影响此节点。

持久顺序：持久节点名后缀加上一个10位数字。

临时：创建客户端会话失效（注意是会话失效，不是连接断了），节点也就没了。不能建子节点。

临时顺序：临时节点名后缀加上一个10位数字。

?

Zookeeper对节点的watch监听通知是永久的吗？

不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。

?

为什么不是永久的，举个例子，

如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。

一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。

在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。

?

部署方式？集群中的机器角色都有哪些？集群最少要几台机器

单机，集群，伪集群。Leader、Follower、Observer。集群最低3（2N+1）台，保证奇数，主要是为了选举算法。

集群如果有3台机器，挂掉一台集群还能工作吗？挂掉两台呢？

过半存活即可用。

集群支持动态添加机器吗？

其实就是水平扩容了，Zookeeper在这方面不太好。两种方式：

全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。

逐个重启：这是比较常用的方式。

?

Zookeeper 具有如下特性：

顺序一致性(有序性)

从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到 Zookeeper 中去。

有序性是 Zookeeper 中非常重要的一个特性。

单一视图

无论客户端连接的是哪个 Zookeeper 服务器，其看到的服务端数据模型都是一致的。

可靠性

一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直被保留，除非有另一个事务对其进行了变更。

实时性

Zookeeper 保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

?

Zookeeper 的通知机制是什么？

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

?

Zookeeper 的会话管理是怎么样的？

ZooKeeper 的每个客户端都维护一组服务端信息，在创建连接时由应用指定，客户端随机选择一个服务端进行连接，连接成功后，服务端为每个连接分配一个唯一标识。

?

集群如果有 3 台机器，挂掉 1 台集群还能工作吗？挂掉 2 台呢？

记住一个原则：过半存活即可用。所以挂掉 1 台可以继续工作，挂掉 2 台不可以工作。

?

ZooKeeper 的工作原理？

ZooKeeper 的核心是原子广播，这个机制保证了各个 Server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）：

?

Zookeeper 的选举过程？

当 Leader 崩溃，或者 Leader 失去大多数的 Follower，这时 Zookeeper 进入恢复模式，恢复模式需要重新选举出一个新的 Leader，让所有的 Server 都恢复到一个正确的状态。

?

?

cs