服务调度方法及边缘节点与流程

本发明实施例涉及通信技术领域，尤其涉及一种服务调度方法及边缘节点。

背景技术：

内容分发网络(Content Delivery Network，简称CDN)是一种通过在网络关键位置上部署节点服务器所构成的智能虚拟网络。CDN通过对网络流量、节点健康、节点负载、节点性能等信息的分析，动态部署内容在网络上的分发和调度。

在CDN中，根据节点的位置及功能的差异，CDN节点可分为：中心节点、区域节点和边缘节点等。在CDN功能的实现上，内容定位和调度是关键所在。在现有CDN中，边缘节点向用户提供服务，服务不可用时，调度方式一般通过向上层区域节点请求直接服务、下拉内容服务或者通过区域节点调度到其他边缘节点等，由于这种调度方式在服务不可用时，需要通过区域节点进行再调度，造成了调度效率低的问题。

技术实现要素：

本发明实施例提供一种服务调度方法及边缘节点，用以提升CDN网络的服务调度效率。

本发明实施例第一方面提供一种服务调度方法，该方法包括：

接收用户的服务请求；

根据自身的服务状态，确定是否向所述用户提供所述服务请求对应的服务；

若不提供，则确定是否存在提供所述服务的第二边缘节点；

若存在，则向所述第二边缘节点转发所述服务请求，以使所述第二边缘节点为所述用户提供服务。

本发明实施例第二方面提供一种边缘节点，该节点包括：

接收模块，用于接收用户的服务请求；

第一确定模块，用于根据自身的服务状态，确定是否向所述用户提供所述服务请求对应的服务；

第二确定模块，用于在不向所述用户提供所述服务请求对应的服务时，确定是否存在提供所述服务的第二边缘节点；

发送模块，用于在存在所述第二边缘节点时，向所述第二边缘节点转发所述服务请求，以使所述第二边缘节点为所述用户提供服务。

本发明实施例中，边缘节点在接收到用户发送的服务请求之后，先通过对自身的服务状态进行判断，确定当前的服务状态是否能够向用户提供用户所请求的服务，若不能提供，则进一步确定临近的节点中是否存在能够提供用户所需服务的边缘节点，若存在，则将用户的服务请求转发给相应的边缘节点，以使相应的边缘节点为用户提供服务。而不需要像现有技术那样，需要上层区域节点的调度才能完成对用户所请求的服务的调度。节约了上层区域节点的调度过程，提高了服务调度的效率。

附图说明

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

图1为本发明一实施例提供的服务调度方法的流程示意图；

图2为本发明一实施例提供的步骤S102的执行方法的流程示意图；

图3为本发明一实施例提供的步骤S103的执行方法的流程示意图；

图4为本发明一实施例提供的信息格式的结构示意图；

图5为本发明一实施例提供的边缘节点的结构示意图；

图6为本发明一实施例提供的第一确定模块12的结构示意图；

图7为本发明一实施例提供的第二确定模块13的结构示意图。

具体实施方式

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

本发明的说明书和权利要求书的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤的过程或结构的装置不必限于清楚地列出的那些结构或步骤而是可包括没有清楚地列出的或对于这些过程或装置固有的其它步骤或结构。

图1为本发明一实施例提供的服务调度方法的流程示意图，该方法可以由CDN网络中的边缘节点来执行，如图1所示，该方法包括如下步骤：

步骤S101、接收用户的服务请求。

步骤S102、根据自身的服务状态，确定是否向所述用户提供所述服务请求对应的服务，若不提供，则执行步骤S103。

本实施例中所涉及的边缘节点的服务状态包括：边缘节点的服务内容，比如语音服务、视频服务等，边缘节点的运行健康状况，比如是否发生故障等，以及边缘节点的资源利用率。

实际应用中，由于边缘节点的服务状态是实时变化的，因此，边缘节点并不是自始至终都能够向用户提供服务的，比如当用户所请求的服务并不包含在边缘节点所能提供的服务内容中，或者边缘节点发生故障，再或者边缘节点的资源利用率已经达到上限时，此时边缘节点就不能向用户提供服务。因此，在边缘节点接收到用户的服务请求后，需要先对自身的服务状态进行判断，以确定自身是否具备为用户提供服务的能力。本实施例中，边缘节点对自身服务状态的判断方法如图2所示。

图2为本发明一实施例提供的步骤S102的执行方法的流程示意图。如图2所示，该方法包括：

