CN117596247A - 基于异构边缘计算系统的资源监控和性能评估的方法 - Google Patents

Abstract

本发明公开了基于异构边缘计算系统的资源监控和性能评估的方法，本发明的方法包括获取服务器主机和边缘设备的集群环境信息，并基于集群环境信息构建异构边缘计算系统；利用索引收集微程序收集异构边缘设备的资源指标，并通过实时索引建立索引收集微程序与异构边缘计算系统之间的数据连接通道；通过数据连接通道对资源指标进行数据传输，并将资源指标转换为时间序列存储于异构边缘计算系统中以得到数据存储结果；利用服务器主机以基于混合性能评估方案对数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果。本发明利用边缘设备的计算和存储能力，使模型训练更接近数据产生的地方，可以提高数据分析和响应时间。

Description

基于异构边缘计算系统的资源监控和性能评估的方法

技术领域

本发明涉及物联网、云计算大数据边缘计算和资源监控技术领域，特别是涉及基于异构边缘计算系统的资源监控和性能评估的方法。

背景技术

现代社会物联网广泛应用在日常生活中，诸如智慧城市，医疗监控等。物联网架构大致分为4层，应用层、平台层、网络层、终端层。物联网凭借云数据中心强大的计算能力和存储能力，日益强大。终端设备通过网络连接云数据中心所在得平台层。但大量数据通过网络在终端设备和远程云数据中心之间传输，会导致长时间的传输延迟和能量损耗。利用边缘计算将云计算能力从网络核心下沉到靠近终端设备的网络边缘，可以使计算密集型和延迟关键型的应用程序实时运行，从而避免上述问题。随着边缘终端设备的数量不断增加，实时获得终端设备状态从而获得整体异构边缘设备的资源事亟待解决的问题。异构是指由不同的元素或部分组成。

在传统的以云为中心的方法中，会存在较长的传播延迟，并且可能导致实时应用程序中的延迟不可接受，例如对时间要求严格类应用程序。传输到云端的海量数据给骨干网络带来负担，消耗大量能源，并给用户带来隐私问题。现有的监控系统，基于在被监控的虚拟机或者物理机上安装agent,从而实现与服务端的通信。额外的服务端服务或进程类服务存在假死、长时间占用资源、端口冲突等潜在不稳定因素。

发明内容

本发明旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明提出了一种基于异构边缘计算系统的资源监控和性能评估的方法，利用边缘设备的计算和存储能力，使模型训练更接近数据产生的地方，并且由于网络边缘进行数据处理而非云数据中心，从而可以提高了数据分析和响应时间。

本发明的另一个目的在于提出一种基于异构边缘计算系统的资源监控和性能评估的装置。

为达上述目的，本发明一方面提出一种基于异构边缘计算系统的资源监控和性能评估的方法，包括：

获取服务器主机和边缘设备的集群环境信息，并基于所述集群环境信息构建所述异构边缘计算系统；

利用索引收集微程序收集异构边缘设备的资源指标，并通过实时索引建立所述索引收集微程序与所述异构边缘计算系统之间的数据连接通道；

通过所述数据连接通道对所述资源指标进行数据传输，并将所述资源指标转换为时间序列存储于所述异构边缘计算系统中以得到数据存储结果；

利用所述服务器主机以基于混合性能评估方案对所述数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果。

本发明实施例的基于异构边缘计算系统的资源监控和性能评估的方法还可以具有以下附加技术特征：

在本发明的一个实施例中，所述资源指标，包括CPU使用率、内存使用率以及系统负载中的多种；所述时间序列的数据格式包括，资源指标名称和相关标签。

在本发明的一个实施例中，别将所述服务器主机作和所述边缘设备做为集群环境中的主节点和工作节点；其中，所述主节点的组件，包括API服务器、调度器、控制器管理组件和调度程序；所述工作节点的组件，包括信息传输组件、代理组件和容器运行时间组件。

在本发明的一个实施例中，基于所述集群环境信息构建所述异构边缘计算系统，包括：

