Dubbo

Dubbo

参考链接

• dubbo面试题

• 分布式相关面试题

• Dubbo 总结：关于 Dubbo 的重要知识点

基础知识

为什么要用 Dubbo？

• 随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。就这样为分布式系统的服务治理框架就出现了，Dubbo 也就这样产生了。

Dubbo 核心组件有哪些？

• Provider：暴露服务的服务提供方
• Consumer：调用远程服务消费方
• Registry：服务注册与发现注册中心
• Monitor：监控中心和访问调用统计
• Container：服务运行容器

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

• 服务容器Container负责启动，加载，运行服务提供者。
• 服务提供者Provider在启动时，向注册中心注册自己提供的服务。
• 服务消费者Consumer在启动时，向注册中心订阅自己所需的服务。
• 注册中心Registry返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 服务消费者Consumer，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 服务消费者Consumer和提供者Provider，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心Monitor。

说说 Dubbo 服务暴露的过程

dubbo采用的nio异步的通信，通信协议默认为 netty,当然也可以选择 mina,grizzy。在服务端（provider）在启动时主要是开启netty监听，在zookeeper上注册服务节点，处理消费者请求，返回处理后的消息给消费者，消费者使用服务时主要是订阅服务的节点，监听zookeeper节点目录，服务端的变化时zookeeper会推送给消费者，消费者重新缓存服务地址等。服务者、消费者、zookeeper三者之间都是长连接。

---

简易的暴露流程

1. Spring将dubbo标签解析，注入到ServiceConfig属性中

2. 服务暴露的入口是：ServiceConfig的export 方法，里面判断是否延迟暴露，最终调用doExport

3. doExport会对解析完的配置再做一次检查，所有的检查通过之后，会调用 doExportUrls 方法，因为dubbo支持多通信协议时，都进行暴露，里面调用doExportUrlsFor1Protocol

4. doExportUrlsFor1Protocol中主要将所有的配置转化成map，然后将map转化成dubbo的统一URL，最终暴露的dubbo服务也就是这个统一的url，这个url也会注册到zookeeper的节点上。然后将所有服务的实现封装成一个invoker，并缓存起来，缓存里使用Invoker的url作为key。代码核心暴露的一行代码为：protocol.export(invoker);

5. RegistryProtocol.exprot主要做两件事情：1、开启netty服务端并监听 。2、创建zookeeper服务临时节点。

6. 启动注册是调用doRegister方法，不同协议重写了此方法。其实从上面已经可以看到 在zookeeper上面创建 节点了，默认不分组的情况下，服务结构如下：/dubbo/XXXXservice/consumers、providers

7. 服务端Server启动，监听端口。（请求来到时，根据请求信息生成key，到缓存查找Exporter，就找到了Invoker，就可以完成调用。）

结合源码

下面看dubbo源码来看服务暴露的过程，服务暴露的入口为：com.alibaba.dubbo.config.ServiceConfig#export 方法，代码如下：

//是否延时暴露
if (delay != null && delay > 0) {
  Thread thread = new Thread(new Runnable() {
    public void run() {
      try {
        Thread.sleep(delay);
      } catch (Throwable e) {
      }
      doExport();
    }
  });
  thread.setDaemon(true);
  thread.setName("DelayExportServiceThread");
  thread.start();
} else {
  //不延时暴露，则直接暴露
  doExport();
}

上在代码无论是延时暴露或直接暴露调用的方法是：doExport(),doExport会对解析完的配置再做一次检查，核心代码大家可以查看dubbo的源码，下面列出一小部分

