服务治理最佳实践：如何快速依据请求参数值进行服务路由、鉴权、限流？

文章来源：infoq腾讯云中间件

微服务网关作为后台架构的入口，提供路由转发、API 管理、访问过滤器等作用，是微服务架构中的重要组件。开源社区中存在多种方式实现微服务网关的功能，但同时也存在不灵活、运维难的问题。本文从实际业务场景出发，通过实际操作为大家演示腾讯云微服务平台 TSF(Tencent Service Framework)是如何解决上述问题的。

前言

微服务网关通过服务路由、API 管理、负载均衡、访问限制等功能，在一定程度上可以实现服务治理，帮助我们管理各个服务之间的调用及关联关系。我们来看这样一个场景：当有外部请求时，我们希望依据某些参数值来决定路由可转发到服务的某个版本，或依据参数值对请求进行限流、鉴权等操作。如下图所示，外网请求通过网关访问后端微服务，当请求参数 region = guangzhou 时，我们希望可以路由转发到微服务的版本 1 中；当 region = shanghai 时，路由可以转发到微服务的版本 2 中。

访问链路

这个场景在实际业务中非常常见，那我们先来看下使用开源方案如何实现基于业务参数的服务治理。

开源社区服务路由初探

在开源社区中，根据不同语言和微服务的技术选型，有以下几种方式实现服务路由能力。

1. 传统路由配置

当我们不依赖服务发现机制的时候，我们通常需要通过具体的配置文件来指定路由的表达式与服务实例的映射关系。当网关调用某个微服务时，若微服务上有多个节点需要进行负载均衡，则需要如下配置：

