dubbo分布式服务框架(高级特性篇)

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介: 本文详细介绍并实际操作dubbo常用高级特性,序列化、地址缓存、超时、重试、负载均衡、多版本、集群容错、服务降级

 1.序列化

序列化是将Java对象转化为流的数据,流的数据才能在两台主机上进行传输

image.gif

dubbo内部已经对序列化和反序列化封装了,我们只需要让实体类实现Serializable接口即可

文章基于本人另一篇博客dubbo入门篇

dubbo分布式服务框架入门_雪月清的博客-CSDN博客

1.新建一个模块为dubbo-pojo,创建一个User类(先不实现Serializable接口)

public class User {
     private int id;
     private  String name;
     private  String password;
     public User() {
     }
     public User(int id, String name, String password) {
         this.id = id;
         this.name = name;
         this.password = password;
     }
     public int getId() {
         return id;
     }
     public void setId(int id) {
         this.id = id;
     }
     public String getName() {
         return name;
     }
     public void setName(String name) {
         this.name = name;
     }
     public String getPassword() {
         return password;
     }
     public void setPassword(String password) {
         this.password = password;
     }
 }

image.gif

2.在dubbo-interface中关联dubbo-pojo,因为我们在接口模块写一个测试user的接口

<dependencies>
     <dependency>
         <groupId>com.xue</groupId>
         <artifactId>dubbo-pojo</artifactId>
         <version>1.0-SNAPSHOT</version>
     </dependency>
 </dependencies>

image.gif

在UserService接口中新增一个方法

/**
  * 查询用户接口
  * @return
  */
 public User findUserById(int id);

image.gif

3.在dubbo-service模块中实现此方法,并简单返回一个测试的user对象

@Override
     public User findUserById(int id) {
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         return users[id-1];
     }

image.gif

4.在dubbo-web模块下的UserController中新增find方法

@RequestMapping("/find")
 public User find(int id) {
     return userService.findUserById(id);
 }

image.gif

然后进行tomcat7:run进行测试

然后测试就发现报错了

image.gif

控制台报错信息

java.lang.IllegalStateException: Serialized class com.xue.pojo.User must implement java.io.Serializable

image.gif

需要实现Serializable接口

public class User implements Serializable

image.gif

重新启动

image.gif

成功访问!

2.地址缓存

面试题:注册中心挂了,服务是否可以正常访问?

可以,因为dubbo服务消费者在第一次调用时,会将服务提供方地址缓存到本地,以后在调用就不会访问注册中心。

当服务提供者地址发生变化时,注册中心会通知服务消费者

停掉zookeeper服务注册中心

image.gif

访问成功!

image.gif

3.超时

问题描述:

服务消费者在调用服务提供者的时候发生了阻塞、等待的情形,这个时候,服务消费者会一

直等待下去。在某个峰值时刻,大量的请求都在同时请求服务消费者,会造成线程的大量堆

积,势必会造成雪崩

dubbo利用超时机制来解决这个问题,设置一个超时时间,在这个时间段内,无法完成服务

访问,则自动断开连接。

使用timeout属性配置超时时间,默认值1000,单位毫秒。

1.在dubbo-service模块中配置超时时间,并模拟超时

@Service(timeout = 3000)
 public class UserServiceImpl implements UserService {
     @Override
     public String demo() {
         return "hello,Dubbo";
     }
     @Override
     public User findUserById(int id) {
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         //模拟超时
         try {
             Thread.sleep(5000);
         } catch (InterruptedException e) {
             e.printStackTrace();
         }
         return users[id-1];
     }
 }

image.gif

2.访问失败,超时

image.gif

注意点

在服务消费方@Reference也可以配置超时时间,并且会覆盖服务提供方的超时时间,也就是说@Reference配置1s,之前服务提供方配置3s,最后结果是1s之后就发生超时

@Reference(timeout = 1000) //远程注入
 private UserService userService;

image.gif