/*
     检查默认设置,如果xml中没有配置<dubbo:provider
     主要是从系统环境变量中寻找是否有相应的provider的配置
  */
 checkDefault();
 //下面设置的内容如果没有配置<dubbo:provider时基本上都是Null
 if (provider != null) {
     if (application == null) {
         application = provider.getApplication();
     }
     if (module == null) {
         module = provider.getModule();
     }
     if (registries == null) {
         registries = provider.getRegistries();
     }
     if (monitor == null) {
         monitor = provider.getMonitor();
     }
     if (protocols == null) {
         protocols = provider.getProtocols();
     }
 }
 if (module != null) {
     //registries一般都会配置
     if (registries == null) {
         registries = module.getRegistries();
     }
     if (monitor == null) {
         monitor = module.getMonitor();
     }
 }
 if (application != null) {
     //application一般也会配置
     if (registries == null) {
         registries = application.getRegistries();
     }
     if (monitor == null) {
         monitor = application.getMonitor();
     }
 }
 //是否泛化调用
 if (ref instanceof GenericService) {
     interfaceClass = GenericService.class;
     if (StringUtils.isEmpty(generic)) {
         generic = Boolean.TRUE.toString();
     }
 } else {
     try {
         interfaceClass = Class.forName(interfaceName, true, Thread.currentThread()
                 .getContextClassLoader());
     } catch (ClassNotFoundException e) {
         throw new IllegalStateException(e.getMessage(), e);
     }
     /*
         检查即将暴露的接口的方法配置,检查方法是否在接口中存在
         一般不会配置所以一般情况下methods为null
         <dubbo:service  > <dubbo:method /> </dubbo:serivce>
      */
     checkInterfaceAndMethods(interfaceClass, methods);
     /*
         检查接口的引用不为空,并且必须实现的是要暴露的接口
      */
     checkRef();
     generic = Boolean.FALSE.toString();
 }

所有的检查通过之后，会调用 ：com.alibaba.dubbo.config.ServiceConfig#doExportUrls 方法，因为dubbo支持多通信协议时，都进行暴露，所以在代码中可以看到

/*
    将注册协议转化成url
    registry://45.119.68.23:2181/com.alibaba.dubbo.registry.RegistryService?
    application=test-dubbo&dubbo=2.5.3&pid=7648&registry=zookeeper×tamp=1462349748801
 */
List<URL> registryURLs = loadRegistries(true);
//配置多通信协议时，都进行暴露
for (ProtocolConfig protocolConfig : protocols) {
    doExportUrlsFor1Protocol(protocolConfig, registryURLs);
}

doExportUrlsFor1Protocol中主要将所有的配置转化成map，然后将map转化成dubbo的统一URL，最终暴露的dubbo服务也就是这个统一的url，这个url也会注册到zookeeper的节点上，部分代码如下：

/*
    将不为null的配置对象中的属性设置到 map 中
    即将 xml 配置文件中的配置设置的值全转化成为map
    {side=provider, application=alijk-dubbo, accepts=1000,
        dubbo=2.5.3, threads=100, pid=7236, interface=cn.eoncloud.account.sdk.export.AccountService,
        threadpool=fixed, version=1.0.0, timeout=500, anyhost=true, timestamp=1462347843960}
 */
appendParameters(map, application);
appendParameters(map, module);
appendParameters(map, provider, Constants.DEFAULT_KEY);
appendParameters(map, protocolConfig);
appendParameters(map, this);
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
/*
    将配置信息转化成 url ,主要根据之前map里的数据组装成url
    调用 URL#buildString方法
    dubbo://10.6.13.137:9998/cn.eoncloud.account.sdk.export.AccountService
    ?accepts=1000&anyhost=true&application=test-dubbo&dubbo=2.5.3
    &interface=cn.eoncloud.account.sdk.export.AccountService
    &methods=getAccountName,getAllTest&pid=7236&revision=1.0.0&side=provider
    &threadpool=fixed&threads=100&timeout=500×tamp=1462347843960&version=1.0.0
 */
URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map);

if (ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
        .hasExtension(url.getProtocol())) {
    url = ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
            .getExtension(url.getProtocol()).getConfigurator(url).configure(url);
}
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
//com.alibaba.dubbo.registry.integration.RegistryProtocol#export 即将进行暴露
Exporter<?> exporter = protocol.export(invoker);

上面的代码核心暴露的一行代码为：protocol.export(invoker); 这个protocol的值为：RegistryProtocol，也就是暴露会跳到：RegistryProtocol.exprot中去处理，RegistryProtocol.exprot主要做两件事情：1、开启netty服务端 。2、创建zookeeper服务节点。下面来看RegistryProtocol.export 方法，代码如下：