当所述工作节点进行调度服务时，将指令输入所述信息传输组件建立第一运行资源，并基于指令验证通过结果将第一运行资源传输到主节点中的API服务器中；

利用控制器管理组件接收到来自API服务器的创建第二运行资源的任务，并根据检测的任务资源容量判断是否构建所述第二运行资源；

当调度器访问API服务器时，判断所述控制器管理组件是否已经构建所述第二运行资源，以根据判断结果利用调度器对构建的所述第二运行资源进行对应节点分配以构建异构边缘计算系统。

在本发明的一个实施例中，利用所述服务器主机以基于混合性能评估方案对所述数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果，包括：

根据所述混合性能评估方案在所述主节点的控制器管理组件中分析预测执行状态和资源需求：

μ＝μ_b+a/λ

μ是每个容器的处理速度，μ_b是每个容器平均处理速率，λ是实时请求到达速率，a是实时请求到达速率的反比系数；

其中和/>是N个容器内存占用率和CPU占用率供低于求的速度，/>和则是供大于求的速度；

系统中没有实时请求速率的概率为：

等待队列中的请求速率和容器的处理速率的期望值为：

请求平均响应时间的期望值为：

第k步平均响应时间y_k是历史数据与当前响应时间的权重之和：

y_k＝b×y_k-1+(1-b)×W_s(N,λ,μ)。

为达上述目的，本发明另一方面提出一种基于异构边缘计算系统的资源监控和性能评估的装置，包括：

异构系统构建模块，用于获取服务器主机和边缘设备的集群环境信息，并基于所述集群环境信息构建所述异构边缘计算系统；

资源指标获取模块，用于利用索引收集微程序收集异构边缘设备的资源指标，并通过实时索引建立所述索引收集微程序与所述异构边缘计算系统之间的数据连接通道；

数据转换传输模块，用于通过所述数据连接通道对所述资源指标进行数据传输，并将所述资源指标转换为时间序列存储于所述异构边缘计算系统中以得到数据存储结果；

资源监控评估模块，用于利用所述服务器主机以基于混合性能评估方案对所述数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果。

本发明实施例的基基于异构边缘计算系统的资源监控和性能评估的方法和装置，考虑设备的异构性来整合这些设备和收集的数据，从而构建一个易于使用的资源监控平台，并基于提出的混合性能评估方案，从系统的稳健性和节约成本两方面考虑，使得性能达到最优值。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是根据本发明实施例的基于异构边缘计算系统的资源监控和性能评估的方法的流程图；

图2是根据本发明实施例的Kubernetes集群架构图；

图3是根据本发明实施例的基于异构边缘计算系统的资源监控和性能评估的装置结构示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

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

下面参照附图描述根据本发明实施例提出的基于异构边缘计算系统的资源监控和性能评估的方法和装置。

图1是根据本发明实施例的基于共享缓存机制的创建文件存储资源的方法的流程图，如图1所示，该方法包括：

S1，获取服务器主机和边缘设备的集群环境信息，并基于集群环境信息构建异构边缘计算系统；

S2，利用索引收集微程序收集异构边缘设备的资源指标，并通过实时索引建立索引收集微程序与异构边缘计算系统之间的数据连接通道；

S3，通过数据连接通道对所述资源指标进行数据传输，并将资源指标转换为时间序列存储于异构边缘计算系统中以得到数据存储结果；

S4，利用服务器主机以基于混合性能评估方案对数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果。

示例性地，异构是指由不同的元素或部分组成。异构边缘设备在本发明中指多种CPU架构的主机。

示例性地，本发明通过集成Docker开源软件、Kubernetes和Prometheus开源软件、Grafana开源系统和Node Exporter索引收集微程序技术实现基于集群的异构边缘计算系统，用于边缘设备的资源监控和性能评估。

示例性地，Docker是一种用于开发、部署和应用程序执行的开源软件。Docker允许用户在系统环境中分离应用程序，从而形成微容器，提高软件部署速度。Docker具有轻量级资源利用、可移植性和可预测性的优点。Docker微容器类似虚拟机，但容器是虚拟化操作系统，虚拟机虚拟化硬件资源。因此容器比虚拟机消耗资源更少。一个核心的操作系统可以在容器内部独立运行，并部署在不同的系统环境中，且忽略各种系统环境的差异。

