第三章 Dubbo高级配置

以下内容均来自,开课吧老雷,感谢老雷

第一章Dubbo概述 https://blog.csdn.net/gqs2019/article/details/115366306
第二章 Dubbo系统框架搭建 https://blog.csdn.net/gqs2019/article/details/115370178
第三章 Dubbo高级配置 https://blog.csdn.net/gqs2019/article/details/115403364
第四章 Dubbo的系统架构解析 https://blog.csdn.net/gqs2019/article/details/115456656
第五章Dubbo 的内核解析 https://blog.csdn.net/gqs2019/article/details/115457046
第六章 Dubbo的源码解析 https://blog.csdn.net/gqs2019/article/details/115460065

一、关闭服务检测

（1） 修改工程 02-consumer-zk
A、修改 ConsumerRun 类
将对消费者方法的调用语句注释掉，使消费者暂时不调用消费者方法。

B、 运行测试

运行后会报错。错误原因是检查 SomeService 的状态失败。
C、 修改配置文件
修改如下：

默认情况下，若服务消费者先于服务提供者启动，则消费者端会报错。因为默认情况下
消费者会在启动时查检其要消费的服务的提供者是否已经注册，若未注册则抛出异常。可以
在消费者端的 spring 配置文件中添加 check=”false”属性，则可关闭服务检查功能。

只要注意启动顺序，该属性看似可以不使用。但在循环消费场景下是必须要使用的。即
A 消费 B 服务，B 消费 C 服务，而 C 消费 A 服务。这是典型的循环消费。在该场景下必须至
少有一方要关闭服务检查功能，否则将无法启动任何一方。

二、多版本控制

当系统进行升级时，一般都是采用“灰度发布（又称为金丝雀发布）”过程。即在低压
力时段，让部分消费者先调用新的提供者实现类，其余的仍然调用老的实现类，在新的实现
类运行没有问题的情况下，逐步让所有消费者全部调用成新的实现类。多版本控制就是实现
灰度发布的。
（1） 创建工程
复制前面的提供者工程 02-provider-zk，并更名为 04-provider-version。
（2） 定义两个接口实现类
删除原来的 SomeServiceImpl 类，并新建两个实现类


（3） 修改配置文件
指定版本 0.0.1 对应的是 oldService 实例，而版本 0.0.2 对应的是 newService 实例。

消费者可以指定版本

三、服务分组

服务分组与多版本控制的使用方式几乎是相同的，只要将 version 替换为 group 即可。
但使用目的不同。使用版本控制的目的是为了升级，将原有老版本替换掉，将来不再提供老
版本的服务，所以不同版本间不能出现相互调用。而分组的目的则不同，其也是针对相同接
口，给出了多种实现类。但不同的是，这些不同实现并没有谁替换掉谁的意思，是针对不同
需求，或针对不同功能模块所给出的不同实现。这些实现所提供的服务是并存的，所以它们
间可以出现相互调用关系。例如，对于支付服务的实现，可以有微信支付实现与支付宝支付
实现等。
（1） 创建工程
复制前面的提供者工程 04-provider-version，并更名为 05-provider-group。
（2） 定义两个接口实现类
删除原来的两个接口实现类，重新定义两个新的实现类。



消费者

四、多协议支持

