CN116155818A - 路由调度方法、系统及存储介质 - Google Patents

Abstract

本申请提供一种路由调度方法、系统及存储介质，涉及通信技术领域。该方法包括：获取监控终端所请求的媒体流，媒体流中的应用请求报文具有至少一个标志信息；根据标志信息和预设的路由规则，确定应用请求报文匹配的服务器群组；其中，不同的服务器群组用于处理不同业务类型、不同业务获取源和/或不同区域的应用请求报文；将应用请求报文输入预先训练好的双向深度学习模型，输出服务器群组中与应用请求报文相匹配的目标服务器，并将应用请求报文分配给目标服务器，以供目标服务器对应用请求报文进行处理。上述方式能够在提高路由调度效率的同时，实现更细颗粒度的负载均衡。

Description

路由调度方法、系统及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种路由调度方法、系统及存储介质。

背景技术

负载均衡（Server Load Balance，SLB）建立在现有网络结构之上，它提供了一种有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

针对负载均衡，现有的路由调度方法是在网络传输层TCP、UDP协议的基础上，基于源IP、源端口、目的IP、目的端口、协议五元组进行的路由。

现有的路由调度方法只能进行粗粒度的路由，具有调度效率低的缺陷。

发明内容

本申请提供了一种路由调度方法、系统及存储介质，用以解决现有技术存在的粗粒度且调度效率低的问题。

根据本申请的第一方面，提供了一种路由调度方法，包括：

获取监控终端所请求的媒体流，所述媒体流中的应用请求报文具有至少一个标志信息；

根据所述标志信息和预设的路由规则，确定所述应用请求报文匹配的服务器群组；其中，不同的服务器群组用于处理不同业务类型、不同业务获取源和/或不同区域的应用请求报文；

将所述应用请求报文输入预先训练好的双向深度学习模型，输出所述服务器群组中与所述应用请求报文相匹配的目标服务器，并将所述应用请求报文分配给所述目标服务器，以供所述目标服务器对所述应用请求报文进行处理。

可选地，所述将所述应用请求报文输入预先训练好的双向深度学习模型，输出所述服务器群组中与所述应用请求报文相匹配的目标服务器，包括：

将所述应用请求报文输入预先训练好的双向深度学习模型的第一模块，以供所述第一模块对所述应用请求报文进行深度特征提取，得到深度特征信息；

将所述服务器群组中所有的服务器的运行状态信息输入预先训练好的双向深度学习模型的第二模块，以供所述第二模块输出由可用服务器构成的可用服务器集合；其中，所述可用服务器是所述运行状态信息为非故障状态的服务器；

将所述深度特征信息和所述可用服务器的属性信息输入至预先训练好的双向深度学习模型的第三模块，以供所述第三模块输出目标服务器。

可选地，所述方法还包括：

在所述目标服务器对所述应用请求报文进行处理的过程中，若监测到所述目标服务器的运行状态信息从非故障状态切换到故障状态，则将所述应用请求报文传输至备选服务器，以供所述目标服务器对所述应用请求报文进行重新处理。

可选地，所述根据所述标志信息和预设的路由规则，确定所述应用请求报文匹配的服务器群组，包括：

将所述应用请求报文与预设模板表中的应用请求报文类型模型进行匹配，基于匹配到的应用请求报文类型模板对所述应用请求报文中的各字段数据进行解析，得到标志信息；

从预设路由表中获取与所述匹配到的应用请求报文类型模板对应的路由规则，并将所述对应的路由规则作为预设的路由规则；

对所述标志信息进行组合处理，得到组合结果；

在所述预设的路由规则包含已有服务器群组的至少一个条件，且所述组合结果满足所有所述条件时，将所述已有服务器群组确定为所述应用请求报文匹配的服务器群组。

可选地，所述基于匹配到的应用请求报文类型模板对所述应用请求报文中的各字段数据进行解析，得到标志信息，包括：

当所述匹配到的应用请求报文类型模板为HTTP请求模板时，基于所述HTTP请求模板对所述应用请求报文中的各字段数据进行解析，得到第一标志信息；其中，所述第一标志信息包括以下至少之一：域名、Cookies、HTTP请求头、URL参数、Host字段、上下文根；

当所述匹配到的应用请求报文类型模板为TCP请求模板时，基于所述TCP请求模板对所述应用请求报文中的各字段数据进行解析，得到第二标志信息。

可选地，在将所述应用请求报文分配给所述目标服务器之后，所述方法还包括：

响应于远程控制指令，将所述应用请求报文从所述目标服务器传输至另一服务器。

可选地，在所述应用请求报文的业务类型为多个时，所述服务器群组为多个，每个所述服务器群组均对应一个所述目标服务器，所述方法还包括：

按照所述应用请求报文的业务类型的优先级，确定所述服务器群组的路由顺序；

将所述服务器群组的路由顺序确定为所述目标服务器的路由顺序；

按照所述目标服务器的路由顺序，依次将所述应用请求报文分配给各所述目标服务器。

根据本申请的第二方面，提供了一种路由调度系统，包括依次连接的监控设备、软负载集群和至少两个服务器群组，其中：

所述监控设备，用于获取监控终端所请求的媒体流，所述媒体流中的应用请求报文具有至少一个标志信息；

所述软负载集群，用于根据所述标志信息和预设的路由规则，确定所述应用请求报文匹配的服务器群组；其中，不同的服务器群组用于处理不同业务类型的应用请求报文；

所述软负载集群，还用于将所述应用请求报文输入预先训练好的双向深度学习模型，输出所述服务器群组中与所述应用请求报文相匹配的目标服务器，并将所述应用请求报文分配给所述目标服务器；

所述目标服务器，用于处理所述应用请求报文。

可选地，所述路由调度系统还包括：第一故障检测设备、第二故障检测设备和第三故障检测设备；

所述第一故障检测设备，用于检测所述监控设备的运行状态；

所述第二故障检测设备，用于检测所述软负载集群的运行状态；

所述第三故障检测设备，用于检测所述服务器群组中的服务器的运行状态。

根据本申请的第三方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如上第一方面所述的路由调度方法。

根据本申请的第四方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所述的路由调度方法。

本申请提供的一种路由方法，包括：获取监控终端所请求的媒体流，媒体流中的应用请求报文具有至少一个标志信息；根据标志信息和预设的路由规则，确定应用请求报文匹配的服务器群组；其中，不同的服务器群组用于处理不同业务类型、不同业务获取源和/或不同区域的应用请求报文；将应用请求报文输入预先训练好的双向深度学习模型，输出服务器群组中与应用请求报文相匹配的目标服务器，并将应用请求报文分配给目标服务器，以供目标服务器对应用请求报文进行处理。

本申请基于不同的服务器群组用于处理不同业务类型、不同业务获取源和/或不同区域的应用请求报文的特点，与双向深度学习模型进行有效结合，能够快速实现对目标服务器的调度，在提高路由调度效率的同时，实现更细颗粒度的负载均衡。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的一种路由调度方法的流程示意图；

图2为本申请实施例提供的预先训练好的双向深度学习模型的结构示意图；

图3为本申请实施例提供的图1中S20的流程示意图；

图4为本申请实施例提供的一种路由调度系统的结构示意图；

图5为本申请实施例提供的另一种路由调度系统的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。

目前常见的负载均衡主要分为硬件负载均衡和软件负载均衡。硬件负载均衡比较知名的产品有 F5、Cirtix Netscaler等，而软件负载均衡常见的有 Haproxy、Nginx、Lvs等。针对软负载均衡，现有的路由调度方法是在网络传输层TCP、UDP协议的基础上，基于源IP、源端口、目的IP、目的端口、协议五元组进行的路由。

但是，现有的路由调度方法只能进行粗粒度的路由，具有调度效率低的缺陷。

为了解决上述技术问题，本申请的整体发明构思为如何提供一种应用于通信领域，用于提高路由调度效率的同时，实现更细颗粒度的负载均衡的路由调度方法。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

实施例1：

图1为本申请实施例提供的一种路由调度方法的流程示意图。如图1所示，本实施例的方法，包括：

S10：获取监控终端所请求的媒体流，媒体流中的应用请求报文具有至少一个标志信息。

应理解，媒体流或称为流量。不同的应用请求报文中具有不同类型的标志信息，详情见下述S2011~S2012，此处不再赘述。

S20：根据标志信息和预设的路由规则，确定应用请求报文匹配的服务器群组，不同的服务器群组用于处理不同业务类型、不同业务获取源和/或不同区域的应用请求报文。

本申请实施例提供的路由调度方法，应用于路由调度系统。在路由调度系统中，一个服务器群组作为一个单元，不同服务器群组作为不同的单元。因此，本申请实施例在单元化架构下，可以实现对服务器群组之间的单元切换，从而实现应用高可用性架构。

本申请实施例可以支持更细粒度的路由调度，例如，可以支持某个应用请求报文按照不同业务类型（即不同功能）、不同业务获取源和/或不同区域进行区分路由，因此本申请实施例中的不同的服务器群组能够支持按照细颗粒度进行单元化的路由调度。

S30：将应用请求报文输入预先训练好的双向深度学习模型，输出服务器群组中与应用请求报文相匹配的目标服务器，并将应用请求报文分配给目标服务器，以供目标服务器对应用请求报文进行处理。

综上，本申请实施例基于不同的服务器群组用于处理不同业务类型、不同业务获取源和/或不同区域的应用请求报文的特点，与双向深度学习模型进行有效结合，能够快速实现对目标服务器的调度，在提高路由调度效率的同时，实现更细颗粒度的负载均衡。

一种可能的实现方式中，在目标服务器对应用请求报文进行处理的过程中，若监测到目标服务器的运行状态信息从非故障状态切换到故障状态，则将应用请求报文传输至备选服务器，以供目标服务器对应用请求报文进行重新处理。

上述备选服务器可以是本服务器群组中业务量最小的节点，也可以是处理速度最快的节点，本申请实施例对备选服务器的获取方式，以及其属性信息不做具体限定。

本申请实施例还可以将针对应用请求报文，目标服务器处理完成的部分内容和未处理的部分内容都发送至备选服务器，以提高处理效率。

本申请实施例在处理过程中，实时确定目标服务器的运行状态信息，能够保证应用请求报文的有效处理。

一种可能的实现方式中，在将应用请求报文分配给目标服务器之后，该方法还包括：

响应于远程控制指令，将应用请求报文从目标服务器传输至另一服务器。

本申请实施例对远程控制指令的接收方式并不做具体限定，用户可以通过手势、滑动操作、点击按钮等进行远程控制的实现。在路由调度结果不太符合用户满意的情况下，用户可以通过远程控制的方式控制路径上的节点选择。

本申请实施例可以添加远程控制功能，进而为用户提供选择的多样性，以满足不同用户的个性化需求。

一种可能的实现方式中，在应用请求报文的业务类型为多个时，服务器群组为多个，每个服务器群组均对应一个目标服务器，该路由调度方法还包括：

S40：按照应用请求报文的业务类型的优先级，确定服务器群组的路由顺序。

示例性的，本申请实施例中的应用请求报文的业务类型包括AAA类型、和CCC类型，由于优先级从高到低的顺序为AAA类型、BBB类型、CCC类型和DDD类型，并且与该优先级对应的服务器群组的路由顺序为服务器群组1、服务器群组2、服务器群组3和服务器群组4。

因此，应用请求报文的业务类型的优先级为AAA类型、和CCC类型，并且服务器群组的路由顺序为服务器群组1、服务器群组3。

S50：将服务器群组的路由顺序确定为目标服务器的路由顺序。

在服务器群组的路由顺序为服务器群组1、服务器群组3的基础上，目标服务器的路由顺序为服务器群组1中的目标服务器、服务器群组3中的目标服务器。

S60：按照目标服务器的路由顺序，依次将应用请求报文分配给各目标服务器。

在应用请求报文的业务类型为多个，依次将该应用请求报文分配给服务器群组1中的目标服务器、服务器群组3中的目标服务器。

此外，本申请实施例针对不同用户，可以设置不同的优先级顺序。

通过执行S40~S60，能够实现优先级的设定，进而可以满足不同用户的个性化需求，提高用户体验。

在上述实施例的基础上，下面结合几个具体的实施例对本申请技术方案进行更详细的描述。

实施例2：

图2为本申请实施例提供的预先训练好的双向深度学习模型的结构示意图。在图1所示实施例的基础上，本实施例重点对图1中的S30进行细化。如图2所示，预先训练好的双向深度学习模型包括第一模块、第二模块和第三模块，本申请实施例对第一模块、第二模块和第三模块所采用的网络的结构、参数等并不做具体限定。

基于该预先训练好的双向深度学习模型的结构，步骤S30：将应用请求报文输入预先训练好的双向深度学习模型，输出服务器群组中与应用请求报文相匹配的目标服务器，包括：

S301：将应用请求报文输入预先训练好的双向深度学习模型的第一模块，以供第一模块对应用请求报文进行深度特征提取，得到深度特征信息。

深度特征信息是不直观的信息，需要通过深度特征提取的方式，实现深度特征信息的准确提取，为快速确定目标服务器提供数据支撑。

S302：将服务器群组中所有的服务器的运行状态信息输入预先训练好的双向深度学习模型的第二模块，以供第二模块输出由可用服务器构成的可用服务器集合。其中，可用服务器是运行状态信息为非故障状态的服务器。

本申请实施例在将双向深度学习模型进行应用之前，可以对该模型进行预先训练，本申请实施例对训练流程以及训练数据的获取，均不做具体限定。

S303：将深度特征信息和可用服务器的属性信息输入至预先训练好的双向深度学习模型的第三模块，以供第三模块输出目标服务器。

可用服务器的属性信息包括但不限于：可用服务器所在的地区信息、处理速度、可用内存等。本申请实施例输出的目标服务器，是针对应用请求报文进行的路由调度，可以实现路由调度的准确性。

综上，本申请实施例根据第一模块能够快速提取到深度特征信息，根据第二模块快速输出由可用服务器构成的可用服务器集合，进而根据第三模块能够快速实现对目标服务器的确定以及输出，提高路由调度的效率。

实施例3：

图3为本申请实施例提供的图1中S20的流程示意图。在图1所示实施例的基础上，本实施例重点对图1中的S20进行细化。如图3所示，步骤S20：根据标志信息和预设的路由规则，确定应用请求报文匹配的服务器群组，包括：

S201：将应用请求报文与预设模板表中的应用请求报文类型模型进行匹配，基于匹配到的应用请求报文类型模板对应用请求报文中的各字段数据进行解析，得到标志信息。

在本申请实施例中，不同应用请求报文类型模板的应用请求报文，其标志信息不同，具体描述见下述S2011~S2012，此处不再赘述。

S202：从预设路由表中获取与匹配到的应用请求报文类型模板对应的路由规则，并将对应的路由规则作为预设的路由规则。

在本申请实施例中，不同的应用请求报文类型模板，对应不同的路由规则，本申请实施例对应用请求报文类型模板的数量以及具体内容均不做具体限定。

S203：对标志信息进行组合处理，得到组合结果。

本申请实施例中的组合处理方式可以包括但不限于：与、或、非，以及由与、或、非构成的组合。

S204：在预设的路由规则包含已有服务器群组的至少一个条件，且组合结果满足所有条件时，将已有服务器群组确定为应用请求报文匹配的服务器群组。

本实施例通过引入软负载均衡SLB，针对应用请求报文进行解析，获取到报文中特定的字段，并将该特定的字段作为标志信息，进行多条件组合，实现深度路由调度能力，支持实现精细化的路由调度和单元化切换。

一种可能的实现方式中，基于匹配到的应用请求报文类型模板对应用请求报文中的各字段数据进行解析，得到标志信息，包括：

S2011：当匹配到的应用请求报文类型模板为HTTP请求模板时，基于HTTP请求模板对应用请求报文中的各字段数据进行解析，得到第一标志信息。其中，第一标志信息包括以下至少之一：域名、Cookies、HTTP请求头、URL参数、Host字段、上下文根。

本实施例通过引入软负载均衡SLB，针对应用请求报文进行解析，获取到报文中特定的字段，例如：域名、Cookies、HTTP请求头、URL参数、Host字段、上下文根等，并且进行与、或、非等多条件组合，实现深度路由调度能力，支持实现精细化的路由调度和单元化切换。

