一、导语
在服务实例数量和规划较大的事务场景下，服务路由是体系比较常见的诉求，比方针对事务特色的全链路灰度、测验环境多分支路由、多Region多AZ时的就近路由等。TSF依据标签化才干完结流量染色和标签主动传递，仅经过控制台装备即可完结服务路由、全链路灰度及就近路由功用，快速满意客户的事务分流诉求。服务路由从行为上讲，是将流量进行染色区分，并经过路由规矩将流量进行分流，本节将对TSF全体服务路由相关才干进行具体介绍。
二、作者介绍
崔凯
多年分布式、高并发电子商务体系的研发、体系架构规划经历，擅长干流微服务架构技能渠道的落地和实施,目前专注于微服务架构相关中间件的研讨推行和最佳实践的沉淀，致力于协助企业完结数字化转型。
三、办理路由
功用阐明
本文中“办理路由”特指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官网进行查阅。 cloud.tencent.com/document/pr…
全链路灰度流量流向规矩与阐明
- 当泳道上已经绑定了全链路灰度发布的规矩，则不能删去泳道。
- 当恳求流量没有射中任何灰度规矩，流量将走到没有被增加到泳道的布置组中。
- 当某一个微服务下的布置组没有被参加任何泳道中，恳求将在该微服务下一切布置组的一切实例中轮询。经过该微服务后，恳求将持续依照规矩流入对应泳道。
- 一个布置组能够归于多个泳道。
- 在泳道中，服务路由规矩不收效。
- 泳道是一个阻隔环境。当泳道上一切规矩封闭后，流量不会进入泳道中。如期望康复树立泳道前的流量分配方法，请将泳道删去。
全链路灰度中音讯主题染色
kafka作为干流的音讯队列产品之一，常常用做事务逻辑间的解耦及大数据场景。那么在全链路灰度发布时，服务间调用假如运用了kafka做异步解耦，在音讯未被染色时就会呈现Consumer过错的消费了其它泳道音讯的现象，这是事务不能承受的。
TSF经过将泳道符号在线程中向下传递的方法完结音讯染色，即染色流量能在流经kafka后被对应泳道中的布置组消费，而未染色音讯被不在任何泳道中的布置组消费，并且泳道标（即LaneId）能在音讯流经kafka后持续传递给下流服务。概况请参见官网最佳实践：cloud.tencent.com/document/pr…
适用场景
全链路灰度发布是大规划微服务架构场景下几乎必备的发布方法，它能够满意指定小流量验证、逐级切流控制毛病范围、多个相关服务一次性共同发布、一次装备重复运用等要求，有效削减了发布本钱及上线变更带来的危险。
依据地域和用户的灰度测验场景
互联网产品常常会邀请公测用户进行体会，当产品需求上线新功用时，期望运用灰度发布的手法在小范围内进行新版别发布测验。在测验一段时间后，逐渐的增加新版别的流量份额，一起削减原有版别的流量份额。上述这种灰度发布的模式，不同于以往新旧版别发布的一次性切换，让整个发布进程经过灰度发布的方法进行过渡。
经过TSF进行如上场景的全链路灰度发布流程过程如下：
- 创立并布置微服务网关；
- 创立悉数待灰度布置组并发布；
- 创立微服务网关分组、导入API并发布分组；
- 新建微服务网关插件并绑定分组；
- 新建泳道，并在泳道中增加悉数灰度布置组，并设置网关为泳道进口；
- 创立灰度发布规矩并设置为收效状况；
依据如上装备，当用户发起的恳求包括region=beijing、usertype=testUser的参数（代表北京地区的公测用户）时，则会进入所装备泳道布置组，完结全链路灰度的发布操作。
一起在装备及运维进程中需注意：
- 评价单个provider服务实例能够处理多少恳求，并依据流量分配来规划布置组的实例数量。
- 假如流量份额变化后，可能需求调整布置组的实例数量来满意新的流量。
- 能够经过设置弹性弹性规矩来支撑动态调整实例数量。
- 全链路灰度发布支撑一起收效多条规矩，并支撑为规矩装备优先级。当同一条恳求一起满意多条规矩时，会优先匹配高优先级的规矩。
五、单元化
功用阐明
单元化架构首要是为了处理多中心容灾、机房弹性扩容等问题，也能够依托单元化架构完结单元级毛病阻隔、单元级全链路灰度。本质上讲，单元化架构也是流量路由的一种方法，只不过路由的意图地是每一个平行的事务自闭环的单元（Set）。
如下为两地三中心架构下TSF单元化最佳实践的扼要阐明：
计划阐明：
-
依据智能DNS解析完结域名到地域的IDC机房路由，进口经过调整DNS解析成果，完结跨地域流量切换。
-
经过进口负载->微服务网关，按权重份额装备路由，完结事务运用的同城双活。
-
微服务网关到运用，依据网关的标签化路由规矩完结单元化路由匹配。
-
依据本地缓存的单元路由规矩进行服务寻址,完结单元路由调用。
注意事项：
- 单元内服务调用尽量在单元内闭环，削减跨单元调用；
- 假如事务需求跨单元调用，由微服务网关办理跨单元恳求的转发；
- 事务南北向流量应尽早完结正确单元的路由寻址，呈现单元寻址过错时需能够正常重定向；
- 当呈现单元化路由KEY不契合任何单元或拜访不带着KEY时，可报错或按默许单元化规矩处理；
- 针对正常/过错的单元化调用流向，做到可监控、可预警、可办理。
TSF单元化才干首要以“微服务网关”+“命名空间”为完结基础。微服务网关首要的作用是单元化规矩的路由转发，为了完结这一意图，TSF深度增强了开源微服务网关Zuul及SCG；命名空间是TSF本身具有的才干，分为一般命名空间和大局命名空间，一般命名空间首要用来对服务间调用进行逻辑阻隔，大局命名空间首要用于打通特别的跨一般命名空间的服务调用。
在TSF单元化布置架构中首要运用大局命名空间放置微服务网关，使得微服务网关能够连通多个逻辑单元（一般命名空间）中的服务并进行单元化路由，运用一般命名空间进行各逻辑单元（Set）的阻隔，确保每个单元的独立。
单元化改造首要触及两个过程：装备单元化、单元化布置，概况官网链接。
装备单元化：cloud.tencent.com/document/pr…
单元化布置：cloud.tencent.com/document/pr…
适用场景
单元化适用场景首要集中在大规划或超大规划的分布式体系中，一起从企业本钱和办理角度讲，整个单元化改造的进程是绵长的、本钱是巨大的，实际状况可能是企业内部体系架构在扩展性、可用性、功能存在多方面痛点，不得不经过单元化改造来处理现有问题。
银行事务单元化改造场景
单元化改造中单元化规矩的规划是重中之重，且银行事务一般状况不触及到地域等其它特色，所以首要仍是从用户的事务特色出发进行规划。
首先以用户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。
更多具体装备请参见：cloud.tencent.com/document/pr…
七、结语
路由首要是处理流量怎么分类，以及从哪里来、到哪里去的问题，本节经过对办理路由、全链路灰度、单元化、就近路由的功用及实践场景的描述，展示了TSF在流量路由方面的中心才干，基本覆盖了首要的流量路由场景，期望能给读者朋友供给一点协助。
引证
cloud.tencent.com/developer/a…
cloud.tencent.com/document/pr…