除了 Dubbo 服务暴露协议 Dubbo 协议外，Dubbo 框架还支持另外 8 种服务暴露协议：
RMI 协议、Hessian 协议、HTTP 协议、WebService 协议、Thrift 协议、Memcached 协议、Redis
协议、Rest 协议。但在实际生产中，使用最多的就是 Dubbo 服务暴露协议。
各个协议的特点:大数据小并发用短连接协议，小数据大并发用长连接协议。
（1） dubbo 协议
? Dubbo 默认传输协议
? 连接个数：单连接
? 连接方式：长连接
? 传输协议：TCP
? 传输方式：NIO 异步传输
? 适用范围：传入传出参数数据包较小（建议小于 100K），消费者比提供者个数多，单一
消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。
（2） rmi 协议
? 采用 JDK 标准的 java.rmi.* 实现
? 连接个数：多连接
? 连接方式：短连接
? 传输协议：TCP
? 传输方式：BIO 同步传输
? 适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
（3） hession 协议
? 连接个数：多连接
? 连接方式：短连接
? 传输协议：HTTP
? 传输方式：BIO 同步传输
? 适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者抗压能力较大，
可传文件
（4） http 协议
? 连接个数：多连接
? 连接方式：短连接
? 传输协议：HTTP
传输方式：BIO 同步传输
? 适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，
可用表单或 URL 传入参数，暂不支持传文件。
（5） webService 协议
? 连接个数：多连接
? 连接方式：短连接
? 传输协议：HTTP
? 传输方式：BIO 同步传输
? 适用场景：系统集成，跨语言调用
（6） thrift 协议
Thrift 是 Facebook 捐给 Apache 的一个 RPC 框架，其消息传递采用的协议即为 thrift
协议。当前 dubbo 支持的 thrift 协议是对 thrift 原生协议的扩展。Thrift 协议不支持 null
值的传递。
（7） memcached 协议与 redis 协议
它们都是高效的 KV 缓存服务器。它们会对传输的数据使用相应的技术进行缓存。
（8） rest 协议
若需要开发具有 RESTful 风格的服务，则需要使用该协议。

同一服务支持多种协议:
对于多协议的用法有两种，一种是同一个服务支持多种协议，一种是不同的服务使用不
同的协议。首先来看“同一服务支持多种协议”的用法。
（1） 修改提供者配置文件
直接在 04-provider-version 工程中进行修改。
在提供者中要首先声明新添加的协议，然后在服务dubbo:service/标签中再增加该新
的协议。若不指定，默认为 dubbo 协议。

这里需要理解这个服务暴露协议的意义。其是指出，消费者若要连接当前的服务，就需
要通过这里指定的协议及端口号进行访问。这里的端口号可以是任意的，不一定非要使用默
认的端口号（Dubbo 默认为 20880，rmi 默认为 1099）。这里指定的协议名称及端口号，在
当前服务注册到注册中心时会一并写入到服务映射表中。当消费者根据服务名称查找到相应
主机时，其同时会查询出消费此服务的协议、端口号等信息。其底层就是一个 Socket 编程，
通过主机名与端口号进行连接。
（2） 修改消费者配置文件
直接在 04-consumer-version 工程中进行修改。
在消费者引用服务时要指出所要使用的协议。

（3） 应用场景
“同一服务支持多种协议”的应用场景是：系统在使用过程中其使用场景逐渐发生了变
化，例如，由原来的消费者数量多于提供者数量，变为了消费者数量与提供者数量差不多了，
并且原来系统不用传输文件，现在的系统需要传输文件了。此时就将将原来默认的 dubbo
协议更换为 rmi 协议。目的是为了兼容老工程，扩展新功能。

不同服务使用不同协议
（1） 应用场景
同一个系统中不同的业务具有不同的特点，所以它们的传输协议就应该根据它们的特点
选择不同的协议。
例如对于前面使用服务分组实现的“微信支付”与“支付宝支付”，就可以针对不同的
支付方式，使用不同的协议。
（2） 修改提供者配置文件
直接在 05-provider-group 工程中进行修改。
首先要修改服务提供者配置文件：声明所要使用的协议；在使用dubbo:service/暴露
服务时通过 protocal 属性指定所要使用的服务协议。

（3） 修改消费者配置文件
直接在 05-consumer-group 工程中进行修改。
然后在消费者端通过dubbo:reference/引用服务时通过添加 protocal 属性指定要使用
的服务协议。

五、负载均衡

搭建负载均衡环境:
该负载均衡中同一服务会有三个提供者，它们均复制于原来的 02-provider-zk。消费者
不用变。
（1） 复制提供者 02-provider-zk01
A、创建工程
复制前面的 02-provider-zk 工程，并重命名为 02-provider-zk01。
B、 修改配置文件


