一种dubbo逻辑路由方案（服务化隔离环境）

时间：2024-01-23 09:13:41

背景介绍

现在很多的公司都在用dubbo、springcloud做为服务化/微服务的开发框架，服务化之后应用越来越多，链路越来越长，服务环境的治理变的很困难。比如：研发团队的人很多的，同时有几个分支在开发和测试，会造成多个同名的服务存在，为了避免不同feature之间的服务不串调，很多研发人员会改服务的版本号来避免这种情况；还有一种情况是因为修改服务版本号，调用链链路上所有的节点都需要修改，存在浪费机器资源的现象。

需求场景描述

  1. 稳定的测试环境一般是有测试的同学维护的，上面的代码一般是验证完成（即将上线）的分支，或者就是和线上代码保持一致的分支（基准代码）；
  2. 下图中需求1是正在开发的某个需求，它涉及了2个需要改动的应用A和B，由于他们在需求1里（代码也切分支），我们称需求1里面的应用A为A1，需求1里面的应用B为B1；
  3. 同理，需求2也是正在开发的某个需求，因为它和需求1同时开发，涉及的应用也有重合，所以称为并发需求。需求2中的应用A为A2，应用B为B2，应用E为E2;
  4. 在不修改服务版本号的情况下，需求1的研发人员希望A1直接调用下游B，然后B调用C1，因为应用B、C、D在需求1里面是没有代码变更的，所以完整的调用链路如下：A1->B->C1->D->E
  5. 需求2中有代码变更的应用是A2、B2、E2，不需要更变的是C、D，所以完成的调用链路如下：A2->B2->C->D->E2

总结起来：
研发只希望调用本需求内应用，如果链路中某个应用没有代码变更，则调用稳定环境中的应用（保证链路能走通，并且把这种逻辑路由的关系传递到下游应用中）

谈dubbo路由

dubbo框架内部自带路由的，它支持2种路由规则：ConditionRouter、ScriptRouter，MockInvokersSelector暂时不讨论。

1、 其中ConditionRouter表示条件路由，条件表达式以 => 分割为whenRule和thenRule：

例子：*

condition://0.0.0.0/com.foo.BarService?category=routers&dynamic=false&rule=" + URL.encode("host = 10.20.153.10 => host = 10.20.153.11"

  • 从url根据RULE_KEY获取路由条件路由内容
  • rule.indexOf("=>") 分割路由内容： =>前面是消费者条件(when)，=>后面是provider的条件(then)
  • 分别调用parseRule(rule) 解析路由为whenRule和thenRules

ConditionRouter执行route方法:

  • 如果url不满足when条件即过来条件， 不过滤返回所有invokers
  • 遍历所有invokers判断是否满足then条件， 将满足条件的加入集合result
  • Result不为空，有满足条件的invokers返回
  • Result为空， 没有满足条件的invokers, 判断参数FORCE_KEY是否强制过来，如果强制过滤返回空， 不是返回所有即不过滤

ConditionRouter的点评

ConditionRouter并不是适合我们的需求，因为我们需要是配合简单运维实现自动路由，不需要开发人员写额外代码和配置，很显然ConditionRouter=>后面的then条件是固定的一个provider或者一组provider，而不能动态路由；第二点是ConditionRouter在稳定测试环境的应用上也需要在URL里面打上路由标识，这就违反了我们初衷：不需要开发人员写额外代码和配置

2、 ScriptRouter表示脚本路由

通过url的RULE_KEY参数获取脚本内容，然后通过java的脚本引擎执行脚本代码， dubbo的测试用例都是通过javascript作为脚本但是理论上也支持groovy, jruby脚本

  • 从url获取脚本类型javascript, groovy等等
  • 从url根据RULE_KEY获取路由规则内容
  • 根据脚本类型获取java支持的脚本执行引擎

ScriptRouter的点评

ScriptRouter虽然比ConditionRouter灵活，可以在消费端执行脚本来控制路由的逻辑，但是还是有同样的问题，对于稳定的测试环境里的应用也需要配置路由脚本，不能做到真正的少配置、少运维、少写额外代码

逻辑路由的方案

我们分析了场景和需求，又分析现有的dubbo路由方案的不满足，现在来来看一下一种可行的方案：

  1. 逻辑路由provider和consumer都通过URL来获取路由标识
  2. 最小运维开支：通过申请应用环境的时候，在机器打上环境变量
  3. 最小的dubbo框架改动：在LoadBalance和AbstractClusterInvoker上修改逻辑路由方案

show me code

具体实现的代码，我放在github上，变更也不大，分支

  1. 在LoadBalance和AbstractClusterInvoker上修改逻辑路由主要逻辑
  2. 在provider注册服务的URL时，加上逻辑路由的标识
  3. dubbox新增加了一个依赖：logical-router，这是我自己写的小的jar包，方便之后做扩展（比如rest入口的应用程序，自启动的应用程序等等）
  4. 运维相关：只需要给申请相同的逻辑路由标识应用的机器，打上相同的环境变量：LOGICAL_ROUTER_ENV

diff文件

更方便的查看变更：diff文件

相关文章