Dubbo常见面试题

1.运行原理以及节点说明

 

节点角色说明：

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

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

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

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

· Container: 服务运行容器。

调用关系说明：

· 0. 服务容器负责启动，加载，运行服务提供者。

· 1. 服务提供者在启动时，向注册中心注册自己提供的服务。

· 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

· 3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

· 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

· 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

2.dubbo+zookeeper 详细介绍，项目如何搭建的，如何配置的，怎么和项目整合。

    dubbo框架的体系结构有5个核心组成部分，分别是提供者provider,它的作用是为消费者提供数据。注册中心registry,它的作用是用来注册和发现服务。消费者consumer,它的作用是调用远程提供者提供的服务。监控中心Monitor用来统计服务的调用次数以及调用时间，还有container用来充当容器来加载，运行服务提供者。

Dubbo 通信方式采用长链接方式，所以当spring启动后链接就接通，dubbo的消费者和生产者就可以直接调用。性能上高于其他http协议的请求。

新建dubbo-provider.xml配置文件，通过dubbo:application配置提供者应用名，通过dubbo:registry配置注册中心的地址，通过dubbo:protocol配置协议，以及通过dubbo:service来暴露要发布的接口。

最后我们在需要使用dubbo接口的项目中配置消费者信息，新建dubbo-consumer.xml文件，通过dubbo:application配置消费者应用名,通过dubbo:registry指明要订阅的注册中心地址，通过dubbo:reference指定要订阅的服务接口。

配置dubbo集群来提高健壮性以及可用性。dubbo默认的集群容错机制是Failover即失败自动切换，默认的重试次数为2，可以通过retries调整。dubbo默认的负载均衡策略是Random随机，可以按权重设置随机概率。我们在写完dubbo提供者之后，为了测试接口的正确性，我们会进行直连测试。首先会在提供者端，通过将dubbo:registry设置为false,使其只订阅服务而不注册现在正在开发的服务；在消费者端，通过设置dubbo:reference的url，直连提供者进行测试。

3.dubbo六种容错策略

一．Failover Cluster 模式

失败自动切换，当出现失败，重试其它服务器。(缺省) 通常用于读操作，但重试会带来更长延迟。 可通过retries=”2”来设置重试次数(不含第一次)。

二．Failfast Cluster

快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

三．Failsafe Cluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

四．Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

五．Forking(fo gen) Cluster

1.并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。 可通过forks=”2”来设置最大并行数。

六．Broadcast(bu ruo ka si te) Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)通常用于通知所有提供者更新缓存或日志等本地资源信息

  

重试次数配置如：(failover集群模式生效)

<dubbo:service retries="2" />

或：

<dubbo:reference retries="2" />

或：

<dubbo:reference>

    <dubbo:method name="findFoo" retries="2" />

</dubbo:reference>

集群模式配置如：

<dubbo:service cluster="failsafe" />

或：

<dubbo:reference cluster="failsafe" />

4.dubbo负载均衡

(1)配置说明
在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。

Random LoadBalance

随机，按权重设置随机概率。

在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

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

存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

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

使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

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

当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。

缺省只对第一个参数Hash，如果要修改，请配置<dubbo:parameter key="hash.arguments" value="0,1" />

缺省用160份虚拟节点，如果要修改，请配置<dubbo:parameter key="hash.nodes" value="320" />

配置如：

<dubbo:service interface="..." loadbalance="roundrobin" />

或：

<dubbo:reference interface="..." loadbalance="roundrobin" />

或：

<dubbo:service interface="...">

     <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:service>

或：

<dubbo:reference interface="...">

      <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:reference>

5.Dubbo优化

开发时的三个优化：

1、开发者在本地开发的时候启动Dubbo比较麻烦，所以采用直接连接的配置；

2、开发者本地开发时会打断点调试，会超过Dubbo默认的超时时间1s，所以需要全局设置超时时间；

