java面试之dubbo

感觉现在面试不说点分布式都不好意思说自己懂java了。而分布式感觉除了最新的springcloud在大神带节奏之下比较火，好多公司还是用的是dubbo。

dubbo是什么

<pre>
dubbo是一个分布式框架，远程服务调用的分布式框架，其核心部分包含：
集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
远程通讯： 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
</pre>

dubbo能做什么

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

dubbo的架构

2016-03-10_56e12543dad72.jpg

节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
对于这些角色来说，其他都还好，Monitor可能猿友们前期使用会把它忽略，但是后期会发现它的作用十分明显哦，如服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？为了解决这个问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
调用关系说明：
0 服务容器负责启动，加载，运行服务提供者。
1 服务提供者在启动时，向注册中心注册自己提供的服务。
2 服务消费者在启动时，向注册中心订阅自己所需的服务。
3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

dubbo的使用

框架搭建
参考http://blog.csdn.net/u013142781/article/details/50396621 写的特别详细。
好了，言归正传，下面大体是一些面试题

1、dubbo默认使用什么通信协议？

dubbo共支持如下几种通信协议：

• dubbo:// Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
• rmi:// RMI协议采用JDK标准的java.rmi.实现，采用阻塞式短连接和JDK标准序列化方式*
• hessian://
• http://
• webservice://
• thrift://
• memcached://
• redis://

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

dubbo在调用服务不成功时，默认是会重试两次的。这样在服务端的处理时间超过了设定的超时时间时，就会有重复请求，比如在发邮件时，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据，那么怎么解决超时问题呢？如下
1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理
全局配置实例

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

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

3、一般使用什么注册中心，还有其他的选择吗？

 Multicast注册中心
 Zookeeper注册中心
 Redis注册中心
 Simple注册中心

ZooKeeper层次命名空间

ZooKeeper的节点是通过像树一样的结构来进行维护的，并且每一个节点通过路径来标示以及访问。除此之外，每一个节点还拥有自身的一些信息，包括：数据、数据长度、创建时间、修改时间等等。

从这样一类既含有数据，又作为路径表标示的节点的特点中，可以看出，ZooKeeper的节点既可以被看做是一个文件，又可以被看做是一个目录，它同时具有二者的特点。为了简单我们可以Znode来表示所讨论的ZooKeeper节点。

具体地说，Znode维护着数据、ACL（access controllist，访问控制列表）、时间戳等交换版本号等数据结构，它通过对这些数据的管理来让缓存生效并且令协调更新。每当Znode中的数据更新后它所维护的版本号将增加，这非常类似于数据库中计数器时间戳的操作方式。

另外Znode还具有原子性操作的特点：命名空间中，每一个Znode的数据将被原子地读写。读操作将读取与Znode相关的所有数据，写操作将替换掉所有的数据。除此之外，每一个节点都有一个访问控制列表，这个访问控制列表规定了用户操作的权限。

ZooKeeper中同样存在临时节点。这些节点与session同时存在，当session生命周期结束，这些临时节点也将被删除。临时节点在某些场合也发挥着非常重要的作用。

了解了Zookeeper的命名空间和节点之后我们需要跟上一篇文章中提到的内部逻辑联系起来.在上篇介绍到的内部流程中,拿到这里看看Zookeeper是如何处理的,流程如下图:

20150130221129168.jpg

1 当服务提供者启动时,Zookeeper向/dubbo/com.foo.BarService/providers目录下写入自己的URL地址。

2 当服务消费者启动时,这时候有两个动作:

订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。
并向/dubbo/com.foo.BarService/consumers目录下写入自己的URL地址。

3当监控中心启动时,订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL地址。

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

Dubbo默认使用的是Hessian序列化。hessian是一个采用二进制格式传输的服务框架，相对传统soap web service，更轻量，更快速。
Hessian原理与协议简析：
http的协议约定了数据传输的方式，hessian也无法改变太多：
1) hessian中client与server的交互，基于http-post方式。
2) hessian将辅助信息，封装在http header中，比如“授权token”等，我们可以基于http-header来封装关于“安全校验”“meta数据”等。hessian提供了简单的"校验"机制。
3) 对于hessian的交互核心数据，比如“调用的方法”和参数列表信息，将通过post请求的body体直接发送，格式为字节流。
4) 对于hessian的server端响应数据，将在response中通过字节流的方式直接输出。
hessian的协议本身并不复杂，在此不再赘言；所谓协议(protocol)就是约束数据的格式，client按照协议将请求信息序列化成字节序列发送给server端，server端根据协议，将数据反序列化成“对象”，然后执行指定的方法，并将方法的返回值再次按照协议序列化成字节流，响应给client，client按照协议将字节流反序列话成"对象"。

5、服务提供者能实现失效踢出的原理。

171146547086727.gif

本文只说dubbo，原理如下：

