day01Doubbo
1.Dubbo两种常用使用方式:
- 给service与controller分开.Controller层通过dubbo调用service层
- 加入SpringCloud进行服务service层调用
2.Dubbo与Feign的区别:
- Dubbo是基于Dubbo协议调用的
- Feign是基于HTTP协议调用
3.Dubbo启动流程:
- 服务提供者启动,将自身信息存入注册中心.
- 消费者启动时,从注册中心订阅提供者的信息
- 消费者通过获取的提供者信息进行调用
- 如果监控中心(Monitor)发现 服务提供者变更了信息(端口),注册中心就会通知调用者
- 服务容器负责启动,加载,运行服务提供者。
- 服务提供者在启动时,向注册中心注册自己提供的服务。
- 服务消费者在启动时,向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
- 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
4.Dubbo入门案例流程:
目录结构:
order-service:服务消费者
user-service:提供者
dubbo-admin:公用信息(实体类)
dubbo-api:调用服务的方法
服务消费者yml
server:
port: 8080
spring:
datasource:
url: jdbc:mysql://localhost:3306/dubbo-demo?useSSL=false
username: root
password: root
driver-class-name: com.mysql.jdbc.Driver
application:
name: order-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
#配置dubbo,注册中心,暴露的端口和协议,dubbo注解的包扫描
dubbo:
registry:
address: spring-cloud://localhost #使用SpringCloud中的注册中心
scan:
base-packages: cn.hmc.order.service #dubbo中包扫描
consumer:
check: false #dubbo默认有启动检查
retries: 0 #dubbo内置的重试机制
服务提供者yml
server:
port: 8081
spring:
datasource:
url: jdbc:mysql://localhost:3306/dubbo-demo?useSSL=false
username: root
password: root
driver-class-name: com.mysql.jdbc.Driver
application:
name: user-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
#配置dubbo,注册中心,暴露的端口和协议,dubbo注解的包扫描
dubbo:
protocol:
name: dubbo
port: 20881
registry:
address: spring-cloud://localhost #使用SpringCloud中的注册中心
scan:
base-packages: cn.hmc.user.service #dubbo中包扫描
将方法注册到dubbo中,使用@DubboService注解
从dubbo中调用服务,使用@DubboReference注解
导入的依赖
<!--nacos注册中心的依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!--springcloud alibaba dubbo依赖 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>
总结:
5.Dubbo高级特性
1.启动检查
-
什么是启动检查
- 为了保障服务的正常可用,Dubbo默认会在启动时检查依赖的服务是否可用,不可用时会抛出异常
- 正式环境可以保证整个调用链路的平稳运行.
- 开发时往往会存在没有提供者的情况,由于启动检查的原因,可能导致开发测试出现问题
-
关闭启动检查
-
在消费端注解上添加
@DubboReference(check=false)
对当前消费者生效 -
在配置文件中配置
-
dubbo: registry: address: nacos://127.0.0.1:8848 consumer: check: false
-
2.多版本检查
- 实际场景有哪些?
- 灰度发布:当出现新功能时,会让一部分用户先使用新功能,用户反馈没问题时,再将所有用户迁移到新功能
- 版本兼容:新版本发布时,还未升级版本的用户还需要使用老版本
- 如何支持多版本
- Dubbo服务提供方指定新老服务版本:
@DubboService(version = “2.0.0”)
- Dubbo服务消费方指定消费服务的版本:
@DubboReference(version = "2.0.0")
3.超时与重试
-
什么时候会造成超时?
- 消费方在调用服务提供方是发生了阻塞, 等待的情形,这个时候,服务消费方会一直等待下去
- 在某个峰值时刻,大量的请求都在同时请求服务消费者,会造成线程的大量堆积,势必会造成雪崩,所以需要有超时即结束当前请求的机制
-
什么时候需要重试?
- 如果当前请求失败,大部分时候需要自动的进行再次尝试,而dubbo也是支持的。
-
超时和重试默认配置是什么?
- 超时默认配置是 1秒
- 重试默认配置是2次
-
如何配置超时与重试?
-
使用注解
-
@DubboReference(timeout = 30000,retries=4)
-
配置文件
-
消费端 dubbo: registry: address: nacos://127.0.0.1:8848 consumer: timeout: 3000 retries: 0
-
-
备注:以上超时与重试配置也可通过在服务提供方指定,但是消费方优先级大于服务提供方
-
消费方注解 > 消费方文件配置 > 服务方注解 > 服务方文件配置
4.负载均衡
-
什么是dubbo负载均衡
-
集群部署时,客户端该调用哪一台机器上提供的服务呢? 如果全部都是调用其中一台肯定是不合理的
Dubbo提供了4种负载均衡策略,帮助消费者找到最优提供者并调用
-
-
dubbo提供了哪几种负载均衡策略
- random :按权重随机,默认值。按权重设置随机概率。
- roundRobin :按权重进行轮询调用。
- leastActive:最少活跃调用数,Dubbo认为活跃度最小的性能会更高,而相同活跃数进行随机调用。
- consistentHash:一致性 Hash,相同参数的请求总是发到同一提供者。
-
如何配置负载均衡
-
1).通过在注解
-
@RestController @RequestMapping("/user") public class UserController { //引用远程服务 @DubboReference(loadbalance = "roundrobin") private UserService userService; }
-
2).通过在配置文件中指定
-
dubbo: registry: address: nacos://127.0.0.1:8848 consumer: loadbalance: random
-
-
备注:以上负载均衡配置也可通过在服务提供方指定,但是消费方优先级大于服务提供方
-
消费方注解 > 消费方文件配置 > 服务方注解 > 服务方文件配置
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 震惊!C++程序真的从main开始吗?99%的程序员都答错了
· 【硬核科普】Trae如何「偷看」你的代码?零基础破解AI编程运行原理
· 单元测试从入门到精通
· winform 绘制太阳,地球,月球 运作规律
· 上周热点回顾(3.3-3.9)