3、开发者本地时可能会先启动消费方服务，再启动提供方服务，为了先后启动没有顺序问题，所以需要设置不检查注册中心及提供方服务；

一、直接连接，即可以停止zookeeper服务；

（1）提供方的配置：

<!-- 配置注册中心 -->

<!--     <dubbo:registry address="192.168.1.110:2181" protocol="zookeeper"/> -->

<dubbo:registry address="N/A"/>

（2）消费方配置：

<!-- 注册中心 -->

<dubbo:registry address="N/A"/>

    

<!-- 获取接口及实现类 -->

<!-- <dubbo:reference interface="cn.itcast.core.service.TestTbService" id="testTbService" /> -->

<dubbo:reference interface="cn.itcast.core.service.TestTbService" id="testTbService"

        url="dubbo://127.0.0.1:20880"/>

二、消费方设置超时时间

在服务消费方设置超时时间

<!-- 全局统一设置请求超时时间，默认为1秒 ; 设置10分钟-->

<dubbo:consumer timeout="600000"/>

三、消费方不检查注册中心及提供方的服务

将 check 参数设置为 "false"，如下

<!-- 注册中心 -->

<!-- <dubbo:registry address="192.168.1.110:2181" protocol="zookeeper" check="false"/> -->

<dubbo:registry address="N/A"/>

    

<!-- 获取接口及实现类 -->

<!-- <dubbo:reference interface="cn.itcast.core.service.TestTbService" id="testTbService" check="false"/> -->

<dubbo:reference interface="cn.itcast.core.service.TestTbService" id="testTbService"

        url="dubbo://127.0.0.1:20880" check="false"/>

6.Dubbo的常见设置

    1、启动时检查

缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。

关闭所有服务的启动时检查：(没有提供者时报错)

<dubbo:consumer check="false" />

关闭某个服务的启动时检查：(没有提供者时报错)

<dubbo:reference interface="com.foo.BarService" check="false" />

其它的启动时检查还包括：注册中心

2、直连提供者

在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，

点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表。

<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" />  

3、服务分组

当一个接口有多种实现时，可以用group区分。

provider：

<dubbo:service group="feedback" interface="com.xxx.IndexService" ref="indexServiceFeedback" />

<dubbo:service group="member" interface="com.xxx.IndexService"   ref="indexServiceMember" />

cosumer：

<dubbo:reference id="feedbackIndexService" group="feedback" interface="com.xxx.IndexService" />

<dubbo:reference id="memberIndexService" group="member" interface="com.xxx.IndexService" />

4、多版本

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

一般处理步骤

1）在低压力时间段，先升级一半提供者为新版本

2）再将所有消费者升级为新版本

3）然后将剩下的一半提供者升级为新版本

<dubbo:service interface="com.foo.BarService" version="1.0.0" />

<dubbo:service interface="com.foo.BarService" version="2.0.0" />

5、异步调用

可完成并行调用多个远程服务。异步总是不等待返回。

<dubbo:reference id="fooService" interface="com.alibaba.foo.FooService">

    <dubbo:method name="findFoo" async="true" />

</dubbo:reference>

6、延迟暴露

如果你的服务需要Warmup时间，比如初始化缓存，等待相关资源就位等，可以使用delay进行延迟暴露。

<dubbo:provider delay="-1" />

当然，也可以配置到服务级别，但有些需要地方需要注意。

7、dubbo:protocol属性

threadpool：线程池类型，可选：fixed/cached ，默认fixed 。

threads ：服务线程池大小(固定大小) ，默认为100

payload：请求及响应数据包大小限制，单位：字节，默认为88388608(=8M)

如：<dubbo:protocol name="dubbo" port="27001" threadpool="cached" threads="20"/>

ThreadPool

fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)

cached 缓存线程池，空闲一分钟自动删除，需要时重建。

limited可伸缩线程池，但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。

8、dubbo:application

<dubbo:application name="xxx_service" />

name必填。当前应用名称，用于注册中心计算应用间依赖关系，注意：消费者和提供者应用名不要一样