CN114143269A - 一种http请求分流方法、装置、设备及介质 - Google Patents

Abstract

本申请公开了一种HTTP请求分流方法、装置、设备及介质，包括：获取源服务发送的目标HTTP请求；对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据；将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略；利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务；将所述目标HTTP请求转发至所述目标服务上。能够避免不同业务的影响，具有通用性，且提升配置的分流策略的有效性和准确性。

Description

一种HTTP请求分流方法、装置、设备及介质

技术领域

本申请涉及请求分流技术领域，特别涉及一种HTTP请求分流方法、装置、设备及介质。

背景技术

在互联网技术中，产品在不断发展，相应服务的技术选型也在不断的变化，技术栈的变化需要对旧服务重构和改造，新服务开发完成后，会进行新旧服务过渡。由于新服务直接发布生产可能出现与预期不匹配的现象，并且造成服务稳定性和可用性问题。故需要一个将旧服务的部分流量分流至新服务，在上线后依据是否达到预期效果来逐步调整流量进行切换，达到平稳切换的目的。为了保证新旧服务平滑切换，并且对上游调用方无感知，一个比较好的方法就是对这两个版本进行分流，通过测试进行效果分析。

目前，常用的流量分发的技术有A/B测试和负载均衡。A/B测试是一种产品优化方法，就是在同一时间维度，分别让组成成分相同(或相似)的访客群组随机的访问各版本服务，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。基于负载均衡实现流量分发的技术，是负载均衡接收到客户端请求后，将流量按照转发策略分发到该负载下的应用服务器上。A/B测试的缺陷在于：要针对每个业务场景单独设置相应的分流机制，消耗大量的人力成本，因此A/B测试更多的是用于不同功能产品的对比测试。基于负载均衡的流量分发方式的缺陷在于转发策略的可配置性弱。

发明内容

有鉴于此，本申请的目的在于提供一种HTTP请求分流方法、装置、设备及介质，能够避免不同业务的影响，具有通用性，且提升配置的分流策略的有效性和准确性。其具体方案如下：

第一方面，本申请公开了一种HTTP请求分流方法，包括：

获取源服务发送的目标HTTP请求；

对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据；

将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略；

利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务；

将所述目标HTTP请求转发至所述目标服务上。

可选的，所述获取源服务发送的目标HTTP请求，包括：

拦截源服务发送的基于指定域名的HTTP请求；

判断所述HTTP请求是否满足预设筛选条件；

若满足，则将所述HTTP请求确定为目标HTTP请求。

可选的，所述将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略，包括：

根据所述目标数据确定出接口信息；

将所述接口信息与预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

可选的，所述将所述接口信息与预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略，包括：

将所述接口信息与本地缓存中的预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略；

若本地缓存中没有所述目标分流策略，则将所述接口信息与数据库中的所述预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

可选的，还包括：

获取变更分流策略，根据所述变更分流策略修改所述数据库，并修改zookeeper中的目标信息，以便zookeeper触发变更事件，通知各分流服务器从所述数据库中将所述变更分流策略刷新至自身缓存中。

可选的，所述利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务，包括：

根据所述目标分流策略中的分流规则以及所述目标数据确定出所述目标HTTP请求对应的目标服务。

可选的，所述将所述目标HTTP请求转发至所述目标服务上之后，还包括：

获取所述目标服务的返回数据，将所述返回数据返回给所述源服务；

若出现请求异常，则将预设状态码返回给所述源服务；

其中，不同的异常类型对应不同的预设状态码。

第二方面，本申请公开了一种HTTP请求分流装置，其包括：

目标请求获取模块，用于获取源服务发送的目标HTTP请求；

目标请求解析模块，用于对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据；

分流策略匹配模块，用于将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略；

目标服务确定模块，用于利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务；

目标请求转发模块，用于将所述目标HTTP请求转发至所述目标服务上。

第三方面，本申请公开了一种电子设备，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现前述的HTTP请求分流方法。

第四方面，本申请公开了一种计算机可读存储介质，用于保存计算机程序，所述计算机程序被处理器执行时实现前述的HTTP请求分流方法。

可见，本申请先获取源服务发送的目标HTTP请求，之后对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据，然后将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略，并利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务，最后将所述目标HTTP请求转发至所述目标服务上。也即，本申请中根据接收到的目标HTTP请求中的目标关键信息匹配出请求对应的预设分流策略，按照与目标HTTP请求匹配的预设分流策略将请求转发至目标服务上，这样，分流策略和请求相关，能够避免不同业务的影响，具有通用性，且提升配置的分流策略的有效性和准确性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请提供的一种HTTP请求分流方法流程图；

