Dubbo（二）：Dubbo 基础配置Xml、注解方式 和 高级

选项参数配置类: java.util.Map

说明:该标签为或或或或的子标签，用于配置自定义参数，该配置项将作为扩展点设置自定义参数使用

• key : 路由参数键
• value : 路由参数键

ApplicationConfig、ProtocolConfig 、 RegistryConfig、Service、Reference

• @EnableDubbo: 开启注解 Dubbo 功能 ，其中可以加入 scanBasePackages 属性配置包扫描的路径，用于扫描并 注册 bean。其中封装了组件 @DubboComponentScan，来扫描 Dubbo @Service 注解暴露 Dubbo 服务，以及 扫描Dubbo @Reference字段或者方法注入Dubbo服务代理。

其它 Dubbo 三种公共信息的配置，有两种方式，根据自己喜好选用

@Configuration
@EnableDubbo(scanBasePackages = ".dubbo.demo.service") 
class ProviderConfiguration {
 
 @Bean
 public ApplicationConfig applicationConfig() {
  ApplicationConfig applicationConfig = ne ApplicationConfig(); 
  applicationConfig.setName("busi-provider");
  return applicationConfig;
 }

 @Bean
 public RegistryConfig registryConfig() {
  RegistryConfig registryConfig = ne RegistryConfig(); 
  registryConfig.setProtocol("zookeeper"); 
  registryConfig.setAddress("192.168.0.128"); 
  registryConfig.setPort(2181);
  return registryConfig; 
 }

 @Bean
 public ProtocolConfig protocolConfig() {
  ProtocolConfig protocolConfig = ne ProtocolConfig();
  protocolConfig.setName("dubbo"); 
  protocolConfig.setPort(20880); 
  return protocolConfig;
 } 
}

• Property 方式: 使用 Springboot 属性文件方式，由 Dubbo 自动将文件信息配置入容器，示例 如下:

@Configuration
@EnableDubbo(scanBasePackages = ".dubbo.demo.service") 
@PropertySource("classpath:/dubbo-provider.properties") 
static class ProviderConfiguration {
}

dubbo.application.name=busi-provider 
dubbo.registry.address=zookeeper://192.168.0.128:2181 
dubbo.protocol.name=dubbo
dubbo.protocol.port=20880

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻 止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check=“true”

可以通过 check="false"关闭检查，比如，测试时，有些服务不关心，或者出 现了循环依赖，必须有一方先启动

，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务， 请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check=“false”，总是会返回引用，当服务恢复时，能自动连上

• 关闭某个服务的启动时检查(没有提供者时报错):
• 关闭所有服务的启动时检查(没有提供者时报错):
• 关闭注册中心启动时检查(注册订阅失败时报错):

Dubbo 消费端在发出请求后，需要有一个临界时间界限来判断服务端是否正常。这样消费端达到超 时时间，那么 Dubbo 会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题， 需要合理设置接口超时时间
Dubbo 超时和重试配置示例:

在服务提供者和服务消费者上都可以配置服务超时时间，这两者是不一样的。

消费者调用一个服务，分为三步

1. 消费者发送请求（网络传输）
2. 服务端执行服务
3. 服务端返回响应（网络传输）

如果在服务端和消费端只在其中一方配置了timeout，那么没有歧义，表示消费端调用服务的超时时间，消费端如果超过时间还没有收到响应结果，则消费端会抛超时异常，但，服务端不会抛异常，服务端在执行服务后，会检查执行该服务的时间，如果超过timeout，则会打印一个超时日志。服务会正常的执行完。

如果在服务端和消费端各配了一个timeout，那就比较复杂了，假设

1. 服务执行为5s
2. 消费端timeout=3s
3. 服务端timeout=6s

那么消费端调用服务时，消费端会收到超时异常（因为消费端超时了），服务端一切正常（服务端没有超时）。

Dubbo 在调用服务不成功时，默认会重试 2 次

Dubbo 的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 Dubbo 的重试机制也能一定程度的保证服务的质量

当消费端某次调用失败是一些环境偶然因素造成的(如网络抖动)，dubbo 还给予了容错补救机会。补救方式存在以下几种

1、 Failover :当出现失败，重试其它服务器。 retries=“2” 来设置重试次数(不含第一次)。
幂等性操作使用，如读操作
2、 Failfast :快速失败，只发起一次调用，失败立即报错
非幂等性操作，如写操作
3、 Failsafe :出现异常时，直接忽略
无关紧要的旁支操作，如打日志
4、 Failback :后台记录失败请求，定时重发
后续专业处理
5、 Forking :并行调用多个服务器，只要一个成功即返回
forks=“2” 来设置最大并行数

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。 可以自行扩展负载均衡策略

