Dubbo
什么是Dubbo
为什么要用Dubbo
什么是分布式?
为什么要分布式?

什么是Dubbo
Apache Dubbo是一款高性能、轻量级的开源Java RPC 框架，它提供了三大核心能力：

面向接口的远程方法调用
智能容错和负载均衡
服务自动注册和发现

简单来说Dubbo就是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

Dubbo 目前已经有接近30k的 Star ，Dubbo的Github 地址：https://github.com/apache/incubator-dubbo 。

Dubbo 是由阿里开源，后来加入了 Apache 。正式由于 Dubbo 的出现，才使得越来越多的公司开始使用以及接受分布式架构。

为什么要用Dubbo
Dubbo的诞生和SOA分布式架构的流行有着莫大的关系。SOA 面向服务的架构(Service Oriented Architecture)，也就是把工程按照业务逻辑拆分成服务层和表现层。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

SOA架构中有两个主要角色：服务提供者（Provider）和服务使用者（Consumer）。



如果要开发分布式程序，也可以直接基于 HTTP 接口进行通信，那为什么要用Dubbo呢？

我认为主要可以从Dubbo提供的下面四点特性来说明：

负载均衡——同一个服务部署在不同的机器时该调用那一台机器上的服务
服务调用链路生成——随着系统的发展，服务越来越多，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。Dubbo可以为我们解决服务之间互相是如何调用的
服务访问压力以及时长统计、资源调度和治理——基于访问压力实时管理集群容量，提高集群利用率
服务降级——某个服务挂掉之后调用备用服务

另外，Dubbo 除了能够应用在分布式系统中，也可以应用在现在比较火的微服务系统中。不过，由于Spring Cloud在微服务中应用更加广泛，所以，一般我们提 Dubbo 的话，大部分是分布式系统的情况。
我们刚刚提到了分布式这个概念，下面再给大家介绍一下什么是分布式？为什么要分布式？
什么是分布式?
分布式重要的就是面向服务，或者说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等，拆分之后的每个服务可以部署在不同的机器上，如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。
为什么要分布式?
从开发角度来讲单体应用的代码都集中在一起，而分布式系统的代码根据业务被拆分。所以，每个团队可以负责一个服务的开发，这样提升了开发效率。

此外，代码根据业务拆分之后更加便于维护和扩展。

还有，将系统拆分成分布式之后不光便于系统扩展和维护，更能提高整个系统的性能。

目录

dubbo是什么？

dubbo的架构

节点角色说明

调用关系说明

连通性

健壮性

伸缩性

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

Dubbo超时重试机制带来的数据重复问题

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

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

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

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

持久节点

临时节点

应用场景

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

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

集群容错怎么做 

dubbo是如何实现负载均衡

遇到的问题

dubbo是什么？

dubbo是一个分布式框架，远程服务调用的分布式框架

dubbo能做什么?

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



节点角色说明

Provider: 暴露服务的服务提供方。
	
Consumer: 调用远程服务的服务消费方。
	
Registry: 服务注册与发现的注册中心。
	
Monitor: 统计服务的调用次调和调用时间的监控中心。
	
Container: 服务运行容器。
调用关系说明

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

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

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

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

4.服务消费者，从提供者地址列表中，基于软负载均衡算法（负载均衡算法包括轮询法、随机法、最少活跃调用数、一致性Hash等），选一台提供者进行调用，如果调用失败，再选另一台调用。

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

Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。

连通性

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
	
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
	
服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
	
服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
	
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
	
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
	
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
	
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
 

健壮性

监控中心宕掉不影响使用，只是丢失部分采样数据
	
数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
	
注册中心对等集群，任意一台宕掉后，将自动切换到另一台
	
注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
	
服务提供者无状态，任意一台宕掉后，不影响使用
	
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
 

伸缩性

注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
	
服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
 

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

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协议
 

Dubbo超时重试机制带来的数据重复问题

Dubbo的超时重试机制为服务容错、服务稳定提供了比较好的框架支持,但是在一些比较特殊的网络环境下(网络传输慢,并发多)可能由于服务响应慢,Dubbo自身的超时重试机制(服务端的处理时间超过了设定的超时时间时，就会有重复请求)可能会带来一些麻烦。



