CN117032770A - 应用程序更新方法及装置 - Google Patents

Abstract

本申请实施例提供了一种应用程序更新方法及装置，涉及计算机技术领域，其中，一种应用程序更新方法，包括：采集包含多个微服务组件的应用程序在运行过程中产生的运行信息；根据运行信息，识别多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，微服务组件对应的第一依赖包括微服务组件调用的依赖；根据所识别的第一依赖信息和预先建立的依赖库，确定与每个微服务组件分别匹配的多个第二依赖的第二依赖信息；其中，微服务组件匹配的第二依赖至少包括微服务组件对应的第一依赖；基于第二依赖信息，更新多个微服务组件对依赖的调用。本申请实施例可以提高应用程序更新的准确性和便捷性。

Description

应用程序更新方法及装置

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种应用程序更新方法及装置。

背景技术

分布式应用程序(application，APP)是一种以微服务的开发风格开发的应用程序。分布式应用程序中通常包括拆分大型的应用程序得到的多个小型的、独立的应用程序，每个小型的应用程序也可以称为微服务组件，分别运行在各自的进程中，拥有各自独立的运行环境以及依赖。其中，依赖可以包括每个微服务组件运行中调用的各种类库、开源组件、应用程序接口(application programming interface，API)等对象。

相关技术中，应用程序的依赖很可能随着时间推移而需要进行更新。例如，可以由开发人员人工排查以及替换应用程序的依赖，如人工将部分类库更换为安全性更高的类库，将部分API更换为新版本等，将一些开源组件替换为另一性能更好的开源组件等。

但是，上述应用程序更新方式容易存在效率较低，以及主观因素导致的更新不够准确的问题。

发明内容

为了解决上述技术问题，本申请提供一种应用程序更新方法及装置。该应用程序更新方法中，根据应用程序运行过程中的运行信息自动识别应用程序中每个微服务组件所调用的依赖的依赖信息，进而基于所识别的依赖信息自动推荐与应用程序匹配的依赖以用于更新应用程序，从而避免主观因素导致的低效率及不够准确的问题，提高应用程序更新的效率及准确度。

第一方面，本申请实施例提供一种应用程序更新方法，该方法包括：采集包含多个微服务组件的应用程序在运行过程中产生的运行信息；根据运行信息，识别多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，微服务组件对应的第一依赖包括微服务组件调用的依赖；根据所识别的第一依赖信息和预先建立的依赖库，确定与每个微服务组件分别匹配的多个第二依赖的第二依赖信息；其中，微服务组件匹配的第二依赖至少包括微服务组件对应的第一依赖；基于第二依赖信息，更新多个微服务组件对依赖的调用。

本申请实施例，通过应用程序运行过程中产生的运行信息识别应用程序中微服务组件所调用依赖的第一依赖信息，进而基于第一依赖信息从预先建立的依赖库中确定与应用程序匹配的第二依赖的第二依赖信息，并基于第二依赖信息更新应用程序中微服务对依赖的调用，从而实现对应用程序中微服务所调用依赖的自动识别以及更新，且基于应用程序运行过程中的运行信息实现，可以避免对从云端调用的依赖的遗漏，以及主观因素导致的更新不准确，保证对应用程序的更新更加全面和准确以及便捷。

根据第一方面，基于第二依赖信息，更新多个微服务组件对依赖的调用，包括：在为微服务组件加载可替换依赖的过程中，获取第二依赖信息指示的推荐依赖；其中，可替换依赖包括微服务组件对应的第一依赖中第一依赖信息与微服务组件的第二依赖信息不同的第一依赖；利用所获取的推荐依赖替换可替换依赖。

本申请实施例，通过在为微服务组件加载可替换依赖的过程中利用所获取的推荐依赖替换可替换依赖，实现在应用程序运行过程中的依赖更新也即热替换，可以保证更加全面更新依赖，进一步提高应用程序更新的准确度。

根据第一方面，或者以上第一方面的任意一种实现方式，根据所识别的第一依赖信息和预先建立的依赖库，确定与每个微服务组件分别匹配的多个第二依赖的第二依赖信息，包括：获取依赖库存储的多个第三依赖信息；将所识别的第一依赖信息和多个第三依赖信息输入预先训练得到的推荐模型，得到多个第三依赖信息中每个第三依赖信息与所识别的第一依赖信息对应的微服务组件间的匹配度；其中，推荐模型为利用样本依赖信息和样本依赖信息与样本应用程序的匹配度标签训练得到的模型；确定多个第三依赖信息中匹配度大于或者等于匹配度阈值的第二依赖信息。