S2012：当匹配到的应用请求报文类型模板为TCP请求模板时，基于TCP请求模板对应用请求报文中的各字段数据进行解析，得到第二标志信息。

本实施例通过引入软负载均衡SLB和双向深度学习模型，针对应用请求报文进行解析，获取到报文中特定的字段，例如：多个标志位信息等，并且进行与、或、非等多条件组合，实现深度路由调度能力，支持实现精细化的路由调度和单元化切换。

示例1，针对HTTP请求场景：

（1）本实施例中监控终端中的某应用将用于深度路由的标志位写入到HTTP请求头（Cookies、HTTP Header、URL参数、Host字段、域名、上下文根）或者HTTP请求体（通过xml或者json报文中的特定字段），生成应用请求报文。

（2）软负载集群读取该标志信息，然后结合预设的路由规则，并且根据该路由规则将该应用请求报文转发到对应的服务器群组（即单元化后的分区），实现深度路由。其中，预设的路由规则可以是深度路由规则，可以是多种条件进行的组合，比如|：域名、上下文根和Cookies等，通过与、或、非正则表达式进行组合。

示例2，针对TCP请求场景：

（1）本实施例中监控终端中的某应用将用于深度路由的标志位写入到TCP交易报文（即上述应用请求报文）中的特定报文字段（例如：第1-10位报文）。

（2）软负载集群读取该标志信息，然后结合预设的路由规则，并且根据该路由规则将应用请求报文转发到对应的服务器群组（即单元化后的分区），实现深度路由。其中，预设的路由规则可以是深度路由规则，可以是多种条件进行的组合，比如TCP数据包中的标志1、标志2、标志3等，通过与、或、非正则表达式进行组合。

本申请实施例通过软负载集群，实现了一种基于应用请求报文的深度路由调度方法，针对应用请求报文中的多种字段进行自定义组合，实现精细深度路由能力，实现了单元化架构下多个单元之间精细化路由调度的问题，以及可以按业务场景的细颗粒度进行单元切换，满足应用控制故障风险的需求。

实施例4：

图4为本申请实施例提供的一种路由调度系统的结构示意图。本实施例的路由调度系统可以为软件和/或硬件的形式。如图4所示，本实施例提供的路由调度系统，包括：包括依次连接的监控设备41、软负载集群42和至少两个服务器群组43，其中：

监控设备41，用于获取监控终端所请求的媒体流，媒体流中的应用请求报文具有至少一个标志信息。

软负载集群42，用于根据标志信息和预设的路由规则，确定应用请求报文匹配的服务器群组。其中，不同的服务器群组用于处理不同业务类型的应用请求报文。

软负载集群42，还用于将应用请求报文输入预先训练好的双向深度学习模型，输出服务器群组中与应用请求报文相匹配的目标服务器，并将应用请求报文分配给目标服务器。

目标服务器43，用于处理应用请求报文。

如图4所示，监控终端为Client。示例性的，应用请求报文为www.aaa.com.cn。当解析出的应用请求报文的标志信息为视频Video时，软负载集群42将该应用请求报文分配为视频服务器群组Video cluster；当解析出的应用请求报文的标志信息为图像Image时，软负载集群42将该应用请求报文分配为图像服务器群组Image cluster；当解析出的应用请求报文的标志信息为文本Text时，软负载集群42将该应用请求报文分配为文本服务器群组Text cluster。

如图4所示，VIP表示在应用请求报文的业务类型为多个时，服务器群组为多个，每个服务器群组均对应一个目标服务器，软负载集群42还用于：

按照应用请求报文的业务类型的优先级，确定服务器群组的路由顺序。

将服务器群组的路由顺序确定为目标服务器的路由顺序。

按照目标服务器的路由顺序，依次将应用请求报文分配给各目标服务器。

如图5所示，该例子是http请求的应用场景，基于域名、URL参数、Cookie和Param进行的深度路由。应用请求报文为www.aaacom.cn，其可以包含四个业务类型：AAA、BBB、CCC和DDD。其中，服务器群组1用于处理URL参数为AAA的AAA业务，服务器群组2用于处理URL参数为BBB且Cookie为B的BBB业务，服务器群组3用于处理URL参数为CCC的CCC业务，服务器群组4用于处理URL参数为DDD且参数Param为D的DDD业务。

