CN116301991A - 一种应用程序升级维护方法、装置、设备及介质 - Google Patents

Abstract

本申请涉及计算机技术领域，尤其是涉及一种应用程序升级维护方法、装置、设备及介质，方法包括当检测到用户触发的升级请求时，基于升级请求确定待升级脚本类型，待升级脚本类型包括业务逻辑脚本类型和基础功能脚本类型；当待升级脚本类型为业务逻辑脚本类型时，获取待升级的业务逻辑脚本，对待升级的业务逻辑脚本进行升级，得到升级后的业务逻辑脚本，并将升级后的业务逻辑脚本重新上传至第一存储空间；当待升级脚本类型为基础功能脚本类型时，获取待升级的基础功能脚本，对待升级的基础功能脚本进行镜像处理，并将镜像处理后的基础功能脚本存储至第二存储空间。本申请可以及时对应用程序进行升级维护。

Description

一种应用程序升级维护方法、装置、设备及介质

技术领域

本申请涉及计算机技术领域，尤其是涉及一种应用程序升级维护方法、装置、设备及介质。

背景技术

随着应用程序使用时间的增长，应用程序在运行过程中出现漏洞的概率也越来越高，当出现漏洞时，可能会导致用户被攻击的概率增大，从而导致用户数据发生泄漏，除此之外，由于用户对应用程序的需求越来越高，当应用程序出现漏洞时可能会影响用户的使用体验。

因此，亟需一种对应用程序进行升级维护的方法，以便于及时对应用程序中可能出现的漏洞进行修复。

发明内容

为了及时对应用程序进行升级维护，从而提高用户的使用体验，本申请提供一种应用程序升级维护方法、装置、设备及介质。

第一方面，本申请提供一种应用程序升级维护方法，采用如下的技术方案：

一种应用程序升级维护方法，包括：

当检测到用户触发的升级请求时，基于所述升级请求确定待升级脚本类型，所述待升级脚本类型包括业务逻辑脚本类型和基础功能脚本类型；

当所述待升级脚本类型为业务逻辑脚本类型时，获取待升级的业务逻辑脚本，对所述待升级的业务逻辑脚本进行升级，得到升级后的业务逻辑脚本，并将所述升级后的业务逻辑脚本重新上传至第一存储空间；

当所述待升级脚本类型为基础功能脚本类型时，获取待升级的基础功能脚本，对所述待升级的基础功能脚本进行镜像处理，并将镜像处理后的基础功能脚本存储至第二存储空间。

通过采用上述技术方案，根据用户触发的升级请求确定出待升级脚本类型后，再根据待升级脚本类型将应用程序中对应的脚本进行升级维护，通过升级请求确定待升级脚本类型，再根据待升级脚本类型对脚本进行升级维护，而不是当检测到用户触发的升级请求时，将应用程序内所有的脚本共同进行升级维护，通过待升级脚本类型将应用程序中升级频率较高的业务逻辑脚本，与升级频率较低的基础功能脚本进行区分，便于减少对升级频率低的基础功能脚本进行维护升级的次数，从而便于降低产生不必要的升级维护操作的概率，进而便于提高对应用程序进行升级维护时的效率。

在一种可能实现的方式中，所述第一存储空间包括远程服务器，所述将所述升级后的业务逻辑脚本重新上传至第一存储空间，之前还包括：

业务逻辑脚本获取所述待升级业务逻辑脚本对应的第一存储地址，所述第一存储地址为所述远程服务器上存储所述待升级业务逻辑脚本的存储地址；

其中，所述将所述升级后的业务逻辑脚本重新上传至第一存储空间，包括：

按照所述第一存储地址将所述升级后的业务逻辑脚本上传至所述远程服务器；

所述将所述升级后的业务逻辑脚本重新上传至第一存储空间，之后还包括：

生成清除映射指令，所述清除映射指令用于清除执行映射表内所述待升级的业务逻辑脚本对应的第一存储地址与第二存储地址的地址映射关系，所述第二存储地址为所述第一存储空间内存储所述待升级业务逻辑脚本的存储地址。

通过采用上述技术方案，通过将升级后的业务逻辑脚本存放在远程服务器中升级前的存储位置处，而不是将升级后的业务逻辑脚本随机存放，以便于对业务逻辑脚本进行管理，并在将升级后的业务逻辑脚本上传至服务器后，对执行映射表内待升级业务逻辑脚本的第一存储地址与第二存储地址的地址映射关系清除，以便于降低对业务逻辑脚本执行时出现地址映射关系引用失误而出现执行误差的概率。

在一种可能实现的方式中，执行映射表的建立方式，包括：

获取应用程序中的各个业务逻辑脚本的第一存储地址和第二存储地址，所述初始业务逻辑脚本为未经过升级操作的业务逻辑脚本；

计算各个初始业务逻辑脚本的第一存储地址分别对应的哈希值；

将各个初始业务逻辑脚本的哈希值和各个初始业务逻辑脚本分别对应的第二存储地址进行绑定，得到各个初始业务逻辑脚本的地址映射关系；

对各个初始业务逻辑脚本进行关键信息识别，并根据识别结果确定各个业务逻辑脚本的重要级别，并根据各个初始业务逻辑脚本的重要级别对各个初始业务逻辑脚本排序得到重要级别序列；

根据所述重要级别序列和各个初始业务逻辑脚本对应的地址映射关系，构成执行映射表。

通过采用上述技术方案，根据应用程序的每一业务逻辑脚本在第一存储空间内的存储地址，计算出每一业务逻辑脚本对应的哈希值，由于哈希值可作为业务逻辑脚本的身份标识，通过哈希值便于提高从多个业务逻辑脚本中确定目标业务逻辑脚本业务逻辑脚本时的效率，并且通过每一业务逻辑脚本的重要级别对每一业务逻辑脚本的地址映射关系进行排列，而不是将所有的业务逻辑脚本对应的地址映射关系随机存放，通过排序便于提高确定重要等级较高的业务逻辑脚本时的速率。

在一种可能实现的方式中，该方法还包括：

当检测到用户触发的执行请求时，根据所述执行请求确定待执行的业务逻辑脚本，并获取所述待执行的业务逻辑脚本的第一存储地址；

识别所述待执行的业务逻辑脚本的第一存储地址中的地址标识，并根据识别到的地址标识确定所述待执行的业务逻辑脚本的类型，所述类型包括远程脚本类型和非远程脚本类型；

若所述待执行的业务逻辑脚本的类型为远程脚本类型，则根据所述待执行的业务逻辑脚本的第一存储地址计算所述待执行的业务逻辑脚本对应的执行哈希值，所述执行哈希值为待执行的业务逻辑脚本的第一存储地址对应的哈希值；

根据所述执行哈希值从所述执行映射表中进行遍历，以判断所述待执行的业务逻辑脚本是否为首次调用；

若是，则基于所述待执行的业务逻辑脚本的第一存储地址，缓存所述待执行的业务逻辑脚本至所述第二存储空间内得到第二存储地址，执行所述待执行的业务逻辑脚本，并基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表；

若否，则根据所述执行哈希值从所述执行映射表中确定所述待执行的业务逻辑脚本的第二存储地址，基于所述待执行的业务逻辑脚本的第二存储地址执行所述待执行的业务逻辑脚本。

通过采用上述技术方案，当待执行的业务逻辑脚本为远程脚本时，根据待执行的业务逻辑脚本的第一存储地址对应的执行哈希值判断该业务逻辑脚本是否为首次调用，若不是首次调用，则直接调用，若为首次调用，则先基于第一存储地址将待执行的业务逻辑脚本从远程服务器上下载，并缓存至第二存储空间后，生成该待执行的业务逻辑脚本的第一存储地址与第二存储地址的地址映射关系，通过将业务逻辑脚本先缓存至第二存储空间，并根据执行映射表对业务逻辑脚本逻辑进行调用便于提升对业务逻辑脚本进行调用时的效率，并且当业务逻辑脚本被调用后，该执行业务逻辑脚本对应的地址映射关系添加至执行映射表内，以便于提高再次对该业务逻辑脚本进行调用时的效率。