本申请实施例，通过多个第三依赖信息与微服务组件间的匹配度，确定匹配度大于或者等于匹配度阈值的第二依赖信息，从而保证后续基于第二依赖信息进行的依赖更新适用于应用程序，更加准确。

根据第一方面，或者以上第一方面的任意一种实现方式，采集包含多个微服务组件的应用程序在运行过程中产生的运行信息之前，方法还包括：在应用程序启动运行的情况下，获取每个微服务组件的代码的代码特征；分别根据每个微服务组件的代码特征，确定微服务组件的代码的目标区域；在目标区域中添加更新模块组；其中，更新模块组用于执行采集包含多个微服务组件的应用程序在运行过程中产生的运行信息。

本申请实施例，在应用程序的运行过程中进行代码增强(例如添加特征识别模块、依赖推荐模块和热替模块)，可以适用于应用程序生命周期的任一阶段，而非局限于代码开发阶段，适用范围更广。

根据第一方面，或者以上第一方面的任意一种实现方式，在应用程序启动运行时，方法还包括：接收针对应用程序配置的代理信息；通过代理信息指示的代理执行利用所获取的推荐依赖替换可替换依赖，或者获取每个微服务组件的代码的代码特征。

本申请实施例，通过预先配置的代理实现依赖替换以及添加更新模块组，更加高效便捷。

根据第一方面，或者以上第一方面的任意一种实现方式，根据运行信息，识别多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息，包括：对运行信息进行特征提取，得到多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，第一依赖信息包括如下至少之一：依赖名称、依赖调用路径和依赖中的参数信息。

本申请实施例，通过对运行信息进行特征提取确定第一依赖信息，从而保证第一依赖信息指示的依赖也即应用程序所调用的第一依赖的识别更加全面、准确。

根据第一方面，或者以上第一方面的任意一种实现方式，基于第二依赖信息，更新多个微服务组件对依赖的调用之后，方法还包括：展示更新的更新内容。

本申请实施例，通过展示更新内容，便于用户基于更新内容进行应用程序的进一步处理。

根据第一方面，或者以上第一方面的任意一种实现方式，基于第二依赖信息，更新多个微服务组件对依赖的调用，包括：基于第二依赖信息，展示是否进行依赖更新的提示信息；在接收到提示信息对应的更新指令的情况下，基于第二依赖信息，更新多个微服务组件对依赖的调用。

本申请实施例，通过展示提示信息，能够实现可选的热替功能也即基于用户选择确定是否自动进行应用程序的依赖更新。更加便捷和符合用户需求。

第二方面，本申请实施例提供一种应用程序更新装置，该装置包括：特征识别模块，用于采集包含多个微服务组件的应用程序在运行过程中产生的运行信息；根据运行信息，识别多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，微服务组件对应的第一依赖包括微服务组件调用的依赖；推荐模块，用于根据所识别的第一依赖信息和预先建立的依赖库，确定与每个微服务组件分别匹配的多个第二依赖的第二依赖信息；其中，微服务组件匹配的第二依赖至少包括微服务组件对应的第一依赖；更新模块，用于基于第二依赖信息，更新多个微服务组件对依赖的调用。

根据第二方面，更新模块，具体用于：在为微服务组件加载可替换依赖的过程中，获取第二依赖信息指示的推荐依赖；其中，可替换依赖包括微服务组件对应的第一依赖中第一依赖信息与微服务组件的第二依赖信息不同的第一依赖；利用所获取的推荐依赖替换可替换依赖。

根据第二方面，或者以上第二方面的任意一种实现方式，推荐模块，具体用于：获取依赖库存储的多个第三依赖信息；将所识别的第一依赖信息和多个第三依赖信息输入预先训练得到的推荐模型，得到多个第三依赖信息中每个第三依赖信息与所识别的第一依赖信息对应的微服务组件间的匹配度；其中，推荐模型为利用样本依赖信息和样本依赖信息与样本应用程序的匹配度标签训练得到的模型；确定多个第三依赖信息中匹配度大于或者等于匹配度阈值的第二依赖信息。

根据第二方面，或者以上第二方面的任意一种实现方式，装置还包括增强模块，用于：在应用程序启动运行的情况下，获取每个微服务组件的代码的代码特征；分别根据每个微服务组件的代码特征，确定微服务组件的代码的目标区域；在目标区域中添加更新模块组；其中，更新模块组用于执行采集包含多个微服务组件的应用程序在运行过程中产生的运行信息。

