Dubbo的高级特性:服务治理篇

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介: 大家好,我是王有志。今天我们一起来了解并学习如何使用Dubbo在服务治理方面提供的高级特性。

王有志,一个分享硬核Java技术的互金摸鱼侠
加入Java人的提桶跑路群共同富裕的Java人

上一篇中,我们已经在Spring Boot应用中集成了Dubbo,并注册了一个服务提供方和一个服务使用方。当然,生产环境中应用往往会部署多个节点,以此来保证服务的高可用,那么如何配置Dubbo的负载均衡策略呢?

下面我们以此为切入点,来介绍Dubbo在服务治理方面提供的高级特性的配置与使用。Dubbo默认支持6种配置来源:

  • JVM System Properties,JVM -D参数
  • System environment,JVM进程的环境变量
  • Externalized Configuration,外部化配置,从配置中心读取
  • Application Configuration,应用的属性配置,从Spring应用的Environment中提取"dubbo"打头的属性集
  • API//注解等编程接口采集的配置可以被理解成配置来源的一种,是直接面向用户编程的配置采集方式
  • 从classpath读取配置文件 dubbo.properties

在今天的内容中,我们只会涉及到Application Configuration,XML和注解这3种常见的配置方式。

Tips:本篇为基础内容,重点在配置和使用,不涉及任何实现原理和算法原理。

负载均衡

微服务中,负载均衡指的是将请求“合理”的分配在服务的不同节点间,以达到优化使用资源,提供高吞吐量,降低响应时间的目的。Dubbo 3.X中提供了7种负载均衡策略:

算法 特性 配置值 默认配置 说明
Weighted Random LoadBalance 加权随机 random 默认算法,默认权重相同
RoundRobin LoadBalance 加权轮询 roundrobin 借鉴于 Nginx 的平滑加权轮询算法,默认权重相同,
LeastActive LoadBalance 最少活跃优先 + 加权随机 leastactive 背后是能者多劳的思想
Shortest-Response LoadBalance 最短响应优先 + 加权随机 shortestresponse 更加关注响应速度
ConsistentHash LoadBalance 一致性哈希 consistenthash 确定的入参,确定的提供者,适用于有状态请求
P2C LoadBalance Power of Two Choice p2c 随机选择两个节点后,继续选择“连接数”较小的那个节点。
Adaptive LoadBalance 自适应负载均衡 adaptive 在 P2C 算法基础上,选择二者中 load 最小的那个节点

Dubbo支持为服务提供方和服务使用方配置负载均衡策略,当两者都配置了负载均衡策略,以服务使用方的负载均衡策略为准。

首先我们来看XML文件的配置方式,通过XML文件,可以为接口,方法配置负载均衡策略,先为服务提供方的DubboDemoService接口配置负载均衡策略:

<dubbo:service interface="com.wyz.api.DubboDemoService" ref="dubboDemoServiceImpl" loadbalance="roundrobin"/>

接着我们为服务使用方在调用DubboDemoService#say方法时配置负载均很策略:

<dubbo:reference id="DubboDemoService" interface="com.wyz.api.DubboDemoService">
  <dubbo:method name="say" loadbalance="roundrobin"/>
</dubbo:reference>

接着我们使用Application文件配置负载均衡策略,通过Application文件,可以配置Dubbo应用的全局负载均衡策略,内容如下:

dubbo:
  provider:
    loadbalance: roundrobin
  consumer:
    loadbalance: roundrobin

最后注解的形式配置负载均衡策略,可以为接口和方法配置负载均衡策略配置,代码如下:

@DubboService(loadbalance = "roundrobin")
public class DubboDemoServiceImpl implements DubboDemoService {

  @Override
  @DubboService(loadbalance = "leastactive")
  public String say(String message) {
    return "DubboProvider  say : " + message;
  }
}

集群容错

当配置好负载均衡策略后,程序一直稳定运行。可是突然有一天,集群中的某个节点不可用了,当请求“命中”了不可用的节点后,Dubbo会如何处理呢?

