CN113590333A - 针对业务引擎的系统资源调度方法及电子设备 - Google Patents

Abstract

本申请公开了一种针对业务引擎的系统资源调度方法及电子设备，该方法包括：获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，其中，所述系统资源的分配信息包括对多个业务引擎分配系统资源的信息，所述系统资源包括与所述业务引擎相绑定的CPU和/或CPU核心；基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，其中包括，对具有不同类型的所述业务引擎，按照类型重新分配所述系统资源。该方法能够根据当前的业务引擎的状态和系统资源的分配，动态的对系统资源的分配进行调控，防止业务引擎由于运行故障或系统资源分配不及时而出现错误导致业务引擎的失效，提高了电子设备的运行效率和稳定性。

Description

针对业务引擎的系统资源调度方法及电子设备

技术领域

本申请涉及网络通信和网络安全领域，特别涉及一种针对业务引擎的系统资源调度方法及电子设备。

背景技术

随着网络技术的快速发展，用于处理网络流量的业务引擎被大量应用。特别用于提高网络安全的安全业务引擎也被大量应用。例如，针对复杂的互联网环境，为实现安全访问和攻击防护，防火墙等安全设备中会设计多个安全业务引擎，如加密安全访问引擎、应用代理引擎、Web安全防护引擎、DDOS防护引擎、深度安全检测引擎、漏洞扫描引擎等。

但是在实际使用过程中，服务器、交换机等与网络相关的电子设备通常会开启所有业务引擎，为所有的业务引擎固定分配好系统资源，而并不对其进行调整。这将使得系统资源调度方法僵化，使得网络设备运行效率低下，安全性降低。

发明内容

本申请实施例的目的在于提供一种针对业务引擎的系统资源调度方法及电子设备，该方法能够基于业务引擎的当前状态以及系统资源的分配情况，及时的对分配给业务引擎的系统资源进行动态调整，防止出现错误，提高设备的运行效率和稳定性。

为了解决上述技术问题，本发明的实施例采用了如下技术方案：一种针对业务引擎的系统资源调度方法，包括：

获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，其中，所述系统资源的分配信息包括对多个业务引擎分配系统资源的信息，所述系统资源包括与所述业务引擎相绑定的CPU和/或CPU核心；

基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，其中包括，对具有不同类型的所述业务引擎，按照类型重新分配所述系统资源。

作为可选，所述获取网络流量中多个业务引擎的运行状态，包括：

获取所述业务引擎发送的心跳消息；

基于所述心跳消息，以及与所述心跳消息相对应的响应周期，确定所述业务引擎的运行状态。

作为可选，所述方法还包括：在所述业务引擎的运行状态发生变化，和/或与所述业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，启动对所述调度策略进行动态控制的操作。

作为可选，所述方法还包括：

获取所述业务引擎的本地调度信息，以及对应了所有所述业务引擎的全局调度信息；

将所述本地调度信息与所述全局调度信息进行对比；

在对比结果不符合第一条件的情况下，确定所述业务引擎的运行状态发生变化。

作为可选，所述方法还包括：

在对比结果不符合第一条件的情况下，基于所述全局调度信息中的全局调度表对所述本地调度信息进行更新。

作为可选，所述获取网络流量中多个业务引擎的运行状态，还包括：

获取所述业务引擎的流量处理信息；

将所述流量处理信息与预设流量阈值进行比较；

基于比较结果确定所述业务引擎的运行状态。

作为可选，所述基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，包括：

确定所述业务引擎的类型；

基于每个类型的所述业务引擎所对应的分配信息，对各个类型的所述业务引擎相绑定的CPU和/或CPU核心的数量进行调整。

本申请实施例还提供了一种电子设备，包括：

管理控制单元，其配置为获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，其中，所述系统资源的分配信息包括对多个业务引擎分配系统资源的信息，所述系统资源包括与所述业务引擎相绑定的CPU和/或CPU核心；

流量调度单元，其配置为基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，其中包括，对具有不同类型的所述业务引擎，按照类型重新分配所述系统资源。

作为可选，该电子设备还包括流量处理单元，所述流量处理单元配置为：获取所述业务引擎发送的心跳消息；