步骤S201、确定自身是否发生故障，若未发生故障，则执行步骤S202，否则，不向所述用户提供所述服务请求对应的服务。

步骤S201中边缘节点的自检可以采用现有方法，比如可以采用定期发送心跳检测信号的方式，确定其内部各功能模块是否发生故障，当然此处仅为示例说明而不是对比本发明的唯一限定。现有技术中凡是可以实现节点自检的手段都可以用于本实施例中边缘节点的自检。

步骤S202、确定自身的服务内容中是否包括所述服务请求对应的服务，若包含，则执行步骤S203，否则，不向所述用户提供所述服务请求对应的服务。

实际应用中，边缘节点在确定自身未发生故障时，则可以进一步的用户所请求的服务进行检测，确定其所能提供的服务内容中是否包括用户所请求的服务。只有在其自身的服务内容中包括用户所需服务的情况下才能为用户提供服务，否则不能够提供服务。比如，用户所请求的服务是视频服务，而边缘节点其自身所能提供的服务内容中包括语音服务，文字服务，而不包括视频服务时，则无法向用户提供服务。

步骤S203、确定当前的资源利用率是否超过第一预设阈值，若超过，则不向所述用户提供所述服务请求对应的服务，否则，自身向用户提供所述服务。

具体的，若边缘节点未发生故障，且其提供的服务内容中包括用户所请求的服务时，这时为了进一步保证服务质量，边缘节点需要进一步对自身的资源利用率进行检测，当边缘节点的资源利用率超过预设的上限时(即第一预设阈值)，则说明此时其已没有足够的资源支持其为新增用户提供服务了。这时，边缘节点也不满足为用户提供服务的条件。

步骤S103、确定是否存在提供所述服务的第二边缘节点，若存在，则向所述第二边缘节点转发所述服务请求，以使所述第二边缘节点为所述用户提供服务；若不存在，则将所述服务请求转发给上层区域节点，使得上层区域节点对用户的服务请求进行调度。

经过步骤S201-步骤S203的判断，若边缘节点确定其不能够向用户提供服务时，则需要进一步的对用户所请求的服务进行调度。现有技术中，通常是通过将用户的服务请求转发给上层区域节点，以使上层区域节点向用户提供服务或通过上层区域节点指定其他的边缘节点处理用户的服务请求，这种方式，需要上层区域节点参与到对用户的服务调度中，调度效率较低。而为了提升服务调度的效率，本实施例中边缘节点在确定自身不向用户提供服务时，不是直接将用户的服务请求转发给上层区域节点，而是先从其临近的节点中确定其中是否存在可以为所述用户提供服务的边缘节点，若存在，则直接将用户的服务请求转发给相应的边缘节点，而不是转发给上层区域节点。若临近的节点不存在能够为所述用户提供服务的边缘节点，再将该用户的服务请求转发给上层区域节点，以使上层区域节点对用户的服务请求进行处理。

具体的，图3为本发明一实施例提供的步骤S103的执行方法的流程示意图，如图3所示，步骤S103具体可以通过以下子步骤实现：

步骤S301、获取临近的边缘节点的服务状态信息。

本实施例中所称的临近的边缘节点的服务状态信息包括临近边缘节点的服务内容、是否故障以及资源利用率等信息。

实际应用中，临近的边缘节点的服务状态信息可以是在预设时间范围内或网络空闲时从临近的边缘节点中获取的，比如，在CDN网络中各边缘节点之间可以预先设置一个用于获取临近边缘节点服务状态信息的指令，临近边缘节点在接收到该指令时，以预设的信息格式将自身的服务状态信息返回给指令的发起方。比如，在一个示例中预设的信息格式可以被具体为图4所示的形式，当然图4仅为示例说明，而不是对本发明的唯一限定。

进一步的，在获取到临近的边缘节点的服务状态信息之后，优选的可以将该些服务状态信息存储在本地数据库中，当需要从临近的边缘节点中选择一个节点处理用户的服务请求时，则可以直接从本地数据库中获取所有临近边缘节点的服务状态信息、

步骤S302、根据所述临近的边缘节点的服务状态信息，确定是否存在提供所述服务的第二边缘节点。

具体的，在实际应用中，可以先根据获取到的临近边缘节点的服务状态信息，对每个临近边缘节点的服务内容和故障情况进行判断，从所有临近的边缘节点中筛选出服务内容与用户请求的服务内容相同，且未发生故障的边缘节点。进一步的，再从筛选出的临近的边缘节点中确定出资源利用率最低的边缘节点(即第二边缘节点)作为处理用户服务请求的节点。

