CN113747506A - 一种资源调度方法、装置和网络系统 - Google Patents

一种资源调度方法、装置和网络系统 Download PDF

Info

Publication number
CN113747506A
CN113747506A CN202010469738.8A CN202010469738A CN113747506A CN 113747506 A CN113747506 A CN 113747506A CN 202010469738 A CN202010469738 A CN 202010469738A CN 113747506 A CN113747506 A CN 113747506A
Authority
CN
China
Prior art keywords
server
data
performance
user experience
terminal devices
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010469738.8A
Other languages
English (en)
Inventor
李林锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010469738.8A priority Critical patent/CN113747506A/zh
Publication of CN113747506A publication Critical patent/CN113747506A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请实施例提供了一种资源调度方法、装置及系统，能够在应用程序首发上线时，采集终端设备的用户体验数据和服务端的服务端性能数据，其中，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；然后根据用户体验数据和服务端性能数据这两方面的数据综合判断服务端是否出现性能不足，并且在服务端出现性能不足时，根据性能基准数据准确地确定需要增加的实例节点的数量。由此，本申请实施例的技术方案能够实现对服务端及时、准确地扩容，消除服务端的性能不足状态，避免服务端出现宕机，提高应用程序首发上线时的用户使用体验。

Description

一种资源调度方法、装置和网络系统
技术领域
本申请涉及计算机技术领域，尤其涉及一种资源调度方法、装置和网络系统。
背景技术
手机、平板电脑、个人电脑(PC)等各类终端设备可以安装各种应用程序APP，安装有应用程序的终端设备可以与该应用程序的运营商提供的服务端建立网络连接，进行数据交互，以实现各种应用功能。
终端设备与服务端的数据交互会产生数据流量，一般来说，应用程序的用户规模越大，同时在线的终端设备的数量越多，服务端承受的数据流量越大，服务端资源的占用率越高，因此，为了保证服务端平稳运行，运维人员通常会根据用户规模去相应地配置服务端资源。然而，当应用程序首次发布时，运维人员通常缺乏用户规模数据，因此无法对应用程序首发上线后的流量进行准确地预测，进而无法确定要投入的服务端的规模。
在这种情况下，如果投入的服务端资源较少，而应用程序首发上线后的数据流量非常大，那么服务端就会由于受到巨大流量冲击而出现性能不足甚至宕机，导致应用程序出现运行卡顿、无法连接服务端、无法登陆、时延(ping值)过高等情况，严重影响用户使用体验，降低用户对首发应用程序的使用体验，导致用户流失。
发明内容
本申请实施例提供了一种资源调度方法、装置和网络系统，能够在应用程序首发上线时，及时准确地为应用程序调度服务端资源，以避免服务端出现性能不足或者宕机，提高应用程序首发上线时的用户使用体验。
第一方面，本申请实施例提供了一种资源调度方法。该方法包括：从安装有目标应用程序APP的终端设备获取目标APP的用户体验数据，以及，从目标APP的服务端获取服务端性能数据，其中，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足；当服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备数量；根据服务端需要增加的实例节点的数量增加服务端的实例节点。
这样，在应用程序首发上线时，本申请实施例的资源调度方法能够采集终端设备的用户体验数据和服务端的服务端性能数据，然后根据用户体验数据和服务端性能数据这两方面的数据综合判断服务端是否出现性能不足，并且在服务端出现性能不足时，根据性能基准数据准确地确定需要增加的实例节点的数量，从而实现对服务端及时、准确地扩容，消除服务端的性能不足状态，避免服务端出现宕机，提高应用程序首发上线时的用户使用体验。
在一种可选择的实现方式中，用户体验数据是由安装于终端设备的数据采集软件开发工具包SDK采集的。
在一种可选择的实现方式中，数据采集SDK通过自身的用户体验数据上报应用程序接口API获取目标APP上报的用户体验数据。
在一种可选择的实现方式中，目标APP用于将生成的用户体验数据存储在第一日志文件中，数据采集SDK通过监听第一日志文件或第一日志文件所在的目录以采集用户体验数据。
在一种可选择的实现方式中，服务端性能数据是由安装于服务端的数据采集软件代理程序agent采集的。
在一种可选择的实现方式中，数据采集agent通过自身的性能数据上报API获取服务端上报的服务端性能数据。
在一种可选择的实现方式中，服务端用于将生成的服务端性能数据存储在第二日志文件中，数据采集agent用于监听第二日志文件或第二日志文件所在的目录以采集服务端性能数据。
在一种可选择的实现方式中，根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足，包括：将用户体验数据和/或服务端性能数据中的一个或者多个指标值与其对应的阈值进行匹配，根据匹配结果判断服务端是否出现性能不足。
在一种可选择的实现方式中，当用户体验数据和/或服务端性能数据中的至少一个指标值超出其对应的阈值所限定的范围时，服务端性能不足。
在一种可选择的实现方式中，当服务端的实例节点的数量减1之后与性能基准数据的乘积大于当前在线的终端设备数量时，服务端性能过剩。
在一种可选择的实现方式中，用户体验数据和/或服务端性能数据包括一个或者多个时延类指标值和一个或者多个资源占用类指标值，每个时延类指标值对应一个时延类阈值，每个资源占用类指标值对应一个资源占用类阈值。
在一种可选择的实现方式中，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，包括：将当前在线的终端设备数量除以性能基准数据，再减去服务端的实例节点的数量，得到预测的需要调整的服务端实例节点的数量；当预测的需要调整的服务端实例节点的数量大于或者等于1时，将预测的需要调整的服务端实例节点的数量取整作为服务端需要增加的实例节点的数量。
在一种可选择的实现方式中，该方法还包括：当预测的需要调整的服务端实例节点的数量小于或者等于-1时，将预测的需要调整的服务端实例节点的数量的绝对值取整作为需要减少的服务端实例节点的数量。
在一种可选择的实现方式中，该方法还包括：将服务端的实例节点的数量与性能基准数据相乘，得到服务端理论上支持的终端设备数量；如果当前在线的终端设备数量小于服务端理论上支持的终端设备数量，并且服务端出现性能不足，则减小性能基准数据的取值。
在一种可选择的实现方式中，减小性能基准数据的取值，包括：周期性地减小性能基准数据的取值，每次减小之后的性能基准数据的取值等于减小之前的性能基准数据的取值乘以经验系数，经验系数大于0并且小于1。
在一种可选择的实现方式中，该方法还包括：当服务端解除性能不足状态时，将服务端当前的实例节点数量能够支持的终端设备数量保存在策略仓库中，所策略仓库包括服务端在不同实例节点数量下能够支持的终端设备数量。
在一种可选择的实现方式中，该方法还包括：当服务端性能不足时，根据当前在线的终端设备数量从策略仓库中确定要增加的实例节点的数量。
第二方面，本申请实施例还提供了一种资源调度装置，该装置包括：收发器、存储器和处理器；其中，存储器包括有程序指令，程序指令被处理器运行时，使得装置用于执行如下步骤：从安装有目标应用程序APP的终端设备获取目标APP的用户体验数据，以及，从目标APP的服务端获取服务端性能数据，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足；当服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备数量；根据服务端需要增加的实例节点的数量增加服务端的实例节点。
进一步地，本申请实施例提供的装置，还可以执行前述第一方面的其他实施方式。
第三方面，本申请实施例还提供了一种网络系统，该系统包括：目标APP的服务端、安装有目标APP的终端设备，以及资源调度装置；其中，终端设备，用于向资源调度装置发送目标APP的用户体验数据，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据；服务端，用于向资源调度装置发送服务端性能数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；资源调度装置，用于根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足；资源调度装置，还用于当服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备数量；资源调度装置，还用于根据服务端需要增加的实例节点的数量增加服务端的实例节点。
第四方面，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。
第五方面，本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面的方法。
第六方面，本申请实施例还提供了一种芯片系统，该芯片系统包括处理器，用于支持上述装置或系统实现上述方面中所涉及的功能，例如，生成或处理上述方法中所涉及的信息。
附图说明
图1是服务端与终端设备的网络连接示意图；
图2是应用程序的用户数量与服务端的数据流量的关系图；
图3是一些影响用户使用体验的场景示意图；
图4目前一种在应用首发上线时对服务端进行扩容和缩容的示意图；
图5目前另一种在应用首发上线时对服务端进行扩容和缩容的示意图；
图6是本申请实施例提供的一种用于实现资源调度方法的装置示意图；
图7是本申请实施例提供的用于实现资源调度方法的装置的一种部署示意图；
图8是本申请实施例提供的一种资源调度方法的流程图；
图9是本申请实施例提供的一种终端设备上报用户体验数据的示意图；
图10是本申请实施例提供的一种服务端上报服务端性能数据的示意图；
图11是本申请实施例示出的健康度模型的结构示意图；
图12是性能基准数据库包括多个性能基准数据时对应的应用场景的示意图；
图13是本申请实施例提供的一种修正性能基准数据的流程图；
图14是本申请实施例提供的借助策略仓库实现资源调度的方法流程图；
图15是本申请实施例提供的一种资源调度装置的结构示意图；
图16是本申请实施例提供的一种网络系统的结构示意图；
图17是本申请实施例提供的一种芯片系统的结构示意图。
具体实施方式
以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
手机、平板电脑、个人电脑(PC)等各类终端设备可以安装各种应用程序APP。安装有应用程序的终端设备可以与该应用程序的运营商提供的服务端建立网络连接，并且通过与服务端的数据交互获取应用程序运行所需的资源和信息。
图1是服务端与终端设备的网络连接示意图。如图1所示，用户可以从终端设备11内置的应用市场程序13、应用程序运营商提供的下载链接、以及第三方应用市场或者下载链接等多种可选择的渠道下载应用程序并且安装到终端设备11中。一款应用程序会被许多用户安装到其使用的终端设备11中，并且这些用户可能会在同一时刻使用这个应用程序，因此服务端12在同一时刻会同时与多个终端设备11建立网络连接。其中，服务端12可以是应用程序的运营商提供的服务器或服务器集群(多个服务器)，也可以是云服务器运营商(例如：华为云、阿里云、腾讯云、微软Azure等)为应用程序的运营商提供的云服务器，本申请实施例对此不作具体限定。终端设备11例如可以包括手机、平板电脑、个人电脑、工作站设备、大屏设备(例如：智慧屏、智能电视等)、掌上游戏机、家用游戏机、虚拟现实设备、增强现实设备、混合现实设备等，本申请实施例对此不做具体限定，能够安装应用程序并且与服务端12建立连接的设备都属于本申请实施例的终端设备11。可以理解的是，从服务端12到终端设备11之间的链路上通常还会包括交换机、路由器、负载均衡器等节点设备，而图1为了便于描述服务端12和终端设备11的连接关系未将这些节点示出。
本申请实施例中的应用程序可以包括游戏应用和非游戏应用，其中，非游戏应用包括但不限于：媒体类应用(例如短视频应用、音乐类应用、直播类应用、影音类应用等)、社交类应用(例如即时通信类应用、社交网络应用、微博客应用等)、购物类应用、票务类应用、理财类应用、生活服务类应用(例如打车应用、地图应用、外卖应用)等。
以游戏应用为例，当用户在终端设备11打开一款游戏应用时，终端设备11会与其服务端12建立网络连接，以从服务端12获取游戏应用运行时所需的资源(例如地图资源、角色资源、UI资源等)，以及处理用户在游戏应用运行过程中的输入。由此可见，在应用程序运行期间，终端设备11与应用程序的服务端12之间会产生数据流量。
一般来说，一款应用程序的服务端所承受的数据流量与应用程序的在线用户数量(即同时使用该应用程序的用户数量)有关。如图2所示，通常，同时使用该应用程序的用户数量越多，与服务器连接的终端设备的数量就越多，服务端承受的数据流量就越大；同时使用该应用程序的用户数量越少，与服务器连接的终端设备的数量就越少，服务端承受的数据流量就越小。另外，服务端在收发和处理数据流量时需要占用一定的服务端资源，例如处理器资源、内存资源(例如RAM资源)和I/O资源。一般而言，数据流量越大，服务端资源的占用率越高，数据流量越小，服务端资源的占用率越低。
一般而言，由于服务端资源通常是有限的，当服务端承受的数据流量远低于自身的处理能力时，服务端会出现系统资源过剩，当服务端承受的数据流量超出了自身的处理能力时，服务端会出现资源不足甚至宕机。为了避免上述情况发生，应用程序的运营商会统计应用程序的用户规模，然后根据应用程序的用户规模确定要投入的服务端的规模，从而既避免服务端出现资源过剩，也避免服务端出现资源不足，使得服务端和应用程序两端均能够平稳运行。
但是，当应用程序首次发布(首发)时，运营商通常缺乏用户规模数据而无法对应用程序首发上线后的流量进行准确地预测，因此无法确定要投入的服务端的规模。在这种情况下，如果投入的服务端资源较少，而应用程序首发上线后的数据流量非常大，那么服务端就会由于受到流量冲击而导致宕机，导致终端设备一侧的应用程序出现运行卡顿、无法连接服务端、无法登陆、时延(ping值)过高等情况，严重影响用户使用体验，降低用户对首发的应用程序的第一印象，导致用户流失。
图3中示出了一些影响用户使用体验的场景。在图3的场景a中，如果服务端资源不足或者宕机，当用户在游戏中切换新的场景时，游戏应用可能会由于无法从服务端获得加载场景所需的游戏资源而游戏界面出现卡顿，导致游戏帧数FPS较低。在图3的场景b中，如果服务端资源不足或者宕机，当用户启动游戏时，游戏应用可能会由于无法连接到服务端而停留在启动界面，并且一直出现转圈圈的动画。在图3的场景c中，如果服务端资源不足或者宕机，用户在游戏登录界面输入账号和密码并且点击登录之后，游戏应用可能会由于无法连接到服务端而出现登录失败或者排队的现象，无法正常登录到游戏中。在图3的场景d中，如果服务端资源不足或者宕机，游戏应用与服务端的数据传输不通畅，会导致游戏在运行过程中出现时延过高、延迟波动大、丢包等现象，影响用户使用体验。
需要补充说明的是，本申请实施例中的“应用程序首次发布”可以包括从未发布过的应用程序发布第一个版本，以及已经发布过的应用程序发布新的版本。本申请实施例中的“发布”至少可以包括两种形式；一种形式是应用程序上架到应用市场，例如：Google公司提供的Play商店、华为公司提供的App Gallery、三星公司提供的Galaxy Apps商店等，这种形式例如可以发生在运行有Android操作系统、iOS操作系统、iPad OS操作系统、Mac OS操作系统、Harmony OS(鸿蒙)操作系统、window mobile操作系统以及其他操作系统的电子设备中，上述操作系统一般包含应用市场，并且用户主要从应用市场获取应用程序；另一种形式是运营商在因特网中提供应用程序的下载链接，使得用户可以通过下载链接将应用程序下载到终端设备本地并安装，这种形式例如可以发生在windows操作系统或者前述任意操作系统中。
如图4所示，为了提高应用程序首发时的用户体验，目前一些运营商在应用程序首发之前会在终端设备的应用市场或者特定的网页发布应用程序的预约页面，并且邀请有意愿体验应用程序的潜在用户参加预约。这样，根据预约的用户规模，运营商的运维人员就可以对应用程序首发上线之后的数据流量规模进行评估，并且准备好相应的服务端资源。在应用程序首发上线之后，运营商的运维人员可以利用运维系统查看应用程序的运维指标数据和舆情信息，并且根据运维指标数据和舆情信息判断是否需要对服务端进行扩容。如果从运维指标数据和舆情信息反映出应用程序出现了运行卡顿等影响用户体验的情况，则需要对服务端进行扩容，此时运维人员可以准备相应的服务器硬件资源、部署软件、启动操作系统、将新的服务器加入生产环境中。扩容完成之后，运维人员可以继续监控应用程序的运维指标数据和舆情信息，判断扩容效果，如果扩容效果没有达到预期，则继续扩容。其中，舆情信息例如可以包括用户在应用程序内的公共聊天系统中发布的聊天内容、用户在应用市场对该应用程序的评价内容、打分内容，以及用户在各大论坛、社区、贴吧对该应用程序的讨论内容等。然而，由于上述方法基于运维人员的人工操作对服务端进行扩容，并且操作步骤繁琐，因此效率较低；并且，人工操作依赖于运维人员的经验，扩容效果难以保证；另外，由于应用程序首发时往往会带来瞬时的流量高峰，因此，如果运维人员不能够在短时间内判断服务端需要扩容以及完成扩容操作，服务端很可能被瞬时流量冲垮，造成严重损失。
为了克服人工扩容方式的不足，如图5所示，一些使用云服务器的运营商还可以利用云服务器提供商的弹性伸缩服务来采集服务器的CPU、内存和网络I/O等资源指标，根据这些指标及其对应的弹性阈值来触发弹性伸缩策略，从而实现云服务器的扩容和缩容。然而，弹性伸缩服务所监控服务器的CPU、内和网络I/O等指标并不能完整地反映出服务器的状态，例如当服务器的业务架构设计不合理时，即使服务器资源占用不高，但是服务器也可能已经达到了最大的处理能力。并且，由于从终端设备到服务端的链路上还包括路由器、交换机、负载均衡器等节点设备，因此服务端资源指标也无法准确反映出应用程序在终端设备的真实用户体验。
为了能够在应用程序首发上线时，及时、准确地为应用程序分配服务端资源，避免服务端宕机或者资源浪费，本申请实施例提供了一种资源调度方法，下面结合具体场景和示例对该方法进行具体描述，在以下描述中，应用程序即对应权利要求书中的目标应用程序。
本申请实施例提供的资源调度方法可以基于图6所示的装置架构实现。如图6所示，该装置包括：数据采集模块21、数据分析模块22和执行模块23。
数据采集模块21可以包括客户端数据采集模块211和服务端数据采集模块212，客户端数据采集模块211可以用于采集应用程序的用户体验数据，用户体验数据也可称为APP运维指标/数据、关键绩效指标(key performance indicators，KPI)指标等，用户体验数据可以包括应用程序运行期间生成的与服务端性能有关的一个或者多个指标值，例如：应用程序的界面卡顿时间、应用程序时延、应用程序对服务端的接口调用时延、接口调用成功率、应用程序的无响应次数等。服务端数据采集模块212可以用于采集服务端的服务端性能数据，服务端性能数据可称为服务端(器)运维数据等，服务端性能数据可以包括服务端的资源使用数据和/或接口性能数据，其中，资源使用数据例如可以包括服务端的CPU使用率、内存使用率和/或网络I/O接口流量等一个或者多个指标值，接口性能数据例如可以包括服务端的数据吞吐量、服务端时延和/或服务端对应用程序的接口调用成功率等一个或者多个指标值。
数据分析模块22可以包括健康度模型221、性能基准数据库222和策略仓库223。健康度模型221用于通过用户体验数据、服务端性能数据、以及与用户体验数据、服务端性能数据相关的阈值来描述应用程序的运行状态。性能基准数据库222用于存储和管理性能基准数据，其中，性能基准数据例如可以包括服务端的单个实例节点能够支持的终端设备的数量。策略仓库223，用于在服务端完成扩容(例如增加服务端的实例数量)和缩容(例如减小服务端的实例数量)并且解除性能不足状态而平稳运行之后，获取不同在线终端设备数量所需要的服务端实例的数量并保存，以便后续使用。根据上述健康度模型221、性能基准数据库222和策略仓库223，数据分析模块22可以汇总用户体验数据和服务端性能数据，根据用户体验数据和所述服务端性能数据判断是否要对服务端进行扩容或者缩容，以及确定要增加或者减少的服务端实例的具体数量。
执行模块23用于执行服务端的扩容和缩容的动作，根据要增加或者减少的服务端实例的具体数量，增加或者减少服务端的实例节点。
本申请实施例中，实例节点(简称实例)可以包含CPU、内存、操作系统、网络、磁盘等最基础的计算组件，可以理解为服务端提供计算服务的最小单元。
图7是本申请实施例提供的上述用于实现资源调度方法的装置的一种部署示意图。如图7所示，客户端数据采集模块211可以与首发的应用程序集成在一起，安装部署到终端设备11中；服务端数据采集模块212可以安装部署在应用程序的服务端12，例如应用程序的后台服务器、服务器集群或者云服务器中；数据分析模块22和执行模块23可以部署在服务端12，例如在云服务器中分配一个实例节点，将数据分析模块22和执行模块23部署在该实例节点中，从而通过该实例节点调度其他的用于为应用程序提供服务的实例节点，实现服务端的扩容和缩容。
本申请实施例提供的一种资源调度方法，如图8所示，该方法可以包括以下步骤S101-S108：
步骤S101，数据分析模块从客户端数据采集模块获取应用程序的用户体验数据。
如图9所示，客户端数据采集模块可以包括与应用程序集成并且安装在终端设备中的数据采集软件开发工具包(software development kit，SDK)。数据采集SDK可以通过应用程序接口(application programming interface，API)调用和/或者监听日志的方式获取应用程序生成的用户体验数据。
示例地，当采用API调用的方式获取用户体验数据时，数据采集SDK可以包含预先设置的用户体验数据上报API。应用程序在采集到的用户体验数据之后，可以通过调用用户体验数据上报API的方式，将用户体验数据上报给数据采集SDK。具体实现中，应用程序可以根据预设的上报周期，例如1分钟、2分钟、3分钟等，定期调用用户体验数据上报API，将用户体验数据定期上报给数据采集SDK；或者，应用程序也可以实时调用用户体验数据上报API，将用户体验数据实时上报给数据采集SDK；或者，数据采集SDK也可以在需要采集用户体验数据时，向应用程序发送指示，使应用程序根据指示调用用户体验数据上报API，将用户体验数据上报给数据采集SDK。本申请实施例中，API调用的优点在于：应用程序在采集到的用户体验数据之后，可以将用户体验数据暂时缓存到终端设备的随机存取存储器(randomaccess memory，RAM)，即内存中，而不需要将用户体验数据写入到终端设备的闪存(flashmemory)或者磁盘中，因此性能更高。
示例地，当采用日志监听的方式获取用户体验数据时，应用程序可以将生成包含用户体验数据的日志文件，并且将日志文件保存在终端设备的闪存或者磁盘的预设目录中。数据采集SDK可以监听日志文件或者日志文件所在目录，监听日志文件是否有更新并且读取日志文件中更新的用户体验数据。具体实现中，数据采集SDK可以根据预设的读取周期，例如1分钟、2分钟、3分钟等，定期读取日志文件，以定期采集用户体验数据；或者，数据采集SDK也可以实时读取日志文件，以实时采集用户体验数据。
本申请实施例中，数据采集SDK可以通过超文本传输安全协议(hyper texttransfer protocol secure，HTTPS)、超文本传输协议(hypertext transfer protocol，HTTP)等传输协议与数据分析模块进行数据交互。例如，当采用HTTPS协议交互时，数据采集SDK可以通过调用数据分析模块预先配置的HTTPS接口，将用户体验数据上报给数据分析模块。示例地，数据采集SDK可以根据预设的上报周期，例如1分钟、2分钟、3分钟等，定期调用HTTPS接口，将用户体验数据上报给数据分析模块；或者，数据采集SDK也可以实时调用HTTPS接口，将用户体验数据实时上报数据分析模块。
步骤S102，数据分析模块从服务端数据采集模块获取服务端的服务端性能数据。
如图10所示，服务端数据采集模块可以包括运行于服务端的数据采集软件代理程序agent。数据采集agent可以通过API调用和/或者监听日志的方式获取服务端性能数据。
示例地，当采用API调用的方式获取服务端性能数据时，数据采集agent可以包含预先设置的服务端性能数据上报API。服务端在采集到的服务端性能数据之后，可以通过调用服务端性能数据上报API的方式，将服务端性能数据上报给数据采集agent。具体实现中，服务端可以根据预设的上报周期，例如1分钟、2分钟、3分钟等，定期调用服务端性能数据上报API，将服务端性能数据定期上报给数据采集agent；或者，服务端也可以实时调用服务端性能数据上报API，将服务端性能数据实时上报给数据采集agent；或者，数据采集agent也可以在需要采集服务端性能数据时，向服务端发送指示，使服务端根据指示调用服务端性能数据上报API，将服务端性能数据上报给数据采集agent。本申请实施例中，API调用的优点在于：服务端在采集到的服务端性能数据之后，可以将服务端性能数据暂时缓存到终端设备的随机存取存储器RAM中，而不需要将服务端性能数据写入到磁盘中，因此性能更高。
示例地，当采用日志监听的方式获取服务端性能数据时，服务端可以将生成包含服务端性能数据的日志文件，并且将日志文件保存在本地磁盘的预设目录中。数据采集agent可以监听日志文件或者日志文件所在目录，监听日志文件是否有更新并且读取日志文件中更新的服务端性能数据。具体实现中，数据采集agent可以根据预设的读取周期，例如1分钟、2分钟、3分钟等，定期读取日志文件，以定期采集服务端性能数据；或者，数据采集agent也可以实时读取日志文件，以实时采集服务端性能数据。
本申请实施例中，数据采集agent可以通过HTTPS、HTTP等传输协议与数据分析模块进行数据交互。例如，当采用HTTPS协议交互时，数据采集agent可以通过调用数据分析模块预先配置的HTTPS接口，将服务端性能数据上报给数据分析模块。示例地，数据采集AGENT可以根据预设的上报周期，例如1分钟、2分钟、3分钟等，定期调用HTTPS接口，将服务端性能数据上报给数据分析模块；或者，数据采集agent也可以实时调用HTTPS接口，将服务端性能数据实时上报数据分析模块。
需要补充说明的是，在本申请实施例中，步骤S101和步骤S102是并行发生的，顺序不分先后，也就是说，数据分析模块会同时从终端设备和服务端接收到用户体验数据和服务端性能数据，并对接收到的数据进行汇总分析。
步骤S103，数据分析模块根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足。
具体实现中，数据分析模块可以借助预先设置的健康度模型来判断服务端是否出现性能不足。图11是本申请实施例示出的健康度模型的结构示意图。该健康度模型可以包括用户体验数据模型、服务端性能数据模型和健康度阈值三部分组成。其中，用户体验数据模型可以用于记录用户体验数据中的各个指标值，例如：应用程序的界面卡顿时间、应用程序时延、应用程序的接口调用时延、接口调用成功率、应用程序界面无响应的次数等。服务端性能数据模型可以用于记录服务端性能数据中的各个指标值，例如：CPU使用率、内存使用率、网络I/O接口流量、服务端的数据吞吐量、服务端的接口调用时延、服务端的接口调用成功率等。其中，服务端性能数据模型可以将其记录的指标值分为两类，一类为资源类指标值，例如CPU使用率、内存使用率和网络I/O接口流量，另一类为业务性能类指标值。例如服务端的数据吞吐量、服务端的接口调用时延和服务端的接口调用成功率。健康度阈值可以包括各个指标值对应的阈值，该阈值可以用于对用户体验数据和服务端性能数据进行评价，以判断服务端是否出现性能不足或者性能过剩。
可选的，健康度阈值也可以被分为两类阈值，例如时延类阈值和资源占用类阈值。其中，时延类阈值对应用户体验数据中的各个指标值以及服务端性能数据中的部分指标值，资源占用类阈值对应服务端性能数据中的另一部分指标值。
示例地，一种健康度阈值的配置如表1所示(其中，ms为毫秒)：
Figure BDA0002513917250000081
Figure BDA0002513917250000091
表1
本申请实施例中，数据分析模块可以基于上述健康度模型，将用户体验数据和/或服务端性能数据中的一个或者多个指标值与其对应的阈值进行匹配，根据匹配结果判断服务端是否出现性能不足。具体来说，只要用户体验数据和/或服务端性能数据中的至少一个指标值超出其对应的阈值所限定的范围时，则认为服务端出现性能不足。
示例地，当应用程序时延的阈值为300ms时，如果应用程序的时延大于300ms，则认为服务端性能不足；当界面卡顿时间的阈值为1500ms时，如果应用程序的界面卡顿时间大于1500ms，则认为服务端性能不足；当应用程序的接口调用时延的阈值为300ms时，如果应用程序的接口调用时延大于300ms，则认为服务端性能不足；当应用程序的接口调用成功率的阈值为80％时，如果应用程序的接口调用成功率小于80％，则认为服务端性能不足；当应用程序的无响应次数的阈值为3次时，如果应用程序的无响应次数大于3次，则认为服务端性能不足；当服务端的接口调用时延的阈值为300ms时，如果服务端的接口调用时延大于300ms，则认为服务端性能不足；当服务端的接口调用成功率的阈值为80％时，如果服务端的接口调用成功率小于80％，则认为服务端性能不足；当服务端的CPU使用率的阈值为80％时，如果服务端的CPU使用率大于80％，则任务服务端性能不足；当网络I/O接口流量的阈值为900Mbps时，如果网络I/O接口流量大于900Mbps，则服务端性能不足；当服务端的数据吞吐量的阈值为900Mbps时，如果服务端的数据吞吐量大于900Mbps，则服务端性能不足。
另外，如果数据分析模块通过上述方式判断服务端没有出现性能不足的情况，则还可以根据服务端当前的实例节点的数量和服务端的性能基准数据performance判断服务端是否存在性能过剩。根据本申请实施例在先描述的内容，性能基准数据performance可以保存在数据分析模块的性能基准数据库中，性能基准数据performance记录了服务端的单个实例节点能够支持的终端设备的数量，那么，在一种实现方式中，如以下公式①所示，数据分析模块可以将服务端当前的实例节点数量N0减1之后与性能基准数据performance相乘，并将所得的乘积与当前在线的终端设备数量Nonline进行比较，如果所得的乘积大于当前在线的终端设备数量Nonline，则说明服务端性能过剩。
服务端性能过剩：(N0-1)*performance>Nonline ①
示例地，如果服务端当前的实例节点数量N0＝10，单个实例节点能够支持的终端设备的数量performance＝1000，当前在线的终端设备数量Nonline＝8000，那么，根据上述公式：
(10-1)*1000＝9000>8000因此，服务端性能过剩。
示例地，如果服务端当前的实例节点数量N0＝10，单个实例节点能够支持的终端设备的数量performance＝1000，当前在线的终端设备数量Nonline＝9500，那么，根据上述公式：
(10-1)*1000＝9000<9500因此，服务端性能没有过剩。
需要补充说明的是，本申请实施例中的性能基准数据库可以包括多个性能基准数据，每一个性能基准数据对应一种应用程序，表示单个实例节点作为该应用程序的服务端时，能够支持的终端设备的数量。
图12是性能基准数据库包括多个性能基准数据时对应的应用场景。如图12所示，应用程序的服务端可以构建在云服务器中，一般来说，云服务器提供商会将云服务器资源划分成大量的实例节点，然后将实例节点分配给不同的用户使用，因此云服务器中可能构建有多个应用程序的服务端。在这种情况下，如果将本申请实施例的装置中的数据分析模块构建和执行模块等在云服务器中，就可以使本申请实施例的方法对多个应用程序的服务端资源进行调度，为了实现这一目的，性能基准数据库中就需要包括多个性能基准数据，分别对应不同的应用程序。
示例地，性能基准数据库可以具有以下数据结构(每一行字段对应一个性能基准数据)：
{“appId”:“xxxxxxxx”,“performance”:“2000”,“growthIndex”,“0.99”}
{“appId”:“yyyyyyyy”,“performance”:“1500”,“growthIndex”,“0.98”}
{“appId”:“zzzzzzzzz”,“performance”:“1500”,“growthIndex”,“0.98”}
……
性能基准数据库中的每一行包括三个字段，构成一组数据，分别为：应用程序标识appId，用于识别不同的应用该程序，不同的应用程序具有不同的appId，appId可以是由数字、字母和符号中的至少一种组成的字符串；性能基准数据performance，表示单个实例节点支持的运行有该组应用程序的终端设备的数量；增长系数growthIndex，用于表示增加一个示例节点之后，实际能够增加支持的终端设备的数量；一般来说，因为系统损耗等原因，增长系数通常小于或者等于1并且大于0；示例地，当增长系数growthIndex＝0.99时，如果performance＝1000，那么每增加一个实例节点，实际增加支持的终端设备的数量为1000*0.99＝990个。
步骤S104，当服务端性能不足时，数据分析模块根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量。
具体实现中，如公式②所示，数据分析模块可以将当前在线的终端设备数量Nonline除以性能基准数据performance，再减去服务端的实例节点的数量N0，得到预测的需要调整的服务端实例节点的数量N。
N＝Nonline/performance-N0 ②
然后，数据分析模块可以根据N的取值来最终决策需要增加或者减少的服务端实例节点的数量。
一种可选的的决策过程如下(1)-(4)所示：
(1)当预测的需要调整的服务端实例节点的数量大于或者等于1时，即N＝[1，∞+)时，将预测的需要调整的服务端实例节点的数量取整作为服务端需要增加的实例节点的数量。
示例地，如果服务端当前的实例节点数量N0＝10，性能基准数据performance＝1000，当前在线的终端设备数量Nonline＝11200，那么，根据上述公式：
N＝11200/1000-10＝1.2取整得到服务端需要增加的实例节点的数量为1。
示例地，如果服务端当前的实例节点数量N0＝10，性能基准数据performance＝1000，当前在线的终端设备数量Nonline＝12300，那么，根据上述公式：
N＝12300/1000-10＝2.3取整得到服务端需要增加的实例节点的数量为2。
(2)当预测的需要调整的服务端实例节点的数量小于或者等于-1时，即N＝(∞-，-1]时，将预测的需要调整的服务端实例节点的数量取整作为需要减少的服务端实例节点的数量。
示例地，如果服务端当前的实例节点数量N0＝10，性能基准数据performance＝1000，当前在线的终端设备数量Nonline＝8888，那么，根据上述公式：
N＝8800/1000-10＝-1.2取绝对值和取整得到需要减少的服务端实例节点的数量为1。
示例地，如果服务端当前的实例节点数量N0＝10，性能基准数据performance＝1000，当前在线的终端设备数量Nonline＝7650，那么，根据上述公式：
N＝7650/1000-10＝-2.35取绝对值和取整得到需要减少的服务端实例节点的数量为2。
(3)当预测的需要调整的服务端实例节点的数量小于或者等于0并且小于1时，即N＝[0，1)时，确定不调整服务端实例节点的数量。示例地，如果服务端当前的实例节点数量N0＝10，性能基准数据performance＝1000，当前在线的终端设备数量Nonline＝1050，那么，根据上述公式：
N＝1050/1000-10＝0.05则确定不调整服务端实例节点的数量。
(4)当预测的需要调整的服务端实例节点的数量大于-1并且小于0时，即N＝(-1，0)时，确定不调整服务端实例节点的数量。示例地，如果服务端当前的实例节点数量N0＝10，性能基准数据performance＝1000，当前在线的终端设备数量Nonline＝950，那么，根据上述公式：
N＝950/1000-10＝-0.05则确定不调整服务端实例节点的数量。
进一步地，当数据分析模块确定需要调整服务端实例节点的数量时，可以向执行模块发送响应的指令，以指示执行模块来执行调整服务端实例节点的数量的具体动作。其中，数据分析模块发送给执行模块的指令可以包括增加服务端实例节点的第一指令和减少服务端实例节点的第二指令。
具体实现中，当数据分析模块确定服务端需要增加的实例节点的数量时，数据分析模块执行步骤S105，使得执行模块执行步骤S106。
步骤S105，数据分析模块将第一指令发送给执行模块。
其中，第一指令可以包含数据分析模块确定的服务端需要增加的实例节点的数量。
当本申请实施例的装置用于对多个应用程序的服务端资源进行调度时，第一指令还可以包含需要增加实例节点的服务端所对应的应用程序的appId，使得执行模块能够得知哪个应用程序的服务端需要增加实例节点。
示例地，当数据分析模块确定的需要增加的游戏“XXXX”的服务端，该游戏的appId为xxxxxxxx，服务端需要增加的实例节点的数量addNodeNumber为2，那么第一指令可以包含以下内容：
{“appId”:“xxxxxxxx”,“addNodeNumber”:“2”}
步骤S106，执行模块响应第一指令，根据服务端需要增加的实例节点的数量增加服务端的实例节点。
具体实现中，执行模块可以调用预先设置的与增加实例节点有关的应用程序接口，以创建新的实例节点，例如，当addNodeNumber为2时，创建2个新的实例节点，并将实例节点增加到服务端的生产环境中，使新增加的实例节点与服务端原有的实例节点共同为应用程序服务。
另外，当数据分析模块确定需要减少的服务端实例节点的数量时，数据分析模块执行步骤S107，使得执行模块执行步骤S108。
步骤S107，数据分析模块将第二指令发送给执行模块。
其中，第二指令可以包含数据分析模块确定的服务端需要减少的实例节点的数量。
当本申请实施例的装置用于对多个应用程序的服务端资源进行调度时，第二指令还可以包含需要减少的实例节点的服务端所对应的应用程序的appId，使得执行模块能够得知哪个应用程序的服务端需要减少实例节点。
示例地，当数据分析模块确定的需要增加的游戏“XXXX”的服务端，该游戏的appId为xxxxxxxx，服务端需要增加的实例节点的数量reduceNodeNumber为3，那么第一指令可以包含以下内容：
{“appId”:“xxxxxxxx”,“reduceNodeNumber”:“3”}
步骤S108，执行模块响应第二指令，根据服务端需要增加的实例节点的数量增加服务端的实例节点。
具体实现中，执行模块可以调用预先设置的与减少实例节点有关的应用程序接口，从服务端当前的实例节点中释放指定数量的实例节点，例如，当reduceNodeNumber为3时，释放3个实例节点，使得这3个实例节点不再为应用程序服务。其中，释放实例节点的过程例如可以包括：将需要释放的这3个实例节点中正在执行的任务分配给其他的实例节点，然后再释放这3个实例节点，使这3个实例节点不再为应用程序提供服务。
需要补充说明的是，本申请实施例中的性能基准数据可以是可变化的数据，其初始值可以由技术人员根据经验确定，也可以由技术人员在测试环境中对服务端的容量进行测试确定。例如，在应用程序在应用市场首发上架之前，技术人员可以在测试环境中针对该应用程序的服务端进行压力测试，以确定单个实例节点在测试环境中能够支持的终端设备的数量，并将这一数量作为性能基准数据的初始值。
可以理解的是，测试环境虽然可以模拟服务端在生产环境中的工况，但是由于测试环境与生产环境并不完全相同，因此，在测试环境中确定的性能基准数据与生产环境中的性能基准数据可能会存在一定的差异，因此，如果一直在生产环境中使用测试环境中确定的性能基准数据，可能会使服务端的资源调度产生一定的误差。为了消除误差，提高资源调度的准确性，本申请实施例还根据生产环境中采集到的用户体验数据和服务端性能数据对性能基准数据进行修正，其修正过程如图13所示可以包括以下步骤S201-步骤S204：
步骤S201，数据分析模块将服务端的实例节点的数量与性能基准数据相乘，得到服务端理论上支持的终端设备数量。
即：
服务端理论上支持的终端设备数量S＝实例节点数量N0*性能基准数据performance
示例地，如果服务端当前的实例节点数量N0＝10，性能基准数据performance＝1000，那么，根据上述公式，服务端理论上支持的终端设备数量S＝10*1000＝10000。
步骤S202，数据分析模块判断当前在线的终端设备数量是否小于服务端理论上支持的终端设备数量。
步骤S203，如果当前在线的终端设备数量小于服务端理论上支持的终端设备数量，判断服务端是否出现性能不足。
可以理解的是，如果性能数据取值合理，那么在当前在线的终端设备数量小于服务端理论上支持的终端设备数量时，服务端应该不会出现性能不足。而如果当前在线的终端设备数量小于服务端理论上支持的终端设备数量，但是服务端却出现了性能不足，则说明服务端实际上支持的终端设备数量比理论上支持的终端设备数量要小，也就是说，当前的性能基准数据取值偏大了。
步骤S204，如果当前在线的终端设备数量小于服务端理论上支持的终端设备数量，并且服务端出现性能不足，数据分析模块减小性能基准数据的取值，直到服务端解除性能不足状态。
具体实现中，数据分析模块可以根据以下公式减小性能基准数据的取值：
减小后的性能基准数据＝当前的(减小之前的)性能基准数据*K
其中，K为经验系数，其取值大于0并且小于1，优选取值为0.8≤K<1。
示例地，当减小之前的性能基准数据为1000，K为0.9时，经过一次减小之后的性能基准数据为1000*0.9＝900。
在减小了性能基准数据之后，数据分析模块可以根据减小后的性能基准数据重新确定需要增加的实例节点的数量，执行模块可以根据重新确定需要增加的实例节点的数量进一步服务端的实例节点。
示例地，如果服务端当前的实例节点数量N0＝10，减小之前的性能基准数据performance＝1000，当前在线的终端设备数量Nonline＝11200，那么，需要增加的实例节点的数量为1，服务端的实例节点的数量增加到11个。如果按照增加后的性能基准数据performance＝900计算，那么，需要增加的实例节点的数量为2，服务端的实例节点的数量增加到12个。因此，在减小性能基准数据的取值之后，本申请实施例的方法能够为服务端增加更多的实例节点，从而进一步缓解服务端的性能不足状态。
需要补充说明的是，本申请示例的上述方法步骤S101-步骤S107，以及步骤S201-步骤S204均可以周期性地重复执行，例如每3分钟执行一次，以实现在应用程序(及其新版本)首发上线时根据用户体验数据和服务端性能数据两方面的数据周期性地持续调整服务端的实例节点的数量，并且周期性地持续修正性能基准数据，直到服务端解除性能不足状态，平稳运行。
进一步地，在服务端解除性能不足状态而平稳运行之后，数据分析模块可以获取到服务端在当前的实例节点数量下，能够支持的终端设备数量，即：不会使服务端出现性能不足的数量。然后，数据分析模块可以将实例节点数量及其能够支持的终端设备数量保存到策略仓库中，该策略仓库包括至少一个应用程序的服务端在不同实例节点数量下能够支持的终端设备数量。
示例地，策略仓库的数据结构可以如下所示：
{“appId”:“xxxxxxxx”,“nodeNumber”:“1”,“userNumber”,“10000”}
{“appId”:“xxxxxxxx”,“nodeNumber”:“2”,“userNumber”,“19000”}
{“appId”:“xxxxxxxx”,“nodeNumber”:“3”,“userNumber”,“28000”}
{“appId”:“yyyyyyyy”,“nodeNumber”:“10”,“userNumber”,“500000”}
{“appId”:“yyyyyyyy”,“nodeNumber”:“11”,“userNumber”,“540000”}
……
策略仓库中的每一行包括三个字段，构成一组数据，分别为：应用程序标识appId、实例节点数量nodeNumber和能够支持的终端设备数量userNumber。
在策略仓库记录了各个应用程序的服务端在不同实例节点数量下能够支持的终端设备数量之后，如图14所示，在应用程序的服务端后续的运行中，数据分析模块可以直接从策略仓库中获取到当前在线的终端设备数量需要多少实例节点来提供支持，然后确定需要增加的实例节点的数量。
示例地，假设某个应用程序appId＝xxxxxxxx的服务端当前有2个实例节点，如果某一时刻该应用程序在线的终端设备数量达到20000，那么服务端会出现性能不足，这时，数据分析模块可以到策略仓库中查询20000个终端设备对应的实例节点的数量。经查询发现，2个实例节点能够支持19000个终端设备，3个实例节点能够支持28000个终端设备，因此数据分析模块可以确定再增加1个实例节点，使服务端有3个实例节点。
示例地，假设某个应用程序appId＝xxxxxxxx的服务端当前有2个实例节点，如果某一时刻该应用程序在线的终端设备数量为10000，那么服务端会出现性能过剩，这时，数据分析模块可以到策略仓库中查询10000个终端设备对应的实例节点的数量。经查询发现，服务端仅需要1个示例节点即可支持10000个终端设备，因此数据分析模块可以确定减少1个实例节点，使服务端有1个实例节点。
由此，数据分析模块通过直接查询策略仓库的方式，省去了如本申请实施例步骤S101-步骤S104的过程，缩短了服务端扩容或者缩容的周期，提升效率。
由以上技术方案可知，本申请实施例提供的资源调度方法，在应用程序首发上线时，能够采集终端设备的用户体验数据和服务端的服务端性能数据，然后根据用户体验数据和服务端性能数据这两方面的数据综合判断服务端是否出现性能不足，并且在服务端出现性能不足时，根据性能基准数据准确地确定需要增加的实例节点的数量，从而实现对服务端及时、准确地扩容，消除服务端的性能不足状态，避免服务端出现宕机，提高应用程序首发上线时的用户使用体验。
上述本申请提供的实施例中，分别从设备或装置本身、以及从设备或装置之间交互的角度对本申请提供的资源调度方法的各方案进行了介绍。可以理解的是，各个设备或装置，例如上述资源调度装置、终端设备和服务端为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
图15是本申请实施例提供的一种资源调度装置的结构示意图。在一个实施例中，资源调度装置可以通过图15所示的硬件装置实现相应的功能。如图15所示，该资源调度装置可以包括：收发器401、存储器402和处理器403。
在一个实施例中，处理器403可以包括一个或多个处理单元，例如：处理器403可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphicsprocessing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
存储器402与处理器403耦合，用于存储各种软件程序和/或多组指令。在一些实施例中，存储器402可包括高速随机存取的存储器，并且也可包括非易失性存储器。存储器402还可以存储操作系统，例如ANDROID，IOS，WINDOWS，或者LINUX等嵌入式操作系统。
在一个实施例中，收发器401为网络接口控制器(英语：network interfacecontroller，NIC)，包括双绞线接口(例如：RJ45)或光纤接口，使该装置能够通过有线连接方式接入局域网LAN或广域网WAN。
当存储器402中的软件程序和/或多组指令被处理器403运行时，使得装置用于执行如下步骤：从安装有目标应用程序APP的终端设备获取目标APP的用户体验数据，以及，从目标APP的服务端获取服务端性能数据，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足；当服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备数量；根据服务端需要增加的实例节点的数量增加服务端的实例节点。
在一个实施例中，用户体验数据是由安装于终端设备的数据采集软件开发工具包SDK采集的；数据采集SDK通过自身的用户体验数据上报应用程序接口API获取目标APP上报的用户体验数据，或者，目标APP用于将生成的用户体验数据存储在第一日志文件中，数据采集SDK通过监听第一日志文件或第一日志文件所在的目录以采集用户体验数据。
在一个实施例中，服务端性能数据是由安装于服务端的数据采集软件代理程序agent采集的；数据采集agent通过自身的性能数据上报API获取服务端上报的服务端性能数据，或者，服务端用于将生成的服务端性能数据存储在第二日志文件中，数据采集agent用于监听第二日志文件或第二日志文件所在的目录以采集服务端性能数据。
在一个实施例中，当存储器402中的软件程序和/或多组指令被处理器403运行时，还使得装置用于执行如下步骤，以实现根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足：将用户体验数据和/或服务端性能数据中的一个或者多个指标值与其对应的阈值进行匹配，根据匹配结果判断服务端是否出现性能不足。
在一个实施例中，当用户体验数据和/或服务端性能数据中的至少一个指标值超出其对应的阈值所限定的范围时，服务端性能不足。
在一个实施例中，当服务端的实例节点的数量减1之后与性能基准数据的乘积大于当前在线的终端设备数量时，服务端性能过剩。
在一个实施例中，用户体验数据和/或服务端性能数据包括一个或者多个时延类指标值和一个或者多个资源占用类指标值，每个时延类指标值对应一个时延类阈值，每个资源占用类指标值对应一个资源占用类阈值。
在一个实施例中，当存储器402中的软件程序和/或多组指令被处理器403运行时，还使得装置用于执行如下步骤，以实现根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量：将当前在线的终端设备数量除以性能基准数据，再减去服务端的实例节点的数量，得到预测的需要调整的服务端实例节点的数量；当预测的需要调整的服务端实例节点的数量大于或者等于1时，将预测的需要调整的服务端实例节点的数量取整作为服务端需要增加的实例节点的数量。
在一个实施例中，当存储器402中的软件程序和/或多组指令被处理器403运行时，还使得装置用于执行如下步骤：当预测的需要调整的服务端实例节点的数量小于或者等于-1时，将预测的需要调整的服务端实例节点的数量的绝对值取整作为需要减少的服务端实例节点的数量。
在一个实施例中，当存储器402中的软件程序和/或多组指令被处理器403运行时，还使得装置用于执行如下步骤：将服务端的实例节点的数量与性能基准数据相乘，得到服务端理论上支持的终端设备数量；如果当前在线的终端设备数量小于服务端理论上支持的终端设备数量，并且服务端出现性能不足，则减小性能基准数据的取值。
在一个实施例中，当存储器402中的软件程序和/或多组指令被处理器403运行时，还使得装置用于执行如下步骤，以实现减小性能基准数据的取值：周期性地减小性能基准数据的取值，每次减小之后的性能基准数据的取值等于减小之前的性能基准数据的取值乘以经验系数，经验系数大于0并且小于1。
在一个实施例中，当存储器402中的软件程序和/或多组指令被处理器403运行时，还使得装置用于执行如下步骤：当服务端解除性能不足状态时，将服务端当前的实例节点数量能够支持的终端设备数量保存在策略仓库中，所策略仓库包括服务端在不同实例节点数量下能够支持的终端设备数量。
在一个实施例中，当存储器402中的软件程序和/或多组指令被处理器403运行时，还使得装置用于执行如下步骤：当服务端性能不足时，根据当前在线的终端设备数量从策略仓库中确定要增加的实例节点的数量。
在另一个实施例中，资源调度装置可以通过图6所示的软件模块实现相应的功能。如图6所示，该资源调度装置可以包括：客户端数据采集模块、服务端数据采集模块、数据分析模块和执行模块。其中，客户端数据采集模块用于向资源调度装置发送目标APP的用户体验数据，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据；服务端数据采集模块，用于向数据分析模块发送服务端性能数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；数据分析模块，用于根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足；数据分析模块，还用于当服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备数量；执行模块，用于根据服务端需要增加的实例节点的数量增加服务端的实例节点。
本申请实施例还提供了一种网络系统，如图16所示，该网络系统包括：目标APP的服务端501、至少一个安装有目标APP的终端设备502，以及资源调度装置503；终端设备502，用于向资源调度装置503发送目标APP的用户体验数据，用户体验数据包括目标APP运行期间生成的与服务端501性能有关的数据；服务端501，用于向资源调度装置503发送服务端501性能数据，服务端501性能数据包括服务端501的资源使用数据和/或接口性能数据；资源调度装置503，用于根据用户体验数据和服务端501性能数据，判断服务端501是否出现性能不足；资源调度装置503，还用于当服务端501性能不足时，根据当前在线的终端设备502数量和预设的性能基准数据确定服务端501需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备502数量；资源调度装置503，还用于根据服务端501需要增加的实例节点的数量增加服务端501的实例节点。
本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。
本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面的方法。
本申请实施例还提供了一种芯片系统，图17为该芯片系统的结构示意图。该芯片系统包括处理器601，用于支持上述装置实现上述方面中所涉及的功能，例如，生成或处理上述方法中所涉及的信息。在一种可能的设计中，芯片系统还包括存储器602，用于保存资源调度装置必要的计算机指令603和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。
以上的具体实施方式，对本申请实施例的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本申请实施例的具体实施方式而已，并不用于限定本申请实施例的保护范围，凡在本申请实施例的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请实施例的保护范围之内。

