vlambda博客
学习文章列表

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

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/

1. 对于实现前文中架构图的路由方式，至少需要将B服务拆分成为两个不同名称的微服务，在网关、A服务上共配置三次路由规则才能实现三个微服务之间基于请求参数的服务路由能力。配置非常复杂。

2.  由于没有注册中心，我们没法对节点的状态进行检测和剔除，当系统中出现坏死节点，必须改变路由配置才能让业务恢复运行。运维困难。

3. 配置后需要重启网关实例配置才能生效，无法热生效。

2. Spring Cloud实现

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

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

zuul.routes.A1=/user1/**

zuul.routes.A2=/user2/**

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

从上述业务场景中，开源Spring Cloud架构在实现上相对麻烦，很难满足实际业务中复杂多变的使用场景。在腾讯微服务平台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 控制台 选择组建中心 - 微服务网关 - 插件管理，点击新建插件
• 创建插件类型为 tag 类型插件，将请求参数中 Header 参数中的 region、usertype 设置为标签。

创建插件类型

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

绑定分组

3. 配置服务治理规则

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

3.1 服务路由

• 新建服务路由规则。
• 创建两条规则，当自定义标签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 的部署组中

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

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

3.3 调用链查询

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

如图所示，下面查询的数据即为携带对应标签的请求trace列表。

1. 腾讯微服务平台TSF预计在4月中推出全链路灰度发布能力，进一步减少配置成本。

2. 预计在6月左右推出流量复制能力。

了解更多有关腾讯微服务框架TSF相关信息！

戳原文，了解更多腾讯微服务平台信息

！

点亮在看，你最好看