1 不同配置覆盖关系
Dubbo高阶配置运用
关于配置参看官方文档：https://dubbo.apache.org/zh/docsv2.7/user/configuration/
演示：
1、通过ProviderConfig配置全局超时（可通过yml配置覆盖）
2、在@DubboService注解上配置接口超时
3、在@DubboService注解上配置接口方法超时
4、在消费方进行配置，查看覆盖情况
- 覆盖规则：
配置规则：
- 方法级优先，接口级次之，全局配置再次之。
- 如果级别一样，则消费方优先，提供方次之。
- 服务端超时设定
增加配置类：
@Configuration public class DubboCustomConfig { /** * 服务端 * @return */ @Bean public ProviderConfig registryConfig() { ProviderConfig providerConfig = new ProviderConfig(); // 设定超时时间为5S providerConfig.setTimeout(5000); return providerConfig; } }
修改服务接口实现：
设定模拟睡眠时间
/** * 获取订单详情 * @param orderId * @return */ public String getOrder(Long orderId) { try { // 休眠1.5秒 Thread.sleep(1500L); } catch (InterruptedException e) { e.printStackTrace(); } return "Get Order Detail, Id: " + orderId + ", serverPort: " + serverPort; }
客户端调用验证
http://127.0.0.1:18084/order/getOrder?orderId=123
- 服务端全局超时设为2秒（不触发超时）， 消费端设定超时时间为1秒（触发超时）。
修改调用代码：
/** * 订单服务接口 */ @DubboReference(version = "${dubbo.spring.provider.version}", timeout = 1000) private OrderService orderService;
调用结果， 触发超时：
表明消费端配置优先。
服务端全局超时设定为1秒（触发超时）， 消费端去掉超时时间配置。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NtRBunAs-1684741065506)(D:\18、狂野架构师\狂野架构师资料\狂野架构 - 课件资料\01-02阶段课程资料\dubbo源码剖析\讲义\images\image-20210119111947521.png)]
触发超时， 表明服务提供方优先级次之。
2 属性配置优先级
优先级从高到低：
- JVM -D 参数；
-Ddubbo.protocol.port=20881
XML（application.yml/application.properties）配置会重写 dubbo.properties 中的，一般配置项目特有的
dubbo: protocol: name: dubbo # 通讯协议 #port: 20880 # dubbo服务提供方的端口，该值是默认值 port: 20882
- Properties默认配置（dubbo.properties），仅仅作用于以上两者没有配置时，一般配置全局公共配置
dubbo.protocol.port=20883
JVM参数优先级验证
- application.properties里面配置了dubbo.protocol.port端口10888
- JVM运行参数端口设定为-Ddubbo.protocol.port=10889
- 启动服务
服务启动完成， 可以看到端口优先以JVM参数为准。
Properties配置文件验证
- 注释掉application.properties里面配置的dubbo.protocol.name和dubbo.protocol.port配置
- dubbo.properties里面配置dubbo.protocol.name和dubbo.protocol.port
- 在启动参数里， 添加-Ddubbo.properties.file=dubbo.properties
- 启动服务
查看dubbo.properties配置的端口， 可以看到正常生效：
C:\Users\hxx68>netstat -ano |findstr 30889 TCP 0.0.0.0:30889 0.0.0.0:0 LISTENING 49816 TCP [::]:30889 [::]:0 LISTENING 49816
3 重试与容错处理机制
- 容错机制：
- Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
- Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。 - Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
- Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。 - Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
- 后面章节还会对其原理做详细讲解。
- 调整客户端重试次数
/** * 订单服务接口 */ @DubboReference(version = "${dubbo.spring.provider.version}",retries = 3) private OrderService orderService;
这里的重试次数设定为3次。
- 修改服务端超时时间
模拟超时， 让客户端触发重试。
/** * 服务端全局配置 * @return */ @Bean public ProviderConfig registryConfig() { ProviderConfig providerConfig = new ProviderConfig(); providerConfig.setTimeout(1000); return providerConfig; }
将超时时间设小一些为1秒。
- 客户端调用（单个服务）
http://127.0.0.1:18084/order/getOrder?orderId=123
查看服务端控制台，可以看到触发重试机制：
加上第一次的调用和3次重试， 共4次。
- 客户端调用（多个，涉及到负载均衡机制，后面再测试）
允许多个实例运行， 开启多个服务
访问接口， http://127.0.0.1:18084/order/getOrder?orderId=123
第一个服务实例，访问两次， 其他每个服务访问一次。
4 多版本控制
- 启动三个服务端
第一个服务端版本为1.0.0， 第二、三个服务端版本分别为：2.0.0 和 3.0.0
- 主要是修改application.properties配置：
#服务版本号 dubbo.spring.provider.version = 2.0.0
- 启动三个服务提供者，通过
-Ddubbo.spring.provider.version = 2.0.0 -Dserver.port=18082来启动三个
相关的端口不能重复
- 消费端指定版本号
同样修改application.properties配置：
#服务版本号 dubbo.spring.provider.version = 2.0.0
仍然通过-Ddubbo.spring.provider.version = 2.0.0来调用不同版本的服务
测试时，注释掉超时的代码
- 仍是采用超时配置， 通过重试测试验证
测试验证结果：
请求只会访问至版本号为2.0.0的服务节点上面。