相应的，所述管理控制单元进一步配置为：基于所述心跳消息，以及与所述心跳消息相对应的响应周期，确定所述业务引擎的运行状态。

作为可选，所述流量调度单元进一步配置为：

在所述业务引擎的运行状态发生变化，和/或与所述业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，启动对分配给所述业务引擎的系统资源的动态控制。

该系统资源调度方法能够根据当前的业务引擎的状态和系统资源的分配，动态而及时的对系统资源的分配进行调控，防止业务引擎由于运行故障或系统资源分配不及时而出现错误导致业务引擎的失效，提高了电子设备的运行效率和稳定性。

附图说明

图1为本申请实施例的针对业务引擎的系统资源调度方法的流程图；

图2为本申请实施例的图1中步骤S10的一个实施例的流程图；

图3为本申请实施例的系统资源调度方法的一个具体实施例的流程图；

图4为本申请实施例的图1中步骤S10的另一个实施例的流程图；

图5为本申请实施例的图1中步骤S20的一个实施例的流程图；

图6为本申请实施例的电子设备的结构框图；

图7为本申请实施例的流量处理单元和管理控制单元的结构关系示意图；

图8为本申请实施例的流量调度单元和管理控制单元的交互示意图；

图9为本申请实施例的流量处理单元分别与管理控制单元和流量统计单元之间的一个实施例的交互示意图；

图10为本申请实施例的管理控制单元分别与流量处理单元和流量统计单元之间的另一个实施例的交互示意图。

具体实施方式

此处参考附图描述本申请的各种方案以及特征。

应理解的是，可以对此处申请的实施例做出各种修改。因此，上述说明书不应该视为限制，而仅是作为实施例的范例。本领域的技术人员将想到在本申请的范围和精神内的其他修改。

包含在说明书中并构成说明书的一部分的附图示出了本申请的实施例，并且与上面给出的对本申请的大致描述以及下面给出的对实施例的详细描述一起用于解释本申请的原理。

通过下面参照附图对给定为非限制性实例的实施例的优选形式的描述，本申请的这些和其它特性将会变得显而易见。

还应当理解，尽管已经参照一些具体实例对本申请进行了描述，但本领域技术人员能够确定地实现本申请的很多其它等效形式。

当结合附图时，鉴于以下详细说明，本申请的上述和其他方面、特征和优势将变得更为显而易见。

此后参照附图描述本申请的具体实施例；然而，应当理解，所申请的实施例仅仅是本申请的实例，其可采用多种方式实施。熟知和/或重复的功能和结构并未详细描述以避免不必要或多余的细节使得本申请模糊不清。因此，本文所申请的具体的结构性和功能性细节并非意在限定，而是仅仅作为权利要求的基础和代表性基础用于教导本领域技术人员以实质上任意合适的详细结构多样地使用本申请。

本说明书可使用词组“在一种实施例中”、“在另一个实施例中”、“在又一实施例中”或“在其他实施例中”，其均可指代根据本申请的相同或不同实施例中的一个或多个。

本申请实施例的一种针对业务引擎的系统资源调度方法，该方法能够应用在电子设备上，该方法能够基于业务引擎的当前状态以及系统资源的分配情况，及时的对分配给业务引擎的系统资源进行动态调整。该方法包括获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息。基于运行状态以及分配信息，对分配给业务引擎的系统资源进行动态控制。具体的，业务引擎可以安装在电子设备中也可以安装在其他网络设备上，能够对网络流量进行与之功能相适配的处理，如对网络流量进行安全处理。业务引擎的运行状态包括业务引擎的正常工作状态，闲置状态，僵死状态等。而系统资源的分配信息包括给予每个业务引擎分配的系统资源，包括为每个业务引擎分配的CPU和/或CPU核心的数量等。基于上述的运行状态和分配信息，能够及时对每个业务引擎分配的CPU和/或CPU核心的数量进行调整。例如对于忙碌的业务引擎为其分配数量较多的CPU核心。而对于空闲的业务引擎，控制原本与其绑定的CPU核心为其他忙碌的业务引擎服务。从而根据当前的实际情况，及时的对分配给业务引擎的系统资源进行动态调整，防止出现错误，提高设备的运行效率和稳定性。