根据第二方面，或者以上第二方面的任意一种实现方式，装置还包括增强模块，用于：在应用程序启动运行时，接收针对应用程序配置的代理信息；通过代理信息指示的代理执行利用所获取的推荐依赖替换可替换依赖，或者获取每个微服务组件的代码的代码特征。

根据第二方面，或者以上第二方面的任意一种实现方式，特征识别模块，具体用于：对运行信息进行特征提取，得到多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，第一依赖信息包括如下至少之一：依赖名称、依赖调用路径和依赖中的参数信息。

根据第二方面，或者以上第二方面的任意一种实现方式，更新模块还用于：展示更新的更新内容。

根据第二方面，或者以上第二方面的任意一种实现方式，更新模块，具体用于：基于第二依赖信息，展示是否进行依赖更新的提示信息；在接收到提示信息对应的更新指令的情况下，基于第二依赖信息，更新多个微服务组件对依赖的调用。

第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第三方面，本申请实施例提供了一种电子设备，包括：处理器和收发器；存储器，用于存储一个或多个程序；当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如第一方面以及第一方面的任意一种实现方式中任一项的方法。

第四方面，本申请实施例提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第五方面，本申请实施例提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。

第六方面，本申请实施例提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种电子设备100的结构框图；

图2是本申请实施例提供的一种应用程序更新系统的架构框图；

图3是本申请实施例提供的一种应用程序更新方法的流程示意图之一；

图4是本申请实施例提供的一种应用程序更新方法的流程示意图之一。

具体实施方式

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

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

为了便于理解本实施例，首先对本实施例所涉及的一些技术术语和背景技术进行介绍：

Java应用程序：使用Java语言开发的应用程序。

代理(Java Agent)：是Java平台提供的一种可编程的方式，它可以动态地检测和修改Java应用程序的运行行为。Java Agent可以通过在Java虚拟机启动时加载一个独立的Java Agent程序也可称为代理，拦截和修改应用程序的字节码，从而实现对应用程序的运行行为的检测和控制。

依赖：在软件开发中，依赖指软件所依赖的该软件自身以外的代码库或模块。其中，模块例如可以是开源组件、API指示的模块。

Class文件：Class文件是Java代码编译后得到的文件，具体可以包括一组以8位字节为基础单位的二进制流，代码的各数据项目经编译后按照有序排列在Class文件之中。Java应用程序可以运行在各种不同的平台上，这些平台提供了一个Java运行环境：虚拟机(JVM)，这些虚拟机都可以载入和执行与平台无关的字节码文件——Class文件。

插桩：一种更改Class文件中字节码的技术手段。通过代理Java Agent在应用程序的主函数(main)执行前或执行后确定拦截字节码加载的时机，并通过更改类字节码的方式，完成业务逻辑注入的，例如，通过接口的形式直接注入Java代码。举例而言，插桩技术可以是cglib、javaassit等。

在分布式应用程序开发中，通常将大型的应用拆分成多个小型的、独立的应用程序，每个小型的应用程序可以独立的部署、扩展和维护。每个应用程序运行在自己的进程中，拥有自己独立的运行环境，每个应用程序有自己的依赖的第三方的各种类库、开源组件和API。Java应用程序一般为分布式应用程序，可以包含多个微服务组件，每个微服务组件很可能存在上述依赖。例如，一个微服务组件通常会存在的依赖：各种类库、开源组件、API，而随着时间的推移，一些类库可能缺乏维护并已经过时，一些类库可能因为安全性等问题不建议使用，一些API可能已提供新版本。对此，可以通过人工排查来识别并处理类似的场景。然而人工排查存在一些不足，例如，效率低，主观因素导致的依赖排查和更新不准确等问题。

因此，本申请实施例提供了一种应用程序更新方法，以解决上述问题。示例性地，应用本申请实施例提供的应用程序更新方法，可以根据应用程序运行过程中产生的运行信息识别应用程序中微服务组件所调用依赖的第一依赖信息，进而基于第一依赖信息从预先建立的依赖库中确定与应用程序匹配的第二依赖的第二依赖信息，并基于第二依赖信息更新应用程序中微服务对依赖的调用，从而实现对应用程序中微服务所调用依赖的自动识别以及更新，且基于应用程序运行过程中的运行信息实现，可以避免对从云端调用的依赖的遗漏，以及主观因素导致的更新不准确，保证对应用程序的更新更加全面和准确以及便捷。