示例性地，Prometheus是一种用于环境监测和警报的开源软件，使用时间序列数据库Time Series Database(TSDB)记录实时数据，并具有灵活的查询功能和实时告警功能。Prometheus系统由多个组件做成，主要包括Promeytheus服务器、客户端和告警管理器。Prmoetheus服务器用于获取和存储时间序列数据。客户端用于检测应用程序代码。告警管理器用于处理警报。

示例性地，Node exporter是一种索引收集微程序，主要为Prometheus提供数据来源。通过实时获取索引数据，构建http连接，从而存储到Prometheus。

示例性地，Grafana是一种用于多平台分析和交互式可视化的开源系统。当Grafana连接到数据源时，可以将TSDB中的数据转换为web界面上的图表。用户可以使用Grafana创建监控仪表盘，从而定制化显示监控警报。

示例性地，本发明利用优化K8s容器集群管理系统、容器编排引擎架构中Master主节点的Controller manager(负责维护集群的状态)分析，并使用网络拓扑信息来调度Pod服务。

示例性地，Kubernetes作为基础设施被谷歌、雅虎等拥有大规模计算能力的公司广泛使用。在以容器部署的服务向用户提供各种功能的系统中，最关健的一点是设计评估和相对应的调度方法从而保证系统的稳健性。而现有的评估更多仅偏向内存使用率和cpu利用率等静态数据，缺少对历史状态的分析，且容器个数固定，因为评估方法并不是最优的。

本发明实施例采用速率变化的排队模型和线性模型混合模型来更准确的评估动态多容器性能，达到系统成本和系统稳健性的最优状态。优化现有的边缘计算监控系统架构模型，在Controller Manager中新增分析和调度功能，避免进程类的服务假死等潜在不稳定因素。

在本发明的一个实施例中，本发明主要描述一种基于K8s的自动弹性伸缩的解决方案，是以下四个步骤的循环：(1)监控，利用Node Exporter收集K8s集群的状态和服务执行状态；(2)分析，利用Master节点Controller Manager分析预测后续执行状态和资源需求；(3)规划，寻求K8s集群最佳放缩操作；(4)执行，对集群进行调整。

本发明的系统架构包括两部分，第一部分为主节点(Master Server)，由四个组件组成；第二部分为工作节点(worker)，由三个组件组成。在本发明中采用软件在系统中建立容器化环境。系统构建的步骤如下：

使用Kubernetes和Docker软件建立容器化的系统环境，管理容器之间的运行状态和更新操作，提供高质量的服务环境。在服务器主机上部署Prometheus服务端和Grafana软件，作为收集索引和可视化展示的监控工具。在边缘计算设备上部署Prometheus NodeExporter软件，收集每个设备的内部系统参数指标，并返回给Prometheus服务端并存储到TSDB中。Grafana软件直观地呈现边缘计算设备的资源使用状态。

图2为本发明实施例的Kubernetes集群架构图，本发明利用开源软件构建一个容器化的系统环境。首先用Kubernetes软件和Docker软件建立服务器主机和边缘设备的集群环境，并构建异构边缘计算系统，如图2所示。将服务器主机作为集群中的主节点，而边缘设备作为集群工作节点，提供在边缘设备上服务分配的时间表。主节点充当Kubernetes集群的主要控制器。

主节点的组件介绍如下：

API服务器：API服务器组件是最重要也是最基础的服务之一。该组件允许用户为Kubernetes配置工作负载。该组件还负责确保etcd存储和部署容器的服务之间的一致性。此外，它还充当各个组件之间的桥梁，传递信息与指令以维持集群的健康状态。API服务器提供了RESTful API接口，从而多种工具很容易通过RESTful API与之通信。它作为本地主机和Kubernetes集群交互的默认方法，即为kubectl的客户端。