图2为本申请提供的一种具体的分流策略配置示意图；

图3为本申请提供的一种具体的HTTP请求分流方法流程图；

图4为本申请提供的一种具体的HTTP请求分流方法流程图；

图5为本申请提供的一种HTTP请求分流装置结构示意图；

图6为本申请提供的一种电子设备结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，常用的流量分发的技术有A/B测试和负载均衡。A/B测试是一种产品优化方法，就是在同一时间维度，分别让组成成分相同(或相似)的访客群组随机的访问各版本服务，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。基于负载均衡实现流量分发的技术，是负载均衡接收到客户端请求后，将流量按照转发策略分发到该负载下的应用服务器上。A/B测试的缺陷在于：要针对每个业务场景单独设置相应的分流机制，消耗大量的人力成本，因此A/B测试更多的是用于不同功能产品的对比测试。基于负载均衡的流量分发方式的缺陷在于转发策略的可配置性弱。为此，本申请提供了一种HTTP请求分流方案，能够避免不同业务的影响，具有通用性，且提升配置的分流策略的有效性和准确性。

参见图1所示，本申请实施例公开了一种HTTP请求分流方法，包括：

步骤S11：获取源服务发送的目标HTTP请求。

在具体的实施方式中，可以拦截源服务发送的基于指定域名的HTTP请求；判断所述HTTP请求是否满足预设筛选条件；若满足，则将所述HTTP请求确定为目标HTTP请求。

其中，指定域名为旧服务的原域名。

并且，预设筛选条件可以为目标HTTP请求非重定向请求或前端资源请求；

需要指出的是，预设筛选条件可以根据实际场景确定，比如，新服务不涉及前端资源请求，则将前端资源请求直接转发至旧服务，不作为目标HTTP请求。

步骤S12：对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据。

其中，目标关键信息可以包括请求方式、请求参数，Header(头部)信息等。将目标关键信息组合为分流策略对应的预设格式的数据实体。

步骤S13：将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略。

在具体的实施方式中，可以根据所述目标数据确定出接口信息；将所述接口信息与预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

也即，本申请实施例可以在请求的接口维度进行分流策略配置，其中，每个接口均存在该接口对应的预设分流策略。

进一步的，在具体的实施方式中，每个接口信息对应的预设分流策略可以包括一种或多种分流策略，比如请求方式策略、参数白名单策略、参数比例策略、流量比例策略中的一种或多种。并且，可以设置策略优先级，根据策略优先级依次利用匹配到的预设分流策略确定目标服务，直到确定出目标服务。

其中，请求方式策略为根据接口的请求方式确定目标服务的策略；参数白名单策略，为根据接口中包含的指定参数是否满足白名单确定目标服务的策略；参数比例策略为根据请求的指定参数的hash值以及预设比例参数确定目标服务的策略；流量比例策略为将请求按比例分流至目标服务的策略。任一分流策略中均包括相应的分流规则，

例如：参数白名单策略，接收到请求后，解析出指定参数，比如用户标识。当该请求的目标标识在参数白名单配置列表里，分流该请求到新服务，当该请求的目标标识不在参数白名单配置列表里，分流该请求到旧服务。

例如，参数比例策略；预设比例参数为percent1：

若percent1＝0：分流所有请求到旧服务。

若0<percent1<100：接收源服务的请求，解析出指定参数，比如用户标识，计算该参数的hash值m，并对m进行位运算，右移16位得到值k，最终对m和k进行与计算，得到n；若n<＝percent：将该请求分流到新服务；若n>percent：分流***将该请求分流到旧服务。

若percent1＝100：所有请求分流到新服务。

例如，流量比例策略，预设比例参数为percent2：

接收到请求后，生成1至100之间的随机数，若该随机数小于等于percent2，则将请求分流至新服务，否则，将请求分流至旧服务。

并且，在具体的实施方式中，本申请实施例将所述接口信息与本地缓存中的预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略；若本地缓存中没有所述目标分流策略，则将所述接口信息与数据库中的所述预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

若从数据库中也无法匹配出与所述接口信息匹配的预设分流策略，则利用默认分流策略确定出所述目标HTTP请求对应的目标服务。

其中，默认分流策略直接指定目标服务，比如指定新服务为目标服务或旧服务为目标服务。

并且，具体的实施方式中，本申请实施例可以获取变更分流策略，根据所述变更分流策略修改所述数据库，并修改zookeeper中的目标信息，以便zookeeper触发变更事件，通知各分流服务器从所述数据库中将所述变更分流策略刷新至自身缓存中。其中目标信息可以为接口信息。