建议在服务提供方配置超时时间,毕竟这个服务是服务提供方编写的,在编写时就应该考虑超时时间的配置问题

4.重试

设置了超时时间,在这个时间段内,无法完成服务访问,则自动断开连接。如果出现网络抖动(网

络突然断掉又重新连接上,网络不稳定),则这一次请求就会失败。

Dubbo提供重试机制来避免类似问题的发生。通过retries属性来设置重试次数,默认为2次。(总

共发了三次)

@Service(timeout = 3000,retries = 2) //当前服务3秒超时,重视2次,一共3次
 public class UserServiceImpl implements UserService {
     int i = 1;
     @Override
     public String demo() {
         return "hello,Dubbo";
     }
     @Override
     public User findUserById(int id) {
         System.out.println("服务被调用"+i++);
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         //模拟超时
         try {
             Thread.sleep(5000);
         } catch (InterruptedException e) {
             e.printStackTrace();
         }
         return users[id-1];
     }
 }

image.gif

进行了超时重试

image.gif

5.多版本

灰度发布: 当出现新功能时,会让一部分用户先使用新功能,用户反馈没问题时,再将所有用户迁

移到新功能。

image.gif

V2.0版本没问题之后再将所有用户迁移到V2.0

image.gif

dubbo中使用version属性来设置和调用同一个接口的不同版本

@Service(version = "v1.0")
 public class UserServiceImpl implements UserService {
     @Override
     public String demo() {
         return "hello,Dubbo";
     }
     @Override
     public User findUserById(int id) {
         System.out.println("v1.0版本");
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         return users[id-1];
     }
 }

image.gif

1.复制UserServiceImpl类并改为v2.0版本

@Service(version = "v2.0") 
 public class UserServiceImpl2 implements UserService {
     @Override
     public String demo() {
         return "hello,Dubbo";
     }
     @Override
     public User findUserById(int id) {
         System.out.println("v2.0版本");
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         return users[id-1];
     }
 }

image.gif

2.先指定访问v1.0版本,启动

@Reference(version = "v1.0") 
 private UserService userService;

image.gif

控制台打印v1.0版本

image.gif

3.指定访问v2.0版本,重启dubbo-web(不需要重启dubbo-service了)

@Reference(version = "v1.0") 
 private UserService userService;

image.gif

image.gif

6.负载均衡

负载均衡策略:

1. Random :按权重随机,默认值。按权重设置随机概率。

2. RoundRobin:按权重轮询。

3. LeastActive:最少活跃调用数,相同活跃数的随机。

4. ConsistentHash: 一致性Hash,相同参数的请求总是发到同一提供者。

以默认的Random为例

1.启动 weight = 100 tomcat端口9000 dubbo端口20880 qos端口22222

@Service(weight = 100)
 public class UserServiceImpl implements UserService {
     @Override
     public String demo() {
         return "1......";
     }
 }

image.gif

<debbo:protocol port="20880"/>
 <dubbo:application name="dubbo-service">
    <dubbo:parameter key="qos.port" value="22222"/>
 </dubbo:application>

image.gif

2. 启动weight = 200 tomcat端口9001 dubbo端口20882 qos端口44444 再启动一次tomcat7:run

(注意不是重启上一个而是再启动一个)

@Service(weight = 200)
 public class UserServiceImpl implements UserService {
     @Override
     public String demo() {
         return "2......";
     }
 }

image.gif

<debbo:protocol port="20882"/>
 <dubbo:application name="dubbo-service">
         <dubbo:parameter key="qos.port" value="44444"/>
     </dubbo:application>

image.gif

3. 启动weight = 100 tomcat端口9002 dubbo端口20883 qos端口55555 再启动一次tomcat7:run

@Service(weight = 100)
 public class UserServiceImpl implements UserService {
     @Override
     public String demo() {
         return "3......";
     }
 }

image.gif