1、 Random :按权重随机------根据eight值(服务方设置)来随机
2、 RoundRobin :轮询
3、 LeastActive :最少活跃数(正在处理的数)，慢的机器，收到的请求少

dubbo 对方法调用的结果，还有缓存功能。

在服务消费方和提供方都可以配置使用缓存。

以消费方为例，可以配置全局缓存策略，这样所有服务引用都启动缓存

还可以仅对某个服务引用配置缓存策略

还支持对单个方法启用缓存策略

服务方配置方法与消费端完全一样

比如，想在同一个注册中心中，分隔测试和开发环境(省一套注册服务)

只要 group 按开发组和测试组对应，同一个注册中心里的两套服务就互不干扰

服务端提供接口的实现升级时，可由 dubbo 的版本号操作进行过渡。如果上线上测试新版本接口有缺陷，为了不影响业务，要迅速切回原版本接口，最大程度减少损失。
服务方:

消费方:

场景:我们在本地开发的时候，不能把自己机器的未开发好的服务注册到开发环境，又需要使 用注册中心的其他服务
服务提供者配置禁止注册 register=“false”

比如开发环境为了省机器，没有部署某个服务，如短信/邮件功能。但整个系统又必须要调用它。此时我们可以借用一下测试环境的此服务(不能影响测试环境原本的服务闭环)。将测试环境的短信/邮件服务也向开发环境注册一份，只注册(其依赖的服务必须还是测试环境的)
服务提供者配置禁止订阅 subscribe=“false”

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/async-call/

理解起来比较容易，主要要理解CompletableFuture，如果不理解，就直接把它理解为Future

其他异步调用方式https://mp.eixin.qq./s/U3eyBUy6HBVy-xR3LGbRQ

Dubbo 的异步调用是非阻塞的 NIO 调用，一个线程可并发调用多个远程服务，每个服务的调用都是非阻塞的，线程立即返回。就是对 java 中 Futrue 模式的扩展支持

如上图，userThread 发出调用后，IOThread 会立即返回，并在 RPC 上下文 RpcContext 中设置 Future。userThread 后续可以从 RpcContext 中取得此 Future， 然后 ait 这个 Future 其它的事情都由 IOThread 完成。
，userThread 发出调用后 IOThread 会立刻返回，而不是等调用在服务端 执行完代码、返回结果后返回。用户返回后可以去做点其它事情，比如调用 一个服务，然后回头等待前一个调用完成。从上图可以看出，异步调用 完全是 Consumer 端的行为。

配置:

async=true 表示异步调用，可以看到配置发生在 Consumer 端，能精确到方法。

方法异步调用后，Consumer 端的代码写法:

// 此方法异步后不再有返回值，会立刻返回 NULL 
xxxService.doSomething(xxx);

// 立刻得到当前调用的 Future 实例，当发生新的调用时这个东西将会被覆盖
Future xxxFuture = RpcContext.getContext().getFuture();

// 等待调用完成，线程会进入 Sleep 状态，当调用完成后被唤醒。 
Foo foo = fooFuture.get();

配置是否等待 IOThread 发送完 Request 后再返回:

• sent=“true”，等待请求发送出去后再返回，如果发送失败直接抛出异常。
• sent=“false”，将调用交给IOThread后立即返回。实际这个时候请求进
  入到 IOThread 的队列，排除等着被发送出去。

如果对返回结果没有兴趣:

对于一次远程方法调用，有 oninvoke、onreturn、onthro 三个事件，分别为调用之前、返回之后， 抛出异常三个事件。

在 Consumer 端，可以为三个事件指定事件处理方法。

，需要在 SpringIOC 容器中，创建一个实现了回调接口的 Bean, 假设 id=callback

interface Callback {
	public void onreturn(Person msg, Integer id); 
	public void onthro(Throable ex, Integer id);
}

方法中，第一个参数是远程方法的返回值，其它是方法的参数。

然后在 Dubbo 中配置:

配置中 async 与 onreturn、onthro 是成对配置，组合不同，功能也不同:

• 异步回调模式: async=true onreturn=“xxx”
• 同步回调模式: async=false onreturn=“xxx”
• 异步无回调 : async=true
• 同步无回调 : async=false

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/callback-parameter/

官网上的Demo其实太复杂，可以看课上的Demo更为简单。

，如果当前服务支持参数回调，意思就是对于某个服务接口中的某个方法，如果想支持消费者在调用这个方法时能设置回调逻辑，那么该方法就需要提供一个入参用来表示回调逻辑。