下面，结合附图对本实施例的系统资源调度方法进行更加详细的说明。如图1所示，本申请实施例的系统资源调度方法，可以应用在电子设备上，该方法包括以下步骤：

S10，获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，其中，所述系统资源的分配信息包括对多个业务引擎分配系统资源的信息，所述系统资源包括与所述业务引擎相绑定的CPU和/或CPU核心。

网络流量中具有多个业务引擎，不同的业务引擎其类型可能不同，而同一类型的业务引擎的数量也不做限定。该业务引擎可以根据其类型对网络中的数据进行相应的处理，如对安全引擎对网络数据进行安全过滤。

在与网络的相关电子设备中，需要将电子设备的系统资源分配给各个业务引擎，以使其进行工作。本实施例中，每个业务引擎均绑定有相应的CPU和/或CPU核心。例如对于具有多核心的单一CPU(或者是多CPU的电子设备)，其中的每个CPU核心均可以绑定业务引擎。CPU核心仅为与其进行绑定的业务引擎工作，这样以来可以对业务引擎以及为其分配的CPU核心进行独立的调整，而不会影响其他的CPU核心以及相对应的业务引擎，便于对系统资源进行调度。

本实施例中的系统资源的分配信息，包括对多个业务引擎分配系统资源的信息。业务引擎的类型和每个类型的数量可能不同，该分配信息包括对每个业务引擎的系统资源的分配情况，如对每个业务引擎分配的CPU的数量和/或CPU核心的数量的信息。电子设备获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，能够更清楚的掌握业务引擎以及系统资源的当前状态，便于进行调度。

S20，基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，其中包括，对具有不同类型的所述业务引擎，按照类型重新分配所述系统资源。

具体来说，对分配给业务引擎的系统资源进行动态控制，可以是将分配给各个业务引擎的CPU的数量和/或CPU核心的数量进行动态控制，也可以是将电子设备中分配给各个业务引擎的其他部件的种类和/或数量进行控制。

本实施例中，对分配给业务引擎的系统资源进行动态控制，包括对具有不同类型的业务引擎，按照类型重新分配系统资源。具体的，业务引擎可以是不同的类型，每个类型可以包括一个或多个数量的业务引擎，在控制系统资源的分配时，可以按照该业务引擎的类型重新对每个类型的业务引擎充分分配系统资源，如重新分配业务引擎所使用的CPU核心的数量。

业务引擎的运行状态包括业务引擎的正常工作状态，闲置状态，忙碌状态，僵死状态等。而系统资源的分配信息包括给予每个业务引擎分配的系统资源，如包括为每个业务引擎分配的CPU和/或CPU核心的数量等资源。业务引擎的运行状态以及系统资源的分配信息能够表征业务引擎在处理网络流量时，自身以及电子设备的具体运行状态。基于运行状态以及分配信息，对分配给业务引擎的系统资源进行动态控制，从而能够在业务引擎处理具体网络流量的过程中即使发生波动也能够及时调整对业务引擎的分配。特别是对安全业务引擎分配的CPU核心的数量的动态调整，保证了安全业务引擎的运行稳定，保证了网络安全。

该方法能够根据当前的业务引擎的状态和系统资源的分配，动态而及时的对系统资源的分配进行调控，防止业务引擎由于运行故障或系统资源分配不及时而出现错误导致业务引擎的失效，提高了电子设备的运行效率和稳定性。

在本申请的一个实施例中，所述获取网络流量中多个业务引擎的运行状态，如图2所示，包括：

S110，获取所述业务引擎发送的心跳消息。

心跳消息也为业务引擎根据电子设备发出的响应请求而进行反馈的响应消息。电子设备可以按照预设时间间隔向各个业务引擎发送响应请求以请求业务引擎进行响应，如果业务引擎为正常工作状态，接收到该响应请求后会在预设的响应周期内发送心跳消息给电子设备，以报告自身状态。