（2） 复制提供者 02-provider-zk02
A、创建工程
复制前面的 02-provider-zk01 工程，并重命名为 02-provider-zk02。
B、 修改配置文件


（3） 复制提供者 02-provider-zk03
A、创建工程
复制前面的 02-provider-zk01 工程，并重命名为 02-provider-zk03。
B、 修改配置文件


负载均衡算法:
若消费者与提供者均设置了负载均衡策略，消费者端设置的优先级高。
若消费者端没有显式的设置，但提供者端显式的设置了，且同一个服务（接口名、版本
号、分组都相同）的负载均衡策略相同。消费者调用时会按照提供者设置的策略调用。
若多个提供者端设置的不相同，则最后一个注册的会将前面注册的信息覆盖。
（1） Dubbo 内置的负载均衡算法
Dubbo 内置了四种负载均衡算法。
A、random
随机算法，是 Dubbo 默认的负载均衡算法。存在服务堆积问题。
B、 roundrobin
轮询算法。按照设定好的权重依次进行调度。
C、 leastactive
最少活跃度调度算法。即被调度的次数越少，其优选级就越高，被调度到的机率就越高。
D、consistenthash
一致性 hash 算法。对于相同参数的请求，其会被路由到相同的提供者。
（2） 指定负载均衡算法
负载均衡算法可以在消费者端指定，也可以在提供者端指定。
A、消费者端指定

B、 提供者端指定

六、集群容错

集群容错指的是，当消费者调用提供者集群时发生异常的处理方案。
Dubbo 内置了 6 种集群容错策略。
（1） Failover
故障转移策略。当消费者调用提供者集群中的某个服务器失败时，其会自动尝试着调用
其它服务器。该策略通常用于读操作，例如，消费者要通过提供者从 DB 中读取某数据。但
重试会带来服务延迟。
（2） Failfast
快速失败策略。消费者端只发起一次调用，若失败则立即报错。通常用于非幂等性的写
操作，比如新增记录。
幂等：在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相
同
GET 请求：幂等
POST 请求：非幂等
PUT 请求：幂等
DELETE 请求：幂等
（4） Failback
失败自动恢复策略。消费者调用提供者失败后，Dubbo 会记录下该失败请求，然后定时
自动重新发送该请求。该策略通常用于实时性要求不太高的服务，例如消息通知操作。
（5） Forking
并行策略。消费者对于同一服务并行调用多个提供者服务器，只要一个成功即调用结束
并返回结果。通常用于实时性要求较高的读操作，但其会浪费较多服务器资源。
（6） Broadcast
广播策略。广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有
提供者更新缓存或日志等本地资源信息。

1.配置集群容错策略

容错策略可以设置在消费者端，也可以设置在提供者端。若消费者与提供者均做了设置，
则消费者端的优先级更高。
（1） 设置重试次数
Dubbo 默认的容错策略是故障转移策略 Failover，即允许失败后重试。可以通过如下方
式来设置重试次数，注意设置的是重试次数，不含第一次正常调用。
A、提供者端设置

B、 消费者端设置

（2） 容错策略设置
A、提供者端

B、 消费者端

七、服务降级

1.服务降级基础（面试题）

（1） 什么是服务降级
服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务有策略的
降低服务级别，以释放服务器资源，保证核心任务的正常运行。例如，双 11 时 0 点-2 点期
间淘宝用户不能修改收货地址，不能查看历史订单，就是典型的服务降级。
（2） 服务降级方式
能够实现服务降级方式很多，常见的有如下几种情况：
? 部分服务暂停：页面能够访问，但是部分服务暂停服务，不能访问。
? 部分服务延迟：页面可以访问，当用户提交某些请求时系统会提示该操作已成功提交给
了服务器，由于当前服务器繁忙，此操作随后会执行。在等待了若干时间后最终用户可
以看到正确的执行结果。
? 全部服务暂停：系统入口页面就不能访问，提示由于服务繁忙此服务暂停。跳转到一个
预先设定好的静态页面。
? 随机拒绝服务：服务器会按照预先设定好的比例，随机挑选用户，对其拒绝服务。作为
用户，其看到的就是请重试。可能再重试就可获得服务。
（3） 整个系统的服务降级埋点