需要指出的是，所有分流服务器均到zookeeper注册节点，当zookeeper触发变更事件，各分流服务器监听到变更事件，从所述数据库中将所述变更分流策略刷新至自身缓存中。

例如，参见图2所示，本申请实施例提供了一种具体的分流策略配置示意图。所有分流服务器到zookeeper注册节点，任一分流服务器变更配置，以变更分流策略，将到zookeeper修改接口信息，zookeeper触发变更事件，包括具体需要变更策略的分流服务器以及变更分流策略对应的接口标识，以便各分流服务器根据接口标识，从数据库中查找对应的分流策略，刷新本地配置缓存。

这样，保障了策略匹配的实时性在请求的策略匹配过程中，是获取缓存中的策略而非从DB中查询，减少I/O交互，同时解决缓存穿透问题，减少DB压力及与中间件的I/O交互损耗，提升接口请求速率。并且保障了策略匹配的可靠性。若未匹配到分流策略，则分配默认策略，避免因策略的缺失导致此次请求异常。

步骤S14：利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务。

在具体的实施方式中，可以根据所述目标分流策略中的分流规则以及所述目标数据确定出所述目标HTTP请求对应的目标服务。

步骤S15：将所述目标HTTP请求转发至所述目标服务上。

进一步的，本申请实施例还可以获取所述目标服务的返回数据，将所述返回数据返回给所述源服务。

并且，若出现请求异常，则将预设状态码返回给所述源服务；其中，不同的异常类型对应不同的预设状态码。

可见，本申请实施例先获取源服务发送的目标HTTP请求，之后对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据，然后将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略，并利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务，最后将所述目标HTTP请求转发至所述目标服务上。也即，本申请中根据接收到的目标HTTP请求中的目标关键信息匹配出请求对应的预设分流策略，按照与目标HTTP请求匹配的预设分流策略将请求转发至目标服务上，这样，分流策略和请求相关，能够避免不同业务的影响，具有通用性，且提升配置的分流策略的有效性和准确性。

进一步的，在具体的实施方式中，本申请中的HTTP请求分流方案可以通过分流***实现。

相应的，具体的异常类型即解决方案可以如下：

1、分流***无故障，下游新服务业务异常。解决方案：针对接口维度切换至旧服务，通过关闭接口分流配置总开关，将上游源服务的请求全部分流到旧服务集群，保障服务可用。也即，本申请实施例提供的分流***包括接口分流配置总开关，当新服务出现故障，则关闭接口分流配置总开关，将目标HTTP请求转发至旧服务上。

2、分流***灰度逻辑异常。解决方案：针对应用维度切换至下游旧服务，通过关闭应用开关，将上游源服务的请求全部分流到旧服务集群，保障服务可用。也即，分流******还包括应用开关，在分流***逻辑异常时，可以将应用开关关闭，以将目标HTTP请求发送至旧服务上。

3、分流***不可用。解决方案：LB(即LoadBalance负载均衡)直接切换至下游旧服务。

4、分流***高负载。解决方案：分流***接入限流组件(sentinel)限制分流接口QPS(即Queries-per-second，每秒查询率)，保障分流***负载不至过高，保障服务可用。

5、下游服务(包括新服务和旧服务)超时或失败。解决方案：分流***分流请求下游服务，根据分流策略配置动态设置请求超时时间；分流***快速失败(failfast)，不做失败重试操作，由上游服务或者负载网关决定是否重试(跨***调用，上游服务需考虑异常场景)，下游服务考虑服务幂等。

可以理解的是，本申请实施例若分流***在任何一步发生异常时，默认转发至指定的旧服务，避免因分流***内部代码异常情况而导致的请求异常。而传统的在LB层做分流的方式，势必会造成LB层的性能损耗，而LB作为服务的最上层应用，一旦阻塞，会影响整个服务的转发。由此可见，本申请提供的方案，可靠性更高。