<debbo:protocol port="20883"/>
 <dubbo:application name="dubbo-service">
    <dubbo:parameter key="qos.port" value="55555"/>
 </dubbo:application>

image.gif

配置负载均衡的策略random

@Reference(loadbalance = "random" )

image.gif

启动dubbo-web模块的tomcat7:run

(我们一个启动了四个tomcat)

访问出现2 说明是第二个服务提供方

image.gif

不断刷新出现3 说明是第三个服务提供方

image.gif

不断刷新出现1 说明是第一个服务提供方

image.gif

7.集群容错

集群容错策略:

1. Failover Cluster:失败重试。(默认值)当出现失败,重试其它服务器,默认重试2次,使用

retries配置。一般用于读操作

2. Failfast Cluster : 快速失败,只发起一次调用,失败立即报错。通常用于写操作。

3. Failsafe Cluster : 失败安全,出现异常时,直接忽略。返回一个空结果。

4. FailbackCluster : 失败自动恢复,后台记录失败请求,定时重发。

5. Forking Cluster : 并行调用多个服务器,只要一个成功即返回。Broadcast Cluster :广播调用

有提供者,逐个调用,任意一台报错则报错。

以Failover Cluster策略为例

1.启动 tomcat端口9000 dubbo端口20880 qos端口22222

@Service()
 public class UserServiceImpl implements UserService {
      @Override
     public User findUserById(int id) {
         System.out.println(1);
         try {
             Thread.sleep(3000);
         } catch (InterruptedException e) {
             e.printStackTrace();
         }
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         return users[id-1];
     }
 }

image.gif

<debbo:protocol port="20880"/>
 <dubbo:application name="dubbo-service">
    <dubbo:parameter key="qos.port" value="22222"/>
 </dubbo:application>

image.gif

2. tomcat端口9001 dubbo端口20881 qos端口44444 再启动一次tomcat7:run

@Service()
 public class UserServiceImpl implements UserService {
      @Override
     public User findUserById(int id) {
         System.out.println(2);
         try {
             Thread.sleep(3000);
         } catch (InterruptedException e) {
             e.printStackTrace();
         }
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         return users[id-1];
     }
 }

image.gif

<debbo:protocol port="20881"/>
 <dubbo:application name="dubbo-service">
         <dubbo:parameter key="qos.port" value="44444"/>
     </dubbo:application>

image.gif

3. tomcat端口9002 dubbo端口20882 qos端口55555 再启动一次tomcat7:run

@Service()
 public class UserServiceImpl implements UserService {
      @Override
     public User findUserById(int id) {
         System.out.println(3);  
         User[]users = {new User(1,"雪月清","123")
                 ,new User(2,"张三","456")
                 ,new User(3,"李四","156")};
         return users[id-1];
     }
 }

image.gif

<debbo:protocol port="20882"/>
 <dubbo:application name="dubbo-service">
    <dubbo:parameter key="qos.port" value="55555"/>
 </dubbo:application>

image.gif

访问成功!

image.gif

但是dubbo-web模块的tomcat日志信息出现超时错误,

三个服务提供方的日志信息

image.gif

image.gif

image.gif

发现三个都访问了,但是1和2都会超时(我们通过进程睡眠模拟了超时),消费方会访问1超时,

然后根据Failover Cluster集群容错策略,重试访问2也超时了,再重试一次访问3成功!

8.服务降级

mock=force:return null 表示消费方对该服务的方法调用都直接返回null值,不发起远程调用。用

来屏蔽不重要服务不可用时对调用方的影响。

1.配置服务提供方

@Service()
 public class UserServiceImpl implements UserService {
  @Override
 public User findUserById(int id) {
     System.out.println(3);  
     User[]users = {new User(1,"雪月清","123")
             ,new User(2,"张三","456")
             ,new User(3,"李四","156")};
     return users[id-1];
 } 
 }

image.gif

2.配置服务消费方

@Reference(mock = "force:return null")

