这个还不算完啊。。。本篇文章给各路神仙简单说下dubbo的配置这一块
dubb的属性配置文档地址
Dubbo配置文件优先级
简单案例带各路神仙理解上面的图解：
简单前提创建一个dubbo.properties(安装官方文档里面的名字…)
插一嘴：此时如果还是按照正常启动的话那么端口肯定就是20881
可以运行看下：可以看出dubbo.properties配置没有用
第二个：在配置文件中做配置，达到JVM启动配置
输入如下：
-Ddubbo.protocol.port=20880
如图：
运行看结果：
第三种：
1、把application.properties中配置的dubbo.protocol.port=20881注释掉
2、然后就是会去使用公共包里面的dubbo.protocol.port=20882端口了
这里就懒得去测试了…
Dubbo启动时的启动检查
废话不多说：大概就是但你没有启动生产端的时候去启动消费端会导致消费端启动不成功，然后小编也大概看了下里面的报错信息内容：意思就是没有可以使用的生产端
下面可以看到小编只是单独的启动了消费端。
小插曲：
存在三种配置方法，可以根据不同的场景使用不同的配置
dubbo.reference.check=false，强制更改所有引用的检查值，即使该配置具有声明，也将被覆盖。
dubbo.consumer.check=false 的默认值check。如果配置中有显式声明，例如<dubbo：reference check =“ true” />` ，则不会受到影响。
dubbo.registry.check=false，上面的两种配置是为了表示订阅成功。如果在提供者列表为空的注册失败时也允许启动订阅，则需要使用此配置。系统将定期在后台重试。
小编这里使用的dubbo.consumer.check=false 所有的消费端都不检查，因为小编使用的是注解式配置，没有dubbo.reference配置，如果只要单一的话肯定是使用dubbo.reference....
dubbo.registry.check是注册中心检查就是在没有注册中心的时候也是可以启动成功的，这些就需要各路神仙自己去测试了...
关于dubbo:reference的超时时间
这里可以看到默认使用的是dubbo:consumer里面的超时时间（里面是1秒），那么如果说响应时间超过1秒就会报错，那么我们可以通过给dubbo:reference里面设置timeout超时时间来避免问题（1000=1秒）当然那么我们使用的是注解式开发的话也是可以配置的，在dubbo:consumer里面配置timeout
这里衍生出来另外一个问题：如果同时配置了谁说了算？拳头大的说话…
以超时为例，这是从高到低的优先级（重试，负载平衡，活动对象也应用相同的规则）：
一副图片可能看不出什么东西，总结一手:
方法级别>>接口级别>>默认/全局级别。
在同一级别上，消费者的优先级高于提供者
关于dubbo:reference的重试次数
场景模拟：比如上面不可能说调用超时了就不去调用了吧？所以就可以简单理解这个重试次数了。
设置重试次数
使用条件限制： 一般来说是在幂等操作中使用重试，而在非幂等操作中是不使用重试的
幂等操作：官方的话不说，大概就是一个操作进行过一次之后，后面的每次一样的操作都不影响结果：比如说查询，删除，修改这样（删除一个数据过后再怎么删除都没有用，修改也是一样）
非幂等操作：每一次操作都是会有新的结果。比如增加...
Dubbo多版本问题
场景模拟：一个接口进行了升级，但是又不可能说直接一开始就直接全部用上去，这里就涉及到多版本问题
一般是在生产端将两个接口都进行配置并且给上不同的Version
dubbo.service.version="1.0.0" 来做以前的老版本 而新的service给一个不同的版本来做
剩下的就是在消费端来选版本使用了
dubbo.reference.version="选择版本就完事了" 也可以选择*来随机使用
相关代码示例：http://dubbo.apache.org/en-us/docs/user/demos/multi-versions.html