public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
        //export invoker doLocalExport调用dubboProtocol.export开启netty服务监听
        final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker);
        //registry provider
        final Registry registry = getRegistry(originInvoker);
        final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);
        //调用zodoRegister的doRegister 创建zookeeper的服务节点
        registry.register(registedProviderUrl);
        // 订阅override数据
        // FIXME 提供者订阅时，会影响同一JVM即暴露服务，又引用同一服务的的场景，因为subscribed以服务名为缓存的key，导致订阅信息覆盖。
        final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
        final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl);
        overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
        //订阅
        registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
        //保证每次export都返回一个新的exporter实例
        return new Exporter<T>() {
            public Invoker<T> getInvoker() {
                return exporter.getInvoker();
            }
            public void unexport() {
                try {
                    exporter.unexport();
                } catch (Throwable t) {
                    logger.warn(t.getMessage(), t);
                }
                try {
                    registry.unregister(registedProviderUrl);
                } catch (Throwable t) {
                    logger.warn(t.getMessage(), t);
                }
                try {
                    overrideListeners.remove(overrideSubscribeUrl);
                    registry.unsubscribe(overrideSubscribeUrl, overrideSubscribeListener);
                } catch (Throwable t) {
                    logger.warn(t.getMessage(), t);
                }
            }
        };
    }

上面的代码里有一段特别重要，关键性的代码在doLocalExport中：

final Invoker<?> invokerDelegete = new InvokerDelegete<T>(originInvoker, getProviderUrl(originInvoker));
//此处protol为dubboProtocol
exporter = new ExporterChangeableWrapper<T>((Exporter<T>)protocol.export(invokerDelegete), originInvoker);

从上面的代码中可以看到会调用dubboProtocol的export对服务进行暴露，这个export最终目的就是开启netty的监听，下面来看dubbo是如何一步一步开启netty的

 private void openServer(URL url) {
        // find server. ip:port
        String key = url.getAddress();
        //client 也可以暴露一个只有server可以调用的服务。
        boolean isServer = url.getParameter(Constants.IS_SERVER_KEY,true);
        if (isServer) {
            ExchangeServer server = serverMap.get(key);
            if (server == null) {
                //创建 Server
                serverMap.put(key, createServer(url));
            } else {
                //server支持reset,配合override功能使用
                server.reset(url);
            }
        }
    }


private ExchangeServer createServer(URL url) {
    //默认开启server关闭时发送readonly事件
    url = url.addParameterIfAbsent(Constants.CHANNEL_READONLYEVENT_SENT_KEY, Boolean.TRUE.toString());
    //默认开启heartbeat
    url = url.addParameterIfAbsent(Constants.HEARTBEAT_KEY, String.valueOf(Constants.DEFAULT_HEARTBEAT));
    //默认使用netty
    String str = url.getParameter(Constants.SERVER_KEY, Constants.DEFAULT_REMOTING_SERVER);

    if (str != null && str.length() > 0 && ! ExtensionLoader.getExtensionLoader(Transporter.class).hasExtension(str))
        throw new RpcException("Unsupported server type: " + str + ", url: " + url);
    //默认使用dubbo协议编码
    url = url.addParameter(Constants.CODEC_KEY, Version.isCompatibleVersion() ? COMPATIBLE_CODEC_NAME : DubboCodec.NAME);
    ExchangeServer server;
    try {
        //HeaderExchangeServer 在此处已经开启了Netty Server 进行监听
        server = Exchangers.bind(url, requestHandler);
    } catch (RemotingException e) {
        throw new RpcException("Fail to start server(url: " + url + ") " + e.getMessage(), e);
    }
    str = url.getParameter(Constants.CLIENT_KEY);
    if (str != null && str.length() > 0) {
        Set<String> supportedTypes = ExtensionLoader.getExtensionLoader(Transporter.class).getSupportedExtensions();
        if (!supportedTypes.contains(str)) {
            throw new RpcException("Unsupported client type: " + str);
        }
    }
    return server;
}

在上面的代码中：Exchangers.bind(url, requestHandler) 默认为：HeaderExchanger.bind()

public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
        //Transporters默认为NettyTransporter
        return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));
    }

代码运行到这里可以看到传输方式了，dubbo默认采用的通信方式为 NettyTransporter ，再来看NettyTransporter.bind方法

public static final String NAME = "netty";
public Server bind(URL url, ChannelHandler listener) throws RemotingException {
    return new NettyServer(url, listener);
}

