CN115250233A - 一种灰度路由控制方法、灰度路由组件及计算机设备 - Google Patents

Abstract

本发明涉及一种灰度路由控制方法，包括如下步骤：定义灰度路由规则；路由规则采用变更zookeeper监听通知获取应用本地内存处理，在客户端及服务端启动时，加载路由规则，在运行过程中，动态更新路由规则，从而热加载路由规则；以客户端组件形式嵌入应用，接受路由规则更新通知及拉取；全链路灰度路由识别处理，对多协议请求判断生成灰度标签并在全链路中进行传递；异步收集全链路请求信息，生成自有的串联关系标识进行记录全链路的信息跟踪。

Description

一种灰度路由控制方法、灰度路由组件及计算机设备

技术领域

本发明涉及路由设备技术领域，特别涉及一种端到端检索式对话方法与系统及计算机设备。

背景技术

请求路由中间件及组件在企业中普通使用广泛，对于普及的web应用中，无论是前端还是后端应用，都会使用到路由规则进行转发处理，路由转发一般包含请求流量的来源及分类，比如正常流量，灰度流量，它们统一都是由路由规则进行识别并处理，一般的路由组件或平台提供了三大核心能力：面向请求的流量接收，路由规则的配置，以及请求代理转发。参见图1的路由组件构成图，框架分为以下部分：基于请求入口拦截或提供统一访问入口的请求流量接收；基于路由规则配置的存储，使用基于动态监听、主动推送方式进行路由规则的热更新及时生效；基于后端服务的注册发现及主动获取服务节点列表缓存进行路由转发判断，根据路由规则的策略实现后端服务的转发及流量标记。

而众多企业采用分布式微服务框架，使用基于中间件或类似网关技术进行不同路由流量策略分发，现常规采用具体架构如下：

1）参见图2，基于中间件nginx分流路由识别及转发架构，基于nginx中间件特殊指令等实现http路由匹配转发；

2）参见图3，基于软件如Spring Cloud Gateway分流路由识别及转发架构，基于Spring Cloud Gateway框架下集成灰度发布路由，进行事先定义转发策略，实现http路由规则分流。

随着业务场景越来越复杂，现有技术存在一定的局限或缺点。企业存在多种协议交互及请求，目前一般的路由组件框架及中间件支持通信协议比较单一，比如框架层面的主要支持http路由转发的SpringCloud Gateway，软负载中间件nginx，这类框架及中间件目前一般实现url（统一资源定位器）级别请求转发处理，Dubbo微服务框架只支持Dubbo协议的路由请求处理，没有全链路识别及串联功能，而且在复杂业务下，存在多协议交互场景，比如Http、Dubbo、Kafka、定时任务等多协议间的流程处理，目前框架无法对多协议请求下的全局路由识别及统一流量标识路由处理。各框架实现方式不一样，无法满足同一框架组件对多种协议的路由及全链路灰度识别处理，存在代码植入、路由判断复杂及配置困难的情况。

发明内容

基于此，有必要提供一种基于规则配置化及全链路请求识别与处理的灰度路由控制方法及灰度路由组件及计算机设备。

本发明实施例一方面提供一种灰度路由控制方法，其包括如下步骤：

定义灰度路由规则，建立灰度版本、灰度应用及灰度路由规则之间的关系映射表，通过关系映射表获取对应的灰度路由规则，配置全链路交互系统的版本管理以及路由策略规则上下线；

路由规则采用变更zookeeper（分布式应用程序协调服务软件）监听通知获取应用本地内存处理，在客户端及服务端启动时，加载路由规则，在运行过程中，动态更新路由规则，从而热加载路由规则；

以客户端组件形式嵌入应用，接受路由规则更新通知及拉取，实现全链路路由实时生效及转发，路由规则还原以通过推送历史路由规则来实现；

全链路灰度路由识别处理，对多协议请求判断生成灰度标签并在全链路中进行传递，根据灰度规则判断结果进行流量的路由至灰度版本或正常版本，以提供灰度服务或正常服务；

异步收集全链路请求信息，生成自有的串联关系标识进行记录全链路的信息跟踪，以日志形式记录客户端上的操作，以错误码形式记录异常情况。

优选地，所述定义灰度路由规则包括：

通用路由规则：支持按生效时间、数据特征、请求总量、TPS以及请求权重来通用路由匹配；

HTTP路由规则：定义服务节点地址、路径匹配模式、HTTP处理方法、注册发现ServiceID及指定目标ip和端口；

