标签：Dubbo 调用 服务 重试 Reference 配置 学习 超时
Dubbo的快速入门案例
一,配置服务的提供者
1.@Service的注解为Dubbo的注解
2.配置Spring的配置文件
2.1配置项目的名称
<dubbo:application name="(项目的名称)"/>2.2 配置注册中心的地址
<dubbo:registry address="zookeeper://192.168.149.135:2181"/>2.3 启动dubbo的注解扫描
<dubbo:annotation package="对应的包名"/>
二,配置服务的消费者（创建web的模块）
1.@Autowired是本地的依赖注入，需要将@Autowired的注解替换成@Reference实现远程的注入
1.1@Reference的过程
1.1.1从zookpeeper注册中心获取userService的访问url
1.1.2进行远程调用rpc
1.1.3将结果封装为一个代理对象。给变量赋值
2.配置web层的spring-mvc配置文件
2.1配置项目的名称
<dubbo:application name="(项目的名称)"/>2.2 配置注册中心的地址
<dubbo:registry address="zookeeper://192.168.149.135:2181"/>2.3 启动dubbo的注解扫描
<dubbo:annotation package="对应的包名"/>
三,Dubbo的高级特性
3.1Dubbo的高级特性-序列化
-
dubbo 内部已经将序列化和反序列化的过程内部封装了
-
我们只需要在定义pojo类时实现serializable接口即可
-
一般会定义一 个公共的pojo模块,让生产者和消费者都依赖该模块。
解决办法：
User implements Serializable
3.2 地址缓存
注册中心挂了，服务是否可以正常访问？
-
可以，因为dubbo服务消费者在第一-次调用时，会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心。
-
当服务提供者地址发生变化时，注册中心会通知服务消费者。
3.3 超时
-
服务消费者在调用服务提供者的时候发生了阻塞、等待的情形,这个时候,服务消费者会直等待下去。
-
在某个峰值时刻，大量的请求都在同时请求服务消费者,会造成线程的大量堆积，势必会造成雪崩。
-
dubbo利用超时机制来解决这个问题，设置-个超时时间, 在这个时间段内，无法完成服务访问,则自动断开连接。
-
使用timeout属性配置超时时间，默认值1000，单位毫秒
//timeout 超时时间 单位毫秒 retries 重试次数 @Service(timeout = 3000,retries=0)
3.4重试
-
设置了超时时间，在这个时间段内，无法完成服务访问,则自动断开连接。
-
如果出现网络抖动,则这一-次请求就会失败。
-
Dubbo提供重试机制来避免类似问题的发生。
-
通过retries属性来设置重试次数。默认为2次
//timeout 超时时间 单位毫秒 retries 重试次数 @Service(timeout = 3000,retries=0)
3.5多版本
灰度发布:当出现新功能时,会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。
dubbo中使用version属性来设置和调用同一个接口的不同版本
生产者配置
@Service(version="v2.0") public class UserServiceImp12 implements UserService {...}消费者配置
@Reference(version = "v2.0")//远程注入 private UserService userService;
3.6负载均衡
负载均衡策略(4种) : Random:按权重随机，默认值。按权重设置随机概率。
RoundRobin: 按权重轮询。
LeastActive: 最少活跃调用数,相同活跃数的随机。
ConsistentHash:一 致性Hash,相同参数的请求总是发到同一提供者。
服务提供者配置
@Service(weight = 100)
public class UserServiceImp12 implements UserService {...}
application.xml 配置parameter key
消费者配置
//@Reference(loadbalance = "roundrobin") //@Reference(loadbalance = "leastactive") //@Reference(loadbalance = "consistenthash") @Reference(loadbalance = "random")//默认 按权重随机 private UserService userService;
3.7集群容错
集群容错模式:
**Failover Cluster:**失败重试。默认值。当出现失败，重试其它服务器，默认重试2次，使用retries配置。一般用于读操作 **Failfast Cluster :**快速失败,发起-次调用，失败立即报错。通常用于写操作。 **Failsafe Cluster:**失败安全，出现异常时，直接忽略。返回一个空结果。 **Failback Cluster:**失败自动恢复,后台记录失败请求,定时重发。 **Forking Cluster :**并行调用多个服务器，只要一个成功即返回。 **Broadcast Cluster:** 广播调用所有提供者,逐个调用，任意一台报错则报错。 消费者配置
@Reference(cluster = "failover")//远程注入 private UserService userService;
3.8服务降级
服务降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作
服务降级方式:mock= force:return null：表示消费方对该服务的方法调用都直接返回null值,不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
mock=fail:return null：表示消费方对该服务的方法调用在失败后，再返回null值,不抛异常。用来容忍不重要服务不稳定时对调用方的影响
消费方配置
//远程注入 @Reference(mock =“ force :return null")//不再调用userService的服务 private UserService userService;
标签：Dubbo,调用,服务,重试,Reference,配置,学习,超时 来源： https://blog.csdn.net/weixin_46115287/article/details/120833379
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。