dubbo解析-探讨dubbo稳定性

本文基于dubbo 2.7.5版本代码

一、问题背景

dubbo成功完成服务调用需要多个组件的参与，比如注册中心、配置中心、元数据中心、服务端提供服务。今天忽然想到一个问题，如果参与组件有任何一个宕机了，那么服务调用还会成功吗？或者有任何一个网络不通，消费端或者服务端能正常启动吗？接下来通过本文探讨这个问题。
因为dubbo在2.7.5版本里面新增了云原生服务自省架构，所以接下来的分析分为传统架构和服务自省架构。

二、提出问题

1、传统架构下：
问题（1）、启动时，注册中心不能访问，消费端和服务端是否可以启动？dubbo启动后，注册中心宕机，是否影响服务访问？
问题（2）、启动时，监控中心不能访问，消费端和服务端是否可以启动？dubbo启动后，监控中心宕机，是否影响服务访问？
问题（3）、启动时，配置中心不能访问，消费端和服务端是否可以启动？dubbo启动后，配置中心宕机，是否影响服务访问？
问题（4）、启动时，元数据中心不能访问，消费端和服务端是否可以启动？dubbo启动后，元数据中心宕机，是否影响服务访问？
2、云原生服务自省架构下：
问题（5）、同（1）问题
问题（6）、同（2）问题
问题（7）、同（3）问题
问题（8）、同（4）问题
问题（9）、启动时，MetadataService服务不能访问，消费端是否可以启动？启动后，MetadataService服务不能访问，是否影响服务访问？
3、这个问题与架构没有关系，当无可用服务时，消费端如何访问服务？

三、解决问题

1、配置中心问题

下面分析问题（3）和问题（7）。
在服务端、消费端启动的时候，如果没有设置配置中心的参数，那么dubbo会将注册中心作为配置中心。
如果在启动时候，设置错误的配置中心地址，dubbo抛出如下异常，启动失败：

java.lang.IllegalStateException: zookeeper not connected

之所以启动失败是因为配置中心的参数设置直接影响服务的调用行为，比如负载均衡、服务超时时间，如果不报错可能服务运行与预想的结果不一致，在生产上会造成严重后果。
启动后，如果配置中心宕机，并不会影响服务端和消费端运行，服务可以正常调用，后台zk不断尝试建立与配置中心的连接，不过配置就不能通过修改配置中心生效了。

2、监控中心问题

下面分析问题（2）和问题（6）。
在dubbo启动的时候，不会建立与监控中心的连接，建立连接是在服务端返回或者客户端收到响应后。
dubbo使用下面的代码建立与监控中心的连接：

private void collect(Invoker<?> invoker, Invocation invocation, Result result, String remoteHost, long start, boolean error) {
        try {
            URL monitorUrl = invoker.getUrl().getUrlParameter(MONITOR_KEY);
            //monitor对象如果不为null，表示成功建立与监控中心的连接，如果为null，表示失败
            Monitor monitor = monitorFactory.getMonitor(monitorUrl);
            if (monitor == null) {
                return;
            }
            URL statisticsURL = createStatisticsUrl(invoker, invocation, result, remoteHost, start, error);
            monitor.collect(statisticsURL);
        } catch (Throwable t) {
            logger.warn("Failed to monitor count service " + invoker.getUrl() + ", cause: " + t.getMessage(), t);
        }
    }

从上面的代码可以看出监控中心无法连接不会对服务调用产生影响。
dubbo将监控数据发送到监控中心是在单独的定时线程内完成的，所以运行过程中，监控中心突然宕机也不会对服务调用产生影响，最多就是缺失一段时间内的监控数据。
监控中心与服务调用关系不大，监控数据缺失不会造成严重问题，所以监控中心在任何时候出问题都不会影响服务的调用。

3、注册中心问题

下面分析问题（1）和问题（5）。
注册中心是非常重要的组件，消费端通过注册中心发现服务端。在启动的时候都向注册中心注册信息，如果注册中心在dubbo启动的时候不能访问，那么服务端和消费端都启动失败。
网上有介绍说设置RegistryConfig的check属性为false可以跳过注册中心的初始化，经过测试check是不起作用的，因为RegistryConfig的isCheck方法没有调用点，自然获取不到check值。
消费端启动时，会将注册中心的数据保存到本地然后建立与服务端的连接，所以启动完毕后，注册中心宕机了，不会影响服务的正常调用，在这种情况下注册中心宕机带来的影响是远程服务不能访问时，客户端觉察不到。

4、元数据中心问题

下面分析问题（4）和问题（8）。
元数据中心用于存储服务的元数据，分为本地和远程。本地存储在内存中，不存在不可用的问题，除非内存满了。下面我们分析远程的元数据中心。
启动时候，如果元数据中心不能访问，dubbo抛出异常，启动失败。
如果在运行过程中，元数据中心宕机，不影响服务的正常调用。只不过访问元数据中心失败后新增一个定时任务，交由后台线程定时访问元数据中心。

5、MetadataService服务问题

MetadataService服务在云原生服务自省架构下才有意义，因为传统架构下，消费端不访问该服务。
不过无论是在传统架构下还是云原生服务自省架构下，如果该服务暴露失败，也会造成dubbo启动不成功。
在云原生架构下，如果服务端暴露该服务成功，消费端启动时访问该服务以获取服务端提供的服务信息并建立服务连接，所以如果MetadataService服务访问失败，客户端便无法建立任何与服务端的连接，如果设置了ReferenceConfig或者ConsumerConfig为false，客户端启动时不会检查是否有可用服务，客户端还是可以正常启动，但是后续的服务访问会报错。
消费端端访问了MetadataService服务后，会将服务返回数据存储在本地，之后便使用本地数据，所以数据放到本地后，MetadataService服务能否访问对服务的正常调用已经没有影响。

6、无可用服务

客户端启动时，如果从注册中心获取不到对应的服务，而且ReferenceConfig和ConsumerConfig的check属性设置为true（默认是true），那么客户端启动报错，无法启动。我们可以设置check为false，使客户端启动时不检查是否有可用服务，这样客户端便可正常启动。但是接下来的服务访问会失败，报找不到服务的错误。
启动完成后，服务端宕机的话，dubbo提供了多种集群容错策略以及Mock功能，他们都可以在服务端宕机时发挥作用。这一块可以参见文章《dubbo解析-集群容错八大Invoker实现类详解》和《dubbo解析-服务降级原理、Mock功能实现》

四、总结

1. 监控中心是否正常，对服务访问没有影响；
2. 启动时，配置中心宕机，dubbo启动失败，启动后，宕机，不影响服务调用；
3. 启动时，注册中心宕机，dubbo启动失败，启动后，宕机，不影响服务调用；
4. 启动时，元数据中心宕机，dubbo启动失败，启动后，宕机，不影响服务调用；
5. 启动时，MetadataService服务访问失败，客户端启动是否成功与check值有关，启动后，该服务正常与否，不影响服务调用；
6. 启动时，如果消费端找不到可用服务，那么消费端启动是否成功与check值有关。