Etcd：etcd是一个分布式系统的调度器。etcd作为Kubernetes的主要数据存储组件，存储和复制所有Kubernetes集群的状态。该组件用于利于维护集群状态的领导选举和分布式锁定的功能。etcd可以配置在单台服务器上，也可以用于多台机器组成的集群之间。

Controller-Manager：Controller manager组件，负责处理和管理任务。控制器负责调节集群的状态、管理工作的生命周期并执行日常任务。Controller manager管理不同的控制器。

Scheduler：即调度器组件负责将工作负载到集群的特定节点。调度器还负责跟踪每个主机的可用容量，以确保工作负载不大于主机的可用资源。其次调度器组件也必须知道已分配给每个服务器的现有工作负载的总容量和资源。

工作节点包含的组件如下：

Kubelet：该组件负责与Controller manager传输信息。它与Etcd存储交互从而读取配置项的值或者设置新配置项的值。此外，Kubelet服务还与集群中的组件通信并进行身份验证，从而接收命令。Kubelet组件负责维护服务器上程序的工作状态，根据需要，控制容器的启动和销毁。

代理(proxy)：每个工作节点都需要运行代理服务，从而管理工作节点的网络分段。代理组件将请求转发到正确的容器实现负载均衡。该组件通常负责确保网络环境是可访问的，但服务之间在一定的情况下是隔离的。

容器运行时间(container runtime)：容器运行时间是每个节点必须具备的基础组件。通常可以通过安装和运行Docker满足该要求。

在本发明的一个实施例中，基于主节点和工作节点的主要组件，在整个集群系统中部署服务的过程。首先，当集群在工作节点上调度服务时，用户通过kubectl输入指令来建立Pod。用户验证指令并将它们传递到主节点中的API服务器，该服务器将指令备份到etcd。其次，controller manager收到来自API server的消息，接收到创建一个新的pod的任务，继而检查资源，根据资源容量，判断是否会构建新的pod。最后，当调度器定期访问API服务器时，它会询问控制器管理器是否已经构建或找到了新的pod。调度器负责将pod分配到最合适的节点。Kubernetes会自动完成后续的部署动作。

示例性地，Kubernetes集群分为一个Master主节点和若干NODE节点；

示例性地，Kubernetes调度最小单位(运行最小单元)是pod，pod中包含很多container(容器)。

示例性地，Pod中运行一个容器，最经常使用的模式，Container封装在pod中调度，两者几乎等同，但k8s不直接管理容器。Pod中运行多个容器，多个容器封装在pod中一起调度，适用于容器之间有数据交互和调用的场景，如app+redis，pod内部共享相同的网络命名空间，存储命名空间，进程命名空间。

可以理解的是，Service的服务进程目前都是基于Socket通信方式对外提供服务，比如Redis、Memcache、MySQL、Web Server，或者是实现了某具体业务的一个特定的TCPServer进程，虽然一个Service通常由多个相关的服务进程来提供服务，每个服务进程都有一个独立的Endpoint(P+Pot)访间点，但Kubernetes能够让我们通过服务连接到指定的Service上，有了Kubernetes的透明负载均衡和故障饮复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故而重新部署到其他机器，都不会影响正常调用，更重要的是这个Service本身一旦创建就不会发生变化，意味着在Kubemetes集群中，不用为了服务的IP地址的变化问题而头疼容器提供了强大的隔离功能，所有有必要把为Service提供服务的这组进程放入容器中进行隔离。为此，Kubernetes设计了Pod对象，将每个服务进程包装到相对应的Pod中，使其成为Pod中运行的一个容器。为了建立SeiceSPod间的关联管理，Kubemetes给每Pod贴上一人标签Label，比如运行MySL的Pod上name＝mys标签，给运行PHP的Pod5上name＝php标签，然后给相应的Service定义标签选择器Label Selector，这样就能巧妙的解决了Service于Pod的关联问题在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node，其中，在Master节点运行着集群管理相关的一进程kube-aDiserer、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩安全控制、系统监控和纵错等管理能力，并目都是全自动完成的。Node作为集群中的工作节点，运行真正的应用程序，在Node上Kuberetes管理的最小运行单元是Pod，Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控和重启。

