1 dubbo:registry和dubbo:reference dubbo:service
dubbo:registry对应一个注册中心，每个registry都有一个id，reference和service都有一个registry的属性，这个属性就是它们对应的registry的id。
1.1 dubbo:registry的属性
id，该注册中心的id；
protocol，表示是使用zookeeper还是redis，还是其它的注册中心。
address，注册中心的ip地址和端口号。
1.2 dubbo:reference的属性
dubbo:reference是dubbo消费者引用的服务。
registry，从指定的注册中心获取服务列表，如果不设置的话，就会从所有的注册中心获取服务列表然后合并。
id，这个和服务提供方的bean id是对应的吗？是对应的，为什么要对应呢？因为在进行rpc的时候，应该需要把这个id发过去，这样就能够迅速的找到对应的服务的bean了。是这样的吗？应该是这样的，因为如果只是靠interface是不够的，因为同一个interface的话可能会有多个实现。
interface，服务的接口，这个需要和provider的对应，这个interface一般在单独的api中定义好。
check，是否在dubbo启动时就检查服务是否可用。
version，服务的版本，这个需要和服务提供者的版本一致。
filter，做一些业务无关的逻辑，比如记一些log之类的事情。
1.3 dubbo:service的属性
executes，每个服务的每个方法最大的请求并行数目。
2 dubbo:consumer和dubbo:provider
dubbo:consumer为dubbo:reference缺省值进行配置，
dubbo:provider为dubbo:service缺省值进行胚子。
3 关于consumer和provider的timeout
配置的超时以consumer的timeout为准，就是需要服务至少在该时间内返回一个结果。但是provider的timeout也是有参考意义的，因为服务的提供者知道自己的服务能够在多长时间内返回一个结果。就算是高并发情况下也应该给出一个确定的值，。
4 为什么consumer和provider都配置负载均衡
无论是在consumer还是在provider配置负载均衡，它们本质上都是一样的，因为如果是在provider端配置的负载均衡的话，会被同步到consumer端。所以，一般情况下都是在consumer端配置负载均衡。
如果在consumer不配置负载均衡的话，默认使用的是provider端配置的负载均衡，如果provider不配置负载均衡的话，默认使用的是随机策略的负载均衡，首先设置权重，然后按照权重设置随机概率，权重高的概率也就大。
5 dubbo:application
应用信息配置，比如当前应用的名字。