Dubbo微服务路由规则：定时Dubbo服务名及方法匹配，支持包名及服务名准确和模糊匹配；

SpringCloud微服务路由规则：支持请求URL路径匹配模式、报文特征和调用方限制的路由规则；

Kafka消息主题路由规则：支持按topic主题名及主题模糊匹配，消息头及消息体、消息ID的数据特征多种匹配；

定时任务路由规则：支持定时任务job名称、方法名、任务数据对象字段匹配。

优选地，还包括客户端路由异常重试及转移，当客户端请求失败后进行异常重试，重试次数可预配置，并根据客户端请求响应码进行区分是业务灰度失败还是转向正常请求。

优选地，还包括引入本地内存缓存和Redis分布式缓存，通过对路由规则本地缓存及灰度标识分布式缓存进行数据路由标识，实现多协议及定时任务入库时的现场保存及现场恢复。

优选地，所述全链路灰度路由识别处理包括如下步骤：

S1、获取多协议请求，获取的灰度标识进并设置头部信息，判断灰度链路是否开启，如果是，则进入步骤S2，如果否，则提供正常服务；

S2、根据灰度版本获取对应的灰度配置信息，并判断是否有灰度配置，如果是，则进入步骤S3，如果否，则提供正常服务；

S3、拼装请求信息，判断协议路由是否匹配，如果是，则进入步骤S4，如果否，则提供正常服务；

S4、判断全链路灰度规则是否匹配，如任意一个规则不匹配，则提供正常服务，如果全部规则匹配，则进入步骤S5；

S5、判断是否有灰度服务，如果是，则提供灰度服务，如果否，则自动查找灰度服务，并提供灰度服务。

优选地，所述判断全链路灰度规则是否匹配包括判断规则表达式是否匹配、访问总量是否超限、每秒处理事务数（qps）是否超限、权重是否匹配以及灰度时间是否匹配。

本发明实施例另一方面还提供一种灰度路由组件，其包括：

UCFF灰度组件，包括客户端路由组件和服务端路由组件，用于定义灰度路由规则，建立灰度版本、灰度应用及灰度规则关系映射表、灰度配置读取、配置变更监听；客户端路由组件与SDK形式嵌入应用，接受路由规则更新通知及拉取，实现全链路路由实时生效及转发；

灰度发布管理平台，用于配置全链路交互系统的版本管理及路由策略规则上下线，包括版本规划、版本审核和上线下线；路由规则维护，业务全链路请求数据查看及分析，提供包含关联系统及灰度版本维护界面；

缓存模块，包括本地内存缓存组件和Redis分布式缓存组件，用于对路由规则本地缓存及灰度标识分布式缓存进行数据路由标识，实现多协议及定时任务入库时的现场保存及现场恢复；

指标输出及日志输出模块，用于异步收集全链路请求信息，生成自有的串联关系标识进行记录全链路的信息跟踪，对灰度发布管理平台内各个功能生成相关的灰度日志。

优选地，所述UCFF灰度组件包括：

灰度配置模块，用于配置变更监听和灰度配置读取，通过心跳机制，进行灰度策略的接收、变更、管理；

流量路由模块，用于根据灰度规则判断结果进行流量的路由至灰度版本或正常版本，流量路由模块需要实现请求的降级处理；

灰度标签生成、传递模块，用于通过对流量报文、来源IP和白名单的判断生成灰度标签并在链路中传递。

优选地，所述流量路由模块包括：

Kafka路由组件，用于接收发送的消息，按topic主题名及主题模糊匹配，消息头及消息体、消息ID的数据特征多种匹配；

HTTP/SpringCloud/Dubbo路由组件，用于接收HTTP/SpringCloud/Dubbo请求；

定时任务路由组件，用于拉起定时任务数据。

本发明实施例还提供一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一项实施例所述控制方法的步骤。

本发明实施例的一种基于规则配置化及全链路请求识别与处理的灰度路由控制方法及灰度路由组件及计算机设备，建立了灵活可配置的路由访问机制，引入灰度管理平台及客户端路由组件进行路由规则配置及规则的动态推送，将应用系统和灰度路由规则进行解耦，通过规则策略的上下线进行路由动态发布，支持多个协议的路由配置，包含常用的Http、Dubbo、SpringCloud、Kafka等多种协议的路由访问识别处理，实现了多协议下的灰度及正常应用请求路由识别处理，实现了多协议下统一的路由界面配置，统一多框架灰度路由识别及处理，同时也对全链路路由跟踪记录。