在对本申请实施例的技术方案说明之前，首先结合附图对本申请实施例的应用程序更新方法中，应用程序的运行平台进行说明，本申请实施例可以应用于电子设备上。在本申请实施例具体实施的过程中，该电子设备例如可以为计算机、服务器、多个服务器组成的计算集群、移动终端、便携式计算机、智能穿戴设备、网络电视等电子设备。举例而言，图1是本申请实施例提供的一种电子设备100的结构框图。如图1所示，电子设备100可包括：处理器101、通信线路105、内存103、存储介质104以及至少一个通信接口102中的部分或全部部件。

其中，处理器101用于执行本申请后续实施例所提供的应用程序更新方法。

具体的，处理器101可以包含通用中央处理器(central processing unit，CPU)，处理器101还可以包含微处理器、现场可编程逻辑门阵列(Field Programmable GateArray，FPGA)、数字信号处理器(digital signal processing，DSP)或者特定应用集成电路(application-specific integrated circuit，ASIC)、或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

通信线路105用于将电子设备100中各部件连接。具体的，通信线路105可以包括数据总线、电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为通信线路105。

内存103可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。内存103可以是独立存在，通过通信线路105与处理器101相连接。内存103也可以和处理器101集成在一起。其中，内存103存储有计算机指令。处理器101可以通过执行内存103中存储的计算机指令，实现本申请后续实施例所提供的应用程序更新方法。可选的，本实施例中的计算机执行指令也可以称之为应用程序代码，本实施例对此不作具体限定。

存储介质104用于存储计算机指令以及实现本申请实施例技术方案的各种数据，以便电子设备100在执行本申请后续实施例提供的应用程序更新方法时，将存储介质104中存储的计算机指令和各种数据加载至内存103中，以使得处理器101可以通过执行内存103中存储的计算机指令，实现本申请实施例所提供的应用程序更新方法。

通信接口102使用任何收发器一类的电子设备，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local areanetworks，WLAN)等。

应该理解的是，图1所示的电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

图2是本申请实施例提供的一种应用程序更新系统的架构框图。如图2所示，应用程序更新系统200可以运行在电子设备100上，该系统可以包括控制面和用户面。

用户面具体可以是图1所示电子设备的人机交互模块，用于用户对应用程序更新系统进行操作，例如，启动应用程序的操作，以及启动应用程序后向用户展示更新内容。其中，更新内容是控制面对应用程序的依赖调用的更新内容。在一种示例中，更新内容可以包括：当前使用的依赖：软件包A1；软件包A2；API V1。推荐使用的依赖：软件包B1；软件包B2；API V2。也就是说，控制面可以在将当前使用的依赖更新为推荐使用的依赖也即完成更新的情况下，通过用户面展示更新内容。在一种可选的示例中，控制面可以在得到更新内容的情况下，执行更新前，在用户面展示提示信息(例如，更新按钮和不更新按钮等)，用于指示用户输入更新指令，更新指令用于指示是否按照所展示的更新内容进行更新。这样，在用户输入的更新指令指示更新的情况下，控制面即按照所展示的更新内容更新应用程序的依赖调用。也就是说，控制面可以在通过用户面展示更新内容、且接收到指示更新的指令的情况下，将当前使用的依赖更新为推荐使用的依赖也即完成更新。在一种可选的示例中，控制面可以在得到更新内容的情况下，在用户面展示更新内容，从而用户可以根据更新内容手动进行依赖更新。

控制面至少可以包括启动模块(图中未示出)、APP运行模块、特征识别模块和推荐模块。其中，启动模块用于配合人机交互模块启动应用程序。在一种示例中，启动模块可以自行启动应用程序，例如，按照用户预先设置的启动周期、检测到用户设置的触发条件等启动应用程序。APP运行模块用于通过APP文件也即应用程序的软件包运行应用程序。特征识别模块用于检测APP运行过程中产生的运行信息以获得应用程序中依赖的特征也即依赖信息。推荐模块用于根据特征识别模块得到的特征进行应用程序的依赖推荐，也就是确定用于更新应用程序中依赖的新的依赖。在本示例中，预先建立的依赖库可以与运行应用程序的电子设备100不同，例如，可以是云存储平台，电子设备100可以远程访问依赖库。依赖库用于存储依赖信息，可以包括应用程序当前使用的依赖的新版本、比当前使用的依赖更优的依赖等。依赖库中的依赖信息可以是人工录入即人手工配置、Cve(CommonVulnerabilities&Exposures，通用漏洞披露)库数据等。