在一种可能实现的方式中，所述基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表，之前还包括：

获取所述待执行的业务逻辑脚本的数据量，并根据所述待执行的业务逻辑脚本的数据量，确定所述待执行的业务逻辑脚本在所述第二存储空间内的第二存储地址；

其中，所述基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表，包括：

将所述待执行的业务逻辑脚本对应的执行哈希值与所述待执行的业务逻辑脚本的第二存储地址进行绑定，得到所述待执行的业务逻辑脚本的地址映射关系；

根据所述待执行的业务逻辑脚本的地址映射关系，更新所述执行映射表。

通过采用上述技术方案，通过待执行的业务逻辑脚本的数据量为待执行的业务逻辑脚本在第二存储空间内为其分配存储空间，而不是将待执行的业务逻辑脚本存放入随机分配的存储空间内，若随机分配的存储空间无法全部将待执行的业务逻辑脚本存储完毕，则需要再次为待执行的业务逻辑脚本分配存储空间，从而可能会增加分配存储空间过程中的工作量，并且两次分配的存储空间可能不相邻，随机分配存储空间可能会导致待执行的业务逻辑脚本在存储过程中发生丢失，通过待执行的业务逻辑脚本的数据量确定待执行的业务逻辑脚本在第二存储空间内的存储地址，便于保证待执行的业务逻辑脚本的完整性，并且便于对待执行的业务逻辑脚本进行管理，及时更新执行映射表便于降低在对执行映射表内的业务逻辑脚本进行调用时，发生调用误差的概率。

在一种可能实现的方式中，所述执行所述待执行的业务逻辑脚本，包括：

识别所述待执行的业务逻辑脚本中的关联信息，所述关联信息为所述待执行的业务逻辑脚本与对应的基础功能脚本之间的关联信息；

根据所述关联信息，从所述第二存储空间内确定与所述待执行的业务逻辑脚本相关联的基础功能脚本，并将所述待执行的业务逻辑脚本与所述基础功能脚本融合得到融合脚本，并执行所述融合脚本。

通过采用上述技术方案，通过待执行的业务逻辑脚本中的关联信息，便于确定出与待执行的业务逻辑脚本相关联的基础功能脚本，通过将对应的基础功能脚本与待执行的业务逻辑脚本相融合，再运行融合脚本以便于实现待执行的业务逻辑脚本对应的操作。

在一种可能实现的方式中，该方法还包括：

统计预设时间段内升级请求的数量，并确定每一升级请求对应的脚本，将升级请求的数量低于预设阈值的脚本确定为异常脚本；

根据每一异常脚本在所述预设时间段内升级请求的数量及对应的请求调整时刻，确定每一异常脚本的升级频率，所述请求升级时刻为检测到升级请求的时刻；

根据所述每一异常脚本的升级频率以及脚本与标准升级频率的预设对应关系，确定超期脚本，并对所述超期脚本进行升级，所述超期脚本为升级频率低于对应标准升级频率的脚本。

通过采用上述技术方案，根据预设时间段内升级请求的数量，以及每一升级请求各自对应的脚本，确定存在异常的脚本，并根据每一异常脚本对应的升级频率，确定出超期脚本，通过对超期业务逻辑脚本进行定期升级，以便于及时发现应用程序中业务逻辑脚本存在的漏洞，对应用程序中可能存在漏洞的业务逻辑脚本进行定期升级，便于降低应用程序运行过程中出现故障的概率。

第二方面，本申请提供一种应用程序升级维护装置，采用如下的技术方案：

一种应用程序升级维护装置，包括：

确定脚本类型模块，用于当检测到用户触发的升级请求时，基于所述升级请求确定待升级脚本类型，所述待升级脚本类型包括业务逻辑脚本类型和基础功能脚本类型；

业务逻辑脚本上传模块，用于当所述待升级脚本类型为业务逻辑脚本类型时，获取待升级的业务逻辑脚本，对所述待升级的业务逻辑脚本进行升级，得到升级后的业务逻辑脚本，并将所述升级后的业务逻辑脚本重新上传至第一存储空间；

基础功能脚本上传模块，用于当所述待升级脚本类型为基础功能脚本类型时，获取待升级的基础功能脚本，对所述待升级的基础功能脚本进行镜像处理，并将镜像处理后的基础功能脚本存储至第二存储空间。

通过采用上述技术方案，根据用户触发的升级请求确定出待升级脚本类型后，再根据待升级脚本类型将应用程序中对应的脚本进行升级维护，通过升级请求确定待升级脚本类型，再根据待升级脚本类型对脚本进行升级维护，而不是当检测到用户触发的升级请求时，将应用程序内所有的脚本共同进行升级维护，通过待升级脚本类型将应用程序中升级频率较高的业务逻辑脚本，与升级频率较低的基础功能脚本进行区分，便于减少对升级频率低的基础功能脚本进行维护升级的次数，从而便于降低产生不必要的升级维护操作的概率，进而便于提高对应用程序进行升级维护时的效率。

在一种可能实现的方式中，该装置还包括：

业务逻辑脚本业务逻辑脚本获取第一存储地址模块，用于获取所述待升级的业务逻辑脚本对应的第一存储地址，所述第一存储地址为所述远程服务器上存储所述待升级的业务逻辑脚本的存储地址；

其中，业务逻辑脚本上传模块在将所述升级后的业务逻辑脚本重新上传至第一存储空间时，具体用于：

按照所述第一存储地址将所述升级后的业务逻辑脚本上传至所述远程服务器；

生成清除指令模块，用于生成清除映射指令，所述清除映射指令用于清除执行映射表内所述待升级的业务逻辑脚本对应的第一存储地址与第二存储地址的地址映射关系，所述第二存储地址为所述第二存储空间内存储所述带升级的业务逻辑脚本的存储地址。

在一种可能实现的方式中，该装置还包括：

获取地址模块，用于获取应用程序中的各个初始业务逻辑脚本的第一存储地址和第二存储地址，所述初始业务逻辑脚本为未经过升级操作的业务逻辑脚本；

计算哈希值模块，用于计算各个初始业务逻辑脚本的第一存储地址分别对应的哈希值；

确定地址映射关系模块，用于将各个初始业务逻辑脚本的哈希值和各个初始业务逻辑脚本分别对应的第二存储地址进行绑定，得到各个初始业务逻辑脚本的地址映射关系；

确定重要级别序列模块，用于对各个初始业务逻辑脚本进行关键信息识别，根据识别结果确定各个初始业务逻辑脚本的重要级别，并根据各个初始业务逻辑脚本的重要级别对各个初始业务逻辑脚本排序得到重要级别序列；

构成映射表模块，用于根据所述重要级别序列和各个初始业务逻辑脚本对应的地址映射关系，构成执行映射表。

在一种可能实现的方式中，该装置还包括：

确定待执行的业务逻辑脚本模块，用于当检测到用户触发的执行请求时，根据所述执行请求确定待执行的业务逻辑脚本，并获取所述待执行的业务逻辑脚本的第一存储地址；

确定业务逻辑脚本的类型模块，用于识别所述待执行的业务逻辑脚本的第一存储地址中的地址标识，并根据识别到的地址标识确定所述待执行的业务逻辑脚本的类型，所述类型包括远程脚本类型和非远程脚本类型；

确定执行哈希值模块，用于若所述待执行的业务逻辑脚本的类型为远程脚本类型，则根据所述待执行的业务逻辑脚本的第一存储地址计算所述待执行的业务逻辑脚本对应的执行哈希值，所述执行哈希值为待执行的业务逻辑脚本的第一存储地址对应的哈希值；

