写点什么

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

  • 2021-01-11
  • 本文字数:3292 字

    阅读完需:约 11 分钟

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

微服务网关作为后台架构的入口,提供路由转发、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=falseuser-service.ribbon.listOfServers=http://localhost:8080/,http://localhost:8081/
复制代码


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


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

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

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


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/**
复制代码


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


  1. 尽管不需要配置实际的节点对应关系,但是由于无法实现微服务之间的不同请求参数转发到不同节点,需要拆分多个微服务,非常复杂。

  2. 而且由于路由配置需要写在 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 的请求数据



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


头图:Unsplash

作者:杨蕊

原文:https://mp.weixin.qq.com/s/i5jZdvEeQ6qds0xdyMeFTA

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

来源:腾讯云中间件 - 微信公众号 [ID:gh_6ea1bc2dd5fd]

转载:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

2021-01-11 21:002455

评论

发布
暂无评论
发现更多内容

架构师0期week2-作业

小高

编程的本质

GalaxyCreater

架构

RPC实战与核心原理-学习笔记(4)

程序员老王

第二周课程学习总结

腾志文(清样)

作业

作业2

annie

极客大学架构师训练营

拼多多市值快 1000 亿美元了

池建强

创业 拼多多

【总结】框架设计之架构师实现自己架构目标的主要手段

魔曦

极客大学架构师训练营

架构师培训第二周作业

talen

极客时间 - 架构师训练营 - week2 - 作业

毛聪

依赖倒置原则

清风明月

极客大学架构师训练营

02架构的方法论

ashuai1106

架构设计 极客大学架构师训练营 架构设计原则

架构师训练营第二周总结

时来运转

设计原则

GalaxyCreater

架构

第二周作业

王鑫龙

极客大学架构师训练营

架构师训练营第二周总结

烟雨濛濛

外包程序员的幸福生活

四猿外

依赖倒置原则理解

Thrine

架构培训 -02 学习总结 架构师实现自己架构的主要手段

刘敏

架构师训练营第二周命题作业

whiter

极客大学架构师训练营

设计原则——依赖倒置原则

GalaxyCreater

架构

极客时间 - 架构师训练营 - week2 - 课堂笔记

毛聪

Week2学习总结

铁血杰克

深入理解JVM垃圾回收机制 - 运行时栈帧的内存变化

Skye

深入理解JVM 运行时栈帧

架构师 0 期 | 架构师怎样实现架构目标?

刁架构

设计模式 极客大学架构师训练营

一周信创舆情观察(6.8~6.14)

统小信uos

新基建 信创

架构作业-第2周

铁血杰克

学习总结 -- Week2

吴炳华

极客大学架构师训练营

极客大学架构师训练营第二周学习总结

竹森先生

设计模式 架构设计 极客大学架构师训练营 面向对象设计原则

架构师训练营-第二课作业-20200617-设计原则???

👑👑merlan

架构设计 软件设计

架构师训练营第二周作业

时来运转

豆瓣9.0,35万读者“搜不到信息”的神秘作者,我们帮你找到了

华章IT

JVM 虚拟机 深入理解JVM Java 25 周年 周志明

服务治理最佳实践:如何快速依据请求参数值进行服务路由、鉴权、限流?_服务革新_腾讯云中间件_InfoQ精选文章