Claims (35)

1.一种资源调度方法，其特征在于，包括：
从安装有目标应用程序APP的终端设备获取所述目标APP的用户体验数据，以及，从所述目标APP的服务端获取服务端性能数据，所述用户体验数据包括所述目标APP运行期间生成的与所述服务端性能有关的数据，所述服务端性能数据包括所述服务端的资源使用数据和/或接口性能数据；
根据所述用户体验数据和所述服务端性能数据，判断所述服务端是否出现性能不足；
当所述服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，所述性能基准数据包括每个实例节点支持的终端设备数量；
根据所述服务端需要增加的实例节点的数量增加所述服务端的实例节点。
2.根据权利要求1所述的资源调度方法，其特征在于，所述用户体验数据是由安装于所述终端设备的数据采集软件开发工具包SDK采集的。
3.根据权利要求2所述的资源调度方法，其特征在于，所述数据采集SDK通过自身的用户体验数据上报应用程序接口API获取所述目标APP上报的所述用户体验数据。
4.根据权利要求2所述的资源调度方法，其特征在于，所述目标APP用于将生成的所述用户体验数据存储在第一日志文件中，所述数据采集SDK通过监听所述第一日志文件或所述第一日志文件所在的目录以采集所述用户体验数据。
5.根据权利要求1所述的资源调度方法，其特征在于，所述服务端性能数据是由安装于所述服务端的数据采集软件代理程序agent采集的。
6.根据权利要求5所述的资源调度方法，其特征在于，所述数据采集agent通过自身的性能数据上报API获取所述服务端上报的所述服务端性能数据。
7.根据权利要求5所述的资源调度方法，其特征在于，所述服务端用于将生成的所述服务端性能数据存储在第二日志文件中，所述数据采集agent用于监听所述第二日志文件或所述第二日志文件所在的目录以采集所述服务端性能数据。
8.根据权利要求1-7任一项所述的资源调度方法，其特征在于，所述根据所述用户体验数据和所述服务端性能数据，判断所述服务端是否出现性能不足，包括：将所述用户体验数据和/或所述服务端性能数据中的一个或者多个指标值与其对应的阈值进行匹配，根据匹配结果判断所述服务端是否出现性能不足。
9.根据权利要求8所述的资源调度方法，其特征在于，当所述用户体验数据和/或所述服务端性能数据中的至少一个所述指标值超出其对应的阈值所限定的范围时，所述服务端性能不足。
10.根据权利要求8所述的资源调度方法，其特征在于，当所述服务端的实例节点的数量减1之后与所述性能基准数据的乘积大于当前在线的终端设备数量时，所述服务端性能过剩。
11.根据权利要求8-10任一项所述的资源调度方法，其特征在于，所述用户体验数据和/或所述服务端性能数据包括一个或者多个时延类指标值和一个或者多个资源占用类指标值，每个时延类指标值对应一个时延类阈值，每个所述资源占用类指标值对应一个资源占用类阈值。
12.根据权利要求1-11任一项所述的资源调度方法，其特征在于，所述根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，包括：
将当前在线的终端设备数量除以所述性能基准数据，再减去所述服务端的实例节点的数量，得到预测的需要调整的服务端实例节点的数量；
当所述预测的需要调整的服务端实例节点的数量大于或者等于1时，将所述预测的需要调整的服务端实例节点的数量取整作为所述服务端需要增加的实例节点的数量。
13.根据权利要求12所述的资源调度方法，其特征在于，还包括：
当所述预测的需要调整的服务端实例节点的数量小于或者等于-1时，将所述预测的需要调整的服务端实例节点的数量取整作为需要减少的服务端实例节点的数量。
14.根据权利要求1-13任一项所述的资源调度方法，其特征在于，还包括：
将所述服务端的实例节点的数量与所述性能基准数据相乘，得到所述服务端理论上支持的终端设备数量；如果当前在线的终端设备数量小于所述服务端理论上支持的终端设备数量，并且所述服务端出现性能不足，则减小所述性能基准数据的取值。
15.根据权利要求14所述的资源调度方法，其特征在于，所述减小所述性能基准数据的取值，包括：周期性地减小所述性能基准数据的取值，每次减小之后的性能基准数据的取值等于减小之前的性能基准数据的取值乘以经验系数，所述经验系数大于0并且小于1。
16.根据权利要求14所述的资源调度方法，其特征在于，还包括：
当所述服务端解除性能不足状态时，将所述服务端当前的实例节点数量能够支持的终端设备数量保存在策略仓库中，所策略仓库包括所述服务端在不同实例节点数量下能够支持的终端设备数量。
17.根据权利要求16所述的资源调度方法，其特征在于，还包括：
当所述服务端性能不足时，根据当前在线的终端设备数量从所述策略仓库中确定要增加的实例节点的数量。
18.一种资源调度装置，其特征在于，包括：收发器、存储器和处理器；其中，所述存储器包括有程序指令，所述程序指令被所述处理器运行时，使得所述装置用于执行如下步骤：
征在于，还包括：程序APP的终端设备获取所述目标APP的用户体验数据，以及，从所述目标APP的服务端获取服务端性能数据，所述用户体验数据包括所述目标APP运行期间生成的与所述服务端性能有关的数据，所述服务端性能数据包括所述服务端的资源使用数据和/或接口性能数据；
根据所述用户体验数据和所述服务端性能数据，判断所述服务端是否出现性能不足；
当所述服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，所述性能基准数据包括每个实例节点支持的终端设备数量；
根据所述服务端需要增加的实例节点的数量增加所述服务端的实例节点。
19.根据权利要求18所述的资源调度装置，其特征在于，所述用户体验数据是由安装于所述终端设备的数据采集软件开发工具包SDK采集的。
20.根据权利要求19所述的资源调度装置，其特征在于，所述数据采集SDK通过自身的用户体验数据上报应用程序接口API获取所述目标APP上报的所述用户体验数据。
21.根据权利要求19所述的资源调度装置，其特征在于，所述目标APP用于将生成的所述用户体验数据存储在第一日志文件中，所述数据采集SDK通过监听所述第一日志文件或所述第一日志文件所在的目录以采集所述用户体验数据。
22.根据权利要求18所述的资源调度装置，其特征在于，所述服务端性能数据是由安装于所述服务端的数据采集软件代理程序agent采集的。
23.根据权利要求22所述的资源调度装置，其特征在于，所述数据采集agent通过自身的性能数据上报API获取所述服务端上报的所述服务端性能数据。
24.根据权利要求22所述的资源调度装置，其特征在于，所述服务端用于将生成的所述服务端性能数据存储在第二日志文件中，所述数据采集agent用于监听所述第二日志文件或所述第二日志文件所在的目录以采集所述服务端性能数据。
25.根据权利要求18-22任一项所述的资源调度装置，其特征在于，所述程序指令还使得所述装置执行如下步骤，以实现根据所述用户体验数据和所述服务端性能数据，判断所述服务端是否出现性能不足：
将所述用户体验数据和/或所述服务端性能数据中的一个或者多个指标值与其对应的阈值进行匹配，根据匹配结果判断所述服务端是否出现性能不足。
26.根据权利要求25所述的资源调度装置，其特征在于，当所述用户体验数据和/或所述服务端性能数据中的至少一个所述指标值超出其对应的阈值所限定的范围时，所述服务端性能不足。
27.根据权利要求25所述的资源调度装置，其特征在于，当所述服务端的实例节点的数量减1之后与所述性能基准数据的乘积大于当前在线的终端设备数量时，所述服务端性能过剩。
28.根据权利要求25-27任一项所述的资源调度装置，其特征在于，所述用户体验数据和/或所述服务端性能数据包括一个或者多个时延类指标值和一个或者多个资源占用类指标值，每个时延类指标值对应一个时延类阈值，每个所述资源占用类指标值对应一个资源占用类阈值。
29.根据权利要求18-28任一项所述的资源调度装置，其特征在于，所述程序指令还使得所述装置执行如下步骤，以实现根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量：
将当前在线的终端设备数量除以所述性能基准数据，再减去所述服务端的实例节点的数量，得到预测的需要调整的服务端实例节点的数量；
当所述预测的需要调整的服务端实例节点的数量大于或者等于1时，将所述预测的需要调整的服务端实例节点的数量取整作为所述服务端需要增加的实例节点的数量。
30.根据权利要求29所述的资源调度装置，其特征在于，所述程序指令还使得所述装置执行如下步骤：
当所述预测的需要调整的服务端实例节点的数量小于或者等于-1时，将所述预测的需要调整的服务端实例节点的数量取整作为所述服务端需要减少的实例节点的数量。
31.根据权利要求18-30任一项所述的资源调度装置，其特征在于，所述程序指令还使得所述装置执行如下步骤：
将所述服务端的实例节点的数量与所述性能基准数据相乘，得到所述服务端理论上支持的终端设备数量；如果当前在线的终端设备数量小于所述服务端理论上支持的终端设备数量，并且所述服务端出现性能不足，则减小所述性能基准数据的取值。
32.根据权利要求31所述的资源调度装置，其特征在于，所述程序指令还使得所述装置执行如下步骤，以实现减小所述性能基准数据的取值：
周期性地减小所述性能基准数据的取值，每次减小之后的性能基准数据的取值等于减小之前的性能基准数据的取值乘以经验系数，所述经验系数大于0并且小于1。
33.根据权利要求31所述的资源调度装置，其特征在于，所述程序指令还使得所述装置执行如下步骤：
当所述服务端解除性能不足状态时，将所述服务端当前的实例节点数量能够支持的终端设备数量保存在策略仓库中，所策略仓库包括所述服务端在不同实例节点数量下能够支持的终端设备数量。
34.根据权利要求33所述的资源调度装置，其特征在于，所述程序指令还使得所述装置执行如下步骤：
当所述服务端性能不足时，根据当前在线的终端设备数量从所述策略仓库中确定要增加的实例节点的数量。
35.一种网络系统，其特征在于，包括：目标APP的服务端、安装有所述目标APP的终端设备，以及资源调度装置；
所述终端设备，用于向所述资源调度装置发送所述目标APP的用户体验数据，所述用户体验数据包括所述目标APP运行期间生成的与所述服务端性能有关的数据；
所述服务端，用于向所述资源调度装置发送服务端性能数据，所述服务端性能数据包括所述服务端的资源使用数据和/或接口性能数据；
所述资源调度装置，用于根据所述用户体验数据和所述服务端性能数据，判断所述服务端是否出现性能不足；
所述资源调度装置，还用于当所述服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，所述性能基准数据包括每个实例节点支持的终端设备数量；
所述资源调度装置，还用于根据所述服务端需要增加的实例节点的数量增加所述服务端的实例节点。
CN202010469738.8A 2020-05-28 2020-05-28 一种资源调度方法、装置和网络系统 Pending CN113747506A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010469738.8A CN113747506A (zh) 2020-05-28 2020-05-28 一种资源调度方法、装置和网络系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010469738.8A CN113747506A (zh) 2020-05-28 2020-05-28 一种资源调度方法、装置和网络系统