遍历模块，用于根据所述执行哈希值从所述执行映射表中进行遍历，以判断所述待执行的业务逻辑脚本是否为首次调用；

第一调用执行模块，用于若是，则基于所述待执行的业务逻辑脚本的第一存储地址，缓存所述待执行的业务逻辑脚本至所述第二存储空间内得到第二存储地址，执行所述待执行的业务逻辑脚本，并基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表；

第二调用执行模块，用于若否，则根据所述执行哈希值从所述执行映射表中确定所述待执行的业务逻辑脚本的第二存储地址，基于所述待执行的业务逻辑脚本的第二存储地址执行所述待执行的业务逻辑脚本。

在一种可能实现的方式中，该装置还包括：

获取数据量模块，用于获取所述待执行的业务逻辑脚本的数据量，并根据所述待执行的业务逻辑脚本的数据量，确定所述待执行的业务逻辑脚本在所述第二存储空间内的第二存储地址；其中，第一调用执行模块在基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表时，具体用于：

将所述待执行的业务逻辑脚本对应的执行哈希值与所述待执行的业务逻辑脚本的第二存储地址进行绑定，得到所述待执行的业务逻辑脚本的地址映射关系；

根据所述待执行的业务逻辑脚本的地址映射关系，更新所述执行映射表。

在一种可能实现的方式中，第一调用执行模块或第二调用执行模块在执行所述待执行的业务逻辑脚本时，具体用于：

识别所述待执行的业务逻辑脚本中的关联信息，所述关联信息为所述待执行的业务逻辑脚本与对应的基础功能脚本之间的关联信息；

根据所述关联信息，从所述第二存储空间内确定与所述待执行的业务逻辑脚本相关联的基础功能脚本，并将所述待执行的业务逻辑脚本与所述基础功能脚本融合得到融合脚本，并执行所述融合脚本。

在一种可能实现的方式中，该装置还包括：

确定异常脚本模块，用于统计预设时间段内调整请求的数量，并确定每一升级请求对应的脚本，将升级请求的数量低于预设阈值的脚本确定为异常脚本；

确定升级频率模块，用于根据每一异常脚本在所述预设时间段内升级请求的数量及对应的请求升级时刻，确定每一异常脚本的升级频率，所述请求升级时刻为检测到升级请求的时刻；超期升级模块，用于根据所述每一异常脚本的升级频率以及脚本与标准升级频率的预设对应关系，确定超期脚本，并对所述超期脚本进行升级，所述超期脚本为升级频率低于对应标准升级频率的脚本。

第三方面，本申请提供一种电子设备，采用如下的技术方案：

一种电子设备，该电子设备包括：

至少一个处理器；

存储器；

至少一个应用程序，其中所述至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行，所述至少一个应用程序配置用于：执行上述应用程序升级维护方法。

第四方面，本申请提供一种计算机可读存储介质，采用如下的技术方案：

一种计算机可读存储介质，包括：存储有能够被处理器加载并执行上述应用程序升级维护方法的计算机程序。

综上所述，本申请包括以下至少一种有益技术效果：

1.根据用户触发的升级请求确定出待升级脚本类型后，再根据待升级脚本类型将应用程序中对应的脚本进行升级维护，通过升级请求确定待升级脚本类型，再根据待升级脚本类型对脚本进行升级维护，而不是当检测到用户触发的升级请求时，将应用程序内所有的脚本共同进行升级维护，通过待升级脚本类型将应用程序中升级频率较高的业务逻辑脚本，与升级频率较低的基础功能脚本进行区分，便于减少对升级频率低的基础功能脚本进行维护升级的次数，从而便于降低产生不必要的升级维护操作的概率，进而便于提高对应用程序进行升级维护时的效率。

2.通过将升级后的业务逻辑脚本存放在远程服务器中升级前的存储位置处，而不是将升级后的业务逻辑脚本随机存放，以便于对业务逻辑脚本进行管理，并在将升级后的业务逻辑脚本上传至服务器后，对执行映射表内待升级业务逻辑脚本的第一存储地址与第二存储地址的地址映射关系清除，以便于降低对业务逻辑脚本执行时出现地址映射关系引用失误而出现执行误差的概率。

附图说明

图1是本申请实施例中一种应用程序升级维护方法的流程示意图；

图2是本申请实施例中一种调整脚本流程图；

图3是本申请实施例中一种业务逻辑脚本调用流程图；

图4是本申请实施例中一种应用程序升级维护装置的结构示意图；

图5是本申请实施例中一种电子设备的结构示意图。

具体实施方式

以下结合附图1-5对本申请作进一步详细说明。

本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改，但只要在本申请的权利要求范围内都受到专利法的保护。

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

具体的，本申请实施例提供了一种应用程序升级维护方法，由电子设备执行，该电子设备可以为服务器也可以为终端设备，其中，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此，该终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例在此不做限制。

参考图1，图1是本申请实施例中一种应用程序升级维护方法的流程示意图，该方法包括步骤S110、步骤S120及步骤S130，其中：

步骤S110：当检测到用户触发的升级请求时，基于升级请求确定待升级脚本类型，待升级脚本类型包括业务逻辑脚本类型和基础功能脚本类型。

具体的，升级请求可以由应用程序自动生成，也可以由用户输入升级需求后生成，还可以在用户对应用程序的页面进行配置更改后自动生成，例如，对应用程序对应的通用按钮进行设置、对导航栏进行设置或对弹窗进行设置等，在检测到用户在应用程序内进行配置更改后，会生成对应的升级请求，通过升级请求可以确定升级请求对应的调整操作，其中，升级请求与升级操作一一对应。

应用程序内包含多个脚本，通过脚本类型对应用程序内的多个脚本进行划分时，可以分为两类，其中一类为业务逻辑脚本，业务逻辑脚本为每一用户独有的，并且逻辑复杂与用户对应用程序的操作息息相关，因此业务逻辑脚本对应的升级频率也比较高；另一类为基础功能脚本，基础功能脚本为多个用户共享的，功能单一稳定、逻辑简单，因此基础功能脚本对应的升级频率较低，为了保证用户对应用程序的使用体验，需要对应用程序进行定期升级维护，例如在预设时间段内，可能需要对业务逻辑脚本升级维护4次，但可能只需要对基础功能脚本升级维护1次。

步骤S120：当待升级脚本类型为业务逻辑脚本类型时，获取待升级的业务逻辑脚本，对待升级的业务逻辑脚本进行升级，得到升级后的业务逻辑脚本，并将升级后的业务逻辑脚本重新上传至第一存储空间。

具体的，根据升级请求确定升级后的业务逻辑脚本时，解析升级请求确定待升级的业务逻辑脚本，在对待升级业务逻辑脚本进行升级时可以对整体业务逻辑脚本进行升级维护，还可以对用户指定的部分业务逻辑脚本进行升级维护，其中：

方式一：当需要对整体业务逻辑脚本进行升级时，解析升级请求确定整体业务逻辑脚本中的功能节点，并依据确定出的功能节点对整体业务逻辑脚本进行划分，再根据功能节点的重要性对多个功能节点进行排序形成功能节点序列，按照功能节点序列对整体业务逻辑脚本进行升级维护，例如，在某购物应用程序中，某用户对应的整体业务逻辑脚本中包含登录功能节点、浏览功能节点、购买功能节点以及收藏功能节点，根据用户预设的功能节点与重要等级的映射关系，确定出功能节点序列为登录功能节点、购买功能节点、收藏功能节点、浏览功能节点，在对整体业务逻辑脚本进行升级维护时，按照功能节点序列对每一功能节点对应的业务逻辑脚本进行升级维护。