常见的应用场景故障:  1、发送邮件(重复) ；2、账户注册(重复)。

解决方案:         

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

          (1)、去掉超时重试机制  

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

 (2)、重新评估设置超时时间

 <dubbo:service interface="*.*" ref="*"  timeout="延长服务时间"/>

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

 

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

1）直连方式

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

2）注册中心方式

     而服务注册中心，动态的注册和发现服务，使服务的位置透明，并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover， 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

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

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

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

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

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地址。

 

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

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

zookeeper中节点是有生命周期的.具体的生命周期取决于节点的类型.节点主要分为持久节点(Persistent)和临时节点(Ephemeral),但是更详细的话还可以加上时序节点(Sequential),创建节点中往往组合使用,因此也就是4种.

持久节点
	
持久顺序节点
	
临时节点
	
临时顺序节点
其实不要纠结于分为几种,这就和语文的断句一样,你断句的方法不同,断出来的结果也不同.那么我们主要讲讲持久节点和临时节点的区别

持久节点


所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点,也就是说不会因为创建该节点的客户端会话失效而消失


临时节点


临时节点的生命周期和客户端会话绑定,也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉


应用场景


在分布式系统中,我们常常需要知道某个机器是否可用,传统的开发中,可以通过Ping某个主机来实现,Ping得通说明对方是可用的,相反是不可用的,ZK 中我们让所有的机器都注册一个临时节点,我们判断一个机器是否可用,我们只需要判断这个节点在ZK中是否存在就可以了,不需要直接去连接需要检查的机器,降低系统的复杂度


 

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

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="*" />

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

底层采用netty。

集群容错怎么做 

当我们的系统中用到Dubbo的集群环境,因为各种原因在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试。
集群容错模式：
1、Failover Cluster

      失败自动切换，当出现失败，重试其它服务器。(缺省)

      通常用于读操作，但重试会带来更长延迟。

      可通过retries="2"来设置重试次数(不含第一次)。正是文章刚开始说的那种情况.
2、Failfast Cluster

      快速失败，只发起一次调用，失败立即报错。

      通常用于非幂等性的写操作，比如新增记录。
3、Failsafe Cluster

      失败安全，出现异常时，直接忽略。

      通常用于写入审计日志等操作。
4、Failback Cluster

      失败自动恢复，后台记录失败请求，定时重发。

      通常用于消息通知操作。
5、Forking Cluster

      并行调用多个服务器，只要一个成功即返回。

      通常用于实时性要求较高的读操作，但需要浪费更多服务资源。

      可通过forks="2"来设置最大并行数。
6、Broadcast Cluster

      广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)

      通常用于通知所有提供者更新缓存或日志等本地资源信息。



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

<dubbo:service retries="2"/>
或：
<dubbo:reference retries="2"/>
或：
<dubbo:reference>
<dubbo:methodname="findFoo"retries="2"/>
</dubbo:reference>

集群模式配置如：

<dubbo:servicecluster="failsafe"/>
或：<dubbo:referencecluster="failsafe"/>

dubbo是如何实现负载均衡

dubbo负载均衡策略：

在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。
1、Random  LoadBalance

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

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

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

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

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

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

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

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


Dubbo的集群容错和负载均衡同样也是Dubbo本身的高级特性。正如我们在说自定义扩展的时候一样,这两个特征同样也可以进行自定义扩展,用户可以根据自己实际的需求来扩展他们从而满足项目的实际需求.

遇到的问题

场景描述：客户端远程异步调用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多的博客整理出来的一些，以后有其他东西再加进去

转载地址：https://www.jianshu.com/p/9d062eceb765

最近研究了一下阿里开源的分布式RPC框架dubbo，楼主写了一个 demo，体验了一下dubbo的功能。
快速开始

实际上，dubbo的官方文档已经提供了如何使用这个RPC框架example代码，基于 Netty 的长连接。楼主看这个框架主要是为了在微服务，service mesh大火的今天做一些技术储备以及了解一下分布式 RPC 框架的设计。
当然即便是写一个dubbo的demo也不能随便写写就好了，要认真对待说不定哪一天可以派上用场呢，下面是楼主写的代码的目录结构：