附图说明

通过附图中所示的本发明优选实施例更具体说明，本发明上述及其它目的、特征和优势将变得更加清晰。在全部附图中相同的附图标记指示相同的部分，且并未刻意按实际尺寸等比例缩放绘制附图，重点在于示出本发明的主旨。

图1为本领域常用路由请求分发示例图；

图2为本领域现在基于中间件nginx的灰度路由识别交互图；

图3为本领域现在基于SpringCloud Gateway的分流路由转发示例图；

图4为本发明实施例提供全链路灰度路由识别处理模块流程图；

图5为本发明实施例提供灰度路由组件的结构示意图。

具体实施方式

下面结合附图和具体实施例对本发明技术方案作进一步的详细描述，以使本领域的技术人员可以更好的理解本发明并能予以实施，但所举实施例不作为对本发明的限定。

本发明实施例一方面提供一种灰度路由控制方法，其包括如下步骤：

S10、定义灰度路由规则，常用的灰度路由规则包括通用路由规则、HTTP路由规则、Dubbo微服务路由规则、SpringCloud微服务路由规则、Kafka消息主题路由规则和定时任务路由规则,通过支持多个协议的路由规则配置，使得能实现对多种协议的路由访问识别处理，进行实现统一的灰度路由下发感知。建立灰度版本、灰度应用及灰度路由规则之间的关系映射表，通过关系映射表获取对应的灰度路由规则，配置全链路交互系统的版本管理以及路由策略规则上下线。即是通过建立灰度版本、灰度应用于灰度路由规则的关系映射表，同时通过对路由规则配置和规则的动态发布、通过路由策略规则的上下线进行路由动态发布，结合灰度应用上下线实现灰度规则动态上下线检测，可以实现在同一个框架下，对多协议请求下的全局路由识别和统一流量标识路由处理，比如灰度流量以正常流量间的来回交互标识透传及处理。

本实施例的定义灰度路由规则具体包括：

通用路由规则：支持按生效时间、数据特征、请求总量、TPS以及请求权重来通用路由匹配；

HTTP路由规则：定义服务节点地址、路径匹配模式、HTTP处理方法、注册发现ServiceID及指定目标ip和端口；

Dubbo微服务路由规则：定时Dubbo服务名及方法匹配，支持包名及服务名准确和模糊匹配；

SpringCloud微服务路由规则：支持请求URL路径匹配模式、报文特征和调用方限制的路由规则；

Kafka消息主题路由规则：支持按topic主题名及主题模糊匹配，消息头及消息体、消息ID的数据特征多种匹配；

定时任务路由规则：支持定时任务job名称、方法名、任务数据对象字段匹配。

在其他实施例中，灰度路由规则还可以包括elasticjob、springbatch等多种协议的路由规则，实现支持多个协议的路由配置。

S20、路由规则采用变更zookeeper监听通知获取应用本地内存处理，在客户端及服务端启动时，加载路由规则，在运行过程中，动态更新路由规则，从而热加载路由规则，从而提升处理效率。在其他实施例中，还可以设置路由规则更新通知机制，即是通过客户端路由组件监控指定的zookeeper路径，从而在zookeeper在监听通知获取路由规则时，可以快速得到通知的更新机制。

S30、以客户端组件形式嵌入应用，接受路由规则更新通知及拉取，实现全链路路由实时生效及转发，路由规则还原以通过推送历史路由规则来实现。客户端路由组件以客户端组件的形式嵌入到应用中，以实现进行灰度应用的访问，同时接受路由规则的更新通知及拉取，如此当在路由规则发生更新时，客户端路由组件能全链路实时生效新的路由规则。

S40、全链路灰度路由识别处理，对多协议请求判断生成灰度标签并在全链路中进行传递，例如可以通过对流量报文、来源IP、白名单等的判断生成灰度标签，根据灰度规则判断结果进行流量的路由至灰度版本或正常版本，以提供灰度服务或正常服务。同时还应能实现请求的降级处理，即是如果灰度版本不存在，请求需要降级路由到正常版本进行处理，避免请求丢失。通过对全链路灰度路由识别，可以实现复杂的业务场景下全链路路由转发识别，在多应用系统交互的业务上实现流量请求划分，应用功能版本修改上线灰度验证影响范围可控，能快速支持多应用全链路请求，应用无需进行代码修改，只需对灰度规则进行相应配置即可实现。

S50、异步收集全链路请求信息，生成自有的串联关系标识进行记录全链路的信息跟踪，在客户端路由组件上的操作，以日志形式记录，可以作为审计记录；而发生的异常情况，以错误码形式记录，同时对接日志监控平台。

灰度路由控制方法还包括客户端路由异常重试及转移机制，当客户端请求失败后进行异常重试，重试次数可预配置，并根据客户端请求响应码进行区分是业务灰度失败还是转向正常请求。即是当客户端路由组件请求灰度版本应用失败时，可以自动进行异常重试，系统自动进行重新请求，而重试的次数可根据用户需求实际进行预先设置，每次重试的间隔时间也可以预先设置，当多次重试还是请求失败的情况下，就根据客户端请求的响应码来确定是报错还是转向正常请求，所谓报错即是通报业务灰度失败。

在本实施例中，灰度路由控制方法还包括引入本地内存缓存和Redis分布式缓存。Redis分布式缓存并不是所有的数据都一直存储在内存中的，其存储分为内存存储、磁盘存储和log文件三部分，同时支持简单的k/v类型的数据，还提供list、set、hash等数据结构的存储，另外还支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。本实施例通过引入本地内存缓存和Redis分布式缓存，大大提升了高并发访问路由规则转发判断及灰度数据标识获取的速度，降低应用引入组件的性能影响。通过对路由规则本地缓存及灰度标识分布式缓存进行数据路由标识，实现多协议及定时任务入库时的现场保存及现场恢复。在其他实施例中，还可以通过本地JVM（Java Virtual Machine-Java虚拟机）+Redis集群提供路由规则缓存快速查询更新，进一步提高效率。

请参考图4，在本实施例中，全链路灰度路由识别处理包括如下步骤：

S1、获取多协议请求，获取的灰度标识进并设置头部信息，判断灰度链路是否开启，如果是，则进入步骤S2，如果否，则提供正常服务；

S2、根据灰度版本获取对应的灰度配置信息，并判断是否有灰度配置，如果是，则进入步骤S3，如果否，则提供正常服务；

S3、拼装请求信息，判断协议路由是否匹配，如果是，则进入步骤S4，如果否，则提供正常服务；

S4、判断全链路灰度规则是否匹配，如任意一个规则不匹配，则提供正常服务，判断全链路灰度规则是否匹配包括判断规则表达式是否匹配、访问总量是否超限、qps是否超限、权重是否匹配以及灰度时间是否匹配，如果全部规则匹配，则进入步骤S5；

S5、判断是否有灰度服务，如果是，则提供灰度服务，如果否，则自动查找灰度服务，并提供灰度服务。

在其他实施例中，还提供其他控制机制，如服务发现机制，即通过提供代理组件实现服务端及客户端服务注册发现的功能；故障保障机制，即当提供灰度实例异常时可以转到正常实例中，从而提供正常的服务，保证全链路路由正常；链路跟踪机制，提供从应用客户端到服务端访问的整体链路跟踪功能；性能评估机制，提供从应用客户端经过路由机制到服务端后访问的性能评估功能。

本发明实施例另一方面还提供一种灰度路由组件，请参考图5，其包括：

UCFF灰度组件，包括客户端路由组件和服务端路由组件，即是服务调用方和服务提供方，用于定义灰度路由规则，建立灰度版本、灰度应用及灰度规则关系映射表、灰度配置读取、配置变更监听。客户端路由组件与服务端路由组件连接，服务端路由组件包括正常实例版本以及灰度实例版本，客户端路由组件以客户端组件形式嵌入应用，接受路由规则更新通知及拉取，实现全链路路由实时生效及转发，客户端路由组件对灰度规则进行判断，根据灰度规则判断结果进行流量的路由至灰度版本还是正常版本，客户端路由组件需要实现请求的降级处理，即如果灰度实例版本不存在，请求需要降级路由到正常实例版本进行处理，避免请求丢失。

灰度发布管理平台，用于配置全链路交互系统的版本管理及路由策略规则上下线，包括版本规划、版本审核和上线下线；路由规则维护，业务全链路请求数据查看及分析，提供包含关联系统及灰度版本维护界面。

缓存模块，包括本地内存缓存组件和Redis分布式缓存组件，用于对路由规则本地缓存及灰度标识分布式缓存进行数据路由标识，实现多协议及定时任务入库时的现场保存及现场恢复。

