一种资源调度方法、装置和网络系统制造方法及图纸

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

【技术实现步骤摘要】
一种资源调度方法、装置和网络系统


[0001]本申请涉及计算机
，尤其涉及一种资源调度方法、装置和网络系统。

技术介绍

[0002]手机、平板电脑、个人电脑(PC)等各类终端设备可以安装各种应用程序APP，安装有应用程序的终端设备可以与该应用程序的运营商提供的服务端建立网络连接，进行数据交互，以实现各种应用功能。
[0003]终端设备与服务端的数据交互会产生数据流量，一般来说，应用程序的用户规模越大，同时在线的终端设备的数量越多，服务端承受的数据流量越大，服务端资源的占用率越高，因此，为了保证服务端平稳运行，运维人员通常会根据用户规模去相应地配置服务端资源。然而，当应用程序首次发布时，运维人员通常缺乏用户规模数据，因此无法对应用程序首发上线后的流量进行准确地预测，进而无法确定要投入的服务端的规模。
[0004]在这种情况下，如果投入的服务端资源较少，而应用程序首发上线后的数据流量非常大，那么服务端就会由于受到巨大流量冲击而出现性能不足甚至宕机，导致应用程序出现运行卡顿、无法连接服务端、无法登陆、时延(ping值)过高等情况，严重影响用户使用体验，降低用户对首发应用程序的使用体验，导致用户流失。

技术实现思路

[0005]本申请实施例提供了一种资源调度方法、装置和网络系统，能够在应用程序首发上线时，及时准确地为应用程序调度服务端资源，以避免服务端出现性能不足或者宕机，提高应用程序首发上线时的用户使用体验。
[0006]第一方面，本申请实施例提供了一种资源调度方法。该方法包括：从安装有目标应用程序APP的终端设备获取目标APP的用户体验数据，以及，从目标APP的服务端获取服务端性能数据，其中，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足；当服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备数量；根据服务端需要增加的实例节点的数量增加服务端的实例节点。
[0007]这样，在应用程序首发上线时，本申请实施例的资源调度方法能够采集终端设备的用户体验数据和服务端的服务端性能数据，然后根据用户体验数据和服务端性能数据这两方面的数据综合判断服务端是否出现性能不足，并且在服务端出现性能不足时，根据性能基准数据准确地确定需要增加的实例节点的数量，从而实现对服务端及时、准确地扩容，消除服务端的性能不足状态，避免服务端出现宕机，提高应用程序首发上线时的用户使用体验。
[0008]在一种可选择的实现方式中，用户体验数据是由安装于终端设备的数据采集软件
开发工具包SDK采集的。
[0009]在一种可选择的实现方式中，数据采集SDK通过自身的用户体验数据上报应用程序接口API获取目标APP上报的用户体验数据。
[0010]在一种可选择的实现方式中，目标APP用于将生成的用户体验数据存储在第一日志文件中，数据采集SDK通过监听第一日志文件或第一日志文件所在的目录以采集用户体验数据。
[0011]在一种可选择的实现方式中，服务端性能数据是由安装于服务端的数据采集软件代理程序agent采集的。
[0012]在一种可选择的实现方式中，数据采集agent通过自身的性能数据上报API获取服务端上报的服务端性能数据。
[0013]在一种可选择的实现方式中，服务端用于将生成的服务端性能数据存储在第二日志文件中，数据采集agent用于监听第二日志文件或第二日志文件所在的目录以采集服务端性能数据。
[0014]在一种可选择的实现方式中，根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足，包括：将用户体验数据和/或服务端性能数据中的一个或者多个指标值与其对应的阈值进行匹配，根据匹配结果判断服务端是否出现性能不足。
[0015]在一种可选择的实现方式中，当用户体验数据和/或服务端性能数据中的至少一个指标值超出其对应的阈值所限定的范围时，服务端性能不足。
[0016]在一种可选择的实现方式中，当服务端的实例节点的数量减1之后与性能基准数据的乘积大于当前在线的终端设备数量时，服务端性能过剩。
[0017]在一种可选择的实现方式中，用户体验数据和/或服务端性能数据包括一个或者多个时延类指标值和一个或者多个资源占用类指标值，每个时延类指标值对应一个时延类阈值，每个资源占用类指标值对应一个资源占用类阈值。
[0018]在一种可选择的实现方式中，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，包括：将当前在线的终端设备数量除以性能基准数据，再减去服务端的实例节点的数量，得到预测的需要调整的服务端实例节点的数量；当预测的需要调整的服务端实例节点的数量大于或者等于1时，将预测的需要调整的服务端实例节点的数量取整作为服务端需要增加的实例节点的数量。
[0019]在一种可选择的实现方式中，该方法还包括：当预测的需要调整的服务端实例节点的数量小于或者等于-1时，将预测的需要调整的服务端实例节点的数量的绝对值取整作为需要减少的服务端实例节点的数量。
[0020]在一种可选择的实现方式中，该方法还包括：将服务端的实例节点的数量与性能基准数据相乘，得到服务端理论上支持的终端设备数量；如果当前在线的终端设备数量小于服务端理论上支持的终端设备数量，并且服务端出现性能不足，则减小性能基准数据的取值。
[0021]在一种可选择的实现方式中，减小性能基准数据的取值，包括：周期性地减小性能基准数据的取值，每次减小之后的性能基准数据的取值等于减小之前的性能基准数据的取值乘以经验系数，经验系数大于0并且小于1。
[0022]在一种可选择的实现方式中，该方法还包括：当服务端解除性能不足状态时，将服
务端当前的实例节点数量能够支持的终端设备数量保存在策略仓库中，所策略仓库包括服务端在不同实例节点数量下能够支持的终端设备数量。
[0023]在一种可选择的实现方式中，该方法还包括：当服务端性能不足时，根据当前在线的终端设备数量从策略仓库中确定要增加的实例节点的数量。
[0024]第二方面，本申请实施例还提供了一种资源调度装置，该装置包括：收发器、存储器和处理器；其中，存储器包括有程序指令，程序指令被处理器运行时，使得装置用于执行如下步骤：从安装有目标应用程序APP的终端设备获取目标APP的用户体验数据，以及，从目标APP的服务端获取服务端性能数据，用户体验数据包括目标APP运行期间生成的与服务端性能有关的数据，服务端性能数据包括服务端的资源使用数据和/或接口性能数据；根据用户体验数据和服务端性能数据，判断服务端是否出现性能不足；当服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加的实例节点的数量，性能基准数据包括每个实例节点支持的终端设备数量；根据服本文档来自技高网...

【技术保护点】

【技术特征摘要】
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运行期间生成的与所述服务端性能有关的数据，所述服务端性能数据包括所述服务端的资源使用数据和/或接口性能数据；根据所述用户体验数据和所述服务端性能数据，判断所述服务端是否出现性能不足；当所述服务端性能不足时，根据当前在线的终端设备数量和预设的性能基准数据确定服务端需要增加...

【专利技术属性】
技术研发人员：李林锋，
申请(专利权)人：华为技术有限公司，
类型：发明
国别省市：