CN113810474B - 一种请求的分流方法及终端 - Google Patents

Abstract

本发明公开一种请求的分流方法及终端，接收微服务应用请求，微服务应用请求包括机房标识；获取机房标识对应的机房的服务容量，判断服务容量是否满足预设条件，若是，则优先返回机房标识对应的机房的路由列表信息；若否，则返回全部机房的路由列表信息；通过在接收微服务应用请求时，同时接收微服务应用请求的机房标识，并通过机房标识获取对应机房的服务容量，当对应的机房具有提供服务的能力时，优先返回对应机房的路由列表信息至微服务应用，而当对应的机房不具有提供服务的能力时，将全部机房的路由列表信息返回至微服务应用，从而能够对路由列表信息进行过滤或者排序，对流量进行负载与分流，实现跨机房或同机房的流量控制。

Description

一种请求的分流方法及终端

技术领域

本发明涉及服务器技术领域，特别是涉及一种请求的分流方法及终端。

背景技术

目前的服务端系统大都采用微服务架构方式构建。采用微服务架构方式需要具备一整套基础配套组件，其中最主要的是服务注册中心。服务注册中心为微服务基础配组件套中的重要组成，每个微服务组件会向服务注册中心注册应用以及获取应用列表。服务注册中心的主要使用流程为：当应用组件启动时，微服务组件向服务注册中心注册信息，后续将会定时从注册中心获取自身应用所需要使用到的其他应用的注册列表信息，并保存注册列表信息至应用自身的本地缓存中。当某个应用宕机、故障、网络抖动或者重启时，服务注册中心将会以主动通知或者被动检测的方式进行感知，并剔除出现问题的应用。最终，其他应用在下个查询注册列表的周期时，能够获取到最新的注册列表，进而避免访问到故障的应用。

在微服务部署中，由于大都采用分布式部署。同时，为了实现高可用、高并发等条件，每个微服务应用都存在多个部署实例。这些部署实例可能分布在多个机房中。而不同机房之间即使通过专线网络带宽进行数据交互，也会有一定的请求延迟。并且同机房之间也可能存在实例的容量无法支持本机房的消费问题。即采用注册中心方式时，同一个应用的不同实例分别部署到不同机房中，在随机访问的过程中，不同机房之间存在访问的网络延迟，不能够解决跨机房或同机房的流量控制。

发明内容

本发明所要解决的技术问题是：提供一种请求的分流方法及终端，实现跨机房或同机房的流量控制。

为了解决上述技术问题，本发明采用的技术方案为：

一种请求的分流方法，包括步骤：

接收微服务应用请求，所述微服务应用请求包括机房标识；

获取所述机房标识对应的机房的服务容量，判断所述服务容量是否满足预设条件，若是，则优先返回所述机房标识对应的机房的路由列表信息；若否，则返回全部机房的路由列表信息。

为了解决上述技术问题，本发明采用的另一种技术方案为：

一种请求的分流终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述一种请求的分流方法中的各个步骤。

本发明的有益效果在于：通过在接收微服务应用请求时，同时接收微服务应用请求的机房标识，并通过机房标识获取对应机房的服务容量，当对应的机房具有提供服务的能力时，优先返回对应机房的路由列表信息至微服务应用，而当对应的机房不具有提供服务的能力时，将全部机房的路由列表信息返回至微服务应用，从而能够对路由列表信息进行过滤或者排序，对流量进行负载与分流，实现跨机房或同机房的流量控制。

附图说明

图1为本发明实施例中的一种请求的分流方法的步骤流程图；

图2为本发明实施例中的一种请求的分流方法的另一步骤流程图；

图3为本发明实施例中的一种请求的分流终端的结构示意图。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

请参照图1，一种请求的分流方法，包括步骤：

接收微服务应用请求，所述微服务应用请求包括机房标识；

获取所述机房标识对应的机房的服务容量，判断所述服务容量是否满足预设条件，若是，则优先返回所述机房标识对应的机房的路由列表信息；若否，则返回全部机房的路由列表信息。

由上述描述可知，本发明的有益效果在于：通过在接收微服务应用请求时，同时接收微服务应用请求的机房标识，并通过机房标识获取对应机房的服务容量，当对应的机房具有提供服务的能力时，优先返回对应机房的路由列表信息至微服务应用，而当对应的机房不具有提供服务的能力时，将全部机房的路由列表信息返回至微服务应用，从而能够对路由列表信息的过滤或者排序，对流量进行负载与分流，实现跨机房或同机房的流量控制。

进一步地，所述若否，则返回全部机房的路由列表信息之前包括步骤：

若否，获取每一机房的服务容量；

判断是否存在满足所述预设条件的机房，若是，则优先返回所述满足所述预设条件的机房的路由列表信息；若否，则返回全部机房的路由列表信息。

由上述描述可知，通过获取每一机房的服务容量，并判断是否存在满足预设条件的机房，从而能够将具有更强服务能力的机房从所有提供服务的机房中挑出，并优先返回至微服务应用，减少了剩余服务能力较低的机房的流量负担，实现跨机房的流量控制。

进一步地，所述获取每一机房的服务容量包括：

获取集群服务实例总数以及每一所述机房可提供服务的实例数量；

所述判断所述服务容量是否满足预设条件包括：

预设服务容量阈值，判断所述机房可提供服务的实例数量与所述集群服务实例总数的比值是否大于所述预设服务容量阈值，若大于，则所述服务容量满足预设条件。

由上述描述可知，通过获取集群服务实例总数以及每一机房可提供服务的实例数量，从而能够精确的计算出每一机房当前实际的服务容量比例，并且能够根据每一机房当前实际的服务容量比例得到每一机房当前负载流量的能力，更精确的实现将当前微服务应用请求分配至负载流量能力更强的机房中，提高对跨机房的流量控制。

进一步地，所述获取所述机房可提供服务的实例数量包括：

获取每一所述机房内的每一实例的请求总量；

判断每一所述实例的请求总量是否到达第一阈值，若否，则所述实例可提供服务；

所述可提供服务的实例数量为所述机房内可提供服务的实例的数量之和。

由上述描述可知，通过获取每一机房内的每一实例的请求总量，并根据设定的第一阈值判断每一实例是否可提供服务，从而可以精细控制到每一个实例，进而实现实例级别的路由，提高流量的分流的精度。

进一步地，还包括：

接收客户端的注册信息，并与所述客户端之间生成长链接。

由上述描述可知，当接收客户端的注册信息后与客户端之间生成长链接，使的每一接入注册中心的微服务应用都与注册中心存在一个长链接，从而能够对每一微服务应用实现监控。

进一步地，所述获取每一所述机房内的每一实例的请求总量包括：

根据所述长链接，实时获取每一所述实例的请求总量。

由上述描述可知，通过注册中心与客户端之间的长链接，实时获取每一实例的请求总量，从而能够实时的反馈每一机房内每一实例的情况，实现实时的进行微服务应用请求的分流与路由的特殊处理。

进一步地，所述获取所述机房标识对应的机房的服务容量之前还包括步骤：

判断所述机房标识对应的机房是否存在与所述微服务应用请求对应的实例，若是，则执行获取所述机房标识对应的机房的服务容量的步骤；若否，则返回全部机房的路由列表信息。

由上述描述可知，通过在获取机房标识对应的机房的服务容量之前先判断机房标识对应的机房内是否有对应的实例存在，当不存在对应的实例时，直接返回全部机房的路由列表信息，从而避免了当不存在对应实例时，仍执行获取机房的服务容量的步骤，减少路由列表信息反馈的时间，提高信息反馈效率。

进一步地，所述接收微服务应用请求，所述微服务应用请求还包括灰度开关标识；

所述判断所述机房标识对应的机房是否存在与所述微服务应用请求对应的实例之前包括步骤：

根据所述灰度开关标识判断灰度开关是否打开，若是，则执行获取所述机房标识对应的机房的服务容量的步骤；若否，则返回全部机房的路由列表信息。

由上述描述可知，通过获取灰度开关标识，并且只有在灰度开关标识处于开启的状态下时，才对微服务应用请求需要的路由列表信息进行过滤和排列；而当大部分机房处于空闲状态时，即大部分的实例都具有可服务的能力时，通过关闭灰度开关，能够将全部实例的路由列表信息返回至微服务应用，从而提高微服务应用接入效率。

进一步地，所述接收微服务应用请求之前还包括：