Publications (1)

Publication Number Publication Date
CN113747506A true CN113747506A (zh) 2021-12-03

Family

ID=78724237

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010469738.8A Pending CN113747506A (zh) 2020-05-28 2020-05-28 一种资源调度方法、装置和网络系统

Country Status (1)

Country Link
CN (1) CN113747506A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023125272A1 (zh) * 2021-12-29 2023-07-06 天翼物联科技有限公司 Radius环境下的全链路压测方法、装置、计算机设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备
CN108366082A (zh) * 2017-01-26 2018-08-03 华为技术有限公司 扩容方法及扩容装置
CN110990138A (zh) * 2019-12-04 2020-04-10 北京三快在线科技有限公司 资源调度方法、装置、服务器及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108206852A (zh) * 2016-12-20 2018-06-26 杭州华为数字技术有限公司 一种微服务框架下的基于会话的服务实例管理方法及设备
CN108366082A (zh) * 2017-01-26 2018-08-03 华为技术有限公司 扩容方法及扩容装置
CN110990138A (zh) * 2019-12-04 2020-04-10 北京三快在线科技有限公司 资源调度方法、装置、服务器及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023125272A1 (zh) * 2021-12-29 2023-07-06 天翼物联科技有限公司 Radius环境下的全链路压测方法、装置、计算机设备及存储介质

