以为是青铜,没想到是王者的dubbo标签路由

简介: 在开发测试中我们通常会遇到多项目并行开发测试,假设应用ABCDE均为dubbo应用,需求1修改了应用A、C代码,需求2修改了应用A、B、E代码,此时如果并行测试,需求1可能会调用到需求2修改的代码上,造成测试混乱。

标签路由简介


在开发测试中我们通常会遇到多项目并行开发测试,假设应用ABCDE均为dubbo应用,需求1修改了应用A、C代码,需求2修改了应用A、B、E代码,此时如果并行测试,需求1可能会调用到需求2修改的代码上,造成测试混乱。


640.png


常见的解决方法有如下几种:


  • 每个项目单独部署一整套系统,注册中心也单独部署,优点是实现简单,缺点是机器资源占用太多;
  • 在消费方应用中通过硬编码或者配置文件的方式指定调用的接口机器ip和端口,优点也是实现简单,缺点是依赖配置复杂。此方案在简单的依赖中可以使用,但在依赖复杂的环境中难实施;
  • 通过逻辑上的分组将请求正确的路由,优点是逻辑清晰机器资源占用少,缺点是实现困难。此方案也正是本文需要探讨的方案。


如果使用的是dubbo,那么在dubbo 2.6.6版本之后提供了一个标签路由(tag router)功能来解决此问题。签路由通过将某一个或多个服务的提供者划分到同一个分组,约束流量只在指定分组中流转,从而实现流量隔离的目的,可以作为蓝绿发布、灰度发布等场景的能力基础。


对于provider端,可以通过静态或动态的方式对服务进行打标签,静态打标可以在JVM的启动参数上增加-Ddubbo.provider.tag={env_tag}来实现,动态打标则是直接修改provider在注册中心上的地址实现,我们对provider采取静态打标即可。对于consumer端,请求标签的作用域为每一次 invocation,使用attachment来传递请求标签,注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递,得益于这样的特性,我们只需要在起始调用时,通过一行代码的设置,达到标签的持续传递。目前仅仅支持硬编码的方式设置dubbo.tag。注意到 RpcContext 是线程绑定的,优雅的使用 TagRouter 特性,建议通过 servlet 过滤器(在 web 环境下),或者定制的 SPI 过滤器设置 dubbo.tag。从代码上看它的实现非常简单,核心代码就这么几行


640.png


它与dubbo的version、group机制有什么区别?dubbo的version与group是静态的路由,如果URL中带了不匹配的version,在上图代码中的invokers就根本不存在该服务提供者;而tag路由是动态的,就算带了不匹配的tag,也是会放在invokers中,每次调用时都执行一次路由逻辑。


标签路由降级约定


  • consumer dubbo.tag=tag1 时优先选择标记了tag=tag1的provider。若集群中不存在与请求标记对应的服务,默认将降级请求 tag为空的provider;如果要改变这种默认行为,即找不到匹配tag1的provider返回异常,需设置request.tag.force=true;
  • consumer dubbo.tag未设置时,只会匹配tag为空的provider。即使集群中存在可用的服务,若tag不匹配也就无法调用,这与约定1不同,携带标签的请求可以降级访问到无标签的服务,但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。


标签路由的“bug”


经过测试发现,consumer端的dubbo.tag通过dubbo的attachment 携带给provider端,但是 attachment有一个特点是在dubbo请求完成会把attachment中保存的值清空,也就是说consumer第一次dubbo请求会带dubbo.tag,第二次请求不会带。


640.png


基于dubbo标签路由打造并行测试环境


翻看了标签路由在github上的PR(点击阅读原文可查看),能看出作者也是知道这个问题的,而且提出建议通过servlet 过滤器(在web环境下),或者定制的 SPI 过滤器设置 dubbo.tag。由此我们想到利用dubbo的SPI机制扩展filter来填充attachment,在provider接收到请求时将dubbo.tag存起来,每次发起调用时再将tag塞回attachment。


640.png


还是以开头的例子,两个项目同时测试,则需要两个tag,需求1定义tag为green,需求2定义tag为red


  • 首先需要一套部署ABCD的稳定环境,即没有打tag的环境,其次再创建新的应用A、C,并打上tag=green,创建新应用A、B、E并打上tag=red,让稳定环境与新创建的机器都注册到一个注册中心;
  • 其次在请求发起处将tag塞入attachements,这一步通常是网关或者调用工具来完成;
  • provider端接收到请求将请求中的tag存在ThreadLocal(EnvContext)中;


640.png


  • 第一次调用将执行tag路由选择,当调用完成并执行完ConsumerContextFilter之后再将tag塞回attachements,以便将tag传递给下一次调用;


640.png


  • 最后本次调用完毕,DubboTagProviderFilter会清除存储的tag信息,不污染下一次请求


相关文章
|
Dubbo 应用服务中间件 测试技术
带你读《Apache Dubbo微服务开发从入门到精通》—— 三、 标签路由规则
带你读《Apache Dubbo微服务开发从入门到精通》—— 三、 标签路由规则
233 6
|
Dubbo 应用服务中间件 Apache
带你读《Apache Dubbo微服务开发从入门到精通》—— 二、 条件路由规则
带你读《Apache Dubbo微服务开发从入门到精通》—— 二、 条件路由规则
189 6
|
负载均衡 Dubbo JavaScript
带你读《Apache Dubbo微服务开发从入门到精通》—— 四、 脚本路由规则
带你读《Apache Dubbo微服务开发从入门到精通》—— 四、 脚本路由规则
187 2
|
缓存 Dubbo Cloud Native
Dubbo 3 StateRouter:下一代微服务高效流量路由
目前 MSE 服务治理的 离群实例摘除、标签路由、金丝雀发布、全链路灰度等功能已经使用该路由方案,经过我们的压测与演练,在 CPU、RT 等方面均有不少提升,以 Demo 应用为例 (服务调用的跳数为 2,下游 30 节点,每个节点 1c2g) 其中调用 RT 提升约 6.7%。
454 1
Dubbo 3 StateRouter:下一代微服务高效流量路由
|
缓存 Dubbo 应用服务中间件
Dubbo3 StateRouter下一代高效流量路由机制
目前 MSE 服务治理的 离群实例摘除、标签路由、金丝雀发布、全链路灰度等功能已经使用该路由方案,经过我们的压测与演练,在CPU、RT等方面均有不少提升,以 Demo 应用为例 (服务调用的跳数为2,下游30节点,每个节点1c2g) 其中调用 RT 提升约 6.7%。
Dubbo3 StateRouter下一代高效流量路由机制
|
Dubbo Java 应用服务中间件
Dubbo——Dubbo中的常用标签、服务化最佳实践
Dubbo——Dubbo中的常用标签、服务化最佳实践
Dubbo——Dubbo中的常用标签、服务化最佳实践
|
负载均衡 算法 Dubbo
Dubbo负载均衡和路由规则的区别
强哥的朋友最近就遇到一个问题。有如下情况:代码仓库中有一套使用Dubbo2.x编写的微服务代码CodeW,其中有一个接口方法algoCompute(Map map),这个方法可以根据传入的Map内部信息的不同,加载不同的算法模型进行计算,以此来达到同一套代码可以根据请求参数的不同处理不同需求的目的。
Dubbo负载均衡和路由规则的区别
|
Dubbo 安全 应用服务中间件
当dubbo多注册中心碰上标签路由
今天的主角是标签路由和dubbo的多注册中心。标签路由在之前的文章《以为是青铜,没想到是王者的dubbo标签路由》中已经详细介绍过,多注册中心是dubbo可以使用多个注册中心来提供或者消费服务,利用多注册中心的特性可以搭建多机房。然而很不幸,当多注册中心遇上标签路由,却产生了一个bug。
234 0
当dubbo多注册中心碰上标签路由
|
6月前
|
Dubbo Java 应用服务中间件
微服务学习 | Springboot整合Dubbo+Nacos实现RPC调用
微服务学习 | Springboot整合Dubbo+Nacos实现RPC调用
|
1月前
|
Dubbo Java 应用服务中间件
Spring Cloud Dubbo:微服务通信的高效解决方案
【10月更文挑战第15天】随着信息技术的发展,微服务架构成为企业应用开发的主流。Spring Cloud Dubbo结合了Dubbo的高性能RPC和Spring Cloud的生态系统,提供高效、稳定的微服务通信解决方案。它支持多种通信协议,具备服务注册与发现、负载均衡及容错机制,简化了服务调用的复杂性,使开发者能更专注于业务逻辑的实现。
58 2
下一篇
无影云桌面