例如，业务引擎的正常状态下，在接收到响应请求的数秒内便发送心跳消息给电子设备。但是如果业务引擎在僵化状态时，其并不能在规定的响应周期内将心跳信息发送给电子设备。

S120，基于所述心跳消息，以及与所述心跳消息相对应的响应周期，确定所述业务引擎的运行状态。

响应周期可以是根据实际使用情况来设置的，用于响应电子设备发出的响应请求的时间周期。当然该响应周期也能够根据实际情况来进行调整。

一方面，电子设备向业务引擎发出响应请求，并在响应周期内接收到业务引擎发送的心跳消息的情况下。则电子设备可以认为业务引擎处于正常的工作状态，有能力在响应周期内容发送该心跳消息。

另一方面，业务引擎发出的心跳消息中所包含的内容可以是关于运行状态的内容，电子设备在接收到该心跳消息后对心跳消息进行分析，便能够获知该业务引擎的运行状态。

在本申请的一个实施例中，所述方法还包括：在所述业务引擎的运行状态发生变化，和/或与所述业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，启动对所述调度策略进行动态控制的操作。

具体来说，业务引擎绑定有CPU和/或CPU核心，这使得被绑定的CPU和/或CPU核心只需要为相应的业务引擎工作，而无需为其他的没有绑定的业务引擎工作。

在一个实施例中，如果业务引擎的运行状态发生变化，则可以启动对对所述调度策略进行动态控制的操作。该调度策略可以包括对CPU和/或CPU核心的服务数量进行调整的策略。

举例说明，第一业务引擎由正常忙碌状态转换为空闲状态，而原本该第一业务引擎绑定了两个CPU核心为其进行工作，在空闲状态下无需该两个CPU核心继续为其工作，则可以对相应的调度策略进行调整，将该两个CUP核心转而为其他仍旧处于忙碌状态的第二业务引擎进行工作，处理第二业务引擎的相关数据。从而实现了系统资源的优化，提高了处理效率。

在另一个实施例中，与业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，也可以对调度策略进行调整。

举例说明，第一CPU核心为第一业务引擎工作，处理第一业务引擎的相关数据。第一CPU核心原本处于正常工作状态，但可能会由于处理数据量的激增而形成忙碌或死机状态，即运行状态发生了变化。本实施中可以根据该运行状态的变化对调度策略进行调整。如将调度第二CPU核心与该第一业务引擎进行绑定。从而分担了第一CPU核心的工作，防止第一CPU核心崩溃，进而造成数据处理失败。

在本申请的一个实施例中，如图3所示，所述方法还包括以下步骤：

S30，获取所述业务引擎的本地调度信息，以及对应了所有所述业务引擎的全局调度信息。

本地调度信息为业务引擎自身的信息，不同的业务引擎具有各自的本地调度信息，该本地调度信息可以存储在业务引擎中，其内容包括对应的业务引擎的调度信息。在一个实施例中，该本地调度信息可以以本地调度表的形式出现，以方便使用。

全局调度信息包括了所有的业务引擎的调度信息，该全局调度信息可以存储在电子设备中。各个业务引擎可以调用该全局调度信息。在一个实施例中，该全局调度信息可以以全局调度表的形式出现，以方便使用。

S40，将所述本地调度信息与所述全局调度信息进行对比。

具体来说，全局调度信息中包含了本地调度信息的相关内容，在业务引擎的运行状态没有发生变化时，业务引擎的本地调度信息中的内容，与全局调度信息中记录的与之相关的内容是相同或相似的，这可以将本地调度信息与全局调度信息进行对比后判断出来。此时可以认为对比结果符合第一条件。

S50，在对比结果不符合第一条件的情况下，确定所述业务引擎的运行状态发生变化。

对比结果不符合第一条件，则表明本地调度信息与全局调度信息中记录的与之相关的信息并不相同或不相似，例如由于CPU核心的僵死导致了本地调度表中的内容发生了变化，从而引起上述“不相同或不相似”的情况。本实施例中在判断对比结果不符合第一条件的情况下，确定业务引擎的运行状态发生变化。