Dubbo提供了集群容错的能力,实现了9中针对集群中节点故障的处理方案:

策略 配置值 默认配置 特性 应用场景
Failover Cluster failover 失败自动切换,当出现失败,重试其它服务器 通常用于读操作,可以配置重试次数
Failfast Cluster failfast 快速失败,失败后立即报错 通常用于非幂等写操作
Failsafe Cluster failsafe 失败安全,出现异常时,直接忽略 通常用于写入审计日志
Failback Cluster failback 失败自动恢复,后台记录失败请求,定时重发 通常用于消息通知
Forking Cluster forking 并行调用多个服务器,只要一个成功即返回 通常用于实时性要求较高的读操作
Broadcast Cluster broadcast 广播调用所有提供者,逐个调用,任意一台报错则报错 缓存更新
Available Cluster available 调用目前可用的实例(只调用一个),如果当前没有可用的实例,则抛出异常 不需要负载均衡的场景
Mergeable Cluster mergeable 将集群中的调用结果聚合起来返回结果,通常和group一起配合使用 /
ZoneAware Cluster / 多注册中心订阅的场景,注册中心集群间的负载均衡 /

XML文件的形式依旧提供了接口及接口方法级别的集群容错策略配置

<dubbo:service interface="com.wyz.api.DubboDemoService" ref="dubboDemoServiceImpl" cluster="failover" retries="2"/>

其中retries是Failover Cluster策略的参数,设定了接口重试的次数(不含正常调用次数),例如,在上述配置中,正常调用失败后,至多会再调用两次。通过XML配置方法级别的集群容错策略与配置负载均衡策略一致,这里就不过多赘述了。

Application文件中可以配置全局的集群容错策略,内容如下:

dubbo:
  provider:
    cluster: failover
    retries: 2

最后是注解配置方式,依旧是通过@DubboService来配置接口和接口方法级别的集群容错策略,代码如下:

@DubboService(cluster = "failover", retries = 2)
public class DubboDemoServiceImpl implements DubboDemoService {

  @Override
  @DubboService(cluster = "failover", retries = 2)
  public String say(String message) {
    return "DubboProviderXML  say : " + message;
  }
}

服务降级

Dubbo自身提供的服务降级功能较为简陋,只提供了mock功能,如果想要体验功能完善的限流熔断等功能,可以使用Sentinel,Hystrix以及Resilience4j等Dubbo支持的专业的技术组件。由于Dubbo的服务降级功能较为简陋,这里只通过3种XML文件的配置方式了解服务降级的功能的配置即可。

配置方式一

<dubbo:service interface="com.wyz.api.DubboDemoService" ref="dubboDemoServiceImpl"  mock="true"/>

这种方式的配置中,需要在相同包下有类名 + Mock后缀的实现类,例如:DubboDemoServiceMock

public class DubboDemoServiceMock implements DubboDemoService {
  @Override
  public String say(String message) {
    return "服务出错了!";
  }
}

配置方式二

通过Mock类的全限名配置:

<dubbo:service interface="com.wyz.api.DubboDemoService" ref="dubboDemoServiceImpl"  mock="com.wyz.api.DubboDemoServiceMock"/>

配置方式三

使用Dubbo定义的表达式:mock="[fail|force]return|throw xxx"

  • [fail|force],默认值fail,表示调用失败后,或不进行方法调用直接强制执行mock方法;
  • return xxx,表示返回指定结果,需要符合接口的返回类型;
  • throw xxx,表示抛出指定异常。

我们举几个例子:

<dubbo:service interface="com.wyz.api.DubboDemoService" ref="dubboDemoServiceImpl"  mock="return fail"/>
<dubbo:service interface="com.wyz.api.DubboDemoService" ref="dubboDemoServiceImpl"  mock="force:return false"/>
<dubbo:service interface="com.wyz.api.DubboDemoService" ref="dubboDemoServiceImpl"  mock="fail:throw java.lang.NullPointException"/>

服务分组

允许通过分组的方式来区分同一个接口的不同实现方式。例如:为DubboXMLService接口添加两个不同的实现DubboXMLServiceImpl和NewDubboXMLServiceImpl。