方式二：当对用户指定的部分业务逻辑脚本进行升级时，解析升级请求确定对应的待升级目的功能节点，并从整体业务逻辑脚本中定位该目的功能节点对应的位置，再基于确定出的位置进行升级维护业务逻辑脚本。

升级前的业务逻辑脚本存放在第一存储空间内，第一存储空间可以为本地缓存空间，也可以为远程存储空间，将升级后的业务逻辑脚本重新上传至第一存储空间，以对第一存储空间内存储的相应内容进行更新。

步骤S130：当待升级脚本类型为基础功能脚本类型时，获取待升级的基础功能脚本，对待升级的基础功能脚本进行镜像处理，并将镜像处理后的基础功能脚本存储至第二存储空间。

具体的，根据升级请求确定升级后的基础功能脚本的方式，可以参考上述根据升级请求确定升级后的业务逻辑脚本的内容，在此不做赘述。第二存储空间可以为本地镜像，本地镜像可以为Docker镜像，其中Docker镜像是一个开源的应用容器引擎，是一个可以让应用程序开发者打包所开发的应用以及开发应用过程中的依赖包上传的空间，并能够将运行结果发布到任何应用Linux操作系统或Windows操作系统的设备上，Docker镜像可以借助Linux操作系统的内核特性，如：控制组(Control Group)、命名空间(Namespace)等，并可以直接调用操作系统的系统调用接口，用于执行对应的应用程序。

对于本申请实施例，根据用户触发的升级请求确定出待升级脚本类型后，再根据待升级脚本类型将应用程序中对应的脚本进行升级维护，通过升级请求确定待升级脚本类型，再根据待升级脚本类型对脚本进行升级维护，而不是当检测到用户触发的升级请求时，将应用程序内所有的脚本共同进行升级维护，通过待升级脚本类型将应用程序中升级频率较高的业务逻辑脚本，与升级频率较低的基础功能脚本进行区分，便于减少对升级频率低的基础功能脚本进行维护升级的次数，从而便于降低产生不必要的升级维护操作的概率，进而便于提高对应用程序进行升级维护时的效率。

为了降低执行业务逻辑脚本时出现误差的概率，步骤S120中将升级后的业务逻辑脚本重新上传至第一存储空间，之前还包括步骤Sa(附图未示出)其中：

步骤Sa：获取待升级的业务逻辑脚本对应的第一存储地址，第一存储地址为远程服务器上存储待升级的业务逻辑脚本的存储地址。

具体的，对升级请求进行语义识别，便于确定出升级请求中包括的待升级的业务逻辑脚本信息，通过待升级的业务逻辑脚本便于确定出调整请求对应的待升级的业务逻辑脚本。待升级的业务逻辑脚本的第一存储地址为远程服务器中存储待升级的业务逻辑脚本的存储地址，其中，远程服务器是指远程访问服务器，即将互联网中的计算机和在局域网中的远程访问服务器相连接，远程服务器具体可以为S3远程服务器，也可以为其他远程服务器，在本申请实施例中不做具体限定，只要能够对业务逻辑脚本进行远程存储即可。

步骤S120中将升级后的业务逻辑脚本重新上传至第一存储空间，包括步骤S1201(附图未示出)，其中：

步骤S1201：按照第一存储地址将升级后的业务逻辑脚本上传至远程服务器。

具体的，清空升级前的业务逻辑脚本在第一存储空间内的存储内容，并将升级后的业务逻辑脚本存储至升级前的业务逻辑脚本所存储的位置，将升级后的业务逻辑脚本重新上传时，可按照升级前的业务逻辑脚本在第一存储空间内的存放地址，进行上传。

步骤120中将升级后的业务逻辑脚本重新上传至第一存储空间，之后还包括步骤Sb(附图未示出)，其中：

步骤Sb：生成清除映射指令，清除映射指令用于清除执行映射表内待升级的业务逻辑脚本对应的第一存储地址与第二存储地址的地址映射关系，第二存储地址为第二存储空间内存储待升级的业务逻辑脚本的存储地址。

具体的，清除映射指令在将升级后的业务逻辑脚本上传至第一存储空间后由电子设备生成，用于对执行映射表中与待升级的业务逻辑脚本业务逻辑脚本对应的地址映射关系清除，例如，待升级的业务逻辑脚本a在第一存储空间内的存储地址为A，将待执行的业务逻辑脚本业务逻辑脚本从第一存储空间下载缓存至第二存储空间后，对应的第二存储地址为B，则待升级的业务逻辑脚本业务逻辑脚本a的第一存储地址A与第二存储地址B的地址映射关系存储在执行映射表内，若对待升级的业务逻辑脚本a进行升级后得到升级后的业务逻辑脚本a1，此时将待执行的业务逻辑脚本a1替换存储地址A中存储的待升级的业务逻辑脚本a，执行映射表内第二存储地址B对应的第一存储地址A中存储的内容为待升级的业务逻辑脚本a，若此时根据执行映射表对脚本进行调用，可能会导致调用过程中出现误差。

如图2所示，图2为本申请实施例中一种升级脚本流程图，当检测到用户触发的升级请求时，判断是否需要升级，若不需要升级则升级流程结束；若需要升级则根据升级请求对业务逻辑脚本进行升级，并将升级后的业务逻辑脚本重新上传至第一存储空间，并生成清除映射指令后结束升级流程。

对于本申请实施例，通过将升级后的业务逻辑脚本存放在远程服务器中升级前的存储位置处，而不是将升级后的业务逻辑脚本随机存放，以便于对业务逻辑脚本进行管理，并在将升级后的业务逻辑脚本上传至服务器后，对执行映射表内待升级业务逻辑脚本的第一存储地址与第二存储地址的地址映射关系清除，以便于降低对业务逻辑脚本执行时出现地址映射关系引用失误而出现执行误差的概率。

为了便于执行业务逻辑脚本，本申请提供的一种应用程序升级维护方法，还包括步骤S1(附图未示出)、步骤S2(附图未示出)、步骤S3(附图未示出)步骤S4(附图未示出)即步骤S5(附图未示出)，其中：

步骤S1：获取应用程序中的各个初始业务逻辑脚本的第一存储地址和第二存储地址，初始业务逻辑脚本为未经过升级操作的业务逻辑脚本。

具体的，SAAS(Software as a Service，软件运营服务)平台一般为多用户模式，即在其中一个应用程序的运行实例同时服务多个用户，每一用户都有独立的业务逻辑脚本，其中第一存储地址为远程服务器中存放待升级的业务逻辑脚本的存储地址，第二存储地址为第二存储空间内存放待升级的业务逻辑脚本的存储地址。

步骤S2：计算各个初始业务逻辑脚本的第一存储地址分别对应的哈希值。

具体的，每一业务逻辑脚本对应有不同的脚本特征，提取业务逻辑脚本中的脚本特征，并将提取到的多个脚本特征进行编码得到特征编码，利用哈希算法将特征编码进行计算，以得每一业务逻辑脚本对应的哈希(Hash)值，其中，对多个脚本特征进行编码时编码方式可以为ASCII码、UTF-8、URL编码或Base64编码，ASCII码中只存储英文字符，有127个字符，占一个字节；UTF-8编码可以存储中文，占两个字节；URL编码是浏览器发送数据时的一种编码，通常附加在URL的参数部分，由于很多服务器只能识别ASCII字符，并对字符进行编码，但是URL拥有一套独立的编码规则，在java的类库中提供了URLEncoder类，以实现对任意字符串进行编码；Base64编码是对二进制数据进行编码，转换成文本格式。具体的编码方式在本申请实施例中不做具体限定，只要能够将识别到的脚本特征进行编码即可。

哈希算法，即散列函数，它是一种单向密码体制,即是一个从明文到密文的不可逆的映射,同时,哈希函数可以将任意长度的输入经过变化以后得到固定长度的输出，通过哈希算法可将任意长度的业务逻辑脚本对应的特征编码映射为较短的固定长度的二进制值，这个固定长度的二进制值称为哈希值，哈希值是一段数据唯一且极其紧凑的数值表示形式，通过哈希值能够确定出对应的业务逻辑脚本。

