Dubbo Cluster

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 这个版本有 10 种容错机制每个具体的 Cluster 实现都是创建一个对应的 Invoker、然后直接返回

Cluster 层

集群容错层、该层中包含 Cluster、Directory、Router、LoadBalance几大核心接口

网络异常,图片无法展示
|

网络异常,图片无法展示
|

这个版本有 10 种容错机制

每个具体的 Cluster 实现都是创建一个对应的 Invoker、然后直接返回


Failover


网络异常,图片无法展示
|

网络异常,图片无法展示
|

  • list(invocation) 从 Directory 中获取提供者的列表
  • initLoadBalance(invokers, invocation); 选择出负载均衡策略
  • doInvoke(invocation, invokers, loadbalance) 调用子类具体实现


很明显、这个是一个模板方法

网络异常,图片无法展示
|

  • checkInvokers(copyInvokers, invocation) 判断 Invoker 列表是否为空、为空则抛出异常
  • int len = getUrl().getMethodParameter(methodName, RETRIES_KEY, DEFAULT_RETRIES) + 1; 获取用户配置的重试次数、如果没有则默认是重试 2 次、这里 +1 是因为正常调用
  • invoked 变脸用于存储已经发起调用过的 Invoker、也就是存在于这个集合里面的、都是调用过发生RPC异常的
  • 当你第一次调用失败之后、那么每一次循环都会重新从 Diretory 中获取最新的 Invoker 列表、因为调用次数是死的、已经失败过一次了、尽可能保证被调用的 Invoker 的质量
  • select(loadbalance, invocation, copyInvokers, invoked) 根据具体的负载均衡算法算出一个 Invoker


Failfast


网络异常,图片无法展示
|


Failsafe


网络异常,图片无法展示
|


Failback


网络异常,图片无法展示
|

网络异常,图片无法展示
|


这个后续的调度重试涉及到时间轮的设计、但是我们在这里只要知道它也会重试、这里默认重试的次数是三次


Forking


同时调用多个相同的服务、只要其中一个返回、则立即返回结果。用户可以配置 forking 参数、来确定最大并行调用的服务数量。

通常使用在对接口实时性要求极高的调用上、但会浪费更多的资源

@Override
 @SuppressWarnings({"unchecked", "rawtypes"})
 public Result doInvoke(final Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
     try {
         checkInvokers(invokers, invocation);
         final List<Invoker<T>> selected;
         final int forks = getUrl().getParameter(FORKS_KEY, DEFAULT_FORKS);
         final int timeout = getUrl().getParameter(TIMEOUT_KEY, DEFAULT_TIMEOUT);
         if (forks <= 0 || forks >= invokers.size()) {
             selected = invokers;
         } else {
             selected = new ArrayList<>(forks);
             while (selected.size() < forks) {
                 Invoker<T> invoker = select(loadbalance, invocation, invokers, selected);
                 if (!selected.contains(invoker)) {
                     //Avoid add the same invoker several times.
                     selected.add(invoker);
                 }
             }
         }
         RpcContext.getContext().setInvokers((List) selected);
         final AtomicInteger count = new AtomicInteger();
         final BlockingQueue<Object> ref = new LinkedBlockingQueue<>();
         for (final Invoker<T> invoker : selected) {
             executor.execute(() -> {
                 try {
                     Result result = invoker.invoke(invocation);
                     ref.offer(result);
                 } catch (Throwable e) {
                     int value = count.incrementAndGet();
                     if (value >= selected.size()) {
                         ref.offer(e);
                     }
                 }
             });
         }
         try {
             Object ret = ref.poll(timeout, TimeUnit.MILLISECONDS);
             if (ret instanceof Throwable) {
                 Throwable e = (Throwable) ret;
                 throw new RpcException("");
             }
             return (Result) ret;
         } catch (InterruptedException e) {
             throw new RpcException("Failed to forking invoke provider " + selected + ", but no luck to perform the invocation. Last error is: " + e.getMessage(), e);
         }
     } finally {
         // clear attachments which is binding to current thread.
         RpcContext.getContext().clearAttachments();
     }
 }
复制代码

默认最大的并行数是 2 个、超时时间是 1 秒。

第一步就是选出合适的 invoker、根据负载均衡算法。如果 forking 的数量大于等于 invoker 的数量、那么就直接不用选了

后续使用线程池异步发起调用、使用 BlockingQueue 对存储结果。最后使用 poll 等待结果、


Broadcast


广播调用所有可用服务、任意一个节点报错则报错。因为请求是调用所以节点、所以不需要做负载均衡

网络异常,图片无法展示
|


Mock


提供者调用失败时、返回伪造的响应结果。或直接强制返回伪造结果、不会发起远程调用

网络异常,图片无法展示
|

  • 默认情况下、或者明确配置了 false、那么直接调用 invoker
  • 配置了 force 开头、那么直接走 mock 逻辑(相当于熔断了)
  • 除了上面的情况、invoker 失败或者异常的情况下、走 mock (相当于降级)


Available


网络异常,图片无法展示
|


Mergeable


自动把多个节点请求得到的结果进行合并

网络异常,图片无法展示
|