下面，以旧服务为.Net服务、新服务为Java服务为例，详细的介绍本申请提供的HTTP请求分流方案。旧服务的原域名为A域名，为了适配分流***创建新域名：B域名。将B域名指向.Net服务，将A域名指向分流***，Java服务注册到服务注册中心(Eureka)，通过如此调整，服务调用方即源服务基于A域名的请求会首先到达分流***，分流***接收到请求后会根据请求参数和请求特征，按照预设分配策略判断当前请求需要被转发到.Net服务还是Java服务，转发后将.Net服务或者Java服务的返回值响应给调用方，起到服务分流的作用。分流***用于对HTTP请求进行拦截，解析出当前请求的HTTP报文信息，得到目标关键信息，包括请求方式、请求参数信息、Header信息等，并将信息组合成分流策略需要的数据实体。并且，可以对分流策略中的分流规则进行定制，支持按请求方式分流、按接口比例分流、按某一请求参数的一个或多个值分流、不同接口的分流支持制定不同规则、指定默认策略。根据分流策略将请求转发至目标服务上，并将下游服务的返回值返回给调用方。并且可以对分流策略和分流规则进行配置，配置完成后同步更新至分流***各个服务器内存中。

例如，参见图3所示，图3为本申请实施例提供的一种HTTP请求分流方法比对示意图，现有技术中的HTTP请求分流方法中，上游业务***也即源服务基于原域名A向.NET服务发送HTTP请求，而本申请提供的方案，上游业务***基于原域名A发送的HTTP请求，通过分流***分流至目标服务，目标服务为.Net，则基于新域名B将HTTP请求发送至.Net服务，目标服务为Java服务，则通过Java网关将HTTP请求发送至Java服务。其中，HTTP请求通过LB到达服务端后，将新LB即基于新域名B的请求指向.Net服务，原LB即基于原域名A的请求指向分流***，分流***按照接口维度配置好的分流策略，以某一参数维度或流量维度等进行分流，这样，原有流量迁移至分流***，分流服务根据策略请求下游服务即.Net服务或新Java服务。

例如，参见图4所示，图4为本申请实施例提供的一种具体的HTTP请求分流方法流程图。首先判断请求是否为重定向或前端资源请求，若是，则直接重定向或请求下游.Net服务；否则解析请求header、param、method等关键信息，组成预设格式的目标数据，根据接口获取缓存中的配置信息也即配置好的分流策略，若不存在则先从db(数据库)中查询并缓存至本地缓存中；根据配置信息执行相关的分流策略，确认目标url，转发HTTP请求，透传上游请求关键信息，若执行无异常，透传目标服务返回结果至上游业务***，若执行异常，返回上游业务***分流***自定义状态码。其中，分流***共支持五种策略，如下：请求方式策略：根据接口请求的方式，直接将请求分流至目标服务；参数白名单策略：根据接口中包含的某一参数信息是否满足白名单而指定目标服务；参数比例策略：根据某一参数hash值进行比例分布而指定目标服务；流量比例策略：根据请求流量的比例分布而指定目标服务；默认策略：直接指定目标服务。

具体的利用分流策略分流的过程，比如，若请求对应的接口的接口分流开关关闭：分流***将请求下发到旧服务；接口分流开关打开，且白名单列表不为空，以白名单分流，白名单列表为空则判断某一参数分流比例配置，比例为空或0则全路由旧服务，比例不为空则按参数比例分流至新服务，其余比例的请求分流到旧服务。也即，本申请实施例中，每个接口均有对应的接口分流开关。

这样，实现新老服务的平稳切换，灵活支持流量分流的策略，可依据线上效果逐步调整流量的比例或策略调整，同时保障业务请求的柔性可用。并且，不依赖上游***变动，极大的减少人力的投入。可实现快速切换：闭环升级，不依赖外部***排期，极大提升新旧服务的迁移速度。

参见图5所示，本申请提供了一种HTTP请求分流装置，包括：

目标请求获取模块11，用于获取源服务发送的目标HTTP请求；

目标请求解析模块12，用于对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据；

分流策略匹配模块13，用于将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略；

目标服务确定模块14，用于利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务；

目标请求转发模块15，用于将所述目标HTTP请求转发至所述目标服务上。

可见，本申请实施例先获取源服务发送的目标HTTP请求，之后对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据，然后将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略，并利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务，最后将所述目标HTTP请求转发至所述目标服务上。也即，本申请中根据接收到的目标HTTP请求中的目标关键信息匹配出请求对应的预设分流策略，按照与目标HTTP请求匹配的预设分流策略将请求转发至目标服务上，这样，分流策略和请求相关，能够避免不同业务的影响，具有通用性，且提升配置的分流策略的有效性和准确性。

其中，目标请求获取模块11，具体用于拦截源服务发送的基于指定域名的HTTP请求；判断所述HTTP请求是否满足预设筛选条件；若满足，则将所述HTTP请求确定为目标HTTP请求。

分流策略匹配模块13，具体包括：

接口信息确定子模块，用于根据所述目标数据确定出接口信息；

分流策略匹配子模块，用于将所述接口信息与预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