下面我来一一说明一下每个model的作用，
micro-service-dubbo-common是通用工具模块其他的model都需要依赖它 。

micro-service-dubbo-dal是整个项目的dao模块，有关数据库操作的相关代码都放在这里。

micro-service-dubbo-interface 是通用接口模块，专门用来声明接口，被consumer与provider同时依赖，这么做是为了项目的可拆分与分布式部署。

micro-service-dubbo-model是公用的实体类模块，不限于数据库对应的model，也可以放DTO，VO等。

micro-service-dubbo-provider项目的服务提供者。

micro-service-dubbo-web 项目的消费者，也是直接跟前端交互的controller层。

另外需要在pom文件中添加相关依赖
<!--dubbo-->
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>${dubbo.version}</version>
</dependency>

<dependency>
    <groupId>com.101tec</groupId>
    <artifactId>zkclient</artifactId>
    <version>${zkclient_version}</version>
</dependency>

<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>${zookeeper_version}</version>
</dependency>

<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-framework</artifactId>
    <version>${curator_version}</version>
</dependency>

接口创建

既然是 RPC 服务，那就需要一个接口，再有一个实现类。在这里的接口定义是在我们的micro-service-dubbo-interface，具体实现是在provider这里创建，在楼主的项目中就是在micro-service-dubbo-provider中创建DemoService 的实现。
public interface DemoService {
    String sayHello(String name);

    public List getUsers();
}

@Service("demoService")
public class DemoServiceImpl implements DemoService {

    @Override
    public String sayHello(String name) {
        System.out.println("[" + new SimpleDateFormat("HH:mm:ss").format(new Date()) + "] Hello " + name + ", request from consumer: " + RpcContext
                .getContext().getRemoteAddress());
        return "Hello " + name + ", response from provider: " + RpcContext.getContext().getLocalAddress();
    }

    @Override
    public List getUsers() {
        List list = new ArrayList();
        User u1 = new User();
        u1.setName("hejingyuan");
        u1.setAge(20);
        u1.setSex("f");

        User u2 = new User();
        u2.setName("xvshu");
        u2.setAge(21);
        u2.setSex("m");


        list.add(u1);
        list.add(u2);

        return list;
    }
}

然后consumer的 pom.xml 添加对这个接口的依赖，在这里的接口定义是在我们的consumer就是micro-service-dubbo-web。
<dependency>
  <groupId>com.whforever</groupId>
    <artifactId>micro-service-dubbo-provider</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
    <groupId>com.whforever</groupId>
    <artifactId>micro-service-dubbo-interface</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

有了接口，就需要配置一下。
接口配置

首先在提供方这里发布接口。创建一个 xml 文件，名为：dubbo-provider.xml。
文件内容：
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xmlns="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
       http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <!-- provider's application name, used for tracing dependency relationship -->
    <dubbo:application name="demo-provider"/>

    <!-- use multicast registry center to export service -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181" />

    <!-- use dubbo protocol to export service on port 20880 -->
    <dubbo:protocol name="dubbo" port="20880"/>

    <!-- service implementation, as same as regular local bean -->
    <bean id="demoProviderService" class="com.whforever.service.impl.DemoServiceImpl"/>

    <!-- declare the service interface to be exported -->
    <dubbo:service interface="com.whforever.service.DemoService" ref="demoProviderService"/>

</beans>

很简单，发布了一个接口，类似 Spring 的一个 bean。
同样的，在consumer即micro-service-dubbo-web的 resource 文件下，也创建一个dubbo-consumer.xml文件。内容稍有不同。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xmlns="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
       http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <!-- consumer's application name, used for tracing dependency relationship (not a matching criterion),
    don't set it same as provider -->
    <dubbo:application name="demo-consumer"/>

    <!-- use multicast registry center to discover service -->
    <!--<dubbo:registry address="multicast://224.5.6.7:1234"/>-->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181" />

    <!-- generate proxy for the remote service, then demoService can be used in the same way as the
    local regular interface -->
    <dubbo:reference id="demoConsumerService" check="false" interface="com.whforever.service.DemoService"/>

</beans>

从上面可以看出这两个文件的注册发现协议是zookeeper，因此在服务启动之前需要启动zookeeper，具体移步Zookeeper 注册中心安装启动
准备测试

测试之前还要做点点工作。
在启动provider事需要一部分引导程序，请看如下代码：
public class ProviderMain {
    public static void main(String[] args) throws IOException {
        System.setProperty("java.net.preferIPv4Stack", "true");
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("dubbo-provider.xml");
        context.start();

        System.in.read(); // press any key to exit
    }
}

consumer代码
@Controller
@RequestMapping("/")
public class IndexController {

    @Autowired
    DemoService demoService;

    @RequestMapping("/echo")
    @ResponseBody
    public String echo() {
        System.out.println(">>>>>>echo");
        return JSON.toJSONString(demoService.getUsers());
    }
}

运行

先运行provider：
[06/06/18 11:56:29:029 CST] main  INFO config.AbstractConfig:  [DUBBO] The service ready on spring started. service: com.whforever.service.DemoService, dubbo version: 2.6.1, current host: 192.168.1.120
[06/06/18 11:56:30:030 CST] main  INFO config.AbstractConfig:  [DUBBO] Export dubbo service com.whforever.service.DemoService to local registry, dubbo version: 2.6.1, current host: 192.168.1.120
[06/06/18 11:56:30:030 CST] main  INFO config.AbstractConfig:  [DUBBO] Export dubbo service com.whforever.service.DemoService to url dubbo://192.168.1.120:20880/com.whforever.service.DemoService?anyhost=true&application=demo-provider&bind.ip=192.168.1.120&bind.port=20880&dubbo=2.6.1&generic=false&interface=com.whforever.service.DemoService&methods=sayHello,getUsers&pid=13992&side=provider&timestamp=1528300589682, dubbo version: 2.6.1, current host: 192.168.1.120
[06/06/18 11:56:30:030 CST] main  INFO config.AbstractConfig:  [DUBBO] Register dubbo service com.whforever.service.DemoService url dubbo://192.168.1.120:20880/com.whforever.service.DemoService?anyhost=true&application=demo-provider&bind.ip=192.168.1.120&bind.port=20880&dubbo=2.6.1&generic=false&interface=com.whforever.service.DemoService&methods=sayHello,getUsers&pid=13992&side=provider&timestamp=1528300589682 to registry registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.6.1&pid=13992&registry=zookeeper&timestamp=1528300589673, dubbo version: 2.6.1, current host: 192.168.1.120
[06/06/18 11:56:30:030 CST] main  INFO transport.AbstractServer:  [DUBBO] Start NettyServer bind /0.0.0.0:20880, export /192.168.1.120:20880, dubbo version: 2.6.1, current host: 192.168.1.120

再运行sonsumer：



通过查看dubbo监控中心，可以看到如下所示的情况，具体dubbo监控中心如何安装部署请移步Simple 监控中心安装



小结

对于dubbo听其大名已久，直到最近才动手写了一些demo，总体来看上手还是比较简单，官方也提供了比较详细的文档，社区也比较活跃。

转载自  史上最全 40 道 Dubbo 面试题及答案，看完碾压面试官

想往高处走，怎么能不懂 Dubbo？

Dubbo是国内最出名的分布式服务框架，也是 Java 程序员必备的必会的框架之一。Dubbo 更是中高级面试过程中经常会问的技术，无论你是否用过，你都必须熟悉。

下面我为大家准备了一些 Dubbo 常见的的面试题，一些是我经常问别人的，一些是我过去面试遇到的一些问题，总结给大家，希望对大家能有所帮助。

1、Dubbo是什么？

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。

面试官问你如果这个都不清楚，那下面的就没必要问了。


官网：http://dubbo.apache.org


2、为什么要用Dubbo？

因为是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。内部使用了 Netty、Zookeeper，保证了高性能高可用性。

使用 Dubbo 可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。

下面这张图可以很清楚的诠释，最重要的一点是，分布式架构可以承受更大规模的并发流量。



 