可选地，某一个服务器群组可以至少处理一种类型的业务，即某一个服务器群组可以处理多个类型的业务，并且不同服务器群组能够处理的业务类型的数量可以不同。本申请实施例可以根据服务器的属性信息，进行实际的配置，本申请实施例对此不做作具体限定。

本申请实施例中的负载均衡，是根据请求的信息不同，来决定如何转发流量。负载均衡分为两级部署，即软负载集群42包括四层软负载集群和七层软负载集群。其中，四层软负载集群可以是提供四层负载均衡能力的LVS集群，七层软负载集群可以是提供七层负载均衡能力的nginx集群。本申请实施例将nginx部署在物理机或者虚拟机内。针对公有云场景，每个客户端可能拥有自己的一个或多个负载均衡实例，作为服务提供商的云厂商为每个实例启动一个nginx服务，用户进行配置的监听以及后端配置，都配置在各自的nginx服务上。

四层软负载集群，用于实现四层软负载均衡。四层软负载均衡是根据请求的IP地址和端口，根据设定的规则，将应用请求报文转发到后端对应的IP地址和端口上。七层软负载集群，用于实现七层软负载均衡。七层负载均衡，则是在四层的基础上，再去考虑应用层的特征。例如：一个WEB服务器的负载均衡，除了根据IP地址和80端口来判断之外，还可以根据七层的HTTP协议、URL，Cookie、浏览器类别等来决定如何转发流量。

综上，本申请实施例通过引入软负载均衡和双向深度学习模型的方式，实现对应用请求报文的解析，进而根据该应用请求报文中的字段进行深度路由，可以满足单元化框架下的路由调度需求。

一种可能的实现方式中，路由调度系统还包括：第一故障检测设备、第二故障检测设备和第三故障检测设备。

第一故障检测设备，用于检测监控设备的运行状态。

第二故障检测设备，用于检测软负载集群的运行状态。

第三故障检测设备，用于检测服务器群组中的服务器的运行状态。

本实施例提供的路由调度系统，可用于执行上述任意方法实施例提供的路由调度系统，其实现原理和技术效果类似，此处不做赘述。

需要说明的是，本申请所涉及的用户信息和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

也就是说，本申请的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现上述实施例中方法中的各个步骤。

本申请实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述实施例中方法中的各个步骤。

本申请以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、芯片上系统的系统（SOC）、负载可编程逻辑设备（CPLD）、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本申请的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或电子设备上执行。

在本申请的上下文中，计算机可读存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。计算机可读存储介质可以是机器可读信号介质或机器可读储存介质。计算机可读存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。计算机可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROM或快闪存储器）、光纤、便捷式紧凑盘只读存储器（CD-ROM）、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置（例如，CRT（阴极射线管）或者LCD（液晶显示器）监视器）；以及键盘和指向装置（例如，鼠标或者轨迹球），用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈（例如，视觉反馈、听觉反馈、或者触觉反馈）；并且可以用任何形式（包括声输入、语音输入或者、触觉输入）来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统（例如，作为数据电子设备）、或者包括中间件部件的计算系统（例如，应用电子设备）、或者包括前端部件的计算系统（例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互）、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信（例如，通信网络）来将系统的部件相互连接。通信网络的示例包括：局域网（LAN）、广域网（WAN）和互联网。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本申请公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims (10)

1.一种路由调度方法，其特征在于，包括：

获取监控终端所请求的媒体流，所述媒体流中的应用请求报文具有至少一个标志信息；

根据所述标志信息和预设的路由规则，确定所述应用请求报文匹配的服务器群组；其中，不同的服务器群组用于处理不同业务类型、不同业务获取源和/或不同区域的应用请求报文；

将所述应用请求报文输入预先训练好的双向深度学习模型，输出所述服务器群组中与所述应用请求报文相匹配的目标服务器，并将所述应用请求报文分配给所述目标服务器，以供所述目标服务器对所述应用请求报文进行处理。

2.根据权利要求1所述的方法，其特征在于，将所述应用请求报文输入预先训练好的双向深度学习模型，输出所述服务器群组中与所述应用请求报文相匹配的目标服务器，包括：