并且，分流策略匹配子模块，具体用于将所述接口信息与本地缓存中的预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略；若本地缓存中没有所述目标分流策略，则将所述接口信息与数据库中的所述预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

进一步的，所述装置还包括：

分流策略配置模块，用于获取变更分流策略，根据所述变更分流策略修改所述数据库，并修改zookeeper中的目标信息，以便zookeeper触发变更事件，通知各分流服务器从所述数据库中将所述变更分流策略刷新至自身缓存中。

目标服务确定模块14，具体用于根据所述目标分流策略中的分流规则以及所述目标数据确定出所述目标HTTP请求对应的目标服务。

进一步的，所述装置还包括：

数据返回模块，用于获取所述目标服务的返回数据，将所述返回数据返回给所述源服务；若出现请求异常，则将预设状态码返回给所述源服务；

其中，不同的异常类型对应不同的预设状态码。

参见图6所示，本申请实施例公开了一种电子设备20，包括处理器21和存储器22；其中，所述存储器22，用于保存计算机程序；所述处理器21，用于执行所述计算机程序，前述实施例公开的HTTP请求分流方法。

关于上述HTTP请求分流方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

并且，所述存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，存储方式可以是短暂存储或者永久存储。

另外，所述电子设备20还包括电源23、通信接口24、输入输出接口25和通信总线26；其中，所述电源23用于为所述电子设备20上的各硬件设备提供工作电压；所述通信接口24能够为所述电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；所述输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

进一步的，本申请实施例还公开了一种计算机可读存储介质，用于保存计算机程序，其中，所述计算机程序被处理器执行时实现前述实施例公开的HTTP请求分流方法。

关于上述HTTP请求分流方法的具体过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种HTTP请求分流方法、装置、设备及介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种HTTP请求分流方法，其特征在于，包括：

获取源服务发送的目标HTTP请求；

对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据；

将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略；

利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务；

将所述目标HTTP请求转发至所述目标服务上。

2.根据权利要求1所述的HTTP请求分流方法，其特征在于，所述获取源服务发送的目标HTTP请求，包括：

拦截源服务发送的基于指定域名的HTTP请求；

判断所述HTTP请求是否满足预设筛选条件；

若满足，则将所述HTTP请求确定为目标HTTP请求。

3.根据权利要求1所述的HTTP请求分流方法，其特征在于，所述将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略，包括：

根据所述目标数据确定出接口信息；

将所述接口信息与预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

4.根据权利要求3所述的HTTP请求分流方法，其特征在于，所述将所述接口信息与预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略，包括：

将所述接口信息与本地缓存中的预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略；

若本地缓存中没有所述目标分流策略，则将所述接口信息与数据库中的所述预设分流策略进行匹配，得到与所述接口信息匹配的目标分流策略。

5.根据权利要求4所述的HTTP请求分流方法，其特征在于，还包括：

获取变更分流策略，根据所述变更分流策略修改所述数据库，并修改zookeeper中的目标信息，以便zookeeper触发变更事件，通知各分流服务器从所述数据库中将所述变更分流策略刷新至自身缓存中。

6.根据权利要求1所述的HTTP请求分流方法，其特征在于，所述利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务，包括：

根据所述目标分流策略中的分流规则以及所述目标数据确定出所述目标HTTP请求对应的目标服务。

7.根据权利要求1至6任一项所述的HTTP请求分流方法，其特征在于，所述将所述目标HTTP请求转发至所述目标服务上之后，还包括：

获取所述目标服务的返回数据，将所述返回数据返回给所述源服务；

若出现请求异常，则将预设状态码返回给所述源服务；

其中，不同的异常类型对应不同的预设状态码。

8.一种HTTP请求分流装置，其特征在于，包括：

目标请求获取模块，用于获取源服务发送的目标HTTP请求；

目标请求解析模块，用于对所述目标HTTP请求进行解析以解析出目标关键信息，并将所述目标关键信息组合为预设格式的目标数据；

分流策略匹配模块，用于将所述目标数据与预设分流策略进行匹配，得到与所述目标数据匹配的目标分流策略；

目标服务确定模块，用于利用所述目标分流策略以及所述目标数据确定出所述目标HTTP请求对应的目标服务；

目标请求转发模块，用于将所述目标HTTP请求转发至所述目标服务上。

9.一种电子设备，其特征在于，包括：

存储器，用于保存计算机程序；

处理器，用于执行所述计算机程序，以实现如权利要求1至7任一项所述的HTTP请求分流方法。

10.一种计算机可读存储介质，其特征在于，用于保存计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的HTTP请求分流方法。

Images