本文转载自公众号
三维家技术实践的服务治理系列文章
1 背景
目前，微服务架构是互联网企业的标配，从单体架构到微服务架构，服务的数量急剧膨胀，且相互之间依赖错综复杂。服务治理，对开发、运维都是一个严峻的考验。
例如，在开发过程中，为了赶进度，一个服务往往有多个Feature版本在并行开发。那么，同一个服务的多个版本如何在开发联调、测试中做到互不影响呢？
最简单粗暴的一种方案是建设多套开发、测试环境，各环境有独立的注册中心、配置中心、服务集群以及相关中间件。显然，这种等同物理隔离的方式，硬件成本高，维护成本大，而且需要建设多少套才够用？ 恐怕没有确定的答案。
所以，如何通过一种轻量的模式，既可以满足我们多版本并行开发和测试的需要，又可以兼顾低成本和易维护呢？
抽象引申一下，就是我们需要有一套低成本的、满足多版本服务并行在同一个服务集群的机制，该机制除了满足开发、测试的需要外， 还能在生产环境中实现新老版本并行，也就是灰度发布的需求。
2 需求
让我们再来理一下需求:
- 在开发阶段，需要保证多版本并行开发和联调。
- 在测试阶段，需要保证多版本并行测试。
- 在发布阶段，需要灰度发布机制，保证产品平滑过渡。
基于上述的背景和需求，我们尝试通过标签路由来解决这个问题。
3 设计思路
我们从服务路由标签的定义、原理以及常见路由规则设置这三方面进行阐述。
3.1 服务路由标签的定义
每个服务在启动时，都会被赋予一个用于识别其版本的标签, 我们称之为服务路由标签, 一般采用迭代版本号作为标签, 例如feature-V0506。 如果没有赋予，则默认为default。该标签会作为服务的一个元数据，随着服务节点信息注册到注册中心上。
例如上图，我们的开发环境dev， 包括一个注册中心，以及一套稳定的服务集群(其路由标签均为default)，包括building、usercenter、material等服务。
然后程序猿A在本地开发building服务的名为F_1的特性分支， 其对应的路由标签也为F_1，且已经注册到注册中心了；程序猿B在本地开发building服务的F_2特性分支， 其对应的路由标签也为F_2。
这时候我们看到， 该服务在注册中心中有3个版本，分别为稳定的默认版本default，F_1以及F_2。
服务的路由标签
R-Label，可在服务的启动参数或者环境变量中设置。
稳定版本，一般为生产上的版本(对应
master分支)
3.2 服务路由标签的原理
上一节我们已经讲述了路由标签作为元数据，会随服务信息注册到注册中心上，那么它有什么用呢？
我们在调用链的头部(一般为网关，或者在非生产环境下为postMan、swagger文档站点甚至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进行灰度，当请求的uId为1024时，给请求加上请求头(染色字段): 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 多版本开发联调
- 开发环境部署相对稳定的版本(一般为
master分支) - 本地和开发环境共用注册中心
程序猿B和程序猿C进行本地联调的时候，给各自服务加上R-Label:F_2(通过环境变量或启动参数的方式)，那么服务在请求的路由选址的时候，会优先选择选择B跟C的本地服务。如果找不到相同标签，就选择默认default的服务节点。
4.2 多版本测试
- 测试环境中部署相对稳定的版本(一般为
master分支) - 不同迭代版本采用不同的路由标签
甚至，我们可以把开发环境跟测试环境合并为一个，保持环境的独立性的同时，进一步节约了成本。
4.2 线上灰度
- 灰度版本部署，添加灰度版本的路由标签（例如
R-Label:F_B） - 线上灰度，支持不同维度（如
gId、uId）动态配置路由规则。
如上图，当请求Req1通过网关gateway，网关会检查路由规则，如果匹配上某个路由规则，就会往该请求添加请求头R-Label:F_B。 - 网关
gateway选择服务转发节点的时候，优先选择路由标签R-Label相同的服务节点，如果找不到，兜底操作选择default的默认服务节点。
5 总结
本文介绍了
标签路由在三维家的实践，从设计思路和场景进行了阐述。标签路由解决了多版本开发联调、多版本迭代测试和线上灰度问题，减少部署环境，节约人力成本和硬件成本。