在一种示例中，控制面还可以包括代码增强模块、热替模块和预先建立的依赖库。其中，代码增强模块用于增加或改进应用程序现有代码的功能，具体的，可以是在应用程序启动的情况下降特征识别模块、推荐模块和热替模块添加至应用程序中以添加依赖更新功能至应用程序。热替模块用于根据推荐模块的确定的推荐结果自动进行应用程序中依赖的更新。

在一种示例中，应用程序更新系统还可以包括推荐结果输出模块，用于实现上述用户面展示更新内容的功能，也就是说对推荐结果和/或热替结果进行展示。

为了便于理解和合理布局，对上述模块功能的具体实现方式后续在图3和图4实施例中进行说明。

应该理解的是，图1所示的电子设备100仅是电子设备的一个范例，并且电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

为了便于理解，下面结合图3和图4对本申请实施例提供的应用程序更新方法进行具体说明。

图3是本申请实施例提供的一种应用程序更新方法的流程示意图之一。如图3所示，本申请实施例提供的一种应用程序更新方法，可以包括如下步骤：

S301，采集包含多个微服务组件的应用程序在运行过程中产生的运行信息。

一个微服务组件用于实现应用程序的一个功能也可以称为微服务模块。在一种示例中，一个微服务组件可以包括多个互为副本的微服务实例。

在一种可选的示例中，在应用程序启动运行时，也就是上述S301之前，本申请实施例提供的应用程序更新方法，还可以包括如下步骤：接收针对应用程序配置的代理信息。其中，代理信息用于指示代理，代理用于获取每个微服务组件的代码的代码特征。

示例性的，图4是本申请实施例提供的一种应用程序更新方法的流程示意图之一。如图4所示，应用程序更新系统中启动模块的子模块配置模块，可以响应于应用程序启动，获取针对应用程序配置的代理信息，也即获取代理文件位置，设置配置文件。这样，该应用程序中代码增强模块的启动和添加子模块可以根据配置文件加载代理以运行代理。举例而言，用户启动应用时指定Java Agent文件(例如，用于实现代理功能的软件)的位置，当Java虚拟机JVM启动即应用程序启动时、且在执行应用程序main函数之前，运行代理的入口函数例如premain。

在一种可选的示例中，在应用程序启动运行的情况下，获取每个微服务组件的代码的代码特征；

分别根据每个微服务组件的代码特征，确定微服务组件的代码的目标区域；

在目标区域中添加更新模块组；其中，更新模块组用于执行采集包含多个微服务组件的应用程序在运行过程中产生的运行信息。

代理运行的情况下，启动和添加子模块通过代理进行目标区域插桩和规则代码注入。具体的，启动和添加子模块通过代理在Class文件加载过程中完成两个功能：代码分析和插桩。

代码分析可以包括通过正则表达式、预先训练得到的识别模型等获取代码特征以及根据代码特征识别应用程序代码中可以用于添加增强功能的代码区域即目标区域。其中，目标区域例如可以是微服务组件的开头位置或者结尾位置。识别模型为利用样本代码和样本代码的目标区域标签训练得到的神经网络模型。

插桩可以包括代码增强模块的启动和添加子模块识别需要增强的代码区域后，使用插桩技术将特定代码注入到这些区域即目标区域。其中，特定代码即更新模块组，具体可以包括特征识别模块和推荐模块，在一种示例中还可以包括热替模块。这样，电子设备可以在应用程序运行过程中改进应用程序代码的功能，适用于应用程序生命周期的任一阶段，而非局限于代码开发阶段，适用范围更广。通过插桩，可以实现在应用程序的类加载、网络调用依赖、API调用等依赖调用前以及调用后进行应用程序的运行信息采集。其中，运行信息例如可以是应用程序运行过程中记载的类、方法、调用的接口和获取的参数等对象的信息。

S302，根据运行信息，识别多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，微服务组件对应的第一依赖包括微服务组件调用的依赖。

仍参见图4，特征识别模块在得到运行信息后，可以识别依赖：根据运行信息，识别多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息。在一种可选的示例中，上述根据运行信息，识别多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息，可以包括如下步骤：

对运行信息进行特征提取，得到多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，第一依赖信息包括如下至少之一：依赖名称、依赖调用路径和依赖中的参数信息。

举例而言，依赖名称例如可以包括类名、方法名、API名称等。依赖调用路径例如可以包括HTTP请求地址URI等，参数信息例如可以包括参数数目、参数类型信息。任何可以用于指示应用程序当前调用的依赖的依赖信息均可用于本申请，本实施例对此不作限制。

S303，根据所识别的第一依赖信息和预先建立的依赖库，确定与每个微服务组件分别匹配的多个第二依赖的第二依赖信息；其中，微服务组件匹配的第二依赖至少包括微服务组件对应的第一依赖。

