前言
本文将介绍 Dubbo 的两个重要功能：属性加载顺序与启动时检查。
属性加载顺序
覆盖策略
在应用启动阶段，Dubbo 会如何读取配置呢？举个例子，我们知道 Dubbo 支持多层级的配置，并会按预定优先级自动实现配置间的覆盖，那么假如我们在通过虚拟机参数对 Dubbo 进行配置的同时，又通过本地配置文件 dubbo.properties 配置，到底会优先采取哪一种配置呢？这个是 Dubbo 的属性加载顺序需要解决的问题。
Dubbo 支持四种配置来源，分别如下：
- JVM 虚拟机参数的配置方式，通过 -D 参数进行配置
- 通过 dubbo.xml （等同于 Spring Boot 中的 application.properties/application.yml）的方式进行配置，也就是外部化配置
- 通过编程接口进行相应的配置
- 通过本地配置文件 dubbo.properties 来进行配置
Dubbo 官方文档的图也展示了这四种配置来源的优先级，从上到下，优先级是依次降低的。
总结
若有 JVM 虚拟机参数传入，以虚拟机参数为优先，否则以自定义的 dubbo.xml 文件优先，若 dubbo.xml 没有定义相关的属性，以编程接口为优先，最后，若前面都没有进行相应的定义，以本地配置文件 dubbo.properties 为准。
配置方式
- 我们可以将公共配置，例如应用程序名字，注册中心地址之类的。配置在本地配置文件 dubbo.properties 中
- 将需要额外改变的配置，配置在自定义的 dubbo.xml 配置文件中
- 将需要临时改变的配置，在启动时通过传入 JVM 虚拟机参数进行配置
启动时检查
什么是启动时检查
Dubbo 在启动时会检查依赖的服务是否可用，如果不可用，会抛出异常，所以默认启动时检查设置为 true。
我们也可以通过设置启动时检查为 false 来关闭检查，适用的场景为对某些服务不关心，以及出现循环依赖需要有一方先启动的场景。
另外，如果 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果启动时检查为 false，总是会返回引用，当服务恢复时，能自动连上。
测试
我们只启动消费者，不启动提供者，由于启动时检查默认为 true，消费者启动时发现依赖的服务不可用，会抛出异常。测试如下：
我们将启动时检查设置为 false，在配置文件中添加如下配置：
#关闭所有服务的启动时检查
dubbo.consumer.check=false
然后我们重新启动消费者，发现这次在启动时不会抛出异常了。
然后我们远程调用提供者提供的方法，发现在调用的时候才会抛出异常。
除了关闭所有服务的启动时检查，我们还可以关闭注册中心启动时检查以及关闭某个服务的启动时检查，具体配置可以参考官方文档。