zuul.routes.user-service.path=/user/**
zuul.routes.user-service.serviceId=user

ribbon.eureka.enabled=false
user-service.ribbon.listOfServers=http://localhost:8080/,http://localhost:8081/

通过上面的配置即可实现/user/**的请求转发到两个实例上去。但我们很容易发现这种配置方式存在以下几个问题：

对于实现前文中架构图的路由方式，至少需要将B服务拆分成为两个不同名称的微服务，在网关、A服务上共配置三次路由规则才能实现三个微服务之间基于请求参数的服务路由能力。配置非常复杂。
由于没有注册中心，我们没法对节点的状态进行检测和剔除，当系统中出现坏死节点，必须改变路由配置才能让业务恢复运行。运维困难。
配置后需要重启网关实例配置才能生效，无法热生效。

2. Spring Cloud 实现

当我们依赖原生 Spring Cloud 的的注册中心：Consul 或 Euraka 以及原生的微服务网关组件 Zuul 或者 Spring Cloud Gateway 来实现服务的自动注册与发现，在网关层面，不需要将节点 ip 配置在转发路径上，注册中心将为我们提供服务与节点的对应关系。

由于只有在网关处可以实现依据不同请求参数转发请求到不同微服务，上图中的架构图需要调整为：其中 A1 A2，B1 B2 都在不同的实例上。

在实现上，我们需要这样配置：在网关上配置不同请求参数转发到不同的微服务 A 中。尽管 B1 和 B2 服务仅仅有一些版本上的差异，接口相同，但是由于无法直接实现 A 服务依据不同参数转发到 B 服务的不同实例上，需要将 A 服务也拆成两个服务来保证请求的一一对应。

zuul.routes.A1=/user1/**

zuul.routes.A2=/user2/**

这样配置依然存在以下问题：

尽管不需要配置实际的节点对应关系，但是由于无法实现微服务之间的不同请求参数转发到不同节点，需要拆分多个微服务，非常复杂。
而且由于路由配置需要写在properties中，如果需要调整路由则需要重启网关。无法灵活调整。

TSF 微服务网关路由能力

从上述业务场景中，开源 Spring Cloud 架构在实现上相对麻烦，很难满足实际业务中复杂多变的使用场景。在腾讯微服务平台 TSF 中，我们提供了以上场景的解决方案，方案的优势为：

页面化配置，无需修改代码，上手方便。管理方便。
随时控制规则生效状态，立即生效，无需重启。
可以灵活实现基于业务参数的路由、限流、鉴权策略，并且可以依据业务参数进行单条请求的过滤，方便运维。
支持可视化运维，可直接查看路由、限流规则的生效情况，也可以查看监控平台。

基于 TSF 的服务治理实践

开始进行本实践之前，你需要先了解下 TSF 中的以下功能：

微服务网关的部署：微服务网关是微服务的请求入口，它本身也是一个微服务。用户可以通过微服务网关托管不同微服务的API。详细微服务网关的部署方式请参考:https://cloud.tencent.com/document/product/649/40200
服务路由：用户可以配置流量分配权重，设置某些权重的流量被分配到某个版本号中，为灰度发布等上线模式提供了无需终止服务的底层能力支持。

下面就开始我们的基于业务参数的服务治理实践指引。

1. 准备工作

准备两个微服务 consumer -demo；provider - demo。其中 provider - demo 存在两个版本的包 provider-demo-guangzhou.jar，provider-demo-shanghai.jar。两个版本在访问请求携带 region 参数并访问 /test-region 接口时，会分别返回 shanghai 和 guangzhou。请求 provider - demo 时，可以携带两个 Header 参数，region 和 usertype。

consumer - demo 部署在一个部署组上，provider - demo 部署在两个部署组上，每个部署组部署一个版本的 jar 包。

有关创建部署组的相关操作请参考：https://cloud.tencent.com/document/product/649/16932

部署一个微服务网关，使用官网 demo ，部署后服务名为 msgw - demo，部署组名称为test，默认端口为8080 （请注意给对应机器开放8080端口。）在本demo中，将直接通过网关访问微服务provider。有关部署微服务网关的操作请参考： https://cloud.tencent.com/document/product/649/40200
新建微服务网关分组，并将微服务网关分组绑定在创建好的网关应用部署组上。

新建微服务网关部署组

绑定网关部署组

将微服务API导入到分组中，并将分组进行发布。

分组发布

2. 配置微服务网关插件

在这一步中，我们在网关配置插件，将请求参数转化为 TSF 中的标签信息。

在 TSF 控制台选择组建中心 - 微服务网关 - 插件管理，点击新建插件
创建插件类型为 tag 类型插件，将请求参数中 Header 参数中的 region、usertype 设置为标签。

创建插件类型

在插件列表页面将创建好的插件与准备工作中创建的分组进行绑定

绑定分组

3. 配置服务治理规则

在这一步中，我们配置依据上一步已经转化的标签，配置服务治理规则。当前 TSF 标签可以与服务路由、服务鉴权、服务限流、调用链进行联动。本文中为您介绍路由、鉴权、以及调用链联动功能。

3.1 服务路由

登陆 TSF 控制台，点击服务治理，找到创建好的 provider - demo 微服务，点击详情至服务路由页面。请注意，路由规则始终是在被调用方进行配置的。

新建服务路由规则。
创建两条规则，当自定义标签region值为guangzhou时，100%的流量指向部署了provider-demo-guangzhou.jar的部署组，当自定义标签region值为shanghai时，100%的流量指向部署了provider-demo-shanghai.jar的部署组。规则配置可参考下图：

创建服务路由规则

生效规则，效果验证：公网发送请求：http://129.XX.XX.XX:8080/test-region/tj-test-1_default/provider-demo/test-region/12，携带Header参数 region = shanghai。验证后，发现请求的确路由到了返回值为 shanghai 的部署组中

同理，当请求 Header 参数 = guangzhou 时，请求也路由到了返回值为 guangzhou 的部署组中。

3.2 服务鉴权

登陆 TSF 控制台，点击服务治理，找到创建好的 provider - demo 微服务，点击详情至服务鉴权页面。
配置服务鉴权规则，我们希望实现的是，当请求参数 Header 中携带了参数usertype = user时，请求不通过。配置方式如下，选择自定义标签，usertype = user 生效。

结果验证：同理发送请求，携带 Header 参数usertype = user，region = shanghai。发现返回请求失败。

3.3 调用链查询

在 TSF 中，我们提供了基于请求标签过滤调用链的能力，你可以依据业务数据过滤对应请求的调用链。最为常见的场景是查询某个用户 id 的请求调用成功失败情况以及层级耗时。使用方法：

访问 TSF 控制台，点击运维中心 - 调用链查询，选择对应的命名空间和微服务
点击 “展开高级查询条件”输入查询标签，此处我们输入 userid：1000001，过滤userid 为1000001的请求数据