已经能看到NettyServer了，dubbo在暴露服务最终开启的netty服务监听，监听消费者发送的请求，通过反射调用方法得到结果通过 tcp/ip 网络传输返回给消费者。再进入到NettyServer中我们就能看到非常传统的开启Netty服务的代码了

   protected void doOpen() throws Throwable {
        NettyHelper.setNettyLoggerFactory();
        ExecutorService boss = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerBoss", true));
        ExecutorService worker = Executors.newCachedThreadPool(new NamedThreadFactory("NettyServerWorker", true));
        //最后一个参数为 NIO 最大工作线程数
        ChannelFactory channelFactory = new NioServerSocketChannelFactory(boss, worker, getUrl().getPositiveParameter(Constants.IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS));
        //netty server 启动器
        bootstrap = new ServerBootstrap(channelFactory);

   final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);
    channels = nettyHandler.getChannels();
    // https://issues.jboss.org/browse/NETTY-365
    // https://issues.jboss.org/browse/NETTY-379
    // final Timer timer = new HashedWheelTimer(new NamedThreadFactory("NettyIdleTimer", true));
    bootstrap.setPipelineFactory(new ChannelPipelineFactory() {
        public ChannelPipeline getPipeline() {
            NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec() ,getUrl(), NettyServer.this);
            ChannelPipeline pipeline = Channels.pipeline();
            /*int idleTimeout = getIdleTimeout();
            if (idleTimeout > 10000) {
                pipeline.addLast("timer", new IdleStateHandler(timer, idleTimeout / 1000, 0, 0));
            }*/
            pipeline.addLast("decoder", adapter.getDecoder());
            pipeline.addLast("encoder", adapter.getEncoder());
            pipeline.addLast("handler", nettyHandler);
            return pipeline;
        }
    });
    // 创建一个绑定到指定地址的新通道，也就是绑定IP、端口供客户端连接
    channel = bootstrap.bind(getBindAddress());
}

上面的代码执行完成后，netty的服务端就已经开启了，可以接收客户端的连接了，但客户端连接上来要怎么处理呢？消息接收、发送怎么处理呢？所有的处理都在上面代码的 NettyHandler类中，Nettyhandler继承了Netty包中的的SimpleChannelHandler

从前面知道,开启netty服务是在RegistryProtocol.export 的 doLocalExport 中，在开启了netty服务后，就是在zookeeper上注册服务节点了，消费者在消费服务时会根据消费的接口名找到对应的zookeeper节点目录，对目录进行监听，接收推送

//registry provider
final Registry registry = getRegistry(originInvoker);
final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);
//调用zodoRegister的doRegister 创建zookeeper的服务节点
registry.register(registedProviderUrl);
// 订阅override数据
// FIXME 提供者订阅时，会影响同一JVM即暴露服务，又引用同一服务的的场景，因为subscribed以服务名为缓存的key，导致订阅信息覆盖。
final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl);
overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
//订阅
registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);

dubbo服务在zookeeper上的节点注册是：com.alibaba.dubbo.registry.support.FailbackRegistry#register

@Override
    public void register(URL url) {
        super.register(url);
        failedRegistered.remove(url);
        failedUnregistered.remove(url);
        try {
            // 向服务器端发送注册请求
            doRegister(url);

因为doRegister是一个抽象的方法，查看他的实现可以看到如下图：

从上图可以看到doRegister实现有 dubbo、redis、zookeeper，这也是在我们配置时经常看到的 注册协议的配置 ，最为常用的就是 zookeeper了，所以再看ZookeeperRegistry的代码，看他的doRegistry干什么了如下

protected void doRegister(URL url) {
        try {
            zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true));
        } catch (Throwable e) {
            throw new RpcException("Failed to register " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e);
        }
    }

其实从上面已经可以看到 在zookeeper上面创建 节点了，默认不分组的情况下，服务结构如下：/dubbo/XXXXservice/consumers、providers

至此，dubbo的暴露基本上已经完成，开启了netty服务，注册了zookeeper的节点，就等着消费者连接上来使用了。

服务端Server启动，监听端口。（请求来到时，根据请求信息生成key，到缓存查找Exporter，就找到了Invoker，就可以完成调用。）

---