特别的，若是临近的边缘节点中不存在能够为用户提供服务的边缘节点，那么直接将用户的服务请求转发给上层区域节点，以使上层区域节点对用户的服务请求进行处理。

本实施例中，边缘节点在接收到用户发送的服务请求之后，先通过对自身的服务状态进行判断，确定当前的服务状态是否能够向用户提供用户所请求的服务，若不能提供，则进一步确定临近的节点中是否存在能够提供用户所需服务的边缘节点，若存在，则将用户的服务请求转发给相应的边缘节点，以使相应的边缘节点为用户提供服务。而不需要像现有技术那样，需要上层区域节点的调度才能完成对用户所请求的服务的调度。节约了上层区域节点的调度过程，提高了服务调度的效率。并且，本实施例中是根据临近的边缘节点的服务内容和资源利用率等情况将用户的服务请求转发给能够为用户提供服务的边缘节点，相较于现有技术服务调度更加具有针对性，且调度具有较高的准确性。

图5为本发明一实施例提供的边缘节点的结构示意图，如图5所示，该边缘节点包括：

接收模块11，用于接收用户的服务请求；

第一确定模块12，用于根据自身的服务状态，确定是否向所述用户提供所述服务请求对应的服务；

第二确定模块13，用于在不向所述用户提供所述服务请求对应的服务时，确定是否存在提供所述服务的第二边缘节点；

发送模块14，用于在存在所述第二边缘节点时，向所述第二边缘节点转发所述服务请求，以使所述第二边缘节点为所述用户提供服务。

本实施例提供的边缘节点能够用于执行图1所示实施例的方法，其执行方式和有益效果类似，在这里不再赘述。

图6为本发明一实施例提供的第一确定模块12的结构示意图。在图5所示实施例的基础上，本实施例中，边缘节点的服务状态包括：服务内容、是否故障，资源利用率。所述第一确定模块12，包括：

第一确定子模块121，用于确定自身是否发生故障；若发生故障，则不向所述用户提供所述服务请求对应的服务；

第二确定子模块122，用于当自身未发生故障时，确定自身的服务内容中是否包括所述服务请求的服务；若不包括，则不向所述用户提供所述服务请求对应的服务；

第三确定子模块123，用于当自身的服务内容中包括所述服务请求对应的服务时，确定当前的资源利用率是否超过第一预设阈值，若超过，则不向所述用户提供所述服务请求对应的服务。

本实施例提供的边缘节点能够用于执行图2所示实施例的方法，其执行方式和有益效果类似，在这里不再赘述。

图7为本发明一实施例提供的第二确定模块13的结构示意图，如图7所示，本实施例中，所述第二确定模块13，包括：

获取子模块131，用于获取临近的边缘节点的服务状态信息；

第四确定子模块132，用于根据所述临近的边缘节点的服务状态信息，确定是否存在提供所述服务的第二边缘节点。

其中，所述获取子模块131，具体用于：

从本地数据库中获取临近的边缘节点的服务状态信息，所述临近的边缘节点的服务状态信息是在预设时间范围内或网络空闲时从所述临近的边缘节点中获得并存储在所述本地数据库中的。

所述临近的边缘节点的服务状态信息包括服务内容、是否故障，资源利用率；

所述第四确定子模块132，具体用于：

根据所述临近的边缘节点的服务状态信息，确定所述临近的边缘节点中是否存在服务内容与所述服务请求的服务内容相同，且未发生故障的边缘节点；

若不存在，则确定不存在提供所述服务的第二边缘节点；

若存在，则确定所述边缘节点中资源利用率最低的边缘节点为所述第二边缘节点。

本实施例提供的边缘节点能够用于执行图3所示实施例的方法，其执行方式和有益效果类似，在这里不再赘述。

最后需要说明的是，本领域普通技术人员可以理解上述实施例方法中的全部或者部分流程，是可以通过计算机程序来指令相关的硬件完成，所述的程序可存储于一计算机可读存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可以为磁盘、光盘、只读存储记忆体(ROM)或随机存储记忆体(RAM)等。

本发明实施例中的各个功能单元可以集成在一个处理模块中，也可以是各个单元单独的物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现，并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。上述提到的存储介质可以是只读存储器、磁盘或光盘等。

以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。