（4） 服务降级与 Mock 机制
Dubbo的服务降级采用的是mock机制。其具有两种降级处理方式：Mock Null降级处理，
与 Class Mock 降级处理。

2.Mock Null 服务降级处理 06-consumer-downgrade

（1） 创建消费者工程
直接复制 02-consumer-zk 工程，并命名为 06-consumer-downgrade。
（2） 定义接口

（3） 修改 pom 文件
由于这里不再需要 00-api 工程了，所以在 pom 文件中将对 00-api 工程的依赖删除即可。
（4） 修改 spring-consumer.xml

（5） 修改消费者启动类

3.Class Mock 服务降级处理 06-consumer-downgrade2

（1） 创建消费者工程
本例直接在前面的例子基础上进行修改。
（2） 定义 Mock Class
在业务接口所在的包中，本例为 com.abc.service 包，定义一个类，该类的命名需要满足
以下规则：业务接口简单类名 + Mock。

八、服务调用超时

前面的服务降级的发生，其实是由于消费者调用服务超时引起的，即从发出调用请求到
获取到提供者的响应结果这个时间超出了设定的时限。默认服务调用超时时限为 1 秒。可以在消费者端与提供者端设置超时时限.
创建提供者工程 06-provider-timeout:
1） 创建工程
复制 02-provider-zk 工程，并重命名为 06-provider-timeout。
（2） 修改依赖
由于这里不再需要 00-api 工程了，所以在 pom 文件中将对 00-api 工程的依赖删除即可。
（3） 定义接口
在 com.abc.service 包中定义如下接口。

（4） 定义接口实现类
在 com.abc.provider 包中定义接口的实现类。该实现类中的业务方法添加一个 2 秒的
Sleep，以延长向消费者返回结果的时间。

创建消费者工程 06-consumer-timeout:
（1） 创建工程
复制 06-consumer-downgrade2 工程，并重命名为 06-consumer-timeout。
（2） 添加日志文件
在 src/main/resources 下添加 log4j.properties 文件。

九、服务限流

为了防止某个消费者的 QPS 或是所有消费者的 QPS 总和突然飙升而导致的重要服务的
失效，系统可以对访问流量进行控制，这种对集群的保护措施称为服务限流。
Dubbo 中能够实现服务限流的方式较多，可以划分为两类：直接限流与间接限流。
? 直接限流：通过对连接的数量直接限制来达到限流的目的。超过限制则会让再来的请求
等待，直到等待超时，或获取到相应服务（官方方案）。
? 间接限流：通过一些非连接数量设置的间接手段来达到限流的目的（个人经验

1.直接限流

（1） executes 限流—仅提供者端
该属性仅能设置在提供者端。可以设置为接口级别，也可以设置为方法级别。对指定服
务（方法）的连接数量进行限制。


（2） accepts 限流—仅提供者端
该属性仅可设置在提供者端的dubbo:provider/与dubbo:protocol/，是针对指定协议
的连接数进行限制。


（3） actives 限流—两端均可
该限流方式与前两种不同的是，其可以设置在提供者端，也可以设置在消费者端。可以
设置为接口级别，也可以设置为方法级别。
A、提供者端限流
根据客户端与服务端建立的连接是长连接还是短连接，其意义不同：
? 长连接：当前这个服务上的一个长连接最多能够处理的请求个数。对长连接数量没
有限制。
? 短连接：当前这个服务上可以同时处理的短连接数量。

B.消费者端限流
根据客户端与服务端建立的连接是长连接还是短连接，其意义不同：
? 长连接：当前这个消费者的一个长连接最多能够提交的请求个数。对长连接数量没
有限制。
? 短连接：当前这个消费者可以同时提交的短连接数量。