因为Dubbo协议是基于长连接的，所以消费端在两次调用同一个方法时想指定不同的回调逻辑，那么就需要在调用时在指定一定key进行区分。

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/local-mock/

本地伪装就是Mock，Dubbo中Mock的功能相对于本地存根更简单一点，Mock其实就是Dubbo中的服务容错的解决方案。

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/local-stub/

本地存根，名字很抽象，但实际上不难理解，本地存根就是一段逻辑，这段逻辑是在服务消费端执行的，这段逻辑一般都是由服务提供者提供，服务提供者可以利用这种机制在服务消费者远程调用服务提供者之前或之后再做一些其他事情，比如结果缓存，请求参数验证等等。

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/fault-tolerent-strategy/

集群容错表示服务消费者在调用某个服务时，这个服务有多个服务提供者，在经过负载均衡后选出其中一个服务提供者之后进行调用，但调用报错后，Dubbo所采取的后续处理策略。

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/service-dongrade/

服务降级表示服务消费者在调用某个服务提供者时，如果该服务提供者报错了，所采取的措施。

集群容错和服务降级的区别在于

1. 集群容错是整个集群范围内的容错
2. 服务降级是单个服务提供者的自身容错

Dubbo 的属性配置优先度上，遵循如下顺序: reference属性 》 service属性 》 consumer属性

其中 reference 和 consumer 是消费端配置，service 是服务端配置

而对于服务调用的超时时间、重试次数等属性，服务的提供方比消费方更了解服务性能，我们应该在 Provider 端尽量多配置 Consumer 端属性， 让其漫游到消费端发挥作用。

Provider 端尽量多配置 Consumer 端的属性，也让 Provider 的实现者一开始就思考 Provider 端的 服务特点和服务质量等问题。

建议在 Provider 端配置的 Consumer 端属性有:

• timeout:方法调用的超时时间
• retries:失败重试次数
• loadbalance:负载均衡算法，缺省是随机 random。
• actives:消费者端的最大并发调用限制，即当 Consumer 对一个服务的并发调用到上限后，新调用会阻塞直到超时，在方法上配置 dubbo:method 则针对该方法进行并发限制，在接口上配置 dubbo:service，则针对该服务进行并发限制

建议在 Provider 端配置的 Provider 端属性有:

• threads: 服务线程池大小
• executes: 一个服务提供者并行执行请求上限，即当 Provider 对一个服务的并发调用达到上限后，新调用会阻塞，此时 Consumer 可能会超时。 在方法上配置 dubbo:method 则针对该方法进行并发限制，在接口上配置 dubbo:service，则针对该服务进行并发限制

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/generic-reference/

泛化调用可以用来做服务测试。

在Dubbo中，如果某个服务想要支持泛化调用，就可以将该服务的generic属性设置为true，那对于服务消费者来说，就可以不用依赖该服务的接口，直接利用GenericService接口来进行服务调用。

建议将服务接口、服务模型、服务异常等均放在 API 包中，因为服务模型和异常也是 API 的一部分，这 样做也符合分包原则:重用发布等价原则(REP:复用的粒度即是发布的粒度，我们所重用的任何东西必须 被发布和跟踪)，共同重用原则(CRP:如果你重用了一个组件中的一个类，那么就要重用包中的所有类)。

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事 务问题，Dubbo 暂未提供分布式事务支持。

不建议使用过于抽象的通用接口，如:Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

每个接口都应定义版本号，为后续不兼容升级提供可能，如:

建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。

当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。

建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，并且语义更友好。

官网地址http://dubbo.apache./zh/docs/v2.7/user/rest/

注意Dubbo的REST也是Dubbo所支持的一种协议。

当我们用Dubbo提供了一个服务后，如果消费者没有使用Dubbo也想调用服务，那么这个时候我们就可以让我们的服务支持REST协议，这样消费者就可以通过REST形式调用我们的服务了。

注意如果某个服务只有REST协议可用，那么该服务必须用@Path注解定义访问路径

github地址https://github./apache/dubbo-admin

• 在 dubbo-admin-server 子项目的属性文件中，设置 zk 地址及登陆帐户/密码
• 编译 mvn clean package
• 启动 cd dubbo-admin-distribution/target && java -jar dubbo-admin-0.1.jar
• 访问 http://localhost:8080
• 条件路由的使用示例: 查询服务列表后，对目标服务添加路由

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/config-rule/

注意动态配置修改的是服务参数，并不能修改服务的协议、IP、PORT、VERSION、GROUP，因为这5个信息是服务的标识信息，是服务的身份证号，是不能修改的。

官网地址http://dubbo.apache./zh/docs/v2.7/user/examples/routing-rule/