将所述应用请求报文输入预先训练好的双向深度学习模型的第一模块，以供所述第一模块对所述应用请求报文进行深度特征提取，得到深度特征信息；

将所述服务器群组中所有的服务器的运行状态信息输入预先训练好的双向深度学习模型的第二模块，以供所述第二模块输出由可用服务器构成的可用服务器集合；其中，所述可用服务器是所述运行状态信息为非故障状态的服务器；

将所述深度特征信息和所述可用服务器的属性信息输入至预先训练好的双向深度学习模型的第三模块，以供所述第三模块输出目标服务器。

3.根据权利要求2所述的方法，其特征在于，还包括：

在所述目标服务器对所述应用请求报文进行处理的过程中，若监测到所述目标服务器的运行状态信息从非故障状态切换到故障状态，则将所述应用请求报文传输至备选服务器，以供所述目标服务器对所述应用请求报文进行重新处理。

4.根据权利要求1所述的方法，其特征在于，所述根据所述标志信息和预设的路由规则，确定所述应用请求报文匹配的服务器群组，包括：

将所述应用请求报文与预设模板表中的应用请求报文类型模型进行匹配，基于匹配到的应用请求报文类型模板对所述应用请求报文中的各字段数据进行解析，得到标志信息；

从预设路由表中获取与所述匹配到的应用请求报文类型模板对应的路由规则，并将所述对应的路由规则作为预设的路由规则；

对所述标志信息进行组合处理，得到组合结果；

在所述预设的路由规则包含已有服务器群组的至少一个条件，且所述组合结果满足所有所述条件时，将所述已有服务器群组确定为所述应用请求报文匹配的服务器群组。

5.根据权利要求4所述的方法，其特征在于，所述基于匹配到的应用请求报文类型模板对所述应用请求报文中的各字段数据进行解析，得到标志信息，包括：

当所述匹配到的应用请求报文类型模板为HTTP请求模板时，基于所述HTTP请求模板对所述应用请求报文中的各字段数据进行解析，得到第一标志信息；其中，所述第一标志信息包括以下至少之一：域名、Cookies、HTTP请求头、URL参数、Host字段、上下文根；

当所述匹配到的应用请求报文类型模板为TCP请求模板时，基于所述TCP请求模板对所述应用请求报文中的各字段数据进行解析，得到第二标志信息。

6.根据权利要求1所述的方法，其特征在于，在将所述应用请求报文分配给所述目标服务器之后，还包括：

响应于远程控制指令，将所述应用请求报文从所述目标服务器传输至另一服务器。

7.根据权利要求1所述的方法，其特征在于，在所述应用请求报文的业务类型为多个时，所述服务器群组为多个，每个所述服务器群组均对应一个所述目标服务器，还包括：

按照所述应用请求报文的业务类型的优先级，确定所述服务器群组的路由顺序；

将所述服务器群组的路由顺序确定为所述目标服务器的路由顺序；

按照所述目标服务器的路由顺序，依次将所述应用请求报文分配给各所述目标服务器。

8.一种路由调度系统，其特征在于，包括依次连接的监控设备、软负载集群和至少两个服务器群组，其中：

所述监控设备，用于获取监控终端所请求的媒体流，所述媒体流中的应用请求报文具有至少一个标志信息；

所述软负载集群，用于根据所述标志信息和预设的路由规则，确定所述应用请求报文匹配的服务器群组；其中，不同的服务器群组用于处理不同业务类型的应用请求报文；

所述软负载集群，还用于将所述应用请求报文输入预先训练好的双向深度学习模型，输出所述服务器群组中与所述应用请求报文相匹配的目标服务器，并将所述应用请求报文分配给所述目标服务器；

所述目标服务器，用于处理所述应用请求报文。

9.根据权利要求8所述的系统，其特征在于，还包括：第一故障检测设备、第二故障检测设备和第三故障检测设备；

所述第一故障检测设备，用于检测所述监控设备的运行状态；

所述第二故障检测设备，用于检测所述软负载集群的运行状态；

所述第三故障检测设备，用于检测所述服务器群组中的服务器的运行状态。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至7任一项所述的路由调度方法。

Images