步骤S3：将各个初始业务逻辑脚本的哈希值和各个初始业务逻辑脚本分别对应的第二存储地址进行绑定，得到各个初始业务逻辑脚本的地址映射关系。

具体的，将每一初始业务逻辑脚本对应的哈希值和第二存储地址进行绑定后，通过第二存储地址能够确定出对应的哈希值，由于通过哈希值能够确定出对应的业务逻辑脚本，因此通过第二存储地址也能确定出对应的业务逻辑脚本。

步骤S4：对各个初始业务逻辑脚本进行关键信息识别，根据识别结果确定各个初始业务逻辑脚本的重要级别，并根据各个初始业务逻辑脚本的重要级别对各个初始业务逻辑脚本排序得到重要级别序列。

具体的，对业务逻辑脚本进行关键信息识别时，可通过识别业务逻辑脚本对应的脚本信息中是否包含预设关键字信息，若脚本信息中存在预设关键字信息，通过预设关键字信息对应的重要等级，便于确定脚本信息对应的重要等级，其中预设关键字信息可基于历史调用信息中被多次调用的业务逻辑脚本进行确定。

步骤S5：根据重要级别序列和各个初始业务逻辑脚本对应的地址映射关系，构成执行映射表。

具体的，通过重要级别序列对多个业务逻辑脚本对应的映射关系进行排列，例如现有4个业务逻辑脚本，分别为业务逻辑脚本1、业务逻辑脚本2、业务逻辑脚本3及业务逻辑脚本4，并且每一业务逻辑脚本存在一个哈希值与第二存储地址进行绑定形成的映射关系，其中4个业务逻辑脚本形成的重要级别序列为业务逻辑脚本1、业务逻辑脚本3、业务逻辑脚本4、业务逻辑脚本2，按照重要级别序列构成的执行映射表可参考表1：

表1

业务逻辑脚本1	映射关系1
		业务逻辑脚本3	映射关系3
业务逻辑脚本4	映射关系4
		业务逻辑脚本2	映射关系2

对于本申请实施例，根据应用程序的每一业务逻辑脚本在第一存储空间内的存储地址，计算出每一业务逻辑脚本对应的哈希值，由于哈希值可作为业务逻辑脚本的身份标识，通过哈希值便于提高从多个业务逻辑脚本中确定目标业务逻辑脚本业务逻辑脚本时的效率，并且通过每一业务逻辑脚本的重要级别对每一业务逻辑脚本的地址映射关系进行排列，而不是将所有的业务逻辑脚本对应的地址映射关系随机存放，通过排序便于提高确定重要等级较高的业务逻辑脚本时的速率。

为了提高对业务逻辑脚本进行调用时的效率，该方法还包括步骤Sc1(附图未示出)、步骤Sc2(附图未示出)、步骤Sc3(附图未示出)、步骤Sc4(附图未示出)、步骤Sc5(附图未示出)及步骤Sc6(附图未示出)，其中：

步骤Sc1：当检测到用户触发的执行请求时，根据执行请求确定待执行的业务逻辑脚本，并获取待执行的业务逻辑脚本的第一存储地址。

步骤Sc2：识别待执行的业务逻辑脚本的第一存储地址中的地址标识，并根据识别到的地址标识确定待执行的业务逻辑脚本的类型，类型包括远程脚本类型和非远程脚本类型。

具体的，执行请求中包含对应的待升级的业务逻辑脚本的第一存储地址，通过对执行请求进行语义识别即可确定出执行请求中包含的待执行的业务逻辑脚本的第一存储地址，例如待执行的业务逻辑脚本的第一存储地址为http_cache://http://${bucket}.${region}.${domain}/companyID/scripts/trans_to_agent便可以从执行请求中获取，其中可通过识别执行请求中的引用标识，其中，引用标识用于引出待执行的业务逻辑脚本的第一存储地址，例如引用标识可以为lua，对执行请求进行引用标识检测，当检测到lua时，位于lua之后的数据为执行业务逻辑脚本地址，引用标识在本申请实施例中不做具体限定，只要能够通过引用标识确定出执行请求中对应的待执行的业务逻辑脚本的第一存储地址即可。

地址标识位于待执行的业务逻辑脚本的第一存储地址中，通过地址标识便于确定出待执行的业务逻辑脚本的类型，例如，当地址标识为“\”时，表征待执行的业务逻辑脚本的类型为非远程脚本，当地址标识为“//”时，表征待执行的业务逻辑脚本的类型为远程脚本。

步骤Sc3：若待执行的业务逻辑脚本的类型为远程脚本，则根据待执行的业务逻辑脚本的第一存储地址计算待执行的业务逻辑脚本对应的执行哈希值，执行哈希值为待执行的业务逻辑脚本的第一存储地址对应的哈希值。

具体的，确定待执行的业务逻辑脚本的执行哈希值的方式，可参考上述确定第一存储地址对应的哈希值的过程，在此不做赘述。

步骤Sc4：根据执行哈希值从执行映射表中进行遍历，以判断待执行的业务逻辑脚本是否为首次调用。

具体的，从执行映射表中进行遍历时，可将执行映射表中的第一个哈希值确定为目标哈希值，将目标哈希值与执行哈希值进行比较，并记录比较次数，直至目标哈希值为执行哈希值，或比较次数与执行映射表内哈希值数量相等，结束遍历。通过将执行哈希值与执行映射表内的每一哈希值进行比较以确定待执行的业务逻辑脚本是否为首次调用，若待执行的业务逻辑脚本为首次调用，则执行映射表内不存在该待执行的业务逻辑脚本对应的执行哈希值；若待执行的业务逻辑脚本非首次调用，则执行映射表内存在待执行的业务逻辑脚本对应的执行哈希值。

步骤Sc5：若待执行的业务逻辑脚本为首次调用，则基于待执行的业务逻辑脚本的第一存储地址，缓存待执行的业务逻辑脚本至第二存储空间内得到第二存储地址，执行待执行的业务逻辑脚本，并基于待执行的业务逻辑脚本的执行哈希值和待执行的业务逻辑脚本的第二存储地址，更新执行映射表。

具体的，若待执行的业务逻辑脚本为首次调用，即执行映射表内不存在该待执行的业务逻辑脚本对应的执行哈希值，需将待执行的业务逻辑脚本在第二存储空间内进行缓存后再执行，为了便于再次对待执行的业务逻辑脚本进行调用，可通过将该待执行的业务逻辑脚本对应的执行哈希值存入执行映射表内。

为了提高从执行映射表中调用业务逻辑脚本时的准确性，本申请实施例提供的方法还包括步骤Sd(附图未示出)，其中：

步骤Sd：获取待执行的业务逻辑脚本的数据量，并根据待执行的业务逻辑脚本的数据量，确定待执行的业务逻辑脚本在第二存储空间内的第二存储地址。

具体的，待执行的业务逻辑脚本的数据量为待执行的业务逻辑脚本中包含的文件数量，通过待执行的业务逻辑脚本中的文件数量确定待执行的业务逻辑脚本在第二存储空间内所需存储空间，并根据所需存储空间为待执行的业务逻辑脚本分配对应的存储地址。

其中，步骤Sc5中基于待执行的业务逻辑脚本的执行哈希值和待执行的业务逻辑脚本的第二存储地址，更新执行映射表，包括步骤Sc51(附图未示出)和步骤Sc52(附图未示出)，其中：

步骤Sc51：将待执行的业务逻辑脚本对应的执行哈希值与待执行的业务逻辑脚本的第二存储地址进行绑定，得到待执行的业务逻辑脚本的地址映射关系。

具体的，将第二存储地址与待执行的业务逻辑脚本对应的执行哈希值进行绑定，通过执行哈希值便于确定出待执行的业务逻辑脚本的第二存储地址，从而便于通过第二存储地址对待执行的业务逻辑脚本进行直接调用。

步骤Sc52：根据待执行的业务逻辑脚本的地址映射关系，更新执行映射表。

具体的，更新执行映射表，即将首次调用的待执行的业务逻辑脚本对应的执行哈希值写入执行映射表内，即将待执行的业务逻辑脚本的地址映射关系写入执行映射表内，写入之前可根据待执行的业务逻辑脚本与执行映射表内写入的业务逻辑脚本的重要级别进行确定，根据待执行的业务逻辑脚本的重要级别确定待执行的业务逻辑脚本的地址映射关系在执行映射表内的位置，并根据确定出的位置将待执行的业务逻辑脚本的地址映射关系写入完成更新。

通过待执行的业务逻辑脚本的数据量为待执行的业务逻辑脚本在第二存储空间内为其分配存储空间，而不是将待执行的业务逻辑脚本存放入随机分配的存储空间内，若随机分配的存储空间无法全部将待执行的业务逻辑脚本存储完毕，则需要再次为待执行的业务逻辑脚本分配存储空间，从而可能会增加分配存储空间过程中的工作量，并且两次分配的存储空间可能不相邻，随机分配存储空间可能会导致待执行的业务逻辑脚本在存储过程中发生丢失，通过待执行的业务逻辑脚本的数据量确定待执行的业务逻辑脚本在第二存储空间内的存储地址，便于保证待执行的业务逻辑脚本的完整性，并且便于对待执行的业务逻辑脚本进行管理，及时更新执行映射表便于降低在对执行映射表内的业务逻辑脚本进行调用时，发生调用误差的概率。

步骤Sc6：若待执行的业务逻辑脚本为非首次调用，则根据执行哈希值从执行映射表中确定待执行的业务逻辑脚本的第二存储地址，基于待执行的业务逻辑脚本的第二存储地址执行待执行的业务逻辑脚本。

具体的，若待执行的业务逻辑脚本不是被首次调用，则表征执行映射表内保存有待执行的业务逻辑脚本对应的执行哈希值，通过执行哈希值便于确定出待执行的业务逻辑脚本对应的第二存储地址，即第二存储空间内的存储地址。

如图3所示，图3为本申请实施例中一种业务逻辑脚本调用流程图，当检测到用户触发的执行请求时，根据执行请求确定待执行的业务逻辑脚本地址，并根据待执行的业务逻辑脚本的第一存储地址判断该待执行的业务逻辑脚本是否为远程脚本，当待执行的业务逻辑脚本不是远程脚本时，根据待执行的业务逻辑脚本地址从本地调用并执行；当待执行的业务逻辑脚本为远程脚本时，判断该待执行的业务逻辑脚本是否已缓存，当待执行的业务逻辑脚本已缓存时，即表征待执行的业务逻辑脚本非首次调用，则从缓存中进行调用并运行；当待执行的业务逻辑脚本为远程脚本，并且为首次调用时，根据待执行的业务逻辑脚本的第一存储地址从第一存储空间中下载缓存至第二存储空间，并计算待执行的业务逻辑脚本地址的执行哈希值，根据待执行的业务逻辑脚本的执行哈希值将待执行的业务逻辑脚本缓存后，运行该待执行的业务逻辑脚本。

对于本申请实施例，当待执行的业务逻辑脚本为远程脚本时，根据待执行的业务逻辑脚本的第一存储地址对应的执行哈希值判断该业务逻辑脚本是否为首次调用，若不是首次调用，则直接调用，若为首次调用，则先基于第一存储地址将待执行的业务逻辑脚本从远程服务器上下载，并缓存至第二存储空间后，生成该待执行的业务逻辑脚本的第一存储地址与第二存储地址的地址映射关系，通过将业务逻辑脚本先缓存至第二存储空间，并根据执行映射表对业务逻辑脚本逻辑进行调用便于提升对业务逻辑脚本进行调用时的效率，并且当业务逻辑脚本被调用后，该执行业务逻辑脚本对应的地址映射关系添加至执行映射表内，以便于提高再次对该业务逻辑脚本进行调用时的效率。

进一步地，步骤Sc5或步骤Sc6中，执行待执行的业务逻辑脚本包括步骤Se1(附图未示出)和步骤Se2(附图未示出)，其中：

步骤Se1：识别待执行的业务逻辑脚本中的关联信息，关联信息为待执行的业务逻辑脚本与对应的基础功能脚本之间的关联信息。

具体的，业务逻辑脚本与基础脚本之间存在关联，通过业务逻辑脚本可对基础脚本进行调用，确定业务逻辑脚本与基础脚本之间的关联信息时可通过在业务逻辑脚本与对应的基础脚本中增加关联标识，例如基础脚本可以为网页框架中的页面基础功能、弹窗基础功能以及导航栏基础功能，因此同一业务逻辑脚本可能存在多个不同的关联基础脚本，同一基础脚本也可能存在多个不同的关联业务逻辑脚本。关联信息中包括与执行业务逻辑脚本相关联的基础脚本的存储路径。

步骤Se2：根据关联信息，从第二存储空间内确定与待执行的业务逻辑脚本相关联的基础功能脚本，并将待执行的业务逻辑脚本与基础功能脚本融合得到融合脚本，并执行融合脚本。

具体的，第二存储空间可以为本地镜像，根据基础脚本的存储路径从本地镜像中对基础脚本进行调用，将待执行的业务逻辑脚本与基础脚本相融合时，可通过识别待执行的业务逻辑脚本中存在的调用接口确定每一调用接口对应的基础脚本，以使待执行的业务逻辑脚本与相关联的基础脚本进行融合。融合脚本中包括待执行的业务逻辑脚本以及与待执行的业务逻辑脚本相关联的基础脚本。

对于本申请实施例，通过待执行的业务逻辑脚本中的关联信息，便于确定出与待执行的业务逻辑脚本相关联的基础功能脚本，通过将对应的基础功能脚本与待执行的业务逻辑脚本相融合，再运行融合脚本以便于实现待执行的业务逻辑脚本对应的操作。

为了降低应用程序运行过程中出现故障的概率，该方法还包括步骤Sf1(附图未示出)、步骤Sf2(附图未示出)及步骤Sf3(附图未示出)，其中：

步骤Sf1：统计预设时间段内升级请求的数量，并确定每一升级请求对应的脚本，将升级请求的数量低于预设阈值的脚本确定为异常脚本。

具体的，预设时间段可以为5天、7天、15天，可由用户进行确定，在本申请实施例中不做具体限定，升级请求的发出数量可从工作日志中获取，当检测到升级请求时在工作日志中对升级请求出现的时刻以及出现次数进行记录，其中将检测到升级请求的时刻确定为升级时刻。预设阈值可由用户进行输入，在本申请实施例中不做具体限定。

步骤Sf2：根据每一异常脚本在预设时间段内升级请求的数量及对应的请求升级时刻，确定每一异常脚本的升级频率，请求升级时刻为检测到升级请求的时刻。

具体的，每一升级请求对应一个待升级的业务逻辑脚本，通过升级次数以及升级时刻便于确定出每一升级请求对应的升级频率，例如在5天内业务逻辑脚本a的升级次数为5次，并且每两个相邻的升级时刻之间间隔12小时以上，因此可确定业务逻辑脚本a的升级频率表为1天/次；若在6天内业务逻辑脚本b的调整次数为6次，但每两个相邻的升级时刻之间间隔低于12小时，则确定业务逻辑脚本b的升级频率为1天/2次。

步骤Sf3：根据每一异常脚本的升级频率以及脚本与标准升级频率的预设对应关系，确定超期脚本，并对超期脚本进行升级，超期脚本为升级频率低于对应标准升级频率的脚本。

具体的，不同的业务逻辑脚本对应的升级频率不同，预设的业务逻辑脚本与标准升级频率的对应关系可根据历史升级信息进行确定，也可以根据用户进行确定，在本申请实施例中不做具体限定，业务逻辑脚本的标准升级频率为使业务逻辑脚本在执行时出现漏洞的概率最低的频率，若业务逻辑脚本的升级频率低于对应的标准升级频率则可能会增大执行过程中出现漏洞的概率。

对超期业务逻辑脚本进行升级，即通过检测超期业务逻辑脚本中可能存在的漏洞，并对可能存在的漏洞进行修复，以实现对超期业务逻辑脚本进行升级，升级完成后电子设备生成清除映射指令，以清除超期业务逻辑脚本在执行映射表内的地址映射关系。

对于本申请实施例，根据预设时间段内升级请求的数量，以及每一升级请求各自对应的脚本，确定存在异常的脚本，并根据每一异常脚本对应的升级频率，确定出超期脚本，通过对超期业务逻辑脚本进行定期升级，以便于及时发现应用程序中业务逻辑脚本存在的漏洞，对应用程序中可能存在漏洞的业务逻辑脚本进行定期升级，便于降低应用程序运行过程中出现故障的概率。

上述实施例从方法流程的角度介绍一种应用程序升级维护方法，下述实施例从虚拟模块或者虚拟单元的角度介绍了一种应用程序升级维护装置，具体详见下述实施例。

本申请实施例提供一种应用程序升级维护装置，如图4所示，该装置具体可以包括确定脚本类型模块410、业务逻辑脚本上传模块420、以及基础功能脚本上传模块430，其中：

确定脚本类型模块410，用于当检测到用户触发的升级请求时，基于升级请求确定待升级脚本类型，待升级脚本类型包括业务逻辑脚本类型和基础功能脚本类型；

业务逻辑脚本上传模块420，用于当待升级脚本类型为业务逻辑脚本类型时，获取待升级的业务逻辑脚本，对待升级的业务逻辑脚本进行升级，得到升级后的业务逻辑脚本，并将升级后的业务逻辑脚本重新上传至第一存储空间；

基础功能脚本上传模块430，用于当待升级脚本类型为基础功能脚本类型时，获取待升级的基础功能脚本，对待升级的基础功能脚本进行镜像处理，并将镜像处理后的基础功能脚本存储至第二存储空间。

在一种可能实现的方式中，该装置还包括：

确定业务脚本业务逻辑脚本模块，用于根据调整请求，确定调整请求对应的待调整业务脚本业务逻辑脚本；

获取第一存储地址模块，用于获取待升级的业务逻辑脚本对应的第一存储地址，第一存储地址为远程服务器上存储待升级的业务逻辑脚本的存储地址；

其中，业务逻辑脚本上传模块420在将升级后的业务逻辑脚本重新上传至第一存储空间时，具体用于：

按照第一存储地址将升级后的业务逻辑脚本上传至远程服务器；

生成清除指令模块，用于生成清除映射指令，清除映射指令用于清除执行映射表内待升级的业务逻辑脚本对应的第一存储地址与第二存储地址的地址映射关系，第二存储地址为第二存储空间内存储待升级的业务逻辑脚本的存储地址。

在一种可能实现的方式中，该装置还包括：

获取地址模块，用于获取应用程序中的各个初始业务逻辑脚本的第一存储地址和第二存储地址，初始业务逻辑脚本为未经过升级操作的业务逻辑脚本；

计算确定哈希值模块，用于计算各个初始业务逻辑脚本的第一存储地址分别对应的哈希值；确定地址映射关系模块，用于将各个初始业务逻辑脚本的哈希值和各个初始业务逻辑脚本分别对应的第二存储地址进行绑定，得到各个初始业务逻辑脚本的地址映射关系；

确定重要级别序列模块，用于对各个初始业务逻辑脚本进行关键信息识别，根据识别结果确定各个初始业务逻辑脚本的重要级别，并根据各个初始业务逻辑脚本的重要级别对各个初始业务逻辑脚本排序得到重要级别序列；

构成映射表模块，用于根据重要级别序列和各个初始业务逻辑脚本对应的地址映射关系，构成执行映射表。

在一种可能实现的方式中，该装置还包括：

确定待执行的业务逻辑脚本地址模块，用于当检测到用户触发的执行请求时，根据执行请求确定待执行的业务逻辑脚本，并获取待执行的业务逻辑脚本的第一存储地址；

确定业务脚本业务逻辑脚本的类型模块，用于识别待执行的业务逻辑脚本的第一存储地址中的地址标识，并根据识别到的地址标识确定待执行的业务逻辑脚本的类型，类型包括远程脚本类型和非远程脚本类型；

确定执行哈希值模块，用于若待执行的业务逻辑脚本的类型为远程脚本类型，则根据待执行的业务逻辑脚本的第一存储地址计算待执行的业务逻辑脚本对应的执行哈希值，执行哈希值为待执行的业务逻辑脚本的第一存储地址对应的哈希值；

遍历模块，用于根据执行哈希值从执行映射表中进行遍历，以判断待执行的业务逻辑脚本是否为首次调用；

第一调用执行模块，用于若待执行的业务逻辑脚本为首次调用，则基于待执行的业务逻辑脚本的第一存储地址，缓存待执行的业务逻辑脚本至第二存储空间内得到第二存储地址，执行待执行的业务逻辑脚本，并基于待执行的业务逻辑脚本的执行哈希值和待执行的业务逻辑脚本的第二存储地址，更新执行映射表；。

第二调用执行模块，用于若待执行的业务逻辑脚本不是首次调用，则根据执行哈希值从执行映射表中确定待执行的业务逻辑脚本的第二存储地址，基于待执行的业务逻辑脚本的第二存储地址执行待执行的业务逻辑脚本。

在一种可能实现的方式中，该装置还包括：

获取数据量模块，用于获取待执行的业务逻辑脚本的数据量，并根据待执行的业务逻辑脚本的数据量，确定待执行的业务逻辑脚本在第二存储空间内的第二存储地址；

其中，第一调用执行模块在基于待执行的业务逻辑脚本的执行哈希值和待执行的业务逻辑脚本的第二存储地址，更新执行映射表时，具体用于：

将待执行的业务逻辑脚本对应的执行哈希值与待执行的业务逻辑脚本的第二存储地址进行绑定，得到待执行的业务逻辑脚本的地址映射关系；

根据待执行的业务逻辑脚本的地址映射关系，更新执行映射表。

在一种可能实现的方式中，第一调用执行模块或第二调用执行模块在执行待执行的业务逻辑脚本时，具体用于：

识别待执行的业务逻辑脚本中的关联信息，关联信息为待执行的业务逻辑脚本与对应的基础功能脚本之间的关联信息；

根据关联信息，从第二存储空间内确定与待执行的业务逻辑脚本相关联的基础功能脚本，并将待执行的业务逻辑脚本与基础功能脚本融合得到融合脚本，并执行融合脚本。

在一种可能实现的方式中，该装置还包括：

统计调整请求数量模块确定异常脚本模块，用于统计预设时间段内调整请求的数量，并确定每一升级请求对应的脚本，将升级请求的数量低于预设阈值的脚本确定为异常脚本；

确定升级调整频率模块，用于根据每一异常脚本在预设时间段内升级请求的数量及对应的请求升级时刻，确定每一异常脚本的升级频率，请求升级时刻为检测到升级请求的时刻；

超期升级模块，用于根据每一异常脚本的升级频率以及脚本与标准升级频率的预设对应关系，确定超期脚本，并对超期脚本进行升级，超期脚本为升级频率低于对应标准升级频率的脚本。。

