一、导语
在服务实例数量和规模较大的业务场景下,服务路由是零碎比拟常见的诉求,比方针对业务属性的全链路灰度、测试环境多分支路由、多 Region 多 AZ 时的就近路由等。TSF 基于标签化能力实现流量染色和标签主动传递,仅通过控制台配置即可实现服务路由、全链路灰度及就近路由性能,疾速满足客户的业务分流诉求。服务路由从行为上讲,是将流量进行染色辨别,并通过路由规定将流量进行分流,本节将对 TSF 整体服务路由相干能力进行具体介绍。
二、作者介绍
崔凯
腾讯云 CSIG 微服务产品核心产品架构师
多年分布式、高并发电子商务系统的研发、零碎架构设计教训,善于支流微服务架构技术平台的落地和施行, 目前专一于微服务架构相干中间件的钻研推广和最佳实际的积淀,致力于帮忙企业实现数字化转型。
三、治理路由
性能阐明
本文中“治理路由”特指 TSF 中的“服务路由”性能,次要为了辨别宽泛意义上的服务路由。治理路由的配置参数包含:
- 流量起源配置:标签类型、标签名、逻辑关系、值;
- 流量目的地:所在利用、目的地类型、部署组 / 版本号、权重。
简略总结:通过判断申请中标签(key)对应的值(value)是否合乎治理规定的配置,进而通过配置的权重比例将申请转发到指定的部署单元,如不同的部署组或版本。
配置过程中需注意如下状况:
- 填写治理路由规定须要在服务提供方进行配置,例如 A 服务调用 B 服务,须要在 B 服务上配置治理路由规定。
- 对于 Spring Cloud 服务,配置治理路由规定后,若配置的指标部署组无奈运行,流量将依照原有默认的轮询形式调配到其余部署组上。
- 对于 Spring Cloud 服务,当服务提醒未绑定利用时,须要在服务详情页单击编辑后绑定服务,能力开始配置治理路由规定。服务绑定利用操作,一经绑定,不能批改。
- 要使治理路由规定失效,须要确保在控制台开启了待失效规定,并在代码中增加了路由的注解。
- 对于 Mesh 利用,配置路由规定后,若配置的指标部署组无奈运行,则路由规定配置失败,申请无奈发送。
配置失效后,能够在列表项的流量调配图中查看流量分配情况,如下图所示。此时留神,配置了流量的权重比例后,要使路由准确性达到预期,申请数至多要在 1000 以上;如果申请样本数不高的状况下偏差会比拟大,样本数越高准确性就才越高。
容错爱护
在应用治理路由时,TSF 还具备容错爱护的性能来躲避一些场景。假如针对 provider 服务调配了两个版本:V1 版本承载 10% 的流量,V2 版本承载 90% 的流量,并针对上述流量调配进行了对应的治理路由的配置。此时,如果 V1 版本所有实例全副故障,那么就会有 10% 的流程报错,这是业务不能承受的。
此时能够应用容错爱护性能,当在 provider 服务的治理路由界面关上容错爱护性能时,TSF-SDK 发现 V1 版本的所有实例都不可用,会尝试将流量路由到目前所有可用的实例上(即 V2 版本的所有实例)。待 V1 版本实例从故障中复原,容错爱护无需手动干涉,即可将流量从新依照 V1 版本 10%+V2 版本 90% 的比例调配。
实用场景
治理路由能力从上述性能形容能够发现,它更着重对于单个或多数服务的路由进行管控,且对上下游服务的自定义标签传递没有强诉求,因为治理路由能够应用 TSF 零碎标签做判断。所以,治理路由更适宜大量串联服务并须要独自配置的路由场景。
测试环境多分支场景
往往客户资源无限的状况下,只有一套测试环境。当该环境正在进行 feature 版本的开发及测试时,如果忽然须要修复生产环境的一个重要 BUG,且当天上线这个 hotfix 版本。那么测试人员须要把 hotfix 版本波及的服务从新公布,并笼罩现有测试环境中正在测试的 feature 版本。并且在 hotfix 版本上线后,将 feature 版本从新公布到原有资源上。除了资源替换产生的额定老本,还会产生版本笼罩前后记录上下文、更换环境配置等额定老本。
那么咱们如何解决呢?咱们能够通过在测试环境创立 hotfix 版本的部署组资源并实现部署,同时通过治理路由规定 + 标签化参数的形式,使得增加“feature”参数的申请调用 feature 分支服务,增加“hotfix”参数的申请调用 hotfix 分支服务,实现测试环境多分支并行测试的目标。在最终测试实现 hotfix 版本后,间接开释 hotfix 分支应用的资源即可,不再须要进行版本替换和上下文更新,极大节俭运维老本、进步测试效率。
配置步骤:
- 测试申请需在 Path、Query、Header 或 Cookie 中任一地位携带 tag 参数,指定分支版本信息(feature 或 hotfix);
- 在微服务网关中新建 Tag 插件,配置 Tag 转换规则,并将 Tag 插件绑定网关分组;
- 新建 Service B、Service C 的 hotfix 版本部署组,并实现利用公布;
- 在 Servcie B 及 Service C 的服务治理 -> 服务路由中新建路由规定,保留并开启。
当在控制台开启治理路由规定时,规定会对利用实时失效。通过上述步骤即可疾速实现测试环境多分支的治理路由配置。另外,假如 Service C 关联了更多的版本 / 部署组(如 4 个),则只需针对 Service C 进行路由规定的增加即可,并不影响 Service B 的路由配置。
四、全链路灰度
性能阐明
随着零碎架构向微服务转变,利用的公布频率和次数都显著增高。尤其当微服务的规模越来越大,如何可能在保障低运维老本、故障爆炸半径可控的状况下,实现全链路大规模的公布动作,成为研发及运维部门面临的难题。
全链路灰度是软件逐渐上线罕用的公布形式,是指将具备肯定特色或者比例的流量,逐渐调配到指定版本的过程,通过生产流量实测发现新版本可能存在的潜在问题,同时将故障损失管制在灰度范畴内。
相比全量上线,灰度公布是更加审慎的公布模式。当线上调用链路较为简单时,全链路灰度公布能够将生产环境隔离出一个逻辑独立的运行环境。同时,全链路灰度的泳道能够重复应用,即便进行变动也比拟灵便,使得全链路灰度的运维老本也放大很多。
应用全链路灰度公布之前,须要先配置泳道。一条泳道相当于一个灰度环境,环境中蕴含利用中须要进行灰度测试的部署组。
泳道:泳道是一组业务关联的部署组的汇合,是灰度流量的目的地。泳道中的部署组属于不同的利用,能够认为用户通过划分泳道而划分出了灰度环境。
灰度规定:用户新建灰度规定以设定灰度流量应满足的条件。当灰度规定判断申请满足条件后,会通过灰度规定将流量路由到某一个泳道中。
泳道入口:
在全链路灰度公布模块中公布灰度规定时,会在泳道的入口部署组上对申请进行灰度规定校验,以此来判断申请是否应该进入某一个泳道中。泳道入口能够是一个微服务网关,也能够是一个微服务。
同一个泳道中反对多个入口,在申请通过每一个入口部署组时,都会判断申请是否应该进入泳道中。
TSF 全链路灰度公布的操作流程如下图,具体操作步骤可浏览 TSF 官网进行查阅。
https://cloud.tencent.com/doc…\
\
全链路灰度流量流向规定与阐明
- 当泳道上曾经绑定了全链路灰度公布的规定,则不能删除泳道。
- 当申请流量没有命中任何灰度规定,流量将走到没有被增加到泳道的部署组中。
- 当某一个微服务下的部署组没有被退出任何泳道中,申请将在该微服务下所有部署组的所有实例中轮询。通过该微服务后,申请将持续依照规定流入对应泳道。
- 一个部署组能够属于多个泳道。
- 在泳道中,服务路由规定不失效。
- 泳道是一个隔离环境。当泳道上所有规定敞开后,流量不会进入泳道中。如心愿复原建设泳道前的流量调配形式,请将泳道删除。
全链路灰度中音讯主题染色
kafka 作为支流的音讯队列产品之一,常常用做业务逻辑间的解耦及大数据场景。那么在全链路灰度公布时,服务间调用如果应用了 kafka 做异步解耦,在音讯未被染色时就会呈现 Consumer 谬误的生产了其它泳道音讯的景象,这是业务不能承受的。
TSF 通过将泳道标记在线程中向下传递的形式实现音讯染色,即染色流量能在流经 kafka 后被对应泳道中的部署组生产,而未染色音讯被不在任何泳道中的部署组生产,并且泳道标(即 LaneId)能在音讯流经 kafka 后持续传递给上游服务。详情请参见官网最佳实际:https://cloud.tencent.com/doc…
实用场景
全链路灰度公布是大规模微服务架构场景下简直必备的公布形式,它能够满足指定小流量验证、逐级切流控制故障范畴、多个关联服务一次性独特公布、一次配置重复应用等要求,无效缩小了公布老本及上线变更带来的危险。
基于地区和用户的灰度测试场景
互联网产品常常会邀请公测用户进行体验,当产品须要上线新性能时,心愿应用灰度公布的伎俩在小范畴内进行新版本公布测试。在测试一段时间后,逐渐的减少新版本的流量比例,同时缩小原有版本的流量比例。上述这种灰度公布的模式,不同于以往新旧版本公布的一次性切换,让整个公布过程通过灰度公布的形式进行过渡。
通过 TSF 进行如上场景的全链路灰度公布流程步骤如下:
- 创立并部署微服务网关;
- 创立全副待灰度部署组并公布;
- 创立微服务网关分组、导入 API 并公布分组;
- 新建微服务网关插件并绑定分组;
- 新建泳道,并在泳道中增加全副灰度部署组,并设置网关为泳道入口;
- 创立灰度公布规定并设置为失效状态;
依据如上配置,当用户发动的申请蕴含 region=beijing、usertype=testUser 的参数(代表北京地区的公测用户)时,则会进入所配置泳道部署组,实现全链路灰度的公布操作。
同时在配置及运维过程中需注意:
- 评估单个 provider 服务实例能够解决多少申请,并依据流量调配来布局部署组的实例数量。
- 如果流量比例变动后,可能须要调整部署组的实例数量来满足新的流量。
- 能够通过设置弹性伸缩规定来反对动静调整实例数量。
- 全链路灰度公布反对同时失效多条规定,并反对为规定配置优先级。当同一条申请同时满足多条规定时,会优先匹配高优先级的规定。
五、单元化
性能阐明
单元化架构次要是为了解决多核心容灾、机房弹性扩容等问题,也能够依靠单元化架构实现单元级故障隔离、单元级全链路灰度。实质上讲,单元化架构也是流量路由的一种形式,只不过路由的目的地是每一个平行的业务自闭环的单元(Set)。
如下为两地三核心架构下 TSF 单元化最佳实际的简要阐明:
计划阐明:
- 基于智能 DNS 解析实现域名到地区的 IDC 机房路由,入口通过调整 DNS 解析后果,实现跨地区流量切换。
- 通过入口负载 -> 微服务网关,按权重比例配置路由,实现业务利用的同城双活。
- 微服务网关到利用,基于网关的标签化路由规定实现单元化路由匹配。
- 基于本地缓存的单元路由规定进行服务寻址, 实现单元路由调用。
注意事项:
- 单元内服务调用尽量在单元内闭环,缩小跨单元调用;
- 如果业务须要跨单元调用,由微服务网关治理跨单元申请的转发;
- 业务南北向流量应尽早实现正确单元的路由寻址,呈现单元寻址谬误时需可能失常重定向;
- 当呈现单元化路由 KEY 不合乎任何单元或拜访不携带 KEY 时,可报错或按默认单元化规定解决;
- 针对失常 / 谬误的单元化调用流向,做到可监控、可预警、可治理。
TSF 单元化能力次要以 “微服务网关”+“命名空间” 为实现根底。微服务网关次要的作用是单元化规定的路由转发,为了实现这一目标,TSF 深度加强了开源微服务网关 Zuul 及 SCG;命名空间是 TSF 自身具备的能力,分为一般命名空间和全局命名空间,一般命名空间次要用来对服务间调用进行逻辑隔离,全局命名空间次要用于买通非凡的跨一般命名空间的服务调用。
在 TSF 单元化部署架构中次要应用全局命名空间搁置微服务网关,使得微服务网关能够连通多个逻辑单元(一般命名空间)中的服务并进行单元化路由,应用一般命名空间进行各逻辑单元(Set)的隔离,保障每个单元的独立。
单元化革新次要波及两个步骤:配置单元化、单元化部署,详情官网链接。
配置单元化:https://cloud.tencent.com/doc…
单元化部署:https://cloud.tencent.com/doc…
实用场景
单元化实用场景次要集中在大规模或超大规模的分布式系统中,同时从企业老本和治理角度讲,整个单元化革新的过程是漫长的、老本是微小的,理论状况可能是企业外部零碎架构在扩展性、可用性、性能存在多方面痛点,不得不通过单元化革新来解决现有问题。
银行业务单元化革新场景
单元化革新中单元化规定的设计是重中之重,且银行业务个别状况不波及到地区等其它属性,所以次要还是从用户的业务属性登程进行设计。
首先以用户 ID 尾号为单元化 KEY,将用户划分为 00-99 等量的 100 个数据单元,此为第一层全局分片规定。而后基于各产品线业务分片需要自定义二层分片规定,如对公对私场景,以用户 ID 前增加的公 / 私前缀字符串为 KEY 进行二次路由计算。通过上述规定设计,实现基于 全局 + 产品线 双维度的单元化规定模型。
例如,假如用户标签 tag 值为:B_20210817,一层标签依据用户 ID 尾号的“17”进行全局分片路由,二层标签依据对公对私的业务标记“B”(B 为对公,P 为对私)进行产品线分片路由,最终得出惟一的单元编码(命名空间 ID)。
确定单元化规定后,如上述《性能阐明》中对微服务网关及相干单元化服务进行代码批改,并依照流程在 TSF 控制台操作创立单元化规定,即可实现业务的单元化革新。
TSF 单元化架构外围价值体现在运维及开发成本、管理效率、高可用容灾、弹性伸缩方面,比照客户自建单元化架构具备运维简略、可用性高、开发便捷、配置灵便的特点,且可与 TSF 平台自身在诸多性能上进行联动。
比照项 | TSF 单元化架构 | 自建单元化架构 |
---|---|---|
运维老本 | 由 TSF 对立运维,提供企业级 SLA 反对 | 需企业本身具备较高运维水准 |
开发成本 | 无需开发单元化服务,通过控制台配置实现 | 需企业自实现单元化服务 |
管理效率 | 与 TSF 整体 Paas 技术平台对立提供可视化治理,缩小跨平台操作 | 代码、配置平台、运维平台等多方面联动治理,无对立可视化界面 |
高可用及容灾 | 依靠 TSF 多年高可用容灾教训积攒,回绝踩坑 | 需逐步完善本身高可用技术及人才 |
弹性扩缩 | 快捷联动 TSF 本身基于容器、虚机的弹性伸缩和路由机制 | 须要本身配置实现弹性扩缩容机制 |
六、就近路由
性能阐明
就近路由次要解决在同城双活或多活场景下,利用在不同 AZ 有多个冗余部署组时,当某一 AZ 的利用部署组实例全副故障后,通过就近路由能够主动切换到另外 AZ 的冗余部署组中。同时,当部署组没有呈现故障时,咱们会优先拜访同 AZ 的的被调服务,以缩小跨 AZ 的拜访延时。通过就近路由能够在保障低延时的同时,进步肯定的零碎高可用性。
其性能配置比较简单,即在创立命名空间后开启即可(默认开启)。
就近路由的实现次要依靠于多个不同 AZ 的实例是注册在同一套注册核心上,通过 consumer 和 provider 服务在注册时上报的信息,咱们能够晓得实例的所属 AZ、Region 和部署组版本等信息,TSF-SDK 会通过这些信息筛选最合适的实例进行调用。
通过上图可察看到,TSF-SDK 会优先判断被调服务是否有实例与主调服务在雷同 AZ 内,如果没有则会对规定降级,持续判断被调服务是否有实例与主调服务在雷同 Region 内,直到最终找到合乎就近路由规定的实例。
实用场景
就近路由次要应用在跨可用区容灾场景下,如在广州一、二区搭建同城双活架构,当开启就近路由时,广州一区的 consumer 会优先调用同一可用区的 provider。
此时,当广州一区的 provider 不可用,consumer 会跨可用区调用广州二区的 provider。
更多具体配置请参见:https://cloud.tencent.com/doc…
七、结语
路由次要是解决流量如何分类,以及从哪里来、到哪里去的问题,本节通过对治理路由、全链路灰度、单元化、就近路由的性能及实际场景的形容,展现了 TSF 在流量路由方面的外围能力,根本笼罩了次要的流量路由场景,心愿能给读者敌人提供一点帮忙。
援用
https://cloud.tencent.com/dev…
https://cloud.tencent.com/doc…