指标输出及日志输出模块，用于异步收集全链路请求信息，生成自有的串联关系标识进行记录全链路的信息跟踪，对灰度发布管理平台内各个功能生成相关的灰度日志。在客户端路由组件上的操作，以日志形式进行记录，可以作为审计记录；而运行过程中的异常情况，以错误码形式进行记录，对接实时日志监控平台。

在本实施例中，UCFF灰度组件包括：

灰度配置模块，用于配置变更监听和灰度配置读取，通过心跳机制，进行灰度策略的接收、变更、管理；灰度配置模块可以读取灰度发布管理平台发布的灰度版本心机或灰度规则变更信息，同时可以通过监听指定zookeeper路径能得到快速通知更新信息，从而提高效率。

流量路由模块，用于根据灰度规则判断结果进行流量的路由至灰度版本或正常版本，流量路由模块需要实现请求的降级处理；即如果灰度实例不存在，请求需要降级路由到正常实例进行处理，避免请求丢失。判断灰度规则是否匹配，如任意一个规则不匹配，则进行流量的路由至正常版本（正常实例），如果全部规则匹配，则进行流量的路由至灰度版本（灰度实例），而判断全链路灰度规则是否匹配包括判断规则表达式是否匹配、访问总量是否超限、qps是否超限、权重是否匹配以及灰度时间是否匹配。

灰度标签生成、传递模块，用于通过对流量报文、来源IP和白名单的判断生成灰度标签并在链路中传递。

在本实施例中，流量路由模块包括：

Kafka路由组件，用于接收发送的消息，按topic主题名及主题模糊匹配，消息头及消息体、消息ID的数据特征多种匹配；

HTTP/SpringCloud/Dubbo路由组件，用于接收HTTP/SpringCloud/Dubbo请求；

定时任务路由组件，用于拉起定时任务数据。

在其他实施例中，流量路由模块还可以包括elasticjob、springbatch等多种协议的路由组件，实现支持多个协议的路由配置。

本发明实施例还提供一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述任一实施例的方法的步骤。该计算机设备可以是可以执行程序的智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。本实施例的计算机设备至少包括但不限于：可通过系统总线相互通信连接的存储器、处理器。

本实施例中，存储器(即可读存储介质)包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，存储器也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card ,SMC)，安全数字(Secure Digital ,SD)卡，闪存卡(Flash Card)等。当然，存储器还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，存储器通常用于存储安装于计算机设备的操作系统和各类应用软件等。此外，存储器还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器通常用于控制计算机设备的总体操作。本实施例中，处理器用于运行存储器中存储的程序代码或者处理数据，以实现上述实施例的端到端检索式对话方法。

本发明实施例的基于规则配置化及全链路请求识别与处理的灰度路由控制方法及灰度路由组件及计算机设备，建立了灵活可配置的路由访问机制，引入灰度管理平台及客户端路由组件进行路由规则配置及规则的动态推送，将应用系统和灰度路由规则进行解耦，通过规则策略的上下线进行路由动态发布，支持多个协议的路由配置，包含常用的Http、Dubbo、SpringCloud、Kafka等多种协议的路由访问识别处理，实现了多协议下的灰度及正常应用请求路由识别处理，实现了多协议下统一的路由界面配置，统一多框架灰度路由识别及处理，同时也对全链路路由跟踪记录。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种灰度路由控制方法，其特征在于，包括如下步骤：

定义灰度路由规则，建立灰度版本、灰度应用及灰度路由规则之间的关系映射表，通过关系映射表获取对应的灰度路由规则，配置全链路交互系统的版本管理以及路由策略规则上下线；

路由规则采用变更zookeeper监听通知获取应用本地内存处理，在客户端及服务端启动时，加载路由规则，在运行过程中，动态更新路由规则，从而热加载路由规则；

以客户端组件形式嵌入应用，接受路由规则更新通知及拉取，实现全链路路由实时生效及转发，路由规则还原以通过推送历史路由规则来实现；

全链路灰度路由识别处理，对多协议请求判断生成灰度标签并在全链路中进行传递，根据灰度规则判断结果进行流量的路由至灰度版本或正常版本，以提供灰度服务或正常服务；

异步收集全链路请求信息，生成自有的串联关系标识进行记录全链路的信息跟踪，以日志形式记录客户端上的操作，以错误码形式记录异常情况。

2.如权利要求1所述的灰度路由控制方法，其特征在于，所述定义灰度路由规则包括：