在本申请的一个实施例中，所述方法还包括以下步骤：在对比结果不符合第一条件的情况下，基于所述全局调度信息中的全局调度表对所述本地调度信息进行更新。

具体的，全局调度信息中记录了本地调度信息的相关内容，对比结果不符合第一条件，表明原本的本地调度信息并不适合使用，不能满足当前业务引擎的需要，如用于调度系统资源的原本地调度表不合适再使用，此时需要将全局调度表中与该业务引擎相关的内容拷贝到本地调度表中，以更新该本地调度表。从而电子设备可以根据更新后的该本地调度表来为相应的业务引擎分配系统资源。

在本申请的一个实施例中，所述获取网络流量中多个业务引擎的运行状态，如图4所示，还包括：

S130，获取所述业务引擎的流量处理信息。

S140，将所述流量处理信息与预设流量阈值进行比较。

S150，基于比较结果确定所述业务引擎的运行状态。

具体来说，业务引擎可以对流量进行处理，如安全业务引擎对网络流量中的数据进行安全处理，当然其他类型的业务引擎也需要对网络流量进行与其功能相关的处理。业务引擎对流量进行处理后，电子设备可以获取相关的流量处理信息，其中包括了业务引擎在处理流量过程中的相关信息。如包括了流量的规模，处理的具体内容等。而预设流量阈值则为预先设置，具体可以是流量规模的阈值，具体内容等与流量处理信息相关的设置。将流量处理信息与预设流量阈值进行比较，包括流量规模的比较，具体内容的比较等至少一个方面。例如，如果当前流量处理规模远远高于预设流量阈值中设置的预设流量规模的阈值，则可以确定业务引擎处于忙碌状态。如果当前流量处理规模远远低于预设流量阈值中设置的预设流量规模的阈值，则可以确定业务引擎处于空闲状态。

在本申请的一个实施例中，所述基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，如图5所示，包括：

S210，确定所述业务引擎的类型。

业务引擎具有不同类型，如可以是加密安全访问引擎、应用代理引擎、Web安全防护引擎、DDOS防护引擎、深度安全检测引擎、漏洞扫描引擎等类型。不同类型的业务引擎具有不同的作用。每个类型的业务引擎所分配的系统资源可能不同。例如为Web安全防护引擎分配的CPU核心的数量较多；而为加密安全访问引擎分配的CPU核心的数量较少。

S220，基于每个类型的所述业务引擎所对应的分配信息，对各个类型的所述业务引擎相绑定的CPU和/或CPU核心的数量进行调整。

具体的，在调整系统资源时，可以对每个类型的业务引擎分别进行调整，如为第一类型的业务引擎增加CPU和/或CPU核心的数量；为第二类型的业务引擎减少CPU和/或CPU核心的数量。本实施例中基于每个类型的业务引擎所对应的分配信息，来进行系统资源的调整。第一类型的业务引擎已经被分配了一个CPU核心为其处理数据，如果确定该第一类型的业务引擎处于忙碌状态时，可以增加为其处理数据的CPU核心数量。当然如果已经为第一类型的业务引擎分配了数量较多的CPU核心，即使该第一类型的业务引擎处于忙碌状态时，也可以不再为其增加更多的CPU核心，而是将有限的CPU核心应用到其他类型的业务引擎上。从而实现系统资源的灵活调度。

本申请实施例还提供了一种电子设备，如图6所示，包括：

管理控制单元，其配置为获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，其中，所述系统资源的分配信息包括对多个业务引擎分配系统资源的信息，所述系统资源包括与所述业务引擎相绑定的CPU和/或CPU核心。

具体的，网络流量中具有多个业务引擎，不同的业务引擎其类型可能不同，而同一类型的业务引擎的数量也不做限定。该业务引擎可以根据其类型对网络中的数据进行相应的处理，如对安全引擎对网络数据进行安全过滤。

在与网络的相关电子设备中，需要将电子设备的系统资源分配给各个业务引擎，以使其进行工作。本实施例中，每个业务引擎均绑定有相应的CPU和/或CPU核心。例如对于具有多核心的单一CPU(或者是多CPU的电子设备)，其中的每个CPU核心均可以绑定业务引擎。CPU核心仅为与其进行绑定的业务引擎工作，这样以来可以对业务引擎以及为其分配的CPU核心进行独立的调整，而不会影响其他的CPU核心以及相对应的业务引擎，便于对系统资源进行调度。