可以理解的是，k8s集群的管理节点，负责管理集群，提供集群的资源教据访问入口。拥有Etcd存储服务(可选)，行Api Server进程，ControllerManager服务进程及Scheduler服务进程，关联工作节点Node。Kubemnetes APl server提供HTTP Rest接口的关键服务进程，是Kubemetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程；Kubemetes Controller Manager是Kubemnetes所有资源对象的自动化控制中心；Kubernetes Schedule是负责资源调度(Pod调度)的进程。

可以理解的是，Node是Kubernetes集群架构中运行Pod的服务节点(亦叫agen域minion)。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息，运行docker eninge服务，守护进程kunelet负载均衡器kube-proxy。

可以理解的是，Pod运行于Node节点上，若干相关容器的组合。Pod内包合的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhos进行通。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。Pod其实有两和类型：普通Pod和静态Pod，后者比较特殊，它并不存在Kubemetes的etcd存储中，而是存放在某个具体的Node上日个具体文件中，并且只在此Node上启动。普通Pod一旦被创建，就会被放入etcd存储中，随后会被Kubernetes Master调度到摸个具体的Node上进行绑定，随后亥Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器水启动起来，在在默认情况下，当Pod里的某个容器停止时，Kubemetes会自动检测到这个问起并且重启这个Pod(重信Pod里的所有容器)，如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。

示例性地，本发明在边缘设备上需搭建监控系统，用于收集异构边缘设备资源指标的所有数据。监控系统使用Node Exporter服务收集数据，并提供标准格式的索引给Prometheus并存储在Prometheus上。设备的资源指标包括CPU使用率、内存使用率以及系统负载。

示例性地，获取的数据转换为时间序列存储到Prometheus中。时间序列数据格式包括指标名称和相关标签用于区分相同时间序列的数据的差异性。

示例性地，Prometheus采集和存储数据后，在服务器上部署Grafana开源软件，为边缘设备的不同资源指标提供可视化环境，从而监控和评估边缘设备的资源使用情况。

示例性地，针对收集的多种数据，本发明在Master节点Controller Manager根据混合性能评估方案分析预测后续执行状态和资源需求。

μ＝μ_b+a/λ

μ是每个容器的处理速度，μ_b是每个容器平均处理速率，λ是实时请求到达速率，a是实时请求到达速率的反比系数。

其中和/>是N个容器内存占用率和CPU占用率供低于求的速度，/>和则是供大于求的速度。

则整个系统中没有实时请求速率的概率为：

则等待队列中的请求速率和容器的处理速率的期望值为：

则请求平均响应时间的期望值为：

同时，当前的请求平均响应时间也受历史数据影响。因此在本发明中第k步平均响应时间y_k是历史数据与当前响应时间的权重之和。

y_k＝b×y_k-1+(1-b)×W_s(N,λ,μ)

针对第k步的弹性伸缩操作，本发明在相同响应时间的情况下，选择成本较低的操作。

根据本发明实施例的基于异构边缘计算系统的资源监控和性能评估的方法，采用速率变化的排队模型和线性模型混合模型来更准确的评估动态多容器性能，达到系统成本和系统稳健性的最优状态。综合对cpu利用率、内存利用率、历史请求响应时间及实时请求响应时间多变量评估服务Pod。利用优化K8s架构中Master节点的Controller manager分析，并使用网络拓扑信息来调度Pod服务，避免已知潜在不稳定因素。

为了实现上述实施例，如图3所示，本实施例中还提供了基于异构边缘计算系统的资源监控和性能评估的装置10，该装置10包括：异构系统构建模块100、资源指标获取模块200、数据转换传输模块300和资源监控评估模块400；

异构系统构建模块100，用于获取服务器主机和边缘设备的集群环境信息，并基于所述集群环境信息构建所述异构边缘计算系统；

资源指标获取模块200，用于利用索引收集微程序收集异构边缘设备的资源指标，并通过实时索引建立所述索引收集微程序与所述异构边缘计算系统之间的数据连接通道；