通用路由规则：支持按生效时间、数据特征、请求总量、TPS以及请求权重来通用路由匹配；

HTTP路由规则：定义服务节点地址、路径匹配模式、HTTP处理方法、注册发现ServiceID及指定目标ip和端口；

Dubbo微服务路由规则：定时Dubbo服务名及方法匹配，支持包名及服务名准确和模糊匹配；

SpringCloud微服务路由规则：支持请求URL路径匹配模式、报文特征和调用方限制的路由规则；

Kafka消息主题路由规则：支持按topic主题名及主题模糊匹配，消息头及消息体、消息ID的数据特征多种匹配；

定时任务路由规则：支持定时任务job名称、方法名、任务数据对象字段匹配。

3.如权利要求1所述的灰度路由控制方法，其特征在于，还包括客户端路由异常重试及转移，当客户端请求失败后进行异常重试，重试次数可预配置，并根据客户端请求响应码进行区分是业务灰度失败还是转向正常请求。

4.如权利要求1所述的灰度路由控制方法，其特征在于，还包括引入本地内存缓存和Redis分布式缓存，通过对路由规则本地缓存及灰度标识分布式缓存进行数据路由标识，实现多协议及定时任务入库时的现场保存及现场恢复。

5.如权利要求1所述的灰度路由控制方法，其特征在于，所述全链路灰度路由识别处理包括如下步骤：

S1、获取多协议请求，获取的灰度标识进并设置头部信息，判断灰度链路是否开启，如果是，则进入步骤S2，如果否，则提供正常服务；

S2、根据灰度版本获取对应的灰度配置信息，并判断是否有灰度配置，如果是，则进入步骤S3，如果否，则提供正常服务；

S3、拼装请求信息，判断协议路由是否匹配，如果是，则进入步骤S4，如果否，则提供正常服务；

S4、判断全链路灰度规则是否匹配，如任意一个规则不匹配，则提供正常服务，如果全部规则匹配，则进入步骤S5；

S5、判断是否有灰度服务，如果是，则提供灰度服务，如果否，则自动查找灰度服务，并提供灰度服务。

6.如权利要求5所述的灰度路由控制方法，其特征在于，所述判断全链路灰度规则是否匹配包括判断规则表达式是否匹配、访问总量是否超限、每秒处理事务数是否超限、权重是否匹配以及灰度时间是否匹配。

7.一种灰度路由组件，其特征在于，包括：

UCFF灰度组件，包括客户端路由组件和服务端路由组件，用于定义灰度路由规则，建立灰度版本、灰度应用及灰度规则关系映射表、灰度配置读取、配置变更监听；客户端路由组件与SDK形式嵌入应用，接受路由规则更新通知及拉取，实现全链路路由实时生效及转发；

灰度发布管理平台，用于配置全链路交互系统的版本管理及路由策略规则上下线，包括版本规划、版本审核和上线下线；路由规则维护，业务全链路请求数据查看及分析，提供包含关联系统及灰度版本维护界面；

缓存模块，包括本地内存缓存组件和Redis分布式缓存组件，用于对路由规则本地缓存及灰度标识分布式缓存进行数据路由标识，实现多协议及定时任务入库时的现场保存及现场恢复；

指标输出及日志输出模块，用于异步收集全链路请求信息，生成自有的串联关系标识进行记录全链路的信息跟踪，对灰度发布管理平台内各个功能生成相关的灰度日志。

8.如权利要求7所述的灰度路由组件，其特征在于，所述UCFF灰度组件包括：

灰度配置模块，用于配置变更监听和灰度配置读取，通过心跳机制，进行灰度策略的接收、变更、管理；

流量路由模块，用于根据灰度规则判断结果进行流量的路由至灰度版本或正常版本，流量路由模块需要实现请求的降级处理；

灰度标签生成、传递模块，用于通过对流量报文、来源IP和白名单的判断生成灰度标签并在链路中传递。

9.如权利要求7所述的灰度路由组件，其特征在于，所述流量路由模块包括：

Kafka路由组件，用于接收发送的消息，按topic主题名及主题模糊匹配，消息头及消息体、消息ID的数据特征多种匹配；

HTTP/SpringCloud/Dubbo路由组件，用于接收HTTP/SpringCloud/Dubbo请求；

定时任务路由组件，用于拉起定时任务数据。

10.一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6任一项所述控制方法的步骤。

Images