下面是 Dubbo 的服务治理图。



 

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

两个没关联，如果硬要说区别，有以下几点。

1）通信方式不同

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

2）组成部分不同



 

4、dubbo都支持什么协议，推荐用哪种？


	
dubbo://（推荐）
	
	

	
rmi://
	
	

	
hessian://
	
	

	
http://
	
	

	
webservice://
	
	

	
thrift://
	
	

	
memcached://
	
	

	
redis://
	
	

	
rest://
	
5、Dubbo需要 Web 容器吗？

不需要，如果硬要用 Web 容器，只会增加复杂性，也浪费资源。

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


	
Spring Container
	
	

	
Jetty Container
	
	

	
Log4j Container
	
Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。

7、Dubbo里面有哪几种节点角色？

 



8、画一画服务注册与发现的流程图



 

该图来自 Dubbo 官网，供你参考，如果你说你熟悉 Dubbo, 面试官经常会让你画这个图，记好了。

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

推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中心，但不推荐。

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

1）Spring 配置方式

2）Java API 配置方式

11、Dubbo 核心的配置有哪些？

我曾经面试就遇到过面试官让你写这些配置，我也是蒙逼。。

 



配置之间的关系见下图。

 



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

1）timeout：方法调用超时

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

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

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

13、Dubbo启动时如果依赖的服务不可用会怎样？

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check="true"，可以通过 check="false" 关闭检查。

14、Dubbo推荐使用什么序列化框架，你知道的还有哪些？

推荐使用Hessian序列化，还有Duddo、FastJson、Java自带序列化。

15、Dubbo默认使用的是什么通信框架，还有别的选择吗？

Dubbo 默认使用 Netty 框架，也是推荐的选择，另外内容还集成有Mina、Grizzly。

16、Dubbo有哪几种集群容错方案，默认是哪种？

 



17、Dubbo有哪几种负载均衡策略，默认是哪种？

 



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

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。

19、Dubbo支持服务多协议吗？

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

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

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

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

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

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

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

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

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

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

异步调用流程图如下。



 

24、Dubbo支持分布式事务吗？

目前暂时不支持，后续可能采用基于 JTA/XA 规范实现，如以图所示。



 

25、Dubbo telnet 命令能做什么？

dubbo 通过 telnet 命令来进行服务治理，具体使用看这篇文章《dubbo服务调试管理实用命令》。


telnet localhost 8090


26、Dubbo支持服务降级吗？

Dubbo 2.2.0 以上版本支持。

27、Dubbo如何优雅停机？

Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。

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

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

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

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

30、服务读写推荐的容错策略是怎样的？

读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。

写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

31、Dubbo必须依赖的包有哪些？

Dubbo 必须依赖 JDK，其他为可选。

32、Dubbo的管理控制台能做什么？

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

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

Dubbo 会在 Spring 实例化完 bean 之后，在刷新容器最后一步发布 ContextRefreshEvent 事件的时候，通知实现了 ApplicationListener 的 ServiceBean 类进行回调 onApplicationEvent 事件方法，Dubbo 会在这个方法中调用 ServiceBean 父类 ServiceConfig 的 export 方法，而该方法真正实现了服务的（异步或者非异步）发布。

34、Dubbo 停止维护了吗？

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

35、Dubbo 和 Dubbox 有什么区别？

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

36、你还了解别的分布式框架吗？

别的还有 Spring cloud、Facebook 的 Thrift、Twitter 的 Finagle 等。

37、Dubbo 能集成 Spring Boot 吗？

可以的，项目地址如下。


https://github.com/apache/incubator-dubbo-spring-boot-project


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

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

39、你读过 Dubbo 的源码吗？

要了解 Dubbo 就必须看其源码，了解其原理，花点时间看下吧，网上也有很多教程，后续有时间我也会在公众号上分享 Dubbo 的源码。

40、你觉得用 Dubbo 好还是 Spring Cloud 好？

扩展性的问题，没有好坏，只有适合不适合，不过我好像更倾向于使用 Dubbo, Spring Cloud 版本升级太快，组件更新替换太频繁，配置太繁琐，还有很多我觉得是没有 Dubbo 顺手的地方……