本实施例中的系统资源的分配信息，包括对多个业务引擎分配系统资源的信息。业务引擎的类型和每个类型的数量可能不同，该分配信息包括对每个业务引擎的系统资源的分配情况，如对每个业务引擎分配的CPU的数量和/或CPU核心的数量的信息。管理控制单元获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，能够更清楚的掌握业务引擎以及系统资源的当前状态，便于进行调度。

流量调度单元，其配置为基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，其中包括，对具有不同类型的所述业务引擎，按照类型重新分配所述系统资源。

具体来说，流量调度单元对分配给业务引擎的系统资源进行动态控制，可以是将分配给各个业务引擎的CPU的数量和/或CPU核心的数量进行动态控制，也可以是将电子设备中分配给各个业务引擎的其他部件的种类和/或数量进行控制。

本实施例中，流量调度单元对分配给业务引擎的系统资源进行动态控制，包括对具有不同类型的业务引擎，按照类型重新分配系统资源。具体的，业务引擎可以是不同的类型，每个类型可以包括一个或多个数量的业务引擎，在控制系统资源的分配时，流量调度单元可以按照该业务引擎的类型重新对每个类型的业务引擎充分分配系统资源，如重新分配业务引擎所使用的CPU核心的数量。

业务引擎的运行状态包括业务引擎的正常工作状态，闲置状态，忙碌状态，僵死状态等。而系统资源的分配信息包括给予每个业务引擎分配的系统资源，如包括为每个业务引擎分配的CPU和/或CPU核心的数量等资源。业务引擎的运行状态以及系统资源的分配信息能够表征业务引擎在处理网络流量时，自身以及电子设备的具体运行状态。流量调度单元基于运行状态以及分配信息，对分配给业务引擎的系统资源进行动态控制，从而能够在业务引擎处理具体网络流量的过程中即使发生波动也能够及时调整对业务引擎的分配。特别是对安全业务引擎分配的CPU核心的数量的动态调整，保证了安全业务引擎的运行稳定，保证了网络安全。

在本申请的一个实施例中，电子设备还包括流量处理单元，所述流量处理单元配置为：获取所述业务引擎发送的心跳消息；

相应的，所述管理控制单元进一步配置为：基于所述心跳消息，以及与所述心跳消息相对应的响应周期，确定所述业务引擎的运行状态。

具体来说，流量处理单元可以利用系统资源实现业务引擎的功能。心跳消息也为业务引擎根据电子设备发出的响应请求而进行反馈的响应消息。电子设备可以按照预设时间间隔向各个业务引擎发送响应请求以请求业务引擎进行响应，如果业务引擎为正常工作状态，流量处理单元接收到该响应请求后会在预设的响应周期内发送心跳消息给电子设备，以报告自身状态。

例如，业务引擎的正常状态下，流量处理单元在接收到响应请求的数秒内便发送心跳消息给电子设备。但是如果业务引擎在僵化状态时，流量处理单元并不能在规定的响应周期内将心跳信息发送给电子设备。

响应周期可以是根据实际使用情况来设置的，用于响应电子设备发出的响应请求的时间周期。当然该响应周期也能够根据实际情况来进行调整。

一方面，电子设备向业务引擎发出响应请求，并在响应周期内接收到业务引擎发送的心跳消息的情况下。则管理控制单元可以认为业务引擎处于正常的工作状态，有能力在响应周期内容发送该心跳消息。

另一方面，业务引擎发出的心跳消息中所包含的内容可以是关于运行状态的内容，管理控制单元在接收到该心跳消息后对心跳消息进行分析，便能够获知该业务引擎的运行状态。