数据转换传输模块300，用于通过所述数据连接通道对所述资源指标进行数据传输，并将所述资源指标转换为时间序列存储于所述异构边缘计算系统中以得到数据存储结果；

资源监控评估模块400，用于利用所述服务器主机以基于混合性能评估方案对所述数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果。

进一步地，资源指标，包括CPU使用率、内存使用率以及系统负载中的多种；时间序列的数据格式包括，资源指标名称和相关标签。

进一步地，上述资源指标获取模块200，还用于分别将所述服务器主机作和所述边缘设备做为集群环境中的主节点和工作节点；其中，所述主节点的组件，包括API服务器、调度器、控制器管理组件和调度程序；所述工作节点的组件，包括信息传输组件、代理组件和容器运行时间组件。

进一步地，上述异构系统构建模块100，还用于：

当所述工作节点进行调度服务时，将指令输入所述信息传输组件建立第一运行资源，并基于指令验证通过结果将第一运行资源传输到主节点中的API服务器中；

利用控制器管理组件接收到来自API服务器的创建第二运行资源的任务，并根据检测的任务资源容量判断是否构建所述第二运行资源；

当调度器访问API服务器时，判断所述控制器管理组件是否已经构建所述第二运行资源，以根据判断结果利用调度器对构建的所述第二运行资源进行对应节点分配以构建异构边缘计算系统。

进一步地，上述资源监控评估模块400，还用于：

根据所述混合性能评估方案在所述主节点的控制器管理组件中分析预测执行状态和资源需求：

μ＝μ_b+a/λ

μ是每个容器的处理速度，μ_b是每个容器平均处理速率，λ是实时请求到达速率，a是实时请求到达速率的反比系数；

其中和/>是N个容器内存占用率和CPU占用率供低于求的速度，/>和则是供大于求的速度；

系统中没有实时请求速率的概率为：

等待队列中的请求速率和容器的处理速率的期望值为：

请求平均响应时间的期望值为：

第k步平均响应时间y_k是历史数据与当前响应时间的权重之和：

y_k＝b×y_k-1+(1-b)×W_s(N,λ,μ)。

根据本发明实施例的基于异构边缘计算系统的资源监控和性能评估的装置，采用速率变化的排队模型和线性模型混合模型来更准确的评估动态多容器性能，达到系统成本和系统稳健性的最优状态。综合对cpu利用率、内存利用率、历史请求响应时间及实时请求响应时间多变量评估服务Pod。利用优化K8s架构中Master节点的Controller manager分析，并使用网络拓扑信息来调度Pod服务，避免已知潜在不稳定因素。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

Claims (10)

1.一种基于异构边缘计算系统的资源监控和性能评估的方法，其特征在于，包括以下步骤：

获取服务器主机和边缘设备的集群环境信息，并基于所述集群环境信息构建所述异构边缘计算系统；

利用索引收集微程序收集异构边缘设备的资源指标，并通过实时索引建立所述索引收集微程序与所述异构边缘计算系统之间的数据连接通道；

通过所述数据连接通道对所述资源指标进行数据传输，并将所述资源指标转换为时间序列存储于所述异构边缘计算系统中以得到数据存储结果；

利用所述服务器主机以基于混合性能评估方案对所述数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果。

2.根据权利要求1所述的方法，其特征在于，所述资源指标，包括CPU使用率、内存使用率以及系统负载中的多种；所述时间序列的数据格式包括，资源指标名称和相关标签。

3.根据权利要求2所述的方法，其特征在于，分别将所述服务器主机作和所述边缘设备做为集群环境中的主节点和工作节点；其中，所述主节点的组件，包括API服务器、调度器、控制器管理组件和调度程序；所述工作节点的组件，包括信息传输组件、代理组件和容器运行时间组件。

4.根据权利要求3所述的方法，其特征在于，基于所述集群环境信息构建所述异构边缘计算系统，包括：

当所述工作节点进行调度服务时，将指令输入所述信息传输组件建立第一运行资源，并基于指令验证通过结果将第一运行资源传输到主节点中的API服务器中；