（4） connections 限流—两端均可
可以设置在提供者端，也可以设置在消费者端。限定连接的个数。
一般情况下，我们使用的都是默认的服务暴露协议 Dubbo，所以，一般会让 connections
与 actives 联用。connections 限制长连接的数量，而 actives 限制每个长连接上的请求数量。

2.间接限流

（1） 延迟连接
只要消费者真正调用提供者方法时才创建长连接。
仅可设置在消费者端，且不能设置为方法级别。仅作用于 Dubbo 服务暴露协议。用于
减少长连接数量。

（2） 粘连连接
系统会尽量让同一个消费者调用同个提供者。其可以限定流向。
仅能设置在消费者端，其可以设置为接口级别，也可以设置为方法级别。仅作用于
Dubbo 服务暴露协议。用于减少长连接数量。粘连连接的开启将自动开启延迟连接。


（3） 负载均衡
可以设置在消费者端，亦可设置在提供者端；可以设置在接口级别，亦可设置在方法级
别。其可以限定流向，但其没有限制了流量。

十、声明式缓存

为了进一步提高消费者对用户的响应速度，减轻提供者的压力，Dubbo 提供了基于结果
的声明式缓存。该缓存是基于消费者端的，所以使用很简单，只需修改消费者配置文件，与
提供者无关。该缓存是缓存在消费者端内存中的，一旦缓存创建，即使提供者宕机也不会影
响消费者端的缓存

当然，若一个接口中只有部分方法需要缓存，则可使用方法级别的缓存。

声明式缓存中可以缓存多少个结果呢？默认可以缓存 1000 个结果。若超出 1000，将采
用 LRU 策略来删除缓存，以保证最热的数据被缓存。注意，该删除缓存的策略不能修改。
直接在 07-consumer-cache 工程中创建 ConsumerRun2 类即可。

十一、多注册中心

同一个服务注册到不同的中心，使用逗号进行分隔

对于消费者工程，用到哪个注册中心了，就声明哪个注册中心，无需将全部注册中心进
行声明。

十二、单功能注册中心

仅订阅
（1） 概念
对于某服务来说，其可以发现和调用注册中心中的其它服务，但不能被其它服务发现和
调用，这种情形称为仅订阅。
仅可去发现，但不能被发现。
即可以从注册中心下载服务注册表，但其不会将当前配置文件中的服务写入到注册中心
的服务注册表。
（2） 设置方式
对于“仅订阅”注册中心的实现，只需修改提供者配置文件，在dubbo:registry/标签
中添加 register=”false”属性。即对于当前服务来说，注册中心不再接受其注册，但该服务可
以通过注册中心去发现和调用其它服务。

仅注册
（1） 概念
对于某服务来说，其可以被注册中心的其它服务发现和调用，但不能发现和调用注册中
心中的其它服务，这种情形称为仅注册。
仅可被发现，但不能去发现。
（2） 设置方式
对于“仅注册”注册中心的实现，只需修改提供者配置文件，在dubbo:registry/标签
中添加 subscribe=”false”的属性。即对于当前服务来说，注册中心中的其它服务可以发现和
调用当前服务，但其不能发现和调用其它服务。

十三、服务暴露延迟

如果我们的服务启动过程需要 warmup 事件，就可以使用 delay 进行服务延迟暴露。只
需在服务提供者的dubbo:service/标签中添加 delay 属性。其值可以有三类：
? 正数：单位为毫秒，表示在提供者对象创建完毕后的指定时间后再发布服务。
? 0：默认值，表示当前提供者创建完毕后马上向注册中心暴露服务。
? -1：表示在 Spring 容器初始化完毕后再向注册中心暴露服务。

十四、消费者异步调用

应用场景:
Dubbo 简介时，我们分析了 Dubbo 的四大组件工作原理图，其中消费者调用提供者
采用的是同步调用方式。其实，消费者对于提供者的调用，也可以采用异步方式进行调用。
异步调用一般应用于提供者提供的是耗时性 IO 服务。