在一个具体实施例中，结合图7，流量处理单元向管理控制单元注册，上报安全业务引擎的类型、该安全业务引擎所绑定的CPU核心ID、调度算法、初始化引擎状态信息等。管理控制单元整合所有注册的流量处理单元信息，维护全局共享内存调度映射表及全局调度信息(全局调度年龄)，同时检测每个流量处理单元的心跳消息，根据心跳消息的响应周期判断流量处理单元的运行状态(如正常、忙碌、僵死)并实时更新本地调度表。

在本申请的一个实施例中，所述流量调度单元进一步配置为：在所述业务引擎的运行状态发生变化，和/或与所述业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，启动对分配给所述业务引擎的系统资源的动态控制。

具体来说，业务引擎绑定有CPU和/或CPU核心，这使得被绑定的CPU和/或CPU核心只需要为相应的业务引擎工作，而无需为其他的没有绑定的业务引擎工作。

在一个实施例中，如果业务引擎的运行状态发生变化，则流量调度单元可以启动对对所述调度策略进行动态控制的操作。该调度策略可以包括对CPU和/或CPU核心的服务数量进行调整的策略。

举例说明，第一业务引擎由正常忙碌状态转换为空闲状态，而原本该第一业务引擎绑定了两个CPU核心为其进行工作，在空闲状态下无需该两个CPU核心继续为其工作，则可以对相应的调度策略进行调整，将该两个CUP核心转而为其他仍旧处于忙碌状态的第二业务引擎进行工作，处理第二业务引擎的相关数据。从而实现了系统资源的优化，提高了处理效率。

在另一个实施例中，与业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，流量调度单元也可以启动对调度策略进行调整。

举例说明，第一CPU核心为第一业务引擎工作，处理第一业务引擎的相关数据。第一CPU核心原本处于正常工作状态，但可能会由于处理数据量的激增而形成忙碌或死机状态，即运行状态发生了变化。本实施中流量调度单元可以根据该运行状态的变化对调度策略进行调整。如将调度第二CPU核心与该第一业务引擎进行绑定。从而分担了第一CPU核心的工作，防止第一CPU核心崩溃，进而造成数据处理失败。

在本申请的一个实施例中，管理控制单元进一步配置为：

获取所述业务引擎的本地调度信息，以及对应了所有所述业务引擎的全局调度信息；

将所述本地调度信息与所述全局调度信息进行对比；

在对比结果不符合第一条件的情况下，确定所述业务引擎的运行状态发生变化。

在本申请的一个实施例中，流量调度单元进一步配置为：

在对比结果不符合第一条件的情况下，基于所述全局调度信息中的全局调度表对所述本地调度信息进行更新。

在一个具体实施例中，结合图8，流量调度单元接收报文，首先匹配用户下发的调度策略，确定调度策略之后比较本地调度年龄与全局共享调度年龄，如果年龄不一致表示需要更新调度映射表，拷贝全局调度映射表到本地，并更新本地调度年龄。拷贝操作能够减少加锁带来的性能开销，流量处理单元僵死重启才会引起调度映射表的变化，所有拷贝带来的开销可以忽略不计。同步调度映射表之后会根据调度算法(源目的地址哈希、轮询)获取需要调度的CPU ID，然后检查对应CPU ID所对应的安全业务引擎运行状态，如果为正常状态就直接将流量调度到对应的流量处理单元。

在本申请的一个实施例中，电子设备还包括流量统计单元，其配置为：获取所述业务引擎的流量处理信息；将所述流量处理信息与预设流量阈值进行比较；以使管理控制单元基于比较结果确定所述业务引擎的运行状态。

在一个具体实施例中，结合图9，流量处理单元获取业务引擎(如安全业务引擎)的流量处理信息，并定期通过流量信息位图向流量统计单元上报流量信息、向管理控制单元发送心跳信息，心跳机制通过共享内存维护一心跳位图，管理控制单元每个运行周期对对应的位图的位计数，流量处理单元只读获取管理控制单元心跳数并对当前引擎对应的心跳位图进行更新，管理控制引擎获取每个安全业务引擎心跳数并与当前心跳数对比判定对应的安全业务引擎状态。N个心跳周期判定对应的安全业务引擎为正常状态；M个心跳周期判定对应的安全业务引擎为忙碌状态；P个心跳周期判定对应的安全业务引擎为僵死状态。当然用户可以配置心跳检测灵敏度。

