动态路由

自定义路由

路由规则分类

规则路由是一种根据一段DSL（路由规则）来控制消息分流的机制。

路由规则分为被调规则和主调规则2部分：

• 被调规则代表的是当服务作为被调方时，控制所有主调方进行流量转发的规则。

• 主调规则代表的是当服务作为主调方时，控制所有被调方进行流量转发的规则。

  

服务上可以配置主调规则和被调规则，如下图所示：

• 主调规则

  

• 被调规则

  

配置被调规则

被调规则在服务作为被调方时候生效，配置界面如下：

图上的规则的含义是：当echo-server（服务名）作为被调方时，对于所有主调方过来的，带有user-type:1的标签的请求，都路由给自身服务版本号为1.0.0的实例分组。

配置主调规则

主调规则在服务作为主调方时候生效，配置界面如下：

图上的规则的含义是：当echo-server（服务名）作为主调方时，对于发出去的请求，带有user-type:1的标签的请求，都路由给目标服务版本号为1.0.0的实例分组。

路由规则的匹配流程

请求匹配规则

可选，指定限流规则的请求参数匹配条件，不填代表不过滤，支持以下四种参数类型：

• 自定义参数：自定义KEY和VALUE，具体的请求参数值可通过SDK进行传入。

• 请求头（HEADER）：针对协议消息头（http header/grpc header）进行过滤。

• 请求参数（QUERY）：针对协议请求参数（http query）进行过滤。

• 请求COOKIE（COOKIE）：针对协议 cookie 参数（http cookie）进行过滤。

• 方法（METHOD)：针对协议的METHOD（http method/grpc method）进行过滤。

• 主调IP（CALLER_IP）：针对主调方机器的IP地址进行过滤。

• 路径（PATH）：针对协议请求路径进行过滤

每种类型参数值支持以下几种值匹配模式：

• 全匹配：全值匹配，传入的值与配置的值相同才匹配通过。

• 正则表达式：用户配置正则表达式，通过正则表达式对传入的值进行匹配，正则表达式支持Google RE2标准。

• 不等于：取反匹配，传入的值与所配置的值不相等才算匹配成功。

• 包含：多字符串取OR匹配，传入的值只要匹配到其中一个字符串，就算匹配成功。字符串之间使用逗号进行分割。值格式为’value1,value2,value3‘，匹配到其中一个就算成功。

• 不包含：多字符串取反匹配，传入的值必须都没有出现在所配置的字符串列表中，才算匹配通过。值格式为’value1,value2,value3‘，全部不等于才算成功。

边界条件

• 通过请求标签进行匹配，没有匹配到一个路由规则，则本次请求路由失败，返回空实例列表。
• 通过请求标签进行匹配，匹配到了路由规则，但是路由规则所对应的destination不存在服务实例，则本次请求获取到的服务实例为空。
• 通过请求标签进行匹配，匹配到了路由规则，路由规则对应的2个同优先级的destination，请求会在这2个destination中按照权重比例随机路由，假如其中一个destination不存在服务实例，则路由到该destination的请求获取到的服务实例为空。

自定义路由实践

按版本号灰度实践

场景描述

请求通过网关接入，路由到后端服务。后端服务上线了新版本，新版本只对打了标签的用户请求开放，未打标签的请求继续路由到老版本。

使用方式

• 配置路由规则

  由于新版本上线的行为发生在被调方，主调方并不感知被调是否上线了新版本服务，因此路由规则需要配置在被调方。配置一个被调规则，指定只有gray=true的请求，才流入版本号为2.0.0的实例分组，其他请求则流入版本号为1.0.0的实例分组。

  (1) 配置兜底规则：将请求导入到1.0.0版本的分组。

  

(2) 配置灰度规则：将gray=true的请求导入到2.0.0版本的分组，不存在2.0.0分组时，请求导入到1.0.0的分组。

(3) 规则列表：将按顺序进行匹配执行规则。

• 执行服务路由

  可以执行各个语言SDK的版本号路由样例进行服务路由功能的执行，执行完可以通过调用结果可以看到灰度的请求都流向了版本号2.0.0的分组。

多环境隔离实践

场景描述

使用微服务架构时，一个业务数据流通常需要跨多个微服务才能完成。而在业务开发过程中，通常会有以下诉求：

• 为了提升开发效率，不同特性开发人员，需要使用特性环境进行并发开发测试联调，特性环境之间需要进行隔离；

• 同时为了降低部署成本，开发测试时，只需要部署特性变更所涉及的服务，链路其他未更改的服务，统一使用基线环境的服务。

  

使用方式

• 配置路由规则

本次场景，存在2个特性并行开发，特性（dev1）涉及修改的微服务为Svr1和Srv4，特性（dev2）涉及修改的微服务为Svr2。其他不涉及修改的微服务，在开发联调过程中，统一使用基线环境的服务。 为了防止混乱，每个特性开发人员只允许针对自己涉及修改的微服务添加针对当前特性的规则，不涉及修改的微服务不允许添加规则。

（1）所有的服务默认配置一个兜底规则，将请求导入到基线环境。

（2）Srv1服务添加一个主调规则，将来源dev1请求路由到dev1的Svr2。

（3）Svr4服务添加一个被调规则，将来源dev1请求路由到dev1的Svr4。

（4）Svr2服务添加一个被调规则，将来源dev2请求路由到dev2的Svr2。

• 执行服务路由

  可以执行各个语言SDK的多环境路由样例进行服务路由功能的执行，执行完可以通过调用结果可以看到不同特性环境的请求都流向了对应特性环境的分组。

• ←上一篇

• 下一篇→