Future 异步执行原理
异步方法调用执行原理如下图所示，其中实线为同步调用，而虚线为异步调用。
? UserThread：消费者线程
? IOThrea：提供者线程
? Server：对 IO 型操作的真正执行者

Future 异步调用
（1） 创建提供者 10-provider-async
A、创建工程
直接复制 02-provider-zk 工程，并命名为 10-provider-async。
B、 定义业务接口




D、修改配置文件

创建消费者 10-consumer-async
A、创建工程
直接复制 02-consumer-zk 工程，并命名为 10-consumer-async。

C、 修改配置文件

D、定义同步消费者类 ConsumerRunSync

E、 定义异步消费者类 ConsumerRunAsync

F、 定义异步消费者类 ConsumerRunAsync2

CompletableFuture 异步调用
使用 Future 实现异步调用，对于无需获取返回值的操作来说不存在问题，但消费者若
需要获取到最终的异步执行结果，则会出现问题：消费者在使用 Future 的 get()方法获取返
回值时被阻塞。为了解决这个问题，Dubbo 又引入了 CompletableFuture 来实现对提供者的
异步调用。
（1） 创建提供者 10-provider-async2
A、创建工程
直接复制 10-provider-async 工程，并命名为 10-provider-async2。
B、 修改业务接口
需要异步调用执行的方法返回 CompletableFuture<>。

C、 修改实现类



（2） 创建消费者 10-consumer-async2
A、创建工程
直接复制 10-consumer-async 工程，并命名为 10-consumer-async2。
B、 修改业务接口

C、 修改消费者类
直接删除同步消费者类，修改异步消费者类。


D、修改配置文件

总结
Futrue 与 CompletableFuture 的区别与联系：
对于消费者不用获取提供者所调用的耗时操作结果的情况，使用 Future 与
CompletableFuture 效果是区别不大的。但对于需要获取返回值的情况，它们的区别是很大
的。
? Future：源自于 JDK5，Dubbo2.7.0 之前使用 Future 实现消费者对提供者的异步调用。通
过 Future 的 get()获取返回结果，get()方法会阻塞，不好。
? CompletableFuture：源自于 JDK8，Dubbo2.7.0 之后使用 Future 实现消费者对提供者的
异步调用。通过 CompletableFutrue 的回调获取返回结果，不会发生阻塞，好用。

十五、提供者的异步执行

从前面“对提供者的异步调用”例子可以看出，消费者对提供者实现了异步调用，消费
者线程的执行过程不再发生阻塞，但提供者对 IO 耗时操作仍采用的是同步调用，即 IO 操作
仍会阻塞 Dubbo 的提供者线程。
但需要注意，提供者对 IO 操作的异步调用，并不会提升 RPC 响应速度，因为耗时操作
终归是需要消耗那么多时间后才能给出结果的
创建提供者 10-provider-async3
（1） 创建工程
直接复制 10-provider-async2 工程，并命名为 10-provider-async3
（2） 修改实现类

十六、Spring Boot中使用dubbo

1定义 commons 工程 11-dubboCommons

（1） 创建工程
这里就创建一个普通的 Maven 的 Java 工程，并命名为 11-dubboCommons。
（2） 定义 pom 文件

（3） 定义实体类

（4） 定义业务接口

（5） 将工程安装到本地库
运行 Maven 的 install 命令，将工程安装到本地版本库，以备其它工程使用。

2.定义提供者 11-provider-springboot

（1） 创建工程
创建一个 Spring Boot 工程，并重命名为 11-provider-springboot。
（2） 定义 pom 文件
A、添加 dubbo 与 spring boot 整合依赖
B、 添加 zkClient 依赖
C、 其它依赖
? dubboCommons 依赖
? spring boot 与 redis 整合依赖
? mybatis 与 spring boot 整合依赖
? 数据源 Druid 依赖
? mysql 驱动依赖
? slf4j-log4j12 依赖
? spring-boot-starter-web 依赖
（3） 定义 Service 实现类