image.gif

3.分别启动服务提供方和服务消费方

image.gif

成为了空白页面,服务被屏蔽了

mock=fail:return null 表示消费方对该服务的方法调用在失败后,再返回null值,不抛异常。用来

容忍不重要服务不稳定时对调用方的影响。

修改服务消费方的配置其余不变重新启动

@Reference(mock = "fail:return null")

image.gif

image.gif

(服务提供方我们模拟了超时)失败后重试了三次,但是页面看不到任何信息

image.gif


相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
7天前
|
负载均衡 Dubbo NoSQL
Dubbo框架的1个核心设计点
Java领域要说让我最服气的RPC框架当属Dubbo,原因有许多,但是最吸引我的还是它把远程调用这个事情设计得很有艺术。
Dubbo框架的1个核心设计点
|
17天前
|
Dubbo Java 应用服务中间件
微服务框架Dubbo环境部署实战
微服务框架Dubbo环境部署的实战指南,涵盖了Dubbo的概述、服务部署、以及Dubbo web管理页面的部署,旨在指导读者如何搭建和使用Dubbo框架。
68 17
微服务框架Dubbo环境部署实战
|
11天前
|
运维 NoSQL Java
SpringBoot接入轻量级分布式日志框架GrayLog技术分享
在当今的软件开发环境中,日志管理扮演着至关重要的角色,尤其是在微服务架构下,分布式日志的统一收集、分析和展示成为了开发者和运维人员必须面对的问题。GrayLog作为一个轻量级的分布式日志框架,以其简洁、高效和易部署的特性,逐渐受到广大开发者的青睐。本文将详细介绍如何在SpringBoot项目中接入GrayLog,以实现日志的集中管理和分析。
50 1
|
23天前
|
数据采集 分布式计算 并行计算
Dask与Pandas:无缝迁移至分布式数据框架
【8月更文第29天】Pandas 是 Python 社区中最受欢迎的数据分析库之一,它提供了高效且易于使用的数据结构,如 DataFrame 和 Series,以及大量的数据分析功能。然而,随着数据集规模的增大,单机上的 Pandas 开始显现出性能瓶颈。这时,Dask 就成为了一个很好的解决方案,它能够利用多核 CPU 和多台机器进行分布式计算,从而有效地处理大规模数据集。
48 1
|
18天前
|
分布式计算 资源调度 Hadoop
在YARN集群上运行部署MapReduce分布式计算框架
主要介绍了如何在YARN集群上配置和运行MapReduce分布式计算框架,包括准备数据、运行MapReduce任务、查看任务日志,并启动HistoryServer服务以便于日志查看。
31 0
|
20天前
|
C# 开发者 Windows
勇敢迈出第一步:手把手教你如何在WPF开源项目中贡献你的第一行代码,从选择项目到提交PR的全过程解析与实战技巧分享
【8月更文挑战第31天】本文指导您如何在Windows Presentation Foundation(WPF)相关的开源项目中贡献代码。无论您是初学者还是有经验的开发者,参与这类项目都能加深对WPF框架的理解并拓展职业履历。文章推荐了一些适合入门的项目如MvvmLight和MahApps.Metro,并详细介绍了从选择项目、设置开发环境到提交代码的全过程。通过具体示例,如添加按钮点击事件处理程序,帮助您迈出第一步。此外,还强调了提交Pull Request时保持专业沟通的重要性。参与开源不仅能提升技能,还能促进社区交流。
28 0
|
20天前
|
缓存 分布式计算 Java
详细解读MapReduce框架中的分布式缓存
【8月更文挑战第31天】
12 0
|
25天前
|
机器学习/深度学习 编译器 PyTorch
自研分布式训练框架EPL问题之吸引社区参与共建如何解决
自研分布式训练框架EPL问题之吸引社区参与共建如何解决
|
25天前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
60 2
基于Redis的高可用分布式锁——RedLock
|
1月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】