官方文档：https://dubbo.apache.org/zh/docs/v2.7/user/references/xml/
标签都支持自定义参数
或者
<code><dubbo:service/></code>
服务配置
用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心
<code><dubbo:reference/></code> 2
引用配置
用于创建一个远程服务代理，一个引用可以指向多个注册中心
<code><dubbo:protocol/></code>
协议配置
用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受
<code><dubbo:application/></code>
应用配置
用于配置当前应用信息，不管该应用是提供者还是消费者
<code><dubbo:module/></code>
模块配置
用于配置当前模块信息，可选
<code><dubbo:registry/></code>
注册中心配置
用于配置连接注册中心相关信息
<code><dubbo:monitor/></code>
监控中心配置
用于配置连接监控中心相关信息，可选
<code><dubbo:provider/></code>
提供方配置
当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选
<code><dubbo:consumer/></code>
消费方配置
当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选
<code><dubbo:method/></code>
方法配置
用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息
<code><dubbo:argument/></code>
参数配置
用于指定方法参数配置
以 timeout 为例，下图显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似：
方法级优先，接口级次之，全局配置再次之。
如果级别一样，则消费方优先，提供方次之。
其中，服务提供方配置，通过 URL 经由注册中心传递给消费方
建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置
理论上 ReferenceConfig 中除了<code>interface</code>这一项，其他所有配置项都可以缺省不配置，框架会自动使用
ConsumerConfig
ServiceConfig
ProviderConfig
<code>2.1.0</code> 开始支持，注意声明
引用缺省是延迟初始化的，只有引用被注入到其它 Bean，或被 <code>getBean()</code> 获取，才会初始化
如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置
配置中心（v2.7.0）在 Dubbo 中承担两个职责
外部化配置，启动配置的集中式存储 （简单理解为 dubbo.properties 的外部化存储）
服务治理，服务治理规则的存储与通知
动态配置项详解：https://dubbo.apache.org/zh/docs/v2.7/user/references/xml/dubbo-config-center/
例如zookeeper
外部化配置目的之一是实现配置的集中式管理，这部分业界已经有很多成熟的专业配置系统如 Apollo, Nacos 等
Dubbo 所做的主要是保证能配合这些系统正常工作
外部化配置和其他本地配置在内容和格式上并无区别
可以简单理解为 <code>dubbo.properties</code> 的外部化存储，配置中心更适合将一些公共配置如注册中心、元数据中心配置等抽取以便做集中管理
外部化配置默认较本地配置有更高的优先级，因此这里配置的内容会覆盖本地配置值
外部化配置有全局和应用两个级别，全局配置是所有应用共享的，应用级配置是由每个应用自己维护且只对自身可见的
当前已支持的扩展实现有Zookeeper、Apollo
默认所有的配置都存储在 <code>/dubbo/config</code> 节点，具体节点结构图如下
namespace，用于不同配置的环境隔离。
config，Dubbo约定的固定节点，不可更改，所有配置和服务治理规则都存储在此节点下。
dubbo/application，分别用来隔离全局配置、应用级别配置：dubbo是默认group值，application对应应用名
dubbo.properties，此节点的node value存储具体配置内容
所有的服务治理规则都是全局性的，默认从公共命名空间 <code>dubbo</code> 读取和订阅：
Apollo中的一个核心概念是命名空间 - namespace（和上面zookeeper的namespace概念不同），在这里全局和应用级别配置就是通过命名空间来区分的
默认情况下
Dubbo会从名叫<code>dubbo</code>（由于 Apollo 不支持特殊后缀 <code>.properties</code> ）的命名空间中读取全局配置（<code><dubbo:config-center namespace="your namespace"></code>）
由于 Apollo 也默认将会在 <code>dubbo</code> namespace 中存储服务治理规则（如路由规则），建议通过单独配置 <code>group</code> 将服务治理和配置文件托管分离开
以 XML 配置方式为例
关于文件配置托管，相当于是把 <code>dubbo.properties</code> 配置文件的内容存储在了 Apollo 中
应用通过关联共享的 <code>dubbo</code> namespace 继承公共配置, 应用也可以按照 Apollo 的做法来覆盖个别配置项
所谓 Dubbo 对配置中心的支持，本质上就是把 <code>.properties</code> 从远程拉取到本地，然后和本地的配置做一次融合
理论上只要 Dubbo 框架能拿到需要的配置就可以正常的启动，它并不关心这些配置是自己加载到的还是应用直接塞给它的
所以Dubbo还提供了以下API，让用户将自己组织好的配置塞给 Dubbo 框架（配置加载的过程是用户要完成的）
这样 Dubbo 框架就不再直接和 Apollo 或 Zookeeper 做读取配置交互。
config，Dubbo 约定的固定节点，不可更改，所有配置和服务治理规则都存储在此节点下。
dubbo，所有服务治理规则都是全局性的，dubbo 为默认节点
configurators/tag-router/condition-router，不同的服务治理规则类型，node value 存储具体规则内容
不同的规则以不同的 key 后缀区分：
configurators，覆盖规则
tag-router，标签路由
condition-router，条件路由
<b>论读书</b>
睁开眼，书在面前
闭上眼，书在心里