接收灰度开关设置请求，根据所述灰度开关设置请求打开或关闭灰度开关。

由上述描述可知，通过接收灰度开关设置请求设置当前灰度，从而能够根据当前机房中实例接收请求总量的信息，将灰度开关设置为开启状态或关闭状态，提高客户端与服务端之间的连接效率。

请参照图3，本发明另一实施例提供了一种请求的分流终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述一种请求的分流方法中的各个步骤。

本发明上述请求的分流方法及终端能够适用于互联网相关的产品中，如具有注册中心的微服务部署项目，以下通过具体实施方式进行说明：

实施例一

请参照图1，一种请求的分流方法，包括步骤：

S1、接收微服务应用请求，所述微服务应用请求包括机房标识；

S2、获取所述机房标识对应的机房的服务容量，判断所述服务容量是否满足预设条件，若是，则优先返回所述机房标识对应的机房的路由列表信息；若否，则获取每一机房的服务容量；判断是否存在满足所述预设条件的机房，若存在，则优先返回所述满足所述预设条件的机房的路由列表信息；若不存在，则返回全部机房的路由列表信息；

即满足所预设条件的机房，则表示该机房仍然可以提供服务支持，反之，则表示该机房存在服务容量的隐患；

其中，所述获取每一机房的服务容量包括：

获取集群服务实例总数以及每一所述机房可提供服务的实例数量；获取每一所述机房内的每一实例的请求总量；判断每一所述实例的请求总量是否到达第一阈值，若否，则所述实例可提供服务；所述可提供服务的实例数量为所述机房内可提供服务的实例的数量之和；通过对后台实例布置监控功能，能够精细控制到每一个实例，进而实现实例级别的路由，而不是针对域名级别的路由；

所述判断所述服务容量是否满足预设条件包括：

预设服务容量阈值，判断所述机房可提供服务的实例数量与所述集群服务实例总数的比值是否大于所述预设服务容量阈值，若大于，则所述服务容量满足预设条件；

具体的，所述微服务应用请求由客户端发出；所述客户端统一接入注册中心SDK(Software Development Kit，软件开发工具包)，每次获取所述路由列表信息时，均需要传递自身应用实例所在的所述机房标志；即为每一实例设置对应的机房归属；

接收端为服务端，在旧有注册中心的基础之上对所述服务端进行对应的改造；当接收所述客户端的注册信息时，所述服务端与所述客户端之间生成长链接；并根据所述长链接，实时获取每一所述实例的请求总量，实时的进行请求的分流与路由的特殊处理；并且，所述服务端内设置有一个监控系统，所述监控系统能够监控一段时间之内每个所述实例的请求总量，监控应用集群的TPS(Transaction Per Second，每秒事务处理量)；对于后台实例的监控功能，能够精细控制到每一个实例，进而实现实例级别的路由，而不是针对域名级别的路由。

实施例二

本实施例与实施例一的不同在于，限定了接收微服务应用请求前的步骤；

请参照图2，步骤S1之前还包括步骤S0：接收灰度开关设置请求，根据所述灰度开关设置请求打开或关闭灰度开关；

所述接收微服务应用请求，所述微服务应用请求还包括灰度开关标识；所述步骤S2之前包括步骤S20：

根据所述灰度开关标识判断灰度开关是否打开，若是，则判断所述机房标识对应的机房是否存在与所述微服务应用请求对应的实例，若存在，则执行获取所述机房标识对应的机房的服务容量的步骤；若不存在，则返回全部机房的路由列表信息；若灰度开关关闭，则返回全部机房的路由列表信息；

其中，在旧有服务器的方式下，所述路由列表只记录每个实例的内网IP和端口信息；而在本技术方案的方式下，需要根据上述的步骤进行对所述路由列表的过滤处理，具体的：

当所述微服务应用对应的所述灰度开关设置为关闭状态时，接收微服务应用请求后，所述灰度开关标识为关闭；因此直接返回全部所述实例的路由列表信息；

当所述微服务应用对应的所述灰度开关设置为开启状态时，接收微服务应用请求后，所述灰度开关标识为开启；根据所述机房标识判断对应所述机房内是否存在与所述微服务应用对应的实例，如所述微服务应用对应的所有实例均不在所述机房标识对应的机房内，则直接返回全部路由列表；