（4） 定义 Dao 接口

（5） 定义映射文件

（6） 修改启动类
在启动类上必须要添加@EnableDubboConfiguration 注解，开启 Dubbo 的自动配
置功能。

（7） 修改主配置文件

server:
 port: 8888
mybatis:
 # 注册 mybatis 中实体类的别名
 type-aliases-package: com.abc.bean
 # 注册映射文件
  mapper-locations: classpath:com/abc/dao/*.xml
spring:
 # 注册数据源
 datasource:
 # 指定数据源类型为 Druid
 type: com.alibaba.druid.pool.DruidDataSource
 driver-class-name: com.mysql.jdbc.Driver
 url: jdbc:mysql:///test?useUnicode=true&characterEncoding=utf8
 username: root
 password: 111
 # 连接 Redis 服务器
 redis:
 host: redis5OS
 port: 6379
 password: 111
 # 连接 Redis 高可有集群
 # redis:
 # sentinel:
 # master: mymaster
 # nodes:
 # - sentinelOS1:26379
 # - sentinelOS2:26379
 # - sentinelOS3:26379
 # 配置缓存
 cache:
 type: redis # 指定缓存类型
 cache-names: realTimeCache # 指定缓存区域名称
 # 功能等价于 spring-dubbo 配置文件中的<dubbo:application/>
 # 该名称是由服务治理平台使用
 application:
 name: 11-provider-springboot
 # 指定 zk 注册中心
 dubbo:
 registry: zookeeper://zkOS:2181
 # zk 集群作注册中心
 # registry: zookeeper://zkOS1:2181?backup=zkOS2:2181,zkOS3:2181

3.定义消费者 11-consumer-springboot

（1） 创建工程
创建一个 Spring Boot 工程，并重命名为 11-consumer-springboot。
（2） 定义 pom 文件
? dubbo 与 spring boot 整合依赖
? zkClient 依赖
? dubboCommons 依赖
? JSP 引擎 jasper 依赖
? slf4j-log4j12 依赖
? spring-boot-starter-web 依赖
（3） 修改主配置文件

spring:
 # 功能等价于 spring-dubbo 配置文件中的<dubbo:application/>
 application:
 name: 11-consumer-springboot
 # 指定 zk 注册中心
 dubbo:
 registry: zookeeper://zkOS:2181
 # zk 集群作注册中心
 # registry: zookeeper://zkOS1:2181?backup=zkOS2:2181,zkOS3:2181

4） 创建 index.jsp 页面
在 src/main/webapp 目录下定义 index.jsp 文件。

（5） 定义处理器


（6） 定义 welcome.jsp 页面
在 src/main/webapp 目录下定义 welcome.jsp 文件。

（7） 修改入口类

十七、属性配置优先级

Dubbo 配置文件中各个标签属性配置的优先级总原则是：
? 方法级优先，接口级(服务级)次之，全局配置再次之。
? 如果级别一样，则消费方优先，提供方次之。
另外，还有两个标签需要说明一下：
? dubbo:consumer/设置在消费者端，用于设置消费者端的默认配置，即消费者端的全
局设置。
? dubbo:provider/设置在提供者端，用于设置提供者端的默认配置，即提供者端的全局
配置。

十八、配置建议

? Provider 端要配置合理的 Provider 端属性
? Provider 端上尽量多配置 Consumer 端属性

以下内容均来自,开课吧老雷,感谢老雷
第一章Dubbo概述 https://blog.csdn.net/gqs2019/article/details/115366306
第二章 Dubbo系统框架搭建 https://blog.csdn.net/gqs2019/article/details/115370178
第三章 Dubbo高级配置 https://blog.csdn.net/gqs2019/article/details/115403364
第四章 Dubbo的系统架构解析 https://blog.csdn.net/gqs2019/article/details/115456656
第五章Dubbo 的内核解析 https://blog.csdn.net/gqs2019/article/details/115457046
第六章 Dubbo的源码解析 https://blog.csdn.net/gqs2019/article/details/115460065