本申请实施例中提供了一种电子设备，如图5所示，图5所示的电子设备500包括：处理器501和存储器503。其中，处理器501和存储器503相连，如通过总线502相连。可选地，电子设备500还可以包括收发器504。需要说明的是，实际应用中收发器504不限于一个，该电子设备500的结构并不构成对本申请实施例的限定。

处理器501可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器501也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线502可包括一通路，在上述组件之间传送信息。总线502可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线502可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器503可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器503用于存储执行本申请方案的应用程序代码，并由处理器501来控制执行。处理器501用于执行存储器503中存储的应用程序代码，以实现前述方法实施例所示的内容。

其中，电子设备包括但不限于：移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。还可以为服务器等。图5示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种应用程序升级维护方法，其特征在于，包括：

当检测到用户触发的升级请求时，基于所述升级请求确定待升级脚本类型，所述待升级脚本类型包括业务逻辑脚本类型和基础功能脚本类型；

当所述待升级脚本类型为业务逻辑脚本类型时，获取待升级的业务逻辑脚本，对所述待升级的业务逻辑脚本进行升级，得到升级后的业务逻辑脚本，并将所述升级后的业务逻辑脚本重新上传至第一存储空间；

当所述待升级脚本类型为基础功能脚本类型时，获取待升级的基础功能脚本，对所述待升级的基础功能脚本进行镜像处理，并将镜像处理后的基础功能脚本存储至第二存储空间。

2.根据权利要求1所述的一种应用程序升级维护方法，其特征在于，所述第一存储空间包括远程服务器，所述将所述升级后的业务逻辑脚本重新上传至第一存储空间，之前还包括：

获取所述待升级的业务逻辑脚本对应的第一存储地址，所述第一存储地址为所述远程服务器上存储所述待升级的业务逻辑脚本的存储地址；

其中，所述将所述升级后的业务逻辑脚本重新上传至第一存储空间，包括：

按照所述第一存储地址将所述升级后的业务逻辑脚本上传至所述远程服务器；

所述将所述升级后的业务逻辑脚本重新上传至第一存储空间，之后还包括：

生成清除映射指令，所述清除映射指令用于清除执行映射表内所述待升级的业务逻辑脚本对应的第一存储地址与第二存储地址的地址映射关系，所述第二存储地址为所述第二存储空间内存储所述待升级的业务逻辑脚本的存储地址。

3.根据权利要求2所述的一种应用程序升级维护方法，其特征在于，执行映射表的建立方式，包括：

获取应用程序中的各个初始业务逻辑脚本的第一存储地址和第二存储地址，所述初始业务逻辑脚本为未经过升级操作的业务逻辑脚本；

计算各个初始业务逻辑脚本的第一存储地址分别对应的哈希值；

将各个初始业务逻辑脚本的哈希值和各个初始业务逻辑脚本分别对应的第二存储地址进行绑定，得到各个初始业务逻辑脚本的地址映射关系；

对各个初始业务逻辑脚本进行关键信息识别，根据识别结果确定各个初始业务逻辑脚本的重要级别，并根据各个初始业务逻辑脚本的重要级别对各个初始业务逻辑脚本排序得到重要级别序列；

根据所述重要级别序列和各个初始业务逻辑脚本对应的地址映射关系，构成执行映射表。

4.根据权利要求2所述的一种应用程序升级维护方法，其特征在于，还包括：

当检测到用户触发的执行请求时，根据所述执行请求确定待执行的业务逻辑脚本，并获取所述待执行的业务逻辑脚本的第一存储地址；

识别所述待执行的业务逻辑脚本的第一存储地址中的地址标识，并根据识别到的地址标识确定所述待执行的业务逻辑脚本的类型，所述类型包括远程脚本类型和非远程脚本类型；

若所述待执行的业务逻辑脚本的类型为远程脚本类型，则根据所述待执行的业务逻辑脚本的第一存储地址计算所述待执行的业务逻辑脚本对应的执行哈希值，所述执行哈希值为待执行的业务逻辑脚本的第一存储地址对应的哈希值；

根据所述执行哈希值从所述执行映射表中进行遍历，以判断所述待执行的业务逻辑脚本是否为首次调用；

若是，则基于所述待执行的业务逻辑脚本的第一存储地址，缓存所述待执行的业务逻辑脚本至所述第二存储空间内得到第二存储地址，执行所述待执行的业务逻辑脚本，并基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表；

若否，则根据所述执行哈希值从所述执行映射表中确定所述待执行的业务逻辑脚本的第二存储地址，基于所述待执行的业务逻辑脚本的第二存储地址执行所述待执行的业务逻辑脚本。

5.根据权利要求4所述的一种应用程序升级维护方法，其特征在于，所述基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表，之前还包括：

获取所述待执行的业务逻辑脚本的数据量，并根据所述待执行的业务逻辑脚本的数据量，确定所述待执行的业务逻辑脚本在所述第二存储空间内的第二存储地址；

其中，所述基于所述待执行的业务逻辑脚本的执行哈希值和所述待执行的业务逻辑脚本的第二存储地址，更新所述执行映射表，包括：

将所述待执行的业务逻辑脚本对应的执行哈希值与所述待执行的业务逻辑脚本的第二存储地址进行绑定，得到所述待执行的业务逻辑脚本的地址映射关系；

根据所述待执行的业务逻辑脚本的地址映射关系，更新所述执行映射表。

6.根据权利要求4所述的一种应用程序升级维护方法，其特征在于，所述执行所述待执行的业务逻辑脚本，包括：

识别所述待执行的业务逻辑脚本中的关联信息，所述关联信息为所述待执行的业务逻辑脚本与对应的基础功能脚本之间的关联信息；

根据所述关联信息，从所述第二存储空间内确定与所述待执行的业务逻辑脚本相关联的基础功能脚本，并将所述待执行的业务逻辑脚本与所述基础功能脚本融合得到融合脚本，并执行所述融合脚本。

7.根据权利要求1所述的一种应用程序升级维护方法，其特征在于，还包括：

统计预设时间段内升级请求的数量，并确定每一升级请求对应的脚本，将升级请求的数量低于预设阈值的脚本确定为异常脚本；

根据每一异常脚本在所述预设时间段内升级请求的数量及对应的请求升级时刻，确定每一异常脚本的升级频率，所述请求升级时刻为检测到升级请求的时刻；

根据所述每一异常脚本的升级频率以及脚本与标准升级频率的预设对应关系，确定超期脚本，并对所述超期脚本进行升级，所述超期脚本为升级频率低于对应标准升级频率的脚本。

8.一种应用程序升级维护装置，其特征在于，包括：

确定脚本类型模块，用于当检测到用户触发的升级请求时，基于所述升级请求确定待升级脚本类型，所述待升级脚本类型包括业务逻辑脚本类型和基础功能脚本类型；

业务逻辑脚本上传模块，用于当所述待升级脚本类型为业务逻辑脚本类型时，获取待升级的业务逻辑脚本，对所述待升级的业务逻辑脚本进行升级，得到升级后的业务逻辑脚本，并将所述升级后的业务逻辑脚本重新上传至第一存储空间；

基础功能脚本上传模块，用于当所述待升级脚本类型为基础功能脚本类型时，获取待升级的基础功能脚本，对所述待升级的基础功能脚本进行镜像处理，并将镜像处理后的基础功能脚本存储至第二存储空间。

9.一种电子设备，其特征在于，该电子设备包括：

至少一个处理器；

存储器；

至少一个应用程序，其中所述至少一个应用程序被存储在存储器中并被配置为由至少一个处理器执行，所述至少一个应用程序配置用于：执行权利要求1-7中任一项所述的一种应用程序升级维护方法。

10.一种计算机可读存储介质，其特征在于，包括：存储有能够被处理器加载并执行如权利要求1-7中任一种所述的一种应用程序升级维护方法的计算机程序。

Images