利用控制器管理组件接收到来自API服务器的创建第二运行资源的任务，并根据检测的任务资源容量判断是否构建所述第二运行资源；

当调度器访问API服务器时，判断所述控制器管理组件是否已经构建所述第二运行资源，以根据判断结果利用调度器对构建的所述第二运行资源进行对应节点分配以构建异构边缘计算系统。

5.根据权利要求3所述的方法，其特征在于，利用所述服务器主机以基于混合性能评估方案对所述数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果，包括：

根据所述混合性能评估方案在所述主节点的控制器管理组件中分析预测执行状态和资源需求：

μ＝μ_b+a/λ

μ是每个容器的处理速度，μ_b是每个容器平均处理速率，λ是实时请求到达速率，a是实时请求到达速率的反比系数；

其中和/>是N个容器内存占用率和CPU占用率供低于求的速度，/>和/>则是供大于求的速度；

系统中没有实时请求速率的概率为：

等待队列中的请求速率和容器的处理速率的期望值为：

请求平均响应时间的期望值为：

第k步平均响应时间y_k是历史数据与当前响应时间的权重之和：

y_k＝b×y_k-1+(1-b)×W_s(N，λ，μ)。

6.一种基于异构边缘计算系统的资源监控和性能评估的装置，其特征在于，包括：

异构系统构建模块，用于获取服务器主机和边缘设备的集群环境信息，并基于所述集群环境信息构建所述异构边缘计算系统；

资源指标获取模块，用于利用索引收集微程序收集异构边缘设备的资源指标，并通过实时索引建立所述索引收集微程序与所述异构边缘计算系统之间的数据连接通道；

数据转换传输模块，用于通过所述数据连接通道对所述资源指标进行数据传输，并将所述资源指标转换为时间序列存储于所述异构边缘计算系统中以得到数据存储结果；

资源监控评估模块，用于利用所述服务器主机以基于混合性能评估方案对所述数据存储结果中的资源指标进行进行监控和评估得到资源监控评估结果。

7.根据权利要求6所述的装置，其特征在于，所述资源指标，包括CPU使用率、内存使用率以及系统负载中的多种；所述时间序列的数据格式包括，资源指标名称和相关标签。

8.根据权利要求7所述的装置，其特征在于，所述资源指标获取模块，还用于分别将所述服务器主机作和所述边缘设备做为集群环境中的主节点和工作节点；其中，所述主节点的组件，包括API服务器、调度器、控制器管理组件和调度程序；所述工作节点的组件，包括信息传输组件、代理组件和容器运行时间组件。

9.根据权利要求8所述的装置，其特征在于，所述异构系统构建模块，还用于：

当所述工作节点进行调度服务时，将指令输入所述信息传输组件建立第一运行资源，并基于指令验证通过结果将第一运行资源传输到主节点中的API服务器中；

利用控制器管理组件接收到来自API服务器的创建第二运行资源的任务，并根据检测的任务资源容量判断是否构建所述第二运行资源；

当调度器访问API服务器时，判断所述控制器管理组件是否已经构建所述第二运行资源，以根据判断结果利用调度器对构建的所述第二运行资源进行对应节点分配以构建异构边缘计算系统。

10.根据权利要求8所述的装置，其特征在于，所述资源监控评估模块，还用于：

根据所述混合性能评估方案在所述主节点的控制器管理组件中分析预测执行状态和资源需求：

μ＝μ_b+a/λ

μ是每个容器的处理速度，μ_b是每个容器平均处理速率，λ是实时请求到达速率，a是实时请求到达速率的反比系数；

其中和/>是N个容器内存占用率和CPU占用率供低于求的速度，/>和/>则是供大于求的速度；

系统中没有实时请求速率的概率为：

等待队列中的请求速率和容器的处理速率的期望值为：

请求平均响应时间的期望值为：

第k步平均响应时间y_k是历史数据与当前响应时间的权重之和：

y_k＝b×y_k-1+(1-b)×W_s(N，λ，μ)。