public interface DubboXMLService {
  String say(String message);
}

public class DubboXMLServiceImpl implements DubboXMLService {
  @Override
  public String say(String message) {
    return "DubboProviderXML say : " + message;
  }
}

public class NewDubboXMLServiceImpl implements DubboXMLService {
  @Override
  public String say(String message) {
    return "NewDubboProviderXML say : " + message;
  }
}

首先是通过XML文件配置服务提供方:

<bean id="dubboXMLServiceImpl" class="com.wyz.service.impl.DubboXMLServiceImpl"/>
<dubbo:service interface="com.wyz.api.DubboXMLService" ref="dubboXMLServiceImpl" group="XML-Provider"/>

<bean id="newDubboXMLServiceImpl" class="com.wyz.service.impl.NewDubboXMLServiceImpl"/>
<dubbo:service interface="com.wyz.api.DubboXMLService" ref="newDubboXMLServiceImpl" group="New-XML-Provider"/>

接着来看服务使用方的配置:

<dubbo:reference id="dubboXMLService" interface="com.wyz.api.DubboXMLService" group="XML-Provider"/>
<dubbo:reference id="newDubboXMLService" interface="com.wyz.api.DubboXMLService" group="New-XML-Provider"/>

使用的话也非常简单,可以直接通过@Autowired方式注入不同分组的服务:

public class DubboConsumerXMLService implements CommandLineRunner {

  @Autowired
  DubboXMLService dubboXMLService;

  @Autowired
  DubboXMLService newDubboXMLService;

  @Override
  public void run(String... args) {
    String message = dubboXMLService.say("wyz");
    System.out.println(message);

    String newMessage = newDubboXMLService.say("wyz");
    System.out.println(newMessage);
  }
}

再来看如何通过注解的方式进行配置:

@DubboService(group = "Annotation-Provider")
public class DubboAnnotationServiceImpl implements DubboAnnotationService {
  @Override
  public String say(String message) {
    return "DubboProviderAnnotation say : " + message;
  }
}

@DubboService(group = "New-Annotation-Provider")
public class NewDubboAnnotationServiceImpl implements DubboAnnotationService {
  @Override
  public String say(String message) {
    return "NewDubboProviderAnnotation say : " + message;
  }
}

最后是通过注解使用不同分组的服务,注意这里要使用@DubboReference注入Bean:

@Component
public class DubboConsumerAnnotationService implements CommandLineRunner {

  @DubboReference(group = "Annotation-Provider")
  DubboAnnotationService dubboAnnotationService;

  @DubboReference(group = "New-Annotation-Provider")
  DubboAnnotationService newDubboAnnotationService;

  @Override
  public void run(String... args) {
    String message = dubboAnnotationService.say("wyz-Annotation");
    System.out.println(message);

    String newMessage = newDubboAnnotationService.say("wyz-Annotation");
    System.out.println(newMessage);
  }
}

Tips:不推荐通过Application文件的方式进行配置。

服务版本

Dubbo中,接口并不能唯一的确定一个服务,只有明确接口+分组+版本号才能唯一的确定一个服务,例如:

<dubbo:service interface="com.wyz.api.DubboXMLService" ref="dubboXMLServiceImpl" group="XML-Provider" version="1.0.0"/>

服务区分版本常见于版本发布验证的场景中,集群中部分节点升级服务,并切换少许流量,验证成功后,再大范围升级节点,可以降低服务升级带来的风险

服务版本的配置与使用方式与服务分组一样,这里只展示XML文件的配置方式:

<bean id="dubboXMLServiceImpl" class="com.wyz.service.impl.DubboXMLServiceImpl"/>
<dubbo:service interface="com.wyz.api.DubboXMLService" ref="dubboXMLServiceImpl" version="1.0.0"/>

服务使用者的XML文件配置:

<dubbo:reference id="dubboXMLService" interface="com.wyz.api.DubboXMLService" version="1.0.0"/>