特征识别模块捕获软件运行时的信息并对其进行特征提取后，推荐模块可以根据所识别的第一依赖信息和预先建立的依赖库，确定与每个微服务组件分别匹配的多个第二依赖的第二依赖信息。

举例而言，推荐模型可以进行与依赖库交互以及计算匹配度：

推荐模块可以直接计算第一依赖信息和预先建立的依赖库中每个依赖信息间的相似度，将相似度前N位的依赖信息确定为第二依赖信息。

或者，在一种可选的示例中，推荐模块可以将提取到的特征和依赖库中的每个依赖信息输入到预先训练好的模型中进行匹配，也就是说，根据所识别的第一依赖信息和预先建立的依赖库，确定与每个微服务组件分别匹配的多个第二依赖的第二依赖信息，可以包括如下步骤：

获取依赖库存储的多个第三依赖信息；

将所识别的第一依赖信息和多个第三依赖信息输入预先训练得到的推荐模型，得到多个第三依赖信息中每个第三依赖信息与所识别的第一依赖信息对应的微服务组件间的匹配度；其中，推荐模型为利用样本应用程序中的样本依赖信息和样本依赖信息与样本应用程序的匹配度标签训练得到的模型；

确定多个第三依赖信息中匹配度大于或者等于匹配度阈值的第二依赖信息。

示例性的，第一依赖信息可以指示应用程序当前调用的依赖的信息，并且，应用程序调用什么样的依赖取决于应用程序的属性信息，因此，第一依赖信息也可以指示应用程序的属性信息。应用程序的属性信息例如可以是：按照应用程序的业务差异划分的程序类型，例如，游戏应用、社交应用、视频应用等；和/或，按照应用程序中微服务组件的功能差异划分的服务类型，例如，登录、视频播放、视频下载、支付等。在此基础上，推荐模型可以将所识别的第一依赖信息和多个第三依赖信息输入预先训练得到的推荐模型，即可使得推荐模型基于第一依赖信息识别应用程序的属性信息，也就是确定第一依赖信息对应的微服务组件的代码或者应用程序属于哪一类别，进而根据属性信息和第三依赖信息计算得到多个第三依赖信息中每个第三依赖信息与所识别的第一依赖信息对应的微服务组件间的匹配度。这样，多个第三依赖信息中匹配度大于或者等于匹配度阈值的第二依赖信息，可以是一个或者多个，可以包含第一依赖信息。

在一种示例中，推荐模型可以包括适用于任何应用程序的一个模型，此时，样本应用程序可以包括多种应用程序，例如视频应用、社交应用、购物应用和游戏应用等。在另一种示例中，推荐模型可以包括适用于上述S301中应用程序的程序类型的一个模型，此时，样本应用程序可以包括与S301中应用程序的程序类型相同的至少一个应用程序，例如，至少一个视频应用、社交应用、购物应用或游戏应用等，具体取决于S301中应用程序的程序类型。

在一种示例中，用于训练得到推荐模型的原始模型例如可以是协同过滤模型、矩阵分解模型、深度神经网络模型等。本申请实施例对具体的原始模型不作限制，任何可以用于内容推荐、匹配度计算的模型均可用于本申请。

S304，基于第二依赖信息，更新多个微服务组件对依赖的调用。

推荐模块得到第二依赖信息后，可以基于第二依赖信息，更新多个微服务组件对依赖的调用也就是确定推荐，以及进行可选的热替操作。在一种可选的示例中，基于第二依赖信息，更新多个微服务组件对依赖的调用，可以包括如下步骤：

在为微服务组件加载可替换依赖的过程中，获取第二依赖信息指示的推荐依赖；其中，可替换依赖包括微服务组件对应的第一依赖中第一依赖信息与微服务组件的第二依赖信息不同的第一依赖；

利用所获取的推荐依赖替换可替换依赖。

示例性的，推荐模块可以将每个微服务组件的第二依赖信息中与该微服务组件的第一依赖信息不同的第二依赖信息指示的依赖确定为推荐结果也即推荐依赖，该第一依赖信息即为可替换依赖。例如，参见图2，微服务组件M1的第一依赖信息包括软件包A1、软件包A2和API V1；微服务组件M1的第二依赖信息包括软件包B1、软件包B2和API V2。那么第一依赖信息即为可替换依赖。在一种示例中，对于任一微服务组件而言，若与第一依赖信息不同的第二依赖信息为多个，则将其中匹配度最高的第二依赖信息指示的依赖确定为推荐依赖。