** ConfigServer（配置中心）**
每个Server/Client之间会作一个实时的心跳检测（因为它们都是建立的Socket长连接），比如几秒钟检测一次。收集每个Server提供的服务的信息，每个Client的信息，整理出一个服务列表，如：
serviceName serverAddressList clientAddressList
UserService 192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 172.16.0.1，172.16.0.2
ProductService 192.168.0.3，192.168.0.4，192.168.0.5，192.168.0.6 172.16.0.2，172.16.0.3
OrderService 192.168.0.10，192.168.0.12，192.168.0.5，192.168.0.6 172.16.0.3，172.16.0.4
当某个Server不可用，那么就更新受影响的服务对应的serverAddressList，即把这个Server从serverAddressList中踢出去（从地址列表中删除），同时将推送serverAddressList给这些受影响的服务的clientAddressList里面的所有Client。如：192.168.0.3挂了，那么UserService和ProductService的serverAddressList都要把192.168.0.3删除掉，同时把新的列表告诉对应的Client 172.16.0.1，172.16.0.2，172.16.0.3；
当某个Client挂了，那么更新受影响的服务对应的clientAddressList
ConfigServer根据服务列表，就能提供一个web管理界面，来查看管理服务的提供者和使用者。
新加一个Server时，由于它会主动与ConfigServer取得联系，而ConfigServer又会将这个信息主动发送给Client，所以新加一个Server时，只需要启动Server，然后几秒钟内，Client就会使用上它提供的服务

** Client（调用服务的机器）**

每个Client启动时，主动与ConfigServer建立Socket长连接，并将自己的IP等相应信息发送给ConfigServer。
Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息（这样ConfigServer就知道某个服务是当前哪几个Client在使用），Client拿到这些服务提供者信息后，与它们都建立连接，后面就可以直接调用服务了，当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等。
一旦Client使用的服务它对应的服务提供者有变化（服务提供者有新增，删除的情况），ConfigServer就会把最新的服务提供者列表推送给Client，Client就会依据最新的服务提供者列表重新建立连接，新增的提供者建立连接，删除的提供者丢弃连接

** Server（真正提供服务的机器）**

每个Server启动时，主动与ConfigServer建立Scoket长连接，并将自己的IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer就会收集到每个Server提供的服务的信息。

优点：

• 只要在Client和Server启动的时候，ConfigServer是好的，服务就可调用了，如果后面ConfigServer挂了，那只影响ConfigServer挂了以后服务提供者有变化，而Client还无法感知这一变化。
• Client每次调用服务是不经过ConfigServer的，Client只是与它建立联系，从它那里获取提供服务者列表而已
• 调用服务-负载均衡：Client调用服务时，可以根据规则在多个服务提供者之间轮流调用服务。
• 服务提供者-容灾：某一个Server挂了，Client依然是可以正确的调用服务的，当前提是这个服务有至少2个服务提供者，Client能很快的感知到服务提供者的变化，并作出相应反应。
• 服务提供者-扩展：添加一个服务提供者很容易，而且Client会很快的感知到它的存在并使用它。

6、服务上线怎么不影响旧版本（多版本支持）。

dubbo的文档中说到：

 当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。
 在低压力时间段，先升级一半提供者为新版本，再将所有消费者升级为新版本，然后将剩下的一半提供者升级为新版本
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
不区分版本：(2.2.0以上版本支持)
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

6、dubbo协议下的单一长连接与多线程并发如何协同工作

底层采用netty。

7、集群容错怎么做

<pre>
dubbo的容错方案
当我们的系统中用到Dubbo的集群环境,因为各种原因在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试。
Dubbo的集群容错在这里想说说他是因为我们实际的项目中出现了此类的问题,因为依赖的第三方项目出现异常,导致dubbo调用超时,此时使用的是默认的集群容错方式,而配置的reties='3',这样前段系统连续掉用了三次服务,结果可想而知.
先说一下各节点关系：
这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。
Directory代表多个Invoker，可以把它看成List<Invoker>，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更。
Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。
Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等。
LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选。
<strong>集群容错模式：</strong>
Failover Cluster
失败自动切换，当出现失败，重试其它服务器。(缺省)
通常用于读操作，但重试会带来更长延迟。
可通过retries="2"来设置重试次数(不含第一次)。正是文章刚开始说的那种情况.
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。
通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。
通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。
通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。
通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
可通过forks="2"来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)
通常用于通知所有提供者更新缓存或日志等本地资源信息。
重试次数配置如：(failover集群模式生效)
<dubbo:serviceretries="2"/>
或：<dubbo:referenceretries="2"/>
或：<dubbo:reference>
<dubbo:methodname="findFoo"retries="2"/>
</dubbo:reference>

集群模式配置如：
<dubbo:servicecluster="failsafe"/>
或：<dubbo:referencecluster="failsafe"/>
</pre>

8、dubbo是如何实现负载均衡

<pre>
dubbo负载均衡策略：
在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。
RandomLoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHashLoadBalance
一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
Dubbo的集群容错和负载均衡同样也是Dubbo本身的高级特性.正如我们在说自定义扩展的时候一样,这两个特征同样也可以进行自定义扩展,用户可以根据自己实际的需求来扩展他们从而满足项目的实际需求.
</pre>

9、遇到的问题

场景描述：客户端远程异步调用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

根据n多的博客整理出来的一些，以后有其他东西再加进去