Dubbo使用篇 - 服务路由

郝承悦

2023-12-01

服务路由

筛选出符合路由规则的服务提供者。服务路由包含一条路由规则，路由规则决定了服务消费者的调用目标，即规定了服务消费者可调用哪些服务提供者。

路由规则在发起一次RPC调用前起到过滤目标服务器地址的作用，过滤后的地址列表将作为消费端最终发起RPC调用的备选地址。

条件路由。支持以服务或者Consumer应用为粒度配置路由规则。
标签路由。支持以Provider应用为粒度配置路由规则。
脚本路由。

1、条件路由

应用粒度

# app1的消费者只能消费所有端口为20880的服务实例
# app2的消费者只能消费所有端口为20881的服务实例
scope: application
force: true
runtime: true
enabled: true
key: goverance-conditionrouter-consumer
conditions: 
	- application=app1 => address=*:20880
	- application=app2 => address=*:20881

服务粒度

scope: service
force: true
runtime: true
enabled: true
key: org.apache.dubbo.samples.governance.api.DemoService
conditions: 
	- method=sayHello => address=*.20880
	- method=sayHi => address=*.20881

规则详解

scope：表示路由规则的作用粒度，scope的取值会决定key的取值。必填。
- service：服务粒度。
- application：应用粒度。
key：明确规则作用在哪个服务或者应用。必填。
- scope=service时，key取值为[{group}:]{service}[:{version}]的组合。
- scope=application时，key取值为application名称。
enabled：当前路由规则是否生效，缺省true，即生效。可不填。
force：当路由结果为空时，是否强制执行。缺省false，不强制执行，路由结果为空的路由规则自动失效。可不填。
runtime：是否在每次调用时执行路由规则。缺省false，只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果设置了参数路由，必须设为true，需要注意设置会影响调用的性能。可不填。
priority：路由规则的优先级，用于排序，优先级越大越靠前执行。缺省为0。可不填。
conditions：定义具体的路由规则内容。必填。

Conditions规则体

=>之前的是消费者匹配条件。所有参数和消费者的URL进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
=>之后的是提供者地址列表的匹配条件。所有参数和提供者的URL进行对比，消费者最终拿到过滤后的地址列表。
如果匹配条件为空，表示对所有消费方应用，比如:=> host != 10.20.153.11
如果过滤条件为空，表示禁止访问，如:host = 10.20.153.10 =>

参数支持：

服务调用信息，如：method, argument 等，暂不支持参数路由
URL 本身的字段，如：protocol, host, port 等
以及 URL 上的所有参数，如：application, organization 等

条件支持：

等号 = 表示"匹配"，如：host = 10.20.153.10
不等号 != 表示"不匹配"，如：host != 10.20.153.10

值支持：

以逗号 , 分隔多个值，如：host != 10.20.153.10,10.20.153.11
以星号 * 结尾，表示通配，如：host != 10.20.*
以美元符 $ 开头，表示引用消费者参数，如：host = $host

2、标签路由

标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。

Provider

标签主要是指对Provider端应用实例的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标，其中动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

动态规则打标，可随时在服务治理控制台下发标签归组规则

  # governance-tagrouter-provider应用增加了两个标签分组tag1和tag2
  # tag1包含一个实例 127.0.0.1:20880
  # tag2包含一个实例 127.0.0.1:20881
  ---
    force: false
    runtime: true
    enabled: true
    key: governance-tagrouter-provider
    tags:
      - name: tag1
     		# 当前标签包含的实例列表
        addresses: ["127.0.0.1:20880"]
      - name: tag2
        addresses: ["127.0.0.1:20881"]

静态打标

  <dubbo:provider tag="tag1"/>

<dubbo:service tag="tag1"/>

java -jar xxx-provider.jar -Ddubbo.provider.tag={the tag you want, may come from OS ENV}

Consumer

RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY,"tag1");

请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。

降级约定

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

Dubbo使用篇 - 服务路由

服务路由

相关阅读

相关文章

相关问答

相关文档