举例而言，在确定执行热替操作的情况下也就是配置使用热替功能时，热替模块在应用程序启动时可以通过网络读取新的依赖和类文件也即获取第二依赖信息指示的推荐依赖，进而使用Java Agent中自定义的类加载器编译并加载类所获取的推荐依赖以覆盖应用程序中已加载的依赖即可替换依赖，从而实现热替换。

可以理解的是，热替功能可以在应用程序启动且接收热替功能启用指令的情况下启用，或者可以在确定并展示推荐结果后接收到更新指令的情况下启用。

这样，本申请实施例实现了在应用程序运行过程中更新依赖调用，可以避免对从云端调用的依赖的遗漏，提高用于更新的新依赖的全面性，从而提高更新的准确性。该更新无需人工操作，可以进一步提高应用程序更新的效率。其中，云端例如可以是提供类库、API和方法调用服务的服务器或服务器集群。

本申请实施例，通过应用程序运行过程中产生的运行信息识别应用程序中微服务组件所调用依赖的第一依赖信息，进而基于第一依赖信息从预先建立的依赖库中确定与应用程序匹配的第二依赖的第二依赖信息，并基于第二依赖信息更新应用程序中微服务对依赖的调用，从而实现对应用程序中微服务所调用依赖的自动识别以及更新，且基于应用程序运行过程中的运行信息实现，可以避免对从云端调用的依赖的遗漏，以及主观因素导致的更新不准确，保证对应用程序的更新更加全面和准确以及便捷。

另外，本申请图1所示的电子设备100和图2所示的应用程序更新系统200为了实现上述本申请实施例中应用程序更新方法的功能，包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的应用程序更新方法。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的应用程序更新方法。

其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

本申请各个实施例的任意内容，以及同一实施例的任意内容，均可以自由组合。对上述内容的任意组合均在本申请的范围之内。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (20)

1.一种应用程序更新方法，其特征在于，所述方法包括：

采集包含多个微服务组件的应用程序在运行过程中产生的运行信息；

根据所述运行信息，识别所述多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，所述微服务组件对应的第一依赖包括所述微服务组件调用的依赖；

根据所识别的第一依赖信息和预先建立的依赖库，确定与所述每个微服务组件分别匹配的多个第二依赖的第二依赖信息；其中，所述微服务组件匹配的第二依赖至少包括所述微服务组件对应的第一依赖；

基于所述第二依赖信息，更新所述多个微服务组件对依赖的调用。

2.根据权利要求1所述的方法，其特征在于，所述基于所述第二依赖信息，更新所述多个微服务组件对依赖的调用，包括：

在为所述微服务组件加载可替换依赖的过程中，获取所述第二依赖信息指示的推荐依赖；其中，所述可替换依赖包括所述微服务组件对应的第一依赖中第一依赖信息与所述微服务组件的第二依赖信息不同的第一依赖；

利用所获取的推荐依赖替换所述可替换依赖。

3.根据权利要求1或2所述的方法，其特征在于，所述根据所识别的第一依赖信息和预先建立的依赖库，确定与所述每个微服务组件分别匹配的多个第二依赖的第二依赖信息，包括：

获取所述依赖库存储的多个第三依赖信息；

将所识别的第一依赖信息和所述多个第三依赖信息输入预先训练得到的推荐模型，得到所述多个第三依赖信息中每个第三依赖信息与所述所识别的第一依赖信息对应的微服务组件间的匹配度；其中，所述推荐模型为利用样本依赖信息和所述样本依赖信息与样本应用程序的匹配度标签训练得到的模型；

确定所述多个第三依赖信息中所述匹配度大于或者等于匹配度阈值的第二依赖信息。

4.根据权利要求1-3中任一项所述的方法，其特征在于，所述采集包含多个微服务组件的应用程序在运行过程中产生的运行信息之前，所述方法还包括：

在所述应用程序启动运行的情况下，获取所述每个微服务组件的代码的代码特征；

分别根据所述每个微服务组件的代码特征，确定所述微服务组件的代码的目标区域；

在所述目标区域中添加更新模块组；其中，所述更新模块组用于执行所述采集包含多个微服务组件的应用程序在运行过程中产生的运行信息。

5.根据权利要求2或4所述的方法，其特征在于，在所述应用程序启动运行时，所述方法还包括：

接收针对所述应用程序配置的代理信息；

通过所述代理信息指示的代理执行所述利用所获取的推荐依赖替换所述可替换依赖，或者所述获取所述每个微服务组件的代码的代码特征。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述根据所述运行信息，识别所述多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息，包括：