当所述微服务应用对应的所述灰度开关设置为开启状态时，接收微服务应用请求后，所述灰度开关标识为开启，并且所述机房标识对应的机房内存在与所述微服务应用对应的实例，即本机房或本机房和跨机房中均存在对应的实例，则执行所述步骤S2。

实施例三

请参照图3，本实施例提供了一种请求的分流终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述实施例一或二中任意一种请求的分流方法中的各个步骤；

在一种可选的实施方式中，上述请求的分流终端为注册中心。

综上所述，本发明提供的一种请求的分流方法及终端，通过注册中心对于已注册的实例进行实例的额外监控，并且在接收微服务应用请求时，同时接收微服务应用请求的机房标识和灰度开关标识，先通过灰度开关标识判断是否进行灰度控制，当灰度开关标识为开启状态时，再通过机房标识判断本机房内是否存在与微服务应用对应的实例，只有当本机房内存在对应的实例后，才获取本机房的服务容量，并判断是否具有提供服务的能力；从而当本机房具有提供服务的能力时，优先返回对应机房的路由列表信息至微服务应用，而当对应的机房不具有提供服务的能力或本机房内不存在对应的实例时，将全部机房的路由列表信息返回至微服务应用；而在将全部机房的路由列表信息返回至微服务应用的过程中，通过判断跨机房中是否存在能够提供服务的机房，能够将具有提供服务的能力再优先返回至微服务应用，从而能够对路由列表信息进行过滤或者排序，较为实时的通知调用的客户端，对流量进行负载与分流，实现跨机房或同机房的流量控制。

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

Claims (7)

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

接收微服务应用请求，所述微服务应用请求包括机房标识；

获取所述机房标识对应的机房的服务容量，判断所述服务容量是否满足预设条件，若是，则优先返回所述机房标识对应的机房的路由列表信息；若否，则返回全部机房的路由列表信息；

所述若否，则返回全部机房的路由列表信息之前包括步骤：

若否，获取每一机房的服务容量；

判断是否存在满足所述预设条件的机房，若是，则优先返回所述满足所述预设条件的机房的路由列表信息；若否，则返回全部机房的路由列表信息；

所述获取每一机房的服务容量包括：

获取集群服务实例总数以及每一所述机房可提供服务的实例数量；

所述判断所述服务容量是否满足预设条件包括：

预设服务容量阈值，判断所述机房可提供服务的实例数量与所述集群服务实例总数的比值是否大于所述预设服务容量阈值，若大于，则所述服务容量满足预设条件；

所述获取集群服务实例总数以及每一所述机房可提供服务的实例数量包括：

获取每一所述机房内的每一实例的请求总量；

判断每一所述实例的请求总量是否到达第一阈值，若否，则所述实例可提供服务；

所述可提供服务的实例数量为每一所述机房内可提供服务的实例的数量之和。

2.根据权利要求1所述的一种请求的分流方法，其特征在于，还包括：

接收客户端的注册信息，并与所述客户端之间生成长链接。

3.根据权利要求2所述的一种请求的分流方法，其特征在于，所述获取每一所述机房内的每一实例的请求总量包括：

根据所述长链接，实时获取每一所述实例的请求总量。

4.根据权利要求1所述的一种请求的分流方法，其特征在于，所述获取所述机房标识对应的机房的服务容量之前还包括步骤：

判断所述机房标识对应的机房是否存在与所述微服务应用请求对应的实例，若是，则执行获取所述机房标识对应的机房的服务容量的步骤；若否，则返回全部机房的路由列表信息。

5.根据权利要求4所述的一种请求的分流方法，其特征在于，所述接收微服务应用请求，所述微服务应用请求还包括灰度开关标识；

所述判断所述机房标识对应的机房是否存在与所述微服务应用请求对应的实例之前包括步骤：

根据所述灰度开关标识判断灰度开关是否打开，若是，则执行获取所述机房标识对应的机房的服务容量的步骤；若否，则返回全部机房的路由列表信息。

6.根据权利要求5所述的一种请求的分流方法，其特征在于，所述接收微服务应用请求之前还包括：

接收灰度开关设置请求，根据所述灰度开关设置请求打开或关闭灰度开关。

7.一种请求的分流终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1-6中任意一项所述的一种请求的分流方法中的各个步骤。

Images