在本申请的一个实施例中，流量调度单元进一步配置为：

确定所述业务引擎的类型；

基于每个类型的所述业务引擎所对应的分配信息，对各个类型的所述业务引擎相绑定的CPU和/或CPU核心的数量进行调整。

在一个具体实施例中，结合图10，流量统计单元收集所有安全业务引擎的流量处理信息，定期向管理控制单元上报流量信息，管理控制单元获取某一时间段各流量处理单元流量情况，与用户设定的流量阈值做比较判定对应的安全业务引擎为空闲或者忙碌状态。同时流量统计单元还会分析各个安全业务引擎具体流量类型，流量调度单元会根据一个动态调整周期内整体流量类型情况，合理调整各安全业务引擎的数量。如关闭部分较为空闲的安全业务引擎，为当前较为忙碌的安全业务引擎分配更多的CPU核心数量以实现流量调度动态调整。

以上实施例仅为本申请的示例性实施例，不用于限制本申请，本申请的保护范围由权利要求书限定。本领域技术人员可以在本申请的实质和保护范围内，对本申请做出各种修改或等同替换，这种修改或等同替换也应视为落在本申请的保护范围内。

Claims (10)

1.一种针对业务引擎的系统资源调度方法，其特征在于，包括：

获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，其中，所述系统资源的分配信息包括对多个业务引擎分配系统资源的信息，所述系统资源包括与所述业务引擎相绑定的CPU和/或CPU核心；

基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，其中包括，对具有不同类型的所述业务引擎，按照类型重新分配所述系统资源。

2.根据权利要求1所述的方法，其特征在于，所述获取网络流量中多个业务引擎的运行状态，包括：

获取所述业务引擎发送的心跳消息；

基于所述心跳消息，以及与所述心跳消息相对应的响应周期，确定所述业务引擎的运行状态。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：在所述业务引擎的运行状态发生变化，和/或与所述业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，启动对所述调度策略进行动态控制的操作。

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

获取所述业务引擎的本地调度信息，以及对应了所有所述业务引擎的全局调度信息；

将所述本地调度信息与所述全局调度信息进行对比；

在对比结果不符合第一条件的情况下，确定所述业务引擎的运行状态发生变化。

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

在对比结果不符合第一条件的情况下，基于所述全局调度信息中的全局调度表对所述本地调度信息进行更新。

6.根据权利要求1所述的方法，其特征在于，所述获取网络流量中多个业务引擎的运行状态，还包括：

获取所述业务引擎的流量处理信息；

将所述流量处理信息与预设流量阈值进行比较；

基于比较结果确定所述业务引擎的运行状态。

7.根据权利要求1所述的方法，其特征在于，所述基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，包括：

确定所述业务引擎的类型；

基于每个类型的所述业务引擎所对应的分配信息，对各个类型的所述业务引擎相绑定的CPU和/或CPU核心的数量进行调整。

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

管理控制单元，其配置为获取网络流量中多个业务引擎的运行状态，以及系统资源的分配信息，其中，所述系统资源的分配信息包括对多个业务引擎分配系统资源的信息，所述系统资源包括与所述业务引擎相绑定的CPU和/或CPU核心；

流量调度单元，其配置为基于所述运行状态以及所述分配信息，对分配给所述业务引擎的系统资源进行动态控制，其中包括，对具有不同类型的所述业务引擎，按照类型重新分配所述系统资源。

9.根据权利要求8所述的电子设备，其特征在于，还包括流量处理单元，所述流量处理单元配置为：获取所述业务引擎发送的心跳消息；

相应的，所述管理控制单元进一步配置为：基于所述心跳消息，以及与所述心跳消息相对应的响应周期，确定所述业务引擎的运行状态。

10.根据权利要求8所述的电子设备，其特征在于，所述流量调度单元进一步配置为：

在所述业务引擎的运行状态发生变化，和/或与所述业务引擎相绑定的CPU和/或CPU核心的运行状态发生变化的情况下，启动对分配给所述业务引擎的系统资源的动态控制。

Images