对所述运行信息进行特征提取，得到所述多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；

其中，所述第一依赖信息包括如下至少之一：依赖名称、依赖调用路径和依赖中的参数信息。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述基于所述第二依赖信息，更新所述多个微服务组件对依赖的调用之后，所述方法还包括：

展示所述更新的更新内容。

8.根据权利要求1-7中任一项所述的方法，其特征在于，所述基于所述第二依赖信息，更新所述多个微服务组件对依赖的调用，包括：

基于所述第二依赖信息，展示是否进行依赖更新的提示信息；

在接收到所述提示信息对应的更新指令的情况下，基于所述第二依赖信息，更新所述多个微服务组件对依赖的调用。

9.一种应用程序更新装置，其特征在于，所述装置包括：

特征识别模块，用于采集包含多个微服务组件的应用程序在运行过程中产生的运行信息；根据所述运行信息，识别所述多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；其中，所述微服务组件对应的第一依赖包括所述微服务组件调用的依赖；

推荐模块，用于根据所识别的第一依赖信息和预先建立的依赖库，确定与所述每个微服务组件分别匹配的多个第二依赖的第二依赖信息；其中，所述微服务组件匹配的第二依赖至少包括所述微服务组件对应的第一依赖；

更新模块，用于基于所述第二依赖信息，更新所述多个微服务组件对依赖的调用。

10.根据权利要求9所述的装置，其特征在于，所述更新模块，具体用于：

在为所述微服务组件加载可替换依赖的过程中，获取所述第二依赖信息指示的推荐依赖；其中，所述可替换依赖包括所述微服务组件对应的第一依赖中第一依赖信息与所述微服务组件的第二依赖信息不同的第一依赖；

利用所获取的推荐依赖替换所述可替换依赖。

11.根据权利要求9或10所述的装置，其特征在于，所述推荐模块，具体用于：

获取所述依赖库存储的多个第三依赖信息；

将所识别的第一依赖信息和所述多个第三依赖信息输入预先训练得到的推荐模型，得到所述多个第三依赖信息中每个第三依赖信息与所述所识别的第一依赖信息对应的微服务组件间的匹配度；其中，所述推荐模型为利用样本依赖信息和所述样本依赖信息与样本应用程序的匹配度标签训练得到的模型；

确定所述多个第三依赖信息中所述匹配度大于或者等于匹配度阈值的第二依赖信息。

12.根据权利要求9-11中任一项所述的装置，其特征在于，所述装置还包括增强模块，用于：

在所述应用程序启动运行的情况下，获取所述每个微服务组件的代码的代码特征；

分别根据所述每个微服务组件的代码特征，确定所述微服务组件的代码的目标区域；

在所述目标区域中添加更新模块组；其中，所述更新模块组用于执行所述采集包含多个微服务组件的应用程序在运行过程中产生的运行信息。

13.根据权利要求10或12所述的装置，其特征在于，所述装置还包括增强模块，用于：

在所述应用程序启动运行时，接收针对所述应用程序配置的代理信息；

通过所述代理信息指示的代理执行所述利用所获取的推荐依赖替换所述可替换依赖，或者所述获取所述每个微服务组件的代码的代码特征。

14.根据权利要求9-13中任一项所述的装置，其特征在于，所述特征识别模块，具体用于：

对所述运行信息进行特征提取，得到所述多个微服务组件中每个微服务组件分别对应的第一依赖的第一依赖信息；

其中，所述第一依赖信息包括如下至少之一：依赖名称、依赖调用路径和依赖中的参数信息。

15.根据权利要求9-14中任一项所述的装置，其特征在于，所述更新模块还用于：

展示所述更新的更新内容。

16.根据权利要求9-15中任一项所述的装置，其特征在于，所述更新模块，具体用于：

基于所述第二依赖信息，展示是否进行依赖更新的提示信息；

在接收到所述提示信息对应的更新指令的情况下，基于所述第二依赖信息，更新所述多个微服务组件对依赖的调用。

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

处理器和收发器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1至8中任一项所述的方法。

18.一种计算机可读存储介质，其特征在于，包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至8中任意一项所述的方法。

19.一种芯片，其特征在于，包括一个或多个接口电路和一个或多个处理器；所述接口电路用于从电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，使得所述电子设备执行权利要求1至8中任意一项所述的方法。

20.一种计算机程序产品，其特征在于，包括计算机程序，当所述计算机程序被电子设备执行时，使得所述电子设备执行权利要求1至8中任意一项所述的方法。