Dubbo 的整体架构设计有哪些分层?

• 第一层：service层，接口层，给服务提供者和消费者来实现的
• 第二层：config层，配置层，主要是对dubbo进行各种配置的
• 第三层：proxy层，服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton
• 第四层：registry层，服务注册层，负责服务的注册与发现
• 第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
• 第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
• 第七层：protocol层，远程调用层，封装rpc调用
• 第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
• 第九层：transport层，网络传输层，抽象mina和netty为统一接口
• 第十层：serialize层，数据序列化层，网络传输需要

Dubbo 有哪些注册中心？

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

分布式框架

Dubbo 和 Spring Cloud 有什么哪些区别？

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

  1）通信方式不同

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

  2）组成部分不同

  

集群

Dubbo集群提供了哪些负载均衡策略？

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

默认为 Random 随机调用。

Dubbo的集群容错方案有哪些？6种

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

默认的容错方案是 Failover Cluster。
读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。
写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

其他

Dubbo 如何优雅停机？

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

Dubbo SPI 和 Java SPI 区别？

SPI是什么

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。

整体机制图如下：

总结：

SPI 全称为 Service Provider Interface，是一种服务提供接口。实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制，不需要改动Dubbo源码，动态根据配置文件加载需要的服务实现类。Dubbo在JDK SPI的基础上做了优化：

1、延迟加载，可以一次只加载自己想要加载的扩展实现。

2、增加了对 IOC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。

• JDK SPI：

  JDK 标准的 SPI 会一次性加载所有的扩展实现，如果有的扩展很耗时，但也没用上，很浪费资源。所以只希望加载某个的实现，就不现实了

• DUBBO SPI：

  1、对 Dubbo 进行扩展，不需要改动 Dubbo 的源码

  2、延迟加载，可以一次只加载自己想要加载的扩展实现。

  3、增加了对扩展点 IOC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。

  4、Dubbo 的扩展机制能很好的支持第三方 IoC 容器，默认支持 Spring Bean。

服务调用是阻塞的吗？

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

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

• 为了提高数据访问的速度。Dubbo 提供了声明式缓存，以减少用户加缓存的工作量<dubbo:reference cache=“true” />
• 其实比普通的配置文件就多了一个标签 cache=“true”

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

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

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

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

2、dubbo 缺省会在启动时检查依赖是否可用，不可用就抛出异常，阻止 spring 初始化完成，check 属性默认为 true。

测试时有些服务不关心或者出现了循环依赖，将 check 设置为 false

Dubbo 中的序列化

Dubbo 中支持的序列化方式：

• dubbo 序列化：阿里尚未开发成熟的高效 java 序列化实现，阿里不建议在生产环境使用它
• hessian2 序列化：hessian 是一种跨语言的高效二进制序列化方式。但这里实际不是原生的 hessian2 序列化，而是阿里修改过的 hessian lite，它是 dubbo RPC 默认启用的序列化方式
• json 序列化：目前有两种实现，一种是采用的阿里的 fastjson 库，另一种是采用 dubbo 中自己实现的简单 json 库，但其实现都不是特别成熟，而且 json 这种文本序列化性能一般不如上面两种二进制序列化。
• java 序列化：主要是采用 JDK 自带的 Java 序列化实现，性能很不理想。

在通常情况下，这四种主要序列化方式的性能从上到下依次递减。对于 dubbo RPC 这种追求高性能的远程调用方式来说，实际上只有 1、2 两种高效序列化方式比较般配，而第 1 个 dubbo 序列化由于还不成熟，所以实际只剩下 2 可用，所以 dubbo RPC 默认采用 hessian2 序列化。

最近几年，各种新的高效序列化方式层出不穷，不断刷新序列化性能的上限，最典型的包括：

• 专门针对 Java 语言的：Kryo，FST 等等
• 跨语言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack 等等

其中，Kryo 是一种非常成熟的序列化实现，已经在 Twitter、Groupon、Yahoo 以及多个著名开源项目（如 Hive、Storm）中广泛的使用。而 FST 是一种较新的序列化实现，目前还缺乏足够多的成熟使用案例。

在面向生产环境的应用中，目前更优先选择 Kryo。

具体实现：

https://www.jianshu.com/p/4317532e779a