Similar Documents

Publication Publication Date Title
US11934868B2 (en) Systems and methods for scheduling tasks
CN108776934B (zh) 分布式数据计算方法、装置、计算机设备及可读存储介质
CN109218355B (zh) 负载均衡引擎，客户端，分布式计算系统以及负载均衡方法
CN108370341B (zh) 资源配置方法、虚拟网络功能管理器和网元管理系统
US8782215B2 (en) Performance testing in a cloud environment
KR20200012981A (ko) 네트워크 슬라이스 관리 방법, 디바이스 및 컴퓨터 판독 가능 저장 매체
CN109246229A (zh) 一种分发资源获取请求的方法和装置
CN109981744B (zh) 数据的分发方法、装置、存储介质及电子设备
CN112311628B (zh) 网络测速方法、系统、网络设备和存储介质
WO2020164476A1 (zh) 数据下载的方法及相关装置
WO2014194704A1 (en) A grouping processing method and system
CN109274534B (zh) 一种网络切片的监管方法及设备、通信系统
CN111966556A (zh) 性能压测方法、装置及服务器和计算机可读存储介质
US9621438B2 (en) Network traffic management
CN116700920A (zh) 云原生混合部署集群资源调度方法及装置
CN111538572A (zh) 任务处理方法、装置、调度服务器及介质
CN113191114B (zh) 用于验证系统的方法和装置
CN113747506A (zh) 一种资源调度方法、装置和网络系统
CN104462116B (zh) 数据选择的方法及装置
CN113271228B (zh) 带宽资源调度方法、装置、设备及计算机可读存储介质
CN116996440A (zh) 流量控制方法、装置、电子设备、存储介质及程序产品
CN114302351A (zh) 短信业务处理方法、装置、计算机设备和存储介质
US20140359104A1 (en) Grouping processing method and system
CN116055496B (zh) 一种监控数据采集方法、装置、电子设备及存储介质
CN111193634B (zh) 一种压力测试方法、装置和计算机可读存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination