一种数据处理方法及相关设备
技术领域
本申请涉及通信领域，尤其涉及一种数据处理方法及相关设备。
背景技术
云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术(Cloudtechnology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。
不同于中心云，边缘场景下，首先要面对云边弱网络的环境，边缘设备常常位于边缘云机房、移动边缘站点，与云端连接的网络环境十分复杂，不像中心云那么可靠。这其中既包含云端(控制端)和边缘端的网络环境不可靠，也包含边缘节点之间的网络环境不可靠，即使是同一区域不同机房之间也无法假设节点之间网络质量良好。
云边弱网络带来的问题是影响运行在边缘节点上的kubelet与云端应用程序接口服务(Application Programming Interface server，APIServer)之间通信，云端APIServer无法收到kubelet的心跳或者续租，无法准确获取该节点和节点上pod的运行情况，如果持续时间超过设置的阈值，原生AIServer会认为该节点不可用，并做出如下一些动作：失联的节点状态被置为NotReady或者Unknown状态，并被添加NoSchedule和NoExecute的taints；失联的节点上的pod被驱逐，并在其他节点上进行重建；失联的节点上的Pod从Service的Endpoint列表中移除。
然而，在原生Kubernetes的情况下，如果Pod因为网络波动而频繁重建，一方面会影响服务实例缓存效果，另一方面会引起调度系统将用户的请求调度到其他服务实例。无疑，这两点都会对内容分发网络(Content Delivery Network，CDN)效果造成极大的影响，甚至不能接受。
发明信息
本申请提供了一种数据处理方法及相关设备，可以确定分布式集群中节点的健康状态，进而根据节点的健康状态执行相应的操作，避免云边网络波动对服务造成的影响。
本申请第一方面提供了一种数据处理方法，包括：
目标节点获取第一节点集合中每个节点的第一初始健康状态，所述第一节点集合为目标分组中除所述目标节点之外的节点的集合，所述目标节点为所述目标分组中的任意一个节点，所述目标分组为分布式集群中的任意一个分组；
所述目标节点获取所述目标分组中每个节点的第二初始健康状态，所述第二初始健康状态为第一目标节点获取的第二节点集合中每个节点的健康状态，所述第二节点集合为所述目标分组中除所述第一目标节点之外的其他节点的集合，所述第一目标节点为所述目标分组中除所述目标节点之外的任意一个节点；
所述目标节点根据所述第一初始健康状态以及所述第二初始健康状态确定所述目标分组中每个节点的第一目标健康状态；
所述目标节点将所述目标分组中每个节点的第一目标健康状态发送至服务器，以使得所述服务器根据所述目标分组中每个节点的第一目标健康状态以及第二目标健康状态执行相应的操作，所述第二目标健康状态为云端获取的所述目标分组中每个节点的健康状态。
可选地，所述目标节点获取第一节点集合中每个节点的第一初始健康状态包括：
所述目标节点向所述第一节点集合中每个节点的目标接口发送目标请求，以获取所述第一节点集合中每个节点返回的健康值；
所述目标节点根据所述第一节点集合中每个节点返回的健康值确定所述第一节点集合中每个节点的第一初始健康状态。
可选地，所述目标节点根据所述第一节点集合中每个节点返回的健康值确定所述第一节点集合中每个节点的第一初始健康状态包括：
当第二目标节点的健康值为正常时，所述目标节点确定所述第二目标节点的第一初始健康状态为正常，所述第二目标节点为所述第一节点集合中的任意一个节点；
当第二目标节点的健康值为异常时，所述目标节点确定所述第二目标节点的第一初始健康状态为异常。
本申请第二方面提供了一种数据处理方法，包括：
服务器接收目标节点发送的目标分组中每个节点的第一目标健康状态，所述目标分组为分布式集群中的任意一个分组，所述目标分组中每个节点的第一目标健康状态为所述目标节点根据第一初始健康状态以及第二初始健康状态确定的，所述第一初始健康状态为所述目标节点获取第一节点集合中每个节点的健康状态，所述第一节点集合为所述目标分组中除所述目标节点之外的其他节点的集合，所述第二初始健康状态为所述目标节点接收第一目标节点发送的第二节点集合中每个节点的健康状态，且所述第二初始健康状态为所述第一目标节点获取的所述第二节点集合中每个节点的健康状态，所述第二节点集合为所述目标分组中除所述第一目标节点之外的其他节点的集合，所述第一目标节点为所述目标分组中除所述目标节点之外的任意一个节点；
所述服务器接收云端发送的所述目标分组中每个节点的第二目标健康状态；
所述服务器根据所述第一目标健康状态以及所述第二目标健康状态对所述目标分组中的每个节点执行相应的操作。
可选地，所述服务器根据所述第一目标健康状态以及所述第二目标健康状态对所述目标分组中的每个节点执行相应的操作包括：
当第三目标节点的第一目标健康状态为正常，且所述第三目标节点的第二目标健康状态为异常时，所述服务器停止调度资源对象至所述第三目标节点，所述第三目标节点为所述目标分组中的任意一个节点；
当所述第三目标节点的第一目标健康状态为异常，且所述第三目标节点的第二目标健康状态为异常时，所述服务器将所述第三目标节点中的资源对象进行驱逐处理，并将所述第三目标节点的资源对象从所述资源对象列表中剔除，且停止调度目标资源对象至所述第三目标节点，所述资源对象列表中存储有包括所述第三节点的资源对象在内的多个节点的资源对象；
当所述第三目标节点的第一目标健康状态为正常，且所述第三目标节点的第二目标健康状态为正常时，所述服务器对所述第三目标节点不执行任何操作。
本申请第三方面提供了一种节点，所述节点为目标节点，包括：
第一获取单元，用于获取第一节点集合中每个节点的第一初始健康状态，所述第一节点集合为目标分组中除所述目标节点之外的节点的集合，所述目标节点为所述目标分组中的任意一个节点，所述目标分组为分布式集群中的任意一个分组；
第二获取单元，用于获取所述目标分组中每个节点的第二初始健康状态，所述第二初始健康状态为第一目标节点获取的第二节点集合中每个节点的健康状态，所述第二节点集合为所述目标分组中除所述第一目标节点之外的其他节点的集合，所述第一目标节点为所述目标分组中除所述目标节点之外的任意一个节点；
确定单元，用于根据所述第一初始健康状态以及所述第二初始健康状态确定所述目标分组中每个节点的第一目标健康状态；
发送单元，用于将所述目标分组中每个节点的第一目标健康状态发送至服务器，以使得所述服务器根据所述目标分组中每个节点的第一目标健康状态以及第二目标健康状态执行相应的操作，所述第二目标健康状态为云端获取的所述目标分组中每个节点的健康状态。
可选地，所述第一获取单元具体用于：
所述目标节点向所述第一节点集合中每个节点的目标接口发送目标请求，以获取所述第一节点集合中每个节点返回的健康值；
所述目标节点根据所述第一节点集合中每个节点返回的健康值确定所述第一节点集合中每个节点的第一初始健康状态。
可选地，所述第一获取单元根据所述第一节点集合中每个节点返回的健康值确定所述第一节点集合中每个节点的第一初始健康状态包括：
当第二目标节点的健康值为正常时，所述目标节点确定所述第二目标节点的第一初始健康状态为正常，所述第二目标节点为所述第一节点集合中的任意一个节点；
当第二目标节点的健康值为异常时，所述目标节点确定所述第二目标节点的第一初始健康状态为异常。
本申请第四方面提供了一种服务器，包括：
接收单元，用于接收目标节点发送的目标分组中每个节点的第一目标健康状态，所述目标分组为分布式集群中的任意一个分组，所述目标分组中每个节点的第一目标健康状态为所述目标节点根据第一初始健康状态以及第二初始健康状态确定的，所述第一初始健康状态为所述目标节点获取第一节点集合中每个节点的健康状态，所述第一节点集合为所述目标分组中除所述目标节点之外的其他节点的集合，所述第二初始健康状态为所述目标节点接收第一目标节点发送的第二节点集合中每个节点的健康状态，且所述第二初始健康状态为所述第一目标节点获取的所述第二节点集合中每个节点的健康状态，所述第二节点集合为所述目标分组中除所述第一目标节点之外的其他节点的集合，所述第一目标节点为所述目标分组中除所述目标节点之外的任意一个节点；
所述接收单元，还用于接收云端发送的所述目标分组中每个节点的第二目标健康状态；
执行单元，用于根据所述第一目标健康状态以及所述第二目标健康状态对所述目标分组中的每个节点执行相应的操作。
可选地，所述执行单元具体用于：
当第三目标节点的第一目标健康状态为正常，且所述第三目标节点的第二目标健康状态为异常时，停止调度资源对象至所述第三目标节点，所述第三目标节点为所述目标分组中的任意一个节点；
当所述第三目标节点的第一目标健康状态为异常，且所述第三目标节点的第二目标健康状态为异常时，将所述第三目标节点中的资源对象进行驱逐处理，并将所述第三目标节点的资源对象从所述资源对象列表中剔除，且停止调度目标资源对象至所述第三目标节点，所述资源对象列表中存储有包括所述第三节点的资源对象在内的多个节点的资源对象；
当所述第三目标节点的第一目标健康状态为正常，且所述第三目标节点的第二目标健康状态为正常时，对所述第三目标节点不执行任何操作。
本申请第三方面提供了一种计算机装置，其包括至少一个连接的处理器、存储器和收发器，其中，所述存储器用于存储程序代码，所述程序代码由所述处理器加载并执行以实现上述所述的数据处理方法的步骤。
本申请第四方面提供了一种计算机可读存储介质，其包括指令，当其在计算机上运行时，使得计算机执行上述所述的数据处理方法的步骤。
综上所述，可以看出，本申请提供的实施例中，目标节点获取目标分组中每个节点的第一初始健康状态以及第二初始健康状态，并根据第一初始健康状态以及第二初始健康状态确定目标分组中每个节点的第一目标健康状态，并将该第一目标健康状态发送至服务器，由服务器根据第一目标健康状态以及从云端获取的目标分组中每个节点的第二目标健康状态执行相应的操作。通过云端和边缘端综合来确定分布式集群中节点的健康状态，这样在云边弱网络情况下大大提高节点健康状态判断的准确性，让系统更健壮，避免云边网络波动对服务造成的影响。
附图说明
图1为本申请实施例提供的数据处理方法的一个应用场景示意图；
图2为本申请实施例提供的数据处理方法的另一应用场景示意图；
图3为本申请实施例提供的数据处理方法的一个技术流程示意图；
图4为本申请实施例提供的数据处理方法的另一技术流程示意图；
图5为本申请实施例提供的数据处理方法的另一技术流程示意图；
图6为本申请实施例提供的网络节点的虚拟结构示意图；
图7为本申请实施例提供的服务器的虚拟结构示意图；
图8为本申请实施例提供的网络节点的硬件结构示意图；
图9为本申请实施例提供的服务器的硬件结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的信息以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本申请中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个系统中，或一些特征向量可以忽略，或不执行，另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合或通信连接可以是电性或其他类似的形式，本申请中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请方案的目的。
下面对本申请涉及到的一些名词进行说明：
kubernetes是一个分布式的集群管理系统，在每个节点(node)上都要运行一个worker程序对容器进行生命周期的管理，该worker程序就是kubelet。
kubelet的主要功能就是定时从某个地方获取节点上Pod/container的期望状态(运行什么容器、运行的副本数量、网络或者存储如何配置等等)，并调用对应的容器平台接口达到这个状态。
API Server提供了各类资源对象(Pod、RC以及Service等)的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。
不同于中心云，边缘场景下，首先要面对云边弱网络的环境，边缘设备常常位于边缘云机房或者移动边缘站点，与云端连接的网络环境十分复杂，不像中心云那么可靠。这其中既包含云端(控制端)和边缘端的网络环境不可靠，也包含边缘节点之间的网络环境不可靠，即使是同一区域不同机房之间也无法假设节点之间网络质量良好。
请参阅图1，图1为本申请实施例提供的数据处理方法的一个应用场景示意图，此处以智慧工厂为例，云端集群101与仓库102以及车间103之间的网络为弱网，仓库102与车间103之间的网络为弱网，边缘节点位于厂房仓库102和车间103，控制端master节点在腾讯云的中心机房内。
仓库102和车间103内的边缘设备同云端集群101之间的网络较复杂，包括因特网、第五代移动通信技术(5th generation mobile networks或5th generation wirelesssystems、5th-Generation，5G)、WIFI等形态均有可能，网络质量差次不齐没有保障；同时，相对于云端的网络环境，由于仓库102和车间103内的边缘设备之间是本地网络，因此网络质量肯定要优于同云端集群之间的连接，相对而言更加可靠。
云边弱网络带来的问题是影响运行在边缘节点上的kubelet与云端APIServer之间通信，云端APIServer101无法收到仓库102以及车间103中的节点的kubelet心跳或者续租，无法准确获取仓库102或车间103中的节点以及该节点上Pod的运行情况，如果该状况持续时间超过设置的阈值，那么云端APIServer102会认为该节点不可用，并做出如下一些动作：
失联的节点状态被置为NotReady或者Unknown状态，并被添加NoSchedule和NoExecute的taints；失联的节点上的Pod被驱逐，并在其他节点上进行重建；失联的节点上的Pod从Service的Endpoint列表中移除。
下面结合图2以音视频拉流场景为例对Pod的重建进行说明，请参阅图2，图2为本申请实施例提供的数据处理方法的另一场景示意图，包括：
云端集群201A以及201B、边缘CDN节点202A以及202B、边缘CDN节点203A以及203B、视频客户端204A以及204B；
基于用户体验及成本考虑，音视频拉流经常需要提高边缘缓存命中率减少回源，将用户请求的同一文件调度到同一个服务实例以及服务实例缓存文件均是常见的做法。
然而，在原生Kubernetes的情况下，如果Pod因为网络波动而频繁重建，如图2中的边缘CDN节点202A中的Pod A因为弱网中断，在云边断网后重连，由于断网的影响，在弱网重连之后，会将边缘CDN节点202A中的Pod A销毁进行重建，并将边缘CDN节点203B的Pod B与视频客户端204B连接。但是这样做一方面会影响服务实例缓存效果，另一方面会引起调度系统将用户请求调度到其他服务实例。
事实上，边缘节点完全运行正常，Pod驱逐或重建其实是完全不必要的。为了克服这个问题，保持服务的持续可用，仅仅依赖边缘端和云端APIServer的连接情况来判断边缘节点是否正常并不合理，为了让系统更健壮，需要引入额外的判断机制。
有鉴于此，本申请提供了一种数据处理方法，通过分布式集群中的边缘分布式节点的健康状态判定技术和机制，除了考虑节点与云端APIServer的连接情况，还引入了边缘节点的判定情况作为评估因子，以便对节点进行更全面的状态判断，由此在云边弱网络情况下大大提高系统在节点状态判断上的准确性，为服务稳定运行保驾护航。
另外，由于边缘网络和拓扑的特殊性，常常会存在节点组之间网络单点故障的问题，比如上述图1中所示的例子中，仓库102和车间103虽然都属于厂房这个地域内，但是可能他们之间的网络连接依靠一条关键链路，一旦这条链路发生中断，就会造成节点组之间的分裂，本申请提供的数据处理方法能够确保两个分裂的节点组失联后互相判定组内节点的健康状态时始终保持多数的一方节点不会被判定为异常，避免被判定为异常造成Pod只能被调度到少部分的节点上，造成节点负载过高的情况。
边缘设备很有可能位于不同的地区、相互不通，本申请提供的数据处理方法也支持多地域内的节点状态判定，可以方便地将节点依据地域或者其他方式进行分组后，实现组内的检查；并且即使重新分组也无需重新部署检测组件或重新初始化，更为适应边缘计算的网络情况。分组后，节点只会判定同一个组内的节点状态，如果不为节点分组，默认各个节点自己是一个组，不会检查其他节点。
下面结合图3从目标节点角度对本申请实施例提供的数据处理方法的进行说明。
请参阅图3，图3为本申请实施例提供的数据处理方法的流程示意图，包括：
301、目标节点获取第一节点集合中每个节点的第一初始健康状态。
本实施例中，目标节点可以获取第一节点集合中每个节点的第一初始健康状态，其中，该第一节点集合为目标分组中除目标节点之外的节点的集合，目标节点为目标分组中的任意一个节点，目标分组为分布式集群中任意一个分组。也就是说，对于分布式Kubernetes集群中各个分组来说，各个分组中的每个节点定期探测组内的其他节点的第一初始健康状态。
一个实施例中，目标节点获取第一节点集合中每个节点的第一初始健康状态包括：
目标节点向第一节点集合中每个节点的目标接口发送目标请求，以获取第一节点集合中每个节点返回的健康值；
目标节点根据第一节点集合中每个节点返回的健康值确定第一节点集合中每个节点的第一初始健康状态。
本实施例中，目标分组中的每个节点通过向目标分组中的其他节点的目标接口发送请求，获取每个节点返回的健康值，根据该健康值确定其对应的健康状态。当第二目标节点的健康值为正常时，目标节点确定第二目标节点的第一初始健康状态为正常，第二目标节点为第一节点集合中的任意一个节点；当第二目标节点的健康值为异常时，目标节点确定第二目标节点的第一初始健康状态为异常。也就是说，目标节点可以通过向第一节点集合中每个节点的kubelet的10255的/healthz接口(也即目标接口)发送请求，获取第一节点集合中每个节点的kubelet健康状态作为每个节点的健康状态；另外，目标节点还可以通过ping第一节点集合中每个节点的22端口的方法，并根据请求返回值是否正常作为判定标准；可以理解的是，判定节点的健康状态的标准为：如果请求返回值正常，则认为该节点的健康状态正常的，如果请求返回值异常，则认为该节点的将康状态为异常。
302、目标节点获取目标分组中每个节点的第二初始健康状态。
本实施例中，目标节点可以获取目标分组中每个节点的第二初始健康状态，该第二初始健康状态为第一目标节点获取的第二节点集合中每个节点的健康状态，第二节点集合为目标分组中除第一目标节点之外的其他节点的集合，该第一目标节点为目标分组中除目标节点之外的任意一个节点。也就是说，目标分组中每个节点除了自己获取其他节点的第一初始健康状态，还会向目标分组中的其他节点获取第二初始健康状态，该第二初始健康状态为目标分组中的其他节点分别获取目标分组中节点的健康状态。例如目标分组中包括节点A、节点B、节点C以及节点D，节点A会获取节点B、节点C以及节点D的健康状态，同理，节点B会获取节点A、节点C以及节点D的健康状态，节点C会获取节点A、节点B以及节点D的健康状态，节点D会获取节点A、节点B以及节点C的健康状态，另外，节点A还会获取节点B、节点C以及节点D获取的目标分组中节点的健康状态，以此类推，节点B、节点C以及节点D也是如此。可以理解的是，目标节点可以周期性的获取目标分组中每个节点的第二初始健康状态，也可以按需进行获取，具体不做限定。
需要说明的是，通过步骤301可以获取第一节点集合中每个节点的第一初始健康状态，通过步骤302可以获取目标分组中每个节点的第二初始健康状态，然而，这两个步骤之间并没有先后执行顺序的限制，可以先执行步骤301，也可以先执行步骤302，或者同时执行，具体不做限定。
303、目标节点根据第一初始健康状态以及第二初始健康状态确定目标分组中每个节点的第一目标健康状态。
本实施例中，目标节点在获取到第一节点集合中每个节点的第一初始健康状态以及目标分组中每个节点的第二初始健康状态之后，目标节点根据第一初始健康状态以及第二初始健康状态确定目标分组中每个节点的第一目标健康状态，也就是说，分布式集群内各个分组的所有节点定期投票决定各分组内节点的健康状态：通过步骤301以及步骤302获取的第一初始健康状态以及第二初始健康状态，目标分组内的各个节点都保存了从自己角度(该节点的自己角度为节点自己认为)确定的各节点的健康状况，另外目标分组中的其他节点之间也会相互交互自己获取到的其他节点的第一初始健康状态，并根据收到的其他节点探测的节点的第二初始健康状态进行统计，即可以选出目标分组中所有节点的第一目标健康状态，例如可以通过预设值来进行确定，例如目标分组中包括节点A、节点B、节点C以及节点D，其中，认为节点A的健康状态为异常的节点有2个，认为节点B的健康状态为异常的节点有3个，认为节点C的健康状态为异常的节点有0个，认为节点D的健康状态为异常的节点有1，假如该预设值为3，则目标分组中第一目标健康状态为异常的节点为节点B，目标分组中第一目标健康状态为正常的节点为节点A、C以及D。
304、目标节点将目标分组中每个节点的第一目标健康状态发送至服务器，以使得服务器根据目标分组中每个节点的第一目标健康状态以及第二目标健康状态执行相应的操作。
本实施例中，目标节点在确定目标分组中每个节点的第一目标健康状态之后，可以将目标分组中每个节点的第一目标健康状态发送至服务器，以使得服务根据从目标节点获取的目标分组中每个节点的第一目标健康状态以及从云端获取的目标分组中每个节点的第二目标健康状态执行相应的操作。
综上所述，可以看出，本申请提供的实施例中，目标节点获取目标分组中每个节点的第一初始健康状态以及第二初始健康状态，并根据第一初始健康状态以及第二初始健康状态确定目标分组中每个节点的第一目标健康状态，并将该第一目标健康状态发送至服务器，由服务器根据第一目标健康状态以及从云端获取的目标分组中每个节点的第二目标健康状态执行相应的操作。通过云端和边缘端综合来确定分布式集群中节点的健康状态，这样在云边弱网络情况下大大提高节点健康状态判断的准确性，让系统更健壮，避免云边网络波动对服务造成的影响。
下面结合图4从服务器的角度对本申请实施例提供的数据处理方法进行说明，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
请参阅图4，图4为本申请实施例提供的数据处理方法的另一流程示意图，包括：
401、服务器接收目标节点发送的目标分组中每个节点的第一目标健康状态。
本实施例中，服务器可以接收目标节点发送的目标分组中每个节点的第一目标健康状态，其中，目标分组为分布式集群中的任意一个分组，目标分组中每个节点的第一目标健康状态为目标节点根据第一初始健康状态以及第二初始健康状态确定的，第一初始健康状态为目标节点获取第一节点集合中每个节点的健康状态，第一节点集合为目标分组中除目标节点之外的其他节点的集合，第二初始健康状态为目标节点接收第一目标节点发送的第二节点集合中每个节点的健康状态，且第二初始健康状态为第一目标节点获取的第二节点集合中每个节点的健康状态，第二节点集合为目标分组中除第一目标节点之外的其节点的集合，第一目标节点为目标分组中除目标节点之外的任意一个节点。
需要说明的是，上述图3中已经对目标节点如何确定第一目标健康状态进行详细说明，具体此处不再赘述。
402、服务器接收云端发送的目标分组中每个节点的第二目标健康状态。
本实施例中，服务器可以接收云端发送的目标分组中每个节点的第二目标健康状态，也就是说，云端APIServer无法收到节点kubelet的心跳或者续租，无法准确获取该节点和节点上Pod的运行情况，如果持续时间超过设置的阈值，云端APIServer会认为该节点的健康状态为异常，否则该节点的健康状态为正常。服务器可以发送请求消息至云端，之后云端返回获取到的目标分组中每个节点的第二目标健康状态。
需要说明的是，通过步骤401可以接收目标节点发送的目标分组中每个节点的第一目标健康状态，通过步骤402可以接收云端发送的目标分组中每个节点的第二目标健康状态，然而这两个步骤之间并没有先后执行顺序的限制，可以先执行步骤401，也可以先执行步骤402，或者同时执行，具体不做限定。
403、服务器根据第一目标健康状态以及第二目标健康状态对目标分组中的每个节点执行相应的操作。
本实施例中，服务器在接收到目标分组中每个节点的第一目标健康状态以及第二目标健康状态之后，可以根据第一目标健康状态以及第二目标健康状态对目标分组中的每个节点执行相应的操作。也就是说，服务器可以根据目标分组中每个节点的第一目标健康状态以及第二目标健康状态确定目标分组中每个节点的最终目标状态，之后根据目标分组中每个节点的最终目标状态执行相应的操作。
一个实施例中，服务器根据第一目标健康状态以及第二目标健康状态对目标分组中的每个节点执行相应的操作包括：
当第三目标节点的第一目标健康状态为正常，且第三目标节点的第二目标健康状态为异常时，服务器停止调度资源对象至第三目标节点，第三目标节点为目标分组中的任意一个节点；
当第三目标节点的第一目标健康状态为异常，且第三目标节点的第二目标健康状态为异常时，服务器将第三目标节点中的资源对象进行驱逐处理，并将第三目标节点的资源对象从资源对象列表中剔除，且停止调度目标资源对象至第三目标节点，资源对象列表中存储有包括述第三节点的资源对象在内的多个节点的资源对象；
当第三目标节点的第一目标健康状态为正常，且第三目标节点的第二目标健康状态为正常时，服务器对第三目标节点不执行任何操作。
本实施例中，目标分组中的节点内部之间进行探测和投票，共同决定目标分组中每个节点是否存在状态异常，保证大多数节点的一致判断才能决定节点的具体状态；另外，虽说节点之间的网络状态一般情况下要优于云边网络，但同时应该注意到，边缘节点之间网络情况也十分复杂，它们之间的网络也不是100％可靠，节点的状态不能只由节点自行决定，云边共同决定才更为可靠。由于是云端和边缘端共同决定节点的健康状态，因此会存在三种情况：
1、第三目标节点的第一目标健康状态为正常，第三目标节点的第二目标健康状态为异常；
2、第三目标节点的第一目标健康状态为异常，第三目标节点的第二目标健康状态为异常；
3、当第三目标节点的第一目标健康状态为正常，第三目标节点的第二目标健康状态为正常。
对于第1种情况，当云端判定节点异常，但是其他节点认为节点正常的时候，虽然不会驱逐已有Pod，但是为了确保增量服务的稳定性，不会再将新的Pod调度到该节点上，存量的正常运行也得益于边缘集群的边缘自治能力；对于第2种情况，服务器会驱逐第三目标节点中的存量Pod；并将该第三目标节点的Pod从Endpoint列表摘除，且不再调度新的Pod到该第三目标节点，对于第3中情况，服务器不对该第三目标节点执行任何操作。
需要说明的是，上述节点与云端判定节点是否正常的方式还可以根据实际情况进行设定，例如节点内部判定该节点正常，云端判定该节点异常，可以判定节点最终状态为正常，节点内部判断该节点异常，云端判断该节点正常，可以判断该节点的最终健康状态为正常，则不执行任何操作，或者是不在调度新的Pod至该节点，当节点内部判断该节点异常，云端也判断该节点异常时，才最终判定该节点异常，驱逐该节点中的存量Pod；并将该节点的Pod从Endpoint列表摘除，且不再调度新的Pod到该节点。
以目标分组中包括节点A、B、C、D四个节点为例，以确定节点A的最终目标状态为例进行说明，例如节点A的第一目标健康状态为正常，节点A的第二目标健康状态为异常，则确定节点A的最终健康状态为异常，节点A的第一目标健康状态为异常，节点A的第二目标状态为正常，则确定节点A的最终目标健康状态为异常，只有当节点A的第一目标健康状态以及第二目标健康状态均为正常，才确定节点A的最终目标健康状态为正常。需要说明的是，上述对节点A的最终目标健康状态的说明仅为举例，当然也还可以根据实际情况进行设定，例如只需要一个正常(例如第一目标健康状态为正常或第二目标健康状态为正常)即可以确定该节点的最终目标健康状态为正常，当然也还可以具体以第一目标健康状态为准或者以第二目标健康状态为准，具体不做限定。另外确定节点为正常或者为异常时，可以根据实际情况执行不同方式的操作。
综上所述，可以看出，本申请提供的实施例中，服务器根据节点端发送的目标分组中每个节点的第一目标健康状态以及云端发送的目标分组中每个节点的第二目标健康状态执行相应的操作。通过云端和边缘端综合确定分布式集群中节点的健康状态，这样在云边弱网络情况下大大提高节点健康状态判断的准确性，让系统更健壮，避免云边网络波动对服务造成的影响。
请参阅图5，图5为本申请实施例提供的数据处理方法的另一流程示意图，包括：
501、目标节点获取第一节点集合中每个节点的第一初始健康状态；
502、目标节点获取目标分组中每个节点的第二初始健康状态；
503、目标节点根据第一初始健康状态以及第二初始健康状态确定目标分组中每个节点的第一目标健康状态；
504、目标节点将目标分组中每个节点的第一目标健康状态发送至服务器；
需要说明的是，步骤501至步骤504与图3中的步骤301至步骤304类似，上述图3中已经进行了详细说明，具体此处不再赘述。
505、服务器接收云端发送的目标分组中每个节点的第二目标健康状态；
506、服务器根据目标分组中每个节点的第一目标健康状态以及第二目标健康状态执行相应的操作。
需要说明的是，步骤505至步骤506与图4中的步骤402至步骤403类似，上述图4中已经进行了详细说明，具体此处不再赘述。
综上所述，可以看出，本申请提供的实施例中，目标节点获取目标分组中每个节点的第一初始健康状态以及第二初始健康状态，并根据第一初始健康状态以及第二初始健康状态确定目标分组中每个节点的第一目标健康状态，并将该第一目标健康状态发送至服务器，由服务器根据第一目标健康状态以及从云端获取的目标分组中每个节点的第二目标健康状态执行相应的操作。通过云端和边缘端综合来确定分布式集群中节点的健康状态，这样在云边弱网络情况下大大提高节点健康状态判断的准确性，让系统更健壮，避免云边网络波动对服务造成的影响。
上面从的数据处理方法的角度对本申请进行说明，下面从节点以及服务器的角度对本申请进行说明。
请参阅图6，图6为本申请实施例提供的一种网络节点的虚拟结构示意图，该网络节点为目标节点，包括：
第一获取单元601，用于获取第一节点集合中每个节点的第一初始健康状态，所述第一节点集合为目标分组中除所述目标节点之外的节点的集合，所述目标节点为所述目标分组中的任意一个节点，所述目标分组为分布式集群中的任意一个分组；
第二获取单元602，用于所述目标分组中每个节点的第二初始健康状态，所述第二初始健康状态为第一目标节点获取的第二节点集合中每个节点的健康状态，所述第二节点集合为所述目标分组中除所述第一目标节点之外的其他节点的集合，所述第一目标节点为所述目标分组中除所述目标节点之外的任意一个节点；
确定单元603，用于根据所述第一初始健康状态以及所述第二初始健康状态确定所述目标分组中每个节点的第一目标健康状态；
发送单元604，用于将所述目标分组中每个节点的第一目标健康状态发送至服务器，以使得所述服务器根据所述目标分组中每个节点的第一目标健康状态以及第二目标健康状态执行相应的操作，所述第二目标健康状态为云端获取的所述目标分组中每个节点的健康状态。
可选地，所述第一获取单元601具体用于：
所述目标节点向所述第一节点集合中每个节点的目标接口发送目标请求，以获取所述第一节点集合中每个节点返回的健康值；
所述目标节点根据所述第一节点集合中每个节点返回的健康值确定所述第一节点集合中每个节点的第一初始健康状态。
可选地，所述第一获取单元601根据所述第一节点集合中每个节点返回的健康值确定所述第一节点集合中每个节点的第一初始健康状态包括：
当第二目标节点的健康值为正常时，所述目标节点确定所述第二目标节点的第一初始健康状态为正常，所述第二目标节点为所述第一节点集合中的任意一个节点；
当第二目标节点的健康值为异常时，所述目标节点确定所述第二目标节点的第一初始健康状态为异常。
请参阅图7，图7为本申请实施例提供的服务器的虚拟结构示意图，包括：
接收单元701，用于接收目标节点发送的目标分组中每个节点的第一目标健康状态，所述目标分组为分布式集群中的任意一个分组，所述目标分组中每个节点的第一目标健康状态为所述目标节点根据第一初始健康状态以及第二初始健康状态确定的，所述第一初始健康状态为所述目标节点获取第一节点集合中每个节点的健康状态，所述第一节点集合为所述目标分组中除所述目标节点之外的其他节点的集合，所述第二初始健康状态为所述目标节点接收第一目标节点发送的第二节点集合中每个节点的健康状态，所述第二初始健康状态为第一目标节点获取的第二节点集合中每个节点的健康状态，所述第二节点集合为所述目标分组中除所述第一目标节点之外的其他节点的集合，所述第一目标节点为所述目标分组中除所述目标节点之外的任意一个节点；
所述接收单元701，还用于接收云端发送的所述目标分组中每个节点的第二目标健康状态；
执行单元702，用于根据所述第一目标健康状态以及所述第二目标健康状态对所述目标分组中的每个节点执行相应的操作。
可选地，所述执行单元702具体用于：
当第三目标节点的第一目标健康状态为正常，且所述第三目标节点的第二目标健康状态为异常时，停止调度资源对象至所述第三目标节点，所述第三目标节点为所述目标分组中的任意一个节点；
当所述第三目标节点的第一目标健康状态为异常，且所述第三目标节点的第二目标健康状态为异常时，将所述第三目标节点中的资源对象进行驱逐处理，并将所述第三目标节点的资源对象从所述资源对象列表中剔除，且停止调度目标资源对象至所述第三目标节点，所述资源对象列表中存储有包括所述第三节点的资源对象在内的多个节点的资源对象；
当所述第三目标节点的第一目标健康状态为正常，且所述第三目标节点的第二目标健康状态为正常时，对所述第三目标节点不执行任何操作。
请参阅图8，本申请中网络节点包括一个或多个中央处理器801、存储器802及通信接口803，其中，中央处理器801、存储器802及通信接口803之间通过总线互相连接。
存储器802可以是短暂存储或持久存储，用于存储相关的指令及数据，通信接口803用于接收和发送数据。更进一步地，中央处理器801可以配置为与存储器802通信，执行存储器802中的一系列指令操作。
上述实施例中的目标节点均可以基于该图8所示的结构。
请参阅图9，图9为本申请实施例提供的一种服务器结构示意图，该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)922(例如，一个或一个以上处理器)和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在服务器900上执行存储介质930中的一系列指令操作。
服务器900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作系统941，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。
上述实施例中由服务器所执行的步骤可以基于该图9所示的服务器结构。
本申请实施例还提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现上述所述数据处理方法的步骤。
本申请实施例还提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述所述数据处理方法的步骤。
本申请实施例还提供了一种终端设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，所述程序代码由所述处理器加载并执行以实现上述所述数据处理方法的步骤。
本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行上述所述数据处理方法的步骤。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。