XML文件的配置方式可以直接使用@Autowired注入不同版本的服务,我们这里就不赘述了。


今天,我们一起了解并学习了如何配置和使用Dubbo提供的服务治理的能力。

除了上面提到的服务治理能力外,Dubbo还提供了服务路由的能力,Dubbo 2.7之前,可以通过<dubbo:route>标签来配置路由规则,但在Dubbo 2.7之后,官方移除了<dubbo:route>标签,引入了一套依赖于注册中心和配置中心的全新路由配置机制,后面会出一篇番外篇,将注册中心迁移到Nacos上,并学习如何配置路由规则。

如果本文对你有帮助的话,还请多多点赞支持。如果文章中出现任何错误,还请批评指正。最后欢迎大家关注分享硬核技术的金融摸鱼侠王有志,我们下次再见!

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
7月前
|
XML Dubbo Java
【Dubbo3高级特性】「框架与服务」服务的异步调用实践以及开发模式
【Dubbo3高级特性】「框架与服务」服务的异步调用实践以及开发模式
165 0
|
7月前
|
Dubbo Cloud Native 网络协议
【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍
【Dubbo3技术专题】「服务架构体系」第一章之Dubbo3新特性要点之RPC协议分析介绍
99 1
|
7月前
|
JSON Dubbo Java
微服务框架(二十)Dubbo Spring Boot 生产就绪特性
  此系列文章将会描述Java框架Spring Boot、服务治理框架Dubbo、应用容器引擎Docker,及使用Spring Boot集成Dubbo、Mybatis等开源框架,其中穿插着Spring Boot中日志切面等技术的实现,然后通过gitlab-CI以持续集成为Docker镜像。   本文为Dubbo Spring Boot 生产就绪特性
|
4月前
|
存储 负载均衡 Dubbo
Dubbo阶段性总结及3.0新特性
该文章是对Dubbo技术的一次总结,包括对Dubbo框架的整体架构、服务提供者发布注册原理、SPI机制、服务消费者订阅原理、服务调用原理、线程池模型、负载均衡机制、服务容错机制等内容的回顾,并简要介绍了Dubbo 3.0的新特性。
Dubbo阶段性总结及3.0新特性
|
7月前
|
负载均衡 Dubbo 算法
深入理解Dubbo-2.Dubbo功能之高级特性分析
深入理解Dubbo-2.Dubbo功能之高级特性分析
111 0
|
7月前
|
SpringCloudAlibaba 负载均衡 Dubbo
SpringCloudAlibaba:3.2dubbo的高级特性
SpringCloudAlibaba:3.2dubbo的高级特性
73 1
|
7月前
|
XML Cloud Native Dubbo
【Dubbo3高级特性】「提升系统安全性」手把手教你如何通过令牌进行Dubbo3服务验证及服务鉴权控制实战指南(一)
【Dubbo3高级特性】「提升系统安全性」手把手教你如何通过令牌进行Dubbo3服务验证及服务鉴权控制实战指南
346 1
|
7月前
|
Dubbo Cloud Native 应用服务中间件
【Dubbo3 终极特性】「云原生三中心架构」带你探索 Dubbo3 体系下的配置中心和元数据中心、注册中心的原理及开发实战(中)
【Dubbo3 终极特性】「云原生三中心架构」带你探索 Dubbo3 体系下的配置中心和元数据中心、注册中心的原理及开发实战(中)
218 1
|
7月前
|
XML Dubbo Java
【Dubbo3高级特性】「框架与服务」 Nacos作为注册中心-服务分组及服务分组聚合实现
【Dubbo3高级特性】「框架与服务」 Nacos作为注册中心-服务分组及服务分组聚合实现
284 0
|
7月前
|
Cloud Native Dubbo 应用服务中间件
【Dubbo3高级特性】「微服务云原生架构」带你从零基础认识搭建公司内部服务用户中心体系(实战指南-序章)
【Dubbo3高级特性】「微服务云原生架构」带你从零基础认识搭建公司内部服务用户中心体系(实战指南-序章)
212 0
下一篇
DataWorks