服务治理之标签路由(转)

本文转载自公众号三维家技术实践的服务治理系列文章

1 背景

目前,微服务架构是互联网企业的标配,从单体架构到微服务架构,服务的数量急剧膨胀,且相互之间依赖错综复杂。服务治理,对开发、运维都是一个严峻的考验。

例如,在开发过程中,为了赶进度,一个服务往往有多个Feature版本在并行开发。那么,同一个服务的多个版本如何在开发联调、测试中做到互不影响呢?

最简单粗暴的一种方案是建设多套开发、测试环境,各环境有独立的注册中心、配置中心、服务集群以及相关中间件。显然,这种等同物理隔离的方式,硬件成本高,维护成本大,而且需要建设多少套才够用? 恐怕没有确定的答案。

所以,如何通过一种轻量的模式,既可以满足我们多版本并行开发和测试的需要,又可以兼顾低成本和易维护呢?

抽象引申一下,就是我们需要有一套低成本的、满足多版本服务并行在同一个服务集群的机制,该机制除了满足开发、测试的需要外, 还能在生产环境中实现新老版本并行,也就是灰度发布的需求。

2 需求

让我们再来理一下需求:

  • 在开发阶段,需要保证多版本并行开发和联调。
  • 在测试阶段,需要保证多版本并行测试。
  • 在发布阶段,需要灰度发布机制,保证产品平滑过渡。

基于上述的背景和需求,我们尝试通过标签路由来解决这个问题。

3 设计思路

我们从服务路由标签的定义、原理以及常见路由规则设置这三方面进行阐述。

3.1 服务路由标签的定义

image

每个服务在启动时,都会被赋予一个用于识别其版本的标签, 我们称之为服务路由标签, 一般采用迭代版本号作为标签, 例如feature-V0506。 如果没有赋予,则默认为default。该标签会作为服务的一个元数据,随着服务节点信息注册到注册中心上。

例如上图,我们的开发环境dev, 包括一个注册中心,以及一套稳定的服务集群(其路由标签均为default),包括building、usercenter、material等服务。

然后程序猿A在本地开发building服务的名为F_1的特性分支, 其对应的路由标签也为F_1,且已经注册到注册中心了;程序猿B在本地开发building服务的F_2特性分支, 其对应的路由标签也为F_2

这时候我们看到, 该服务在注册中心中有3个版本,分别为稳定的默认版本defaultF_1以及F_2

服务的路由标签R-Label,可在服务的启动参数或者环境变量中设置。

稳定版本,一般为生产上的版本(对应master分支)

3.2 服务路由标签的原理

上一节我们已经讲述了路由标签作为元数据,会随服务信息注册到注册中心上,那么它有什么用呢?

我们在调用链的头部(一般为网关,或者在非生产环境下为postManswagger文档站点甚至curl等),根据一定规则把路由标签设置到请求头中 (请求头key为R-Label,一个请求最多带一个标签,没有则默认为default),这个请求头将会作为一个染色字段在整个调用链路中透传。

那么在服务的路由选择逻辑中,我们会优先选择版本跟请求的标签值相同的节点。如果找不到相同标签的节点,就选择default的服务节点。

例如上述程序猿A,其本地building服务版本为F_1,该服务的接口A依赖usercenter以及material两个服务。那么在自测的时候,其调用链路是

前端(postMan/swagger等)->apiGateway->building->usercenter->material

这时,程序猿A在前端(手动)或者apiGateway(通过染色规则)中加上染色字段R-Label:F_1,那么apiGateway在选择building节点的时候,选择了路由标签为F_1的节点(也就是程序猿A的本地节点),其最终调用路径为:

前端(postMan/swagger等)->apiGateway->building.F_1->usercenter.default->material.default

同理, 程序猿B在自测的时候,其最终调用路径为:

前端(postMan/swagger等)->apiGateway->building.F_2->usercenter.default->material.default

还记得我们上一篇关于链路染色的服务治理文章吗?本篇也是其落地场景之一

3.3 路由规则

路由规则设置在配置中心,并实时推送至网关,它是网关对请求做整形的依据之一。
在网关中,我们根据路由规则, 给特定的请求打上特定的路由标签,并作为染色字段透传到整个服务集群。

路由规则暂时支持如下几种:

3.3.1 组Id路由

gId match 'G0168' => L'feature-V0506'
gId match 'G0235' => L'feature-V0506'

表示根据gId进行打标,当请求的gId请求头等于G0168或者G0235时,给请求加上请求头(染色字段): R-Label:feature-V0506

3.3.2 用户uId路由

uId match 1024 => L'feature-V0506'

表示根据uId进行灰度,当请求的uId1024时,给请求加上请求头(染色字段): R-Label:feature-V0506

uId match %'10n+1' => L'feature-V0506'

表示uId与10取模结果为1时,执行请求整形,相当于1/10的用户访问指定版本的服务

uId match %'10n+3..5' => L'feature-V0506'

表示uId与10取模结果为3到5的用户,执行请求整形,相当于3/10的用户访问指定版本的服务

路由规则暂只支持基于特定请求头的规则

请求整形,是指在请求处理前,改变请求的内容(通常是增加请求头字段)

4 应用场景

4.1 多版本开发联调

image
  • 开发环境部署相对稳定的版本(一般为master分支)
  • 本地和开发环境共用注册中心

程序猿B和程序猿C进行本地联调的时候,给各自服务加上R-Label:F_2(通过环境变量或启动参数的方式),那么服务在请求的路由选址的时候,会优先选择选择B跟C的本地服务。如果找不到相同标签,就选择默认default的服务节点。

4.2 多版本测试

image
  • 测试环境中部署相对稳定的版本(一般为master分支)
  • 不同迭代版本采用不同的路由标签

甚至,我们可以把开发环境跟测试环境合并为一个,保持环境的独立性的同时,进一步节约了成本。

4.2 线上灰度

image
  • 灰度版本部署,添加灰度版本的路由标签(例如R-Label:F_B
  • 线上灰度,支持不同维度(如gIduId)动态配置路由规则。
    如上图,当请求Req1通过网关gateway,网关会检查路由规则,如果匹配上某个路由规则,就会往该请求添加请求头R-Label:F_B
  • 网关gateway选择服务转发节点的时候,优先选择路由标签R-Label相同的服务节点,如果找不到,兜底操作选择default的默认服务节点。

5 总结

本文介绍了标签路由在三维家的实践,从设计思路和场景进行了阐述。标签路由解决了多版本开发联调、多版本迭代测试和线上灰度问题,减少部署环境,节约人力成本和硬件成本。

你可能感兴趣的:(服务治理之标签路由(转))