网络异常,图片无法展示
|

网络异常,图片无法展示
|

调用所有的 invoker、设置为异步调用。后续对返回的结果进行处理合并

内置的合并器

网络异常,图片无法展示
|


Zone


这个是新版本家的一个集群策略、主要是真的注册中心的负载、也即是对多注册中心进行负载均衡

网络异常,图片无法展示
|

网络异常,图片无法展示
|

  • 如果该 Invoker 中有 preferred 值为 true 、那么就直接选该注册中心
  • 如果消费者和服务注册中心注册地址是在同一个 zone 的话、那么优先选择该服务注册中心
  • 如果都没有配置、那么就根据负载均衡算法选出一个



相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
存储 缓存 负载均衡
Dubbo Cluster集群那点你不知道的事。
现在有这样一个需求:一个如果接口调用失败,需要自动进行重试。虽然关系不大,但是我还是想到了Dubbo的集群容错策略:Failover Cluster,即失败自动切换。(这个转折是不是有点...
181 0
|
存储 负载均衡 Dubbo
Dubbo Cluster集群那点你不知道的事。 (下)
Dubbo Cluster集群那点你不知道的事。 (下)
209 0
|
缓存 负载均衡 Dubbo
Dubbo Cluster集群那点你不知道的事。 (上)
Dubbo Cluster集群那点你不知道的事。 (上)
183 0
|
负载均衡 Dubbo 应用服务中间件
Dubbo Cluster介绍
开篇  这篇文章的目的主要是为了分析Consumer侧Cluster的初始化过程,并针对Consumer实际执行invoke()的过程ClusterInvoker的执行流程进行分解。  Cluster初始化过程中会梳理Cluster和ClusterInvoker的关系,了解核心的join()方法。
1819 0
|
7月前
|
Dubbo Java 应用服务中间件
微服务学习 | Springboot整合Dubbo+Nacos实现RPC调用
微服务学习 | Springboot整合Dubbo+Nacos实现RPC调用
|
2月前
|
Dubbo Java 应用服务中间件
Spring Cloud Dubbo:微服务通信的高效解决方案
【10月更文挑战第15天】随着信息技术的发展,微服务架构成为企业应用开发的主流。Spring Cloud Dubbo结合了Dubbo的高性能RPC和Spring Cloud的生态系统,提供高效、稳定的微服务通信解决方案。它支持多种通信协议,具备服务注册与发现、负载均衡及容错机制,简化了服务调用的复杂性,使开发者能更专注于业务逻辑的实现。
70 2
|
4月前
|
Dubbo Java 应用服务中间件
💥Spring Cloud Dubbo火爆来袭!微服务通信的终极利器,你知道它有多强大吗?🔥
【8月更文挑战第29天】随着信息技术的发展,微服务架构成为企业应用开发的主流模式,而高效的微服务通信至关重要。Spring Cloud Dubbo通过整合Dubbo与Spring Cloud的优势,提供高性能RPC通信及丰富的生态支持,包括服务注册与发现、负载均衡和容错机制等,简化了服务调用管理并支持多种通信协议,提升了系统的可伸缩性和稳定性,成为微服务通信领域的优选方案。开发者仅需关注业务逻辑,而无需过多关心底层通信细节,使得Spring Cloud Dubbo在未来微服务开发中将更加受到青睐。
89 0
|
26天前
|
Dubbo Cloud Native 应用服务中间件
阿里云的 Dubbo 和 Nacos 深度整合,提供了高效的服务注册与发现、配置管理等关键功能,简化了微服务治理,提升了系统的灵活性和可靠性。
在云原生时代,微服务架构成为主流。阿里云的 Dubbo 和 Nacos 深度整合,提供了高效的服务注册与发现、配置管理等关键功能,简化了微服务治理,提升了系统的灵活性和可靠性。示例代码展示了如何在项目中实现两者的整合,通过 Nacos 动态调整服务状态和配置,适应多变的业务需求。
37 2
|
2月前
|
Dubbo Java 应用服务中间件
Dubbo学习圣经:从入门到精通 Dubbo3.0 + SpringCloud Alibaba 微服务基础框架
尼恩团队的15大技术圣经,旨在帮助开发者系统化、体系化地掌握核心技术,提升技术实力,从而在面试和工作中脱颖而出。本文介绍了如何使用Dubbo3.0与Spring Cloud Gateway进行整合,解决传统Dubbo架构缺乏HTTP入口的问题,实现高性能的微服务网关。
|
3月前
|
Dubbo 应用服务中间件 Apache
Star 4w+,Apache Dubbo 3.3 全新发布,Triple X 领衔,开启微服务通信新时代
在 Apache Dubbo 突破 4w Star 之际,Apache Dubbo 团队正式宣布,Dubbo 3.3 正式发布!作为全球领先的开源微服务框架,Dubbo 一直致力于为开发者提供高性能、可扩展且灵活的分布式服务解决方案。此次发布的 Dubbo 3.3,通过 Triple X 的全新升级,突破了以往局限,实现了对南北向与东西向流量的全面支持,并提升了对云原生架构的友好性。
154 10
下一篇
DataWorks