Application program update starting method and device, medium, product and equipment

Abstract

The invention belongs to the field of computers, and provides an application program update starting method and device, a medium, a product and equipment. The application program updating starting method comprises the following steps: judging a scene in which an application program is updated, and matching and selecting a corresponding updating strategy; executing the selected updating strategy to update a preset source file in the application program and start the updated source file; the corresponding strategy of application updating is matched according to the use scene, the duration required by updating is shortened, and the user experience and the service continuity are improved.

Description

Technical Field

[0001] The present invention belongs to the field of computers, and in particular relates to an application program update startup method, device, medium, product and equipment. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] In a private deployment environment, when an application needs to be updated, the entire application is usually stopped first, then some or all source code files are replaced using a specific update tool, and finally the entire application is restarted. This update method is called a "full update."

[0004] However, with the "full update" method, even modifying only a few source code files requires stopping the entire application, performing the update, and restarting it. For large, multi-module, monolithic applications containing a large number of source code and resource files, the "full update" method requires loading all modules and resources into memory at startup, significantly increasing startup time and reducing update efficiency. Especially with limited hardware configuration or a large number of modules, the startup process can cause lengthy service interruptions, impacting user experience and business continuity. Summary of the Invention

[0005] In order to solve the above technical problems, the present invention provides an application update startup method, device, medium, product and equipment, which matches the corresponding application update strategy according to the application update scenario, shortens the update time, and improves user experience and business continuity.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions: A first aspect of the present invention provides a method for starting an application update.

[0007] In one or more embodiments, a method for initiating an application update is provided, comprising: Determine the application update scenario and select the corresponding update strategy; executing the selected update strategy to update the preset source files in the application and start the updated source files; If the application is updated in the first scenario, the full downtime update strategy is selected; the first scenario is that the update frequency of the application is less than the preset frequency threshold, and all application modules in the application need to be updated; If the application update is in the second scenario, the on-demand downtime update strategy is selected; the second scenario is the scenario where the number of application modules to be updated in the application is less than the preset number threshold; If the application update is in the third scenario, the immediate downtime update strategy is selected; the third scenario is a scenario in which only source files less than a preset number in the application are updated.

[0008] As an implementation method, the full shutdown update strategy is: When the application is started for the first time using the full startup mode, the resources of all application modules in the application are loaded into the memory after the application is started for the first time, and the dependency relationship between the resources is obtained in the memory; Close the application and trigger the shutdown callback. In the shutdown callback, analyze the dependencies between resources and re-divide all resources into several startup modules according to the principle of group dependencies. Save the module division results to the hard disk file. Update the application source file and restart the application, read the module division results saved on the hard disk, and use a separate thread to start each startup module.

[0009] As an implementation method, each startup module corresponds to several source file address lists, and each thread loads the corresponding source file by obtaining the source file address list corresponding to the corresponding startup module.

[0010] As an implementation method, the number of startup modules is less than or equal to a set ratio of the number of tasks that can be processed in parallel at the same time.

[0011] As an implementation method, the on-demand shutdown update strategy is: Before the update, the application service is stopped without any downtime, and the resources of the application module to be updated are divided into several startup modules; Before updating a source file, stop the corresponding startup module, update the source file and mark the corresponding startup module as a module that needs to be restarted; After the update is complete, start only the modules that require a restart and restore the application's service.

[0012] As an implementation method, the instant shutdown update strategy is: Before updating the source files, stop providing the application without shutting down the server; Before updating a source file, mark the corresponding source file path as needing to be reloaded; After all source files to be updated are updated, all source files marked as needing to be reloaded are reloaded and the application service is restored.

[0013] A second aspect of the present invention provides an application program update startup device.

[0014] In one or more embodiments, a device for initiating application program update includes: An update strategy matching and selection module is used to determine the scenario in which the application is updated and to match and select the corresponding update strategy; A source file update startup module, which is used to execute the selected update strategy to update the preset source file in the application and start the updated source file; Wherein, in the update strategy matching selection module, if the application update is in the first scenario, the full shutdown update strategy is selected; the first scenario is a scenario where the update frequency of the application is less than a preset frequency threshold and all application modules in the application need to be updated; If the application update is in the second scenario, the on-demand downtime update strategy is selected; the second scenario is the scenario where the number of application modules to be updated in the application is less than the preset number threshold; If the application update is in the third scenario, the immediate downtime update strategy is selected; the third scenario is a scenario in which only source files less than a preset number in the application are updated.

[0015] A third aspect of the present invention provides a computer-readable storage medium.

[0016] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps in the above-mentioned application program update startup method.

[0017] A fourth aspect of the present invention provides a computer program product.

[0018] A computer program product includes a computer program / instruction, which implements the steps in the above-mentioned application update startup method when executed by a processor.

[0019] A fifth aspect of the present invention provides an electronic device.

[0020] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the steps in the application program update startup method described above are implemented.

[0021] Compared with the prior art, the present invention has the following beneficial effects: (1) The present invention matches the corresponding application update strategy according to the application update scenario. By executing the selected update strategy, the preset source files in the application are updated and the updated source files are started. This solves the problems of significantly increased startup time and low update efficiency existing in the "full update" method, shortens the overall update time, and improves user experience and business continuity.

[0022] (2) The full shutdown update strategy and on-demand shutdown update strategy of the present invention redistribute resources into startup modules, and based on the dependencies between application modules and the reasonable allocation of hardware resources (such as the number of CPU cores), realize modular startup and on-demand update of applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0024] Figure 1 1 is a flow chart of a method for starting an application program update according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the full shutdown update strategy process according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the on-demand downtime update strategy process according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the instant shutdown update strategy process according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an application update startup device according to an embodiment of the present invention; Figure 6 is a schematic diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0026] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0027] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or combinations thereof.

[0028] Figure 1 FIG. 1 is a flow chart of a method for starting an application program update according to an embodiment of the present invention. Figure 1 The application update startup method in this embodiment may include the following steps S101 to S102.

[0029] S101: Determine the scenario in which the application is updated, and select a corresponding update strategy.

[0030] Among them, if the application update is in the first scenario, the full shutdown update strategy is selected; the first scenario is that the update frequency of the application is less than the preset frequency threshold, and each application module in the application needs to be updated.

[0031] For example, the application may be updated every month or every set number of months.

[0032] In the first scenario, you can choose not to perform system upgrades and maintenance during the day, and only perform upgrades at night after work hours. This gives you ample time to complete the system upgrade and reboot. The first scenario does not require high reboot speed.

[0033] like Figure 2 As shown, the full shutdown update strategy is: Step a1: Start the application for the first time using the full startup mode. After the application is started for the first time, the resources of all application modules in the application are loaded into the memory, and the dependency relationship between the resources is obtained in the memory; Step a2: Close the application and trigger the shutdown callback. In the shutdown callback, analyze the dependency relationship between resources, and re-divide all resources into several startup modules according to the principle of dependency grouping. The module division results are saved to the hard disk file.

[0034] The number of startup modules is less than or equal to the set ratio of the number of tasks that can be processed in parallel. The number of tasks that can be processed in parallel can be expressed as the number of CPU cores. For example, the number of startup modules n is less than 3 / 4 of the number of CPU cores (this ratio can be set according to time conditions).

[0035] The 3 / 4 of the number of CPU cores here is a rule of thumb. The number of CPU cores indicates the number of tasks that can be processed simultaneously. Therefore, if the number of tasks exceeds the number of CPU cores, multiple tasks will compete for CPU resources. The operating system also consumes some CPU resources, so the number of tasks should be slightly smaller than the number of CPU cores.

[0036] For example, there are four business modules, A, B, C, and D. Module A has many files, but modules B, C, and D have very few files. According to the business modules, they need to be divided into four modules, A, B, C, and D. However, modules B, C, and D have fewer files and are not suitable to be started as separate modules (they will compete with module A for CPU resources during startup). However, relying on the same group principle can break the module isolation and divide it into two startup modules. Module A is a separate startup module, and the three business modules B, C, and D are combined into one startup module. In step a2, the dependency principle is: two dependent resources must be in the same group.

[0037] For example, there are four modules in the memory: asset management, asset operation, financial accounting, and supply chain. The number of CPU cores is four. At this time, they need to be divided into three startup modules, that is, there is a startup module that contains two business modules. At this time, two business modules are not randomly selected as a startup module, but according to the principle of dependency group. The asset operation module has a dependency relationship with the asset management module, so in the end, asset management and asset operation will be divided into one startup module, financial accounting has its own startup module, and supply chain also has its own startup module.

[0038] This embodiment breaks the original module isolation and does not need to divide modules according to business areas. According to the principle of relying on the same group, all resources are redivided into n startup modules. This can avoid module division caused by business tilt, improve update efficiency, and ultimately shorten the time required for updates, thereby improving user experience and business continuity.

[0039] Step a3: Update the application source file and restart the application, read the module division result saved in the hard disk, and start each startup module using a separate thread.

[0040] In step a3, each startup module corresponds to a number of source file address lists, and each thread loads the corresponding source file by obtaining the source file address list corresponding to the corresponding startup module.

[0041] If the application update is in the second scenario, the on-demand shutdown update strategy is selected; the second scenario is the scenario where the number of application modules to be updated in the application is less than a preset number threshold (the specific value can be set according to actual conditions).

[0042] For example, the second scenario might involve a customer requesting further updates for a specific module while the application is running smoothly. This involves upgrading the system, allowing the customer to try the application and request further updates, then upgrading the system, allowing the customer to try the application and request further updates. This scenario is characterized by updates requiring updates for only a few modules (one or a few), requiring a relatively large number of files, and requiring real-time performance (the customer needs to see the results of the upgrade as quickly as possible). This scenario is well-suited for on-demand updates, which are faster than full updates (meeting real-time requirements).

[0043] like Figure 3 As shown, the on-demand shutdown update strategy is: Step b1: Before the update, stop providing application services but do not shut down the system, and divide the resources of the application module to be updated into several startup modules. The number of startup modules n here is greater than 1.5 times the number of CPU cores. Step b2: before updating a source file, stop the corresponding startup module, update the source file and mark the corresponding startup module as a module that needs to be restarted; Step b3: After the update is complete, only restart the modules that need to be restarted and restore the application's services.

[0044] This embodiment uses an on-demand shutdown update strategy to achieve rapid updates to a set single application module, meeting the timeliness requirement for viewing update effects, improving update efficiency, shortening the time required for updates, and improving user experience and business continuity.

[0045] If the application update is in the third scenario, the immediate downtime update strategy is selected; the third scenario is a scenario in which only source files less than a preset number in the application are updated.

[0046] The third scenario involves, for example, a low-code platform where a user modifies functionality (actually, certain files) or manually writes code to modify a file. The modifications are minor, and the user is eager to see the results. By reloading only the few files modified by the user, real-time performance is highly achieved.

[0047] like Figure 4 As shown, the immediate shutdown update strategy is: Step c1: Before updating the source files, stop providing the application without shutting down the server; Step c2: Before updating a source file, mark the corresponding source file path as requiring reloading; Step c3: After all source files to be updated are updated, all source files marked as needing to be reloaded are reloaded and the application service is restored.

[0048] This embodiment adopts an immediate shutdown update strategy for scenarios with a small number of source file updates, which increases the real-time requirements of updates, improves update efficiency, shortens the time required for updates, and improves user experience and business continuity.

[0049] S102: Execute the selected update strategy to update the preset source file in the application and start the updated source file.

[0050] This embodiment matches the corresponding application update strategy according to the application update scenario. By executing the selected update strategy, the preset source files in the application are updated and the updated source files are started. This solves the problems of significantly increased startup time and low update efficiency in the "full update" method, shortens the overall update time, and improves user experience and business continuity.

[0051] like Figure 5 As shown, the application update startup device provided by the embodiment of the present invention can be implemented in software. The application update startup device 500 includes the following software modules: an update strategy matching selection module 501 and a source file update startup module 502 .

[0052] The functions of each software module in the application update startup device 500 are introduced below: The update strategy matching and selection module 501 is used to determine the scenario in which the application is updated and match and select the corresponding update strategy.

[0053] In the update strategy matching selection module 501, if the application update is in the first scenario, the full shutdown update strategy is selected; the first scenario is that the update frequency of the application is less than the preset frequency threshold and all application modules in the application need to be updated.

[0054] For example, the application may be updated every month or every set number of months.

[0055] In the first scenario, you can choose not to perform system upgrades and maintenance during the day, and only perform upgrades at night after work hours. This gives you ample time to complete the system upgrade and reboot. The first scenario does not require high reboot speed.

[0056] like Figure 2 As shown, the full shutdown update strategy is: Step a1: Start the application for the first time using the full startup mode. After the application is started for the first time, the resources of all application modules in the application are loaded into the memory, and the dependency relationship between the resources is obtained in the memory; Step a2: Close the application and trigger the shutdown callback. In the shutdown callback, analyze the dependency relationship between resources, and re-divide all resources into several startup modules according to the principle of dependency grouping. The module division results are saved to the hard disk file.

[0057] The number of startup modules is less than or equal to the set ratio of the number of tasks that can be processed in parallel. The number of tasks that can be processed in parallel can be expressed as the number of CPU cores. For example, the number of startup modules n is less than 3 / 4 of the number of CPU cores (this ratio can be set according to time conditions).

[0058] The 3 / 4 of the number of CPU cores here is a rule of thumb. The number of CPU cores indicates the number of tasks that can be processed simultaneously. Therefore, if the number of tasks exceeds the number of CPU cores, multiple tasks will compete for CPU resources. The operating system also consumes some CPU resources, so the number of tasks should be slightly smaller than the number of CPU cores.

[0059] For example, there are four business modules, A, B, C, and D. Module A has many files, but modules B, C, and D have very few files. According to the business modules, they need to be divided into four modules, A, B, C, and D. However, modules B, C, and D have fewer files and are not suitable to be started as separate modules (they will compete with module A for CPU resources during startup). However, relying on the same group principle can break the module isolation and divide it into two startup modules. Module A is a separate startup module, and the three business modules B, C, and D are combined into one startup module. In step a2, the dependency principle is: two dependent resources must be in the same group.

[0060] For example, there are four modules in the memory: asset management, asset operation, financial accounting, and supply chain. The number of CPU cores is four. At this time, they need to be divided into three startup modules, that is, there is a startup module that contains two business modules. At this time, two business modules are not randomly selected as a startup module, but according to the principle of dependency group. The asset operation module has a dependency relationship with the asset management module, so in the end, asset management and asset operation will be divided into one startup module, financial accounting has its own startup module, and supply chain also has its own startup module.

[0061] This embodiment breaks the original module isolation and does not need to divide modules according to business areas. According to the principle of relying on the same group, all resources are redivided into n startup modules. This can avoid module division caused by business tilt, improve update efficiency, and ultimately shorten the time required for updates, thereby improving user experience and business continuity.

[0062] Step a3: Update the application source file and restart the application, read the module division result saved in the hard disk, and start each startup module using a separate thread.

[0063] Each startup module corresponds to several source file address lists, and each thread loads the corresponding source file by obtaining the source file address list corresponding to the corresponding startup module.

[0064] If the application update is in the second scenario, the on-demand shutdown update strategy is selected; the second scenario is the scenario where the number of application modules to be updated in the application is less than a preset number threshold (the specific value can be set according to actual conditions).

[0065] For example, the second scenario might involve a customer requesting further updates for a specific module while the application is running smoothly. This involves upgrading the system, allowing the customer to try the application and request further updates, then upgrading the system, allowing the customer to try the application and request further updates. This scenario is characterized by updates requiring updates for only a few modules (one or a few), requiring a relatively large number of files, and requiring real-time performance (the customer needs to see the results of the upgrade as quickly as possible). This scenario is well-suited for on-demand updates, which are faster than full updates (meeting real-time requirements).

[0066] like Figure 3 As shown, the on-demand shutdown update strategy is: Before the update, the application service is stopped without downtime, and the resources of the application module to be updated are divided into several startup modules. The number of startup modules n here is greater than 1.5 times the number of CPU cores. Before updating a source file, stop the corresponding startup module, update the source file and mark the corresponding startup module as a module that needs to be restarted; After the update is complete, start only the modules that require a restart and restore the application's service.

[0067] This embodiment uses an on-demand shutdown update strategy to achieve rapid updates to a set single application module, meeting the timeliness requirement for viewing update effects, improving update efficiency, shortening the time required for updates, and improving user experience and business continuity.

[0068] If the application update is in the third scenario, the immediate downtime update strategy is selected; the third scenario is a scenario in which only source files less than a preset number in the application are updated.

[0069] The third scenario involves, for example, a low-code platform where a user modifies functionality (actually, certain files) or manually writes code to modify a file. The modifications are minor, and the user is eager to see the results. By reloading only the few files modified by the user, real-time performance is highly achieved.

[0070] like Figure 4 As shown, the immediate shutdown update strategy is: Before updating the source files, stop providing the application without shutting down the server; Before updating a source file, mark the corresponding source file path as needing to be reloaded; After all source files to be updated are updated, all source files marked as needing to be reloaded are reloaded and the application service is restored.

[0071] This embodiment adopts an immediate shutdown update strategy for scenarios with a small number of source file updates, which increases the real-time requirements of updates, improves update efficiency, shortens the time required for updates, and improves user experience and business continuity.

[0072] The source file update activation module 502 is configured to execute the selected update strategy to update the preset source file in the application program and activate the updated source file.

[0073] This embodiment matches the corresponding application update strategy according to the application update scenario. By executing the selected update strategy, the preset source files in the application are updated and the updated source files are started. This solves the problems of significantly increased startup time and low update efficiency in the "full update" method, shortens the overall update time, and improves user experience and business continuity.

[0074] The full shutdown update strategy and on-demand shutdown update strategy of this embodiment redistribute resources into startup modules, and based on the dependencies between application modules and the reasonable allocation of hardware resources (such as the number of CPU cores), realize modular startup and on-demand updates of applications.

[0075] The structure of the electronic device according to the embodiment of the present invention is described in detail below. Figure 6 The schematic diagram of the structure of the electronic device provided in the embodiment of the present invention can be understood as follows: Figure 6 Only exemplary structures of the electronic device are shown, not all structures. Part or all of the shown structures may be implemented as needed.

[0076] The electronic device provided in the embodiment of the present invention includes: at least one processor 601, a memory 602, a user interface 603 and at least one network interface 604. The various components in the application update startup device are coupled together via a bus system 605. It can be understood that the bus system 605 is used to achieve connection and communication between these components. In addition to including a data bus, the bus system 605 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 605 is not described in detail. Figure 6 Various buses are labeled as bus system 605.

[0077] The user interface 603 may include a display, a keyboard, a mouse, a trackball, a click wheel, keys, buttons, a touch pad or a touch screen.

[0078] It will be appreciated that the memory 602 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. The memory 602 in the embodiment of the present invention can store data to support the operation of the terminal. Examples of such data include any computer program used to operate on the terminal, such as an operating system and application programs. The operating system includes various system programs, such as a framework layer, a core library layer, and a driver layer, which are used to implement various basic services and handle hardware-based tasks. The application program may include various application programs.

[0079] In some embodiments, the application update initiation device 500 provided in the embodiments of the present invention can be implemented using a combination of software and hardware. As an example, the application update initiation device 500 provided in the embodiments of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the application update initiation method provided in the embodiments of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0080] As an example, the processor 601 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0081] As an example of hardware implementation of the application update startup device 500 provided in an embodiment of the present invention, the device provided in an embodiment of the present invention can be directly executed by a processor 601 in the form of a hardware decoding processor. For example, one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components can be used to implement the application update startup method provided in an embodiment of the present invention.

[0082] The memory 602 in the embodiment of the present invention is used to store various types of data to support the operation of the application update startup device 500, or to store data for executing Figure 1 Examples of such data include any executable instructions for operating on an application update initiation device, such as executable instructions. A program implementing the method for initiating an application update according to an embodiment of the present invention may be included in the executable instructions.

[0083] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, the computer program including a computer program for executing Figure 1 In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion and / or installed from a removable medium. When the computer program is executed by the central processing unit, the various functions defined in the apparatus of the present application are performed.

[0084] in, Figure 1 The computer program instructions corresponding to the method shown can also be stored in a computer readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0085] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that the present invention is susceptible to various modifications and variations. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A method for starting an application update, characterized in that: include: Determine the application update scenario and select the corresponding update strategy; executing the selected update strategy to update the preset source files in the application and start the updated source files; Among them, if the application update is in the first scenario, the full shutdown update strategy is selected; the first scenario is the scenario where the update frequency of the application is less than the preset frequency threshold and all application modules in the application need to be updated; If the application update is in the second scenario, the on-demand downtime update strategy is selected; the second scenario is the scenario where the number of application modules to be updated in the application is less than the preset number threshold; If the application update is in the third scenario, the immediate downtime update strategy is selected; the third scenario is a scenario in which only source files less than a preset number in the application are updated.

2. The application update startup method according to claim 1, wherein: The full shutdown update strategy is: When the application is started for the first time using the full startup mode, the resources of all application modules in the application are loaded into the memory after the application is started for the first time, and the dependency relationship between the resources is obtained in the memory; Close the application and trigger the shutdown callback. In the shutdown callback, analyze the dependencies between resources and re-divide all resources into several startup modules according to the principle of group dependencies. Save the module division results to the hard disk file. Update the application source file and restart the application, read the module division results saved on the hard disk, and use a separate thread to start each startup module.

3. The application update startup method according to claim 2, wherein: Each startup module corresponds to several source file address lists, and each thread loads the corresponding source file by obtaining the source file address list corresponding to the corresponding startup module.

4. The application update startup method according to claim 2, wherein: The number of startup modules is less than or equal to the set ratio of the number of tasks that can be processed in parallel.

5. The application update startup method according to claim 1, wherein: The on-demand downtime update strategy is: Before the update, the application service is stopped without any downtime, and the resources of the application module to be updated are divided into several startup modules; Before updating a source file, stop the corresponding startup module, update the source file and mark the corresponding startup module as a module that needs to be restarted; After the update is complete, start only the modules that require a restart and restore the application's service.

6. The application update startup method according to claim 1, wherein: The instant downtime update strategy is: Before updating the source files, stop providing the application without shutting down the server; Before updating a source file, mark the corresponding source file path as needing to be reloaded; After all source files to be updated are updated, all source files marked as needing to be reloaded are reloaded and the application service is restored.

7. An application update startup device, characterized in that: include: An update strategy matching and selection module is used to determine the scenario in which the application is updated and to match and select the corresponding update strategy; A source file update startup module, which is used to execute the selected update strategy to update the preset source file in the application and start the updated source file; Wherein, in the update strategy matching selection module, if the application update is in the first scenario, the full shutdown update strategy is selected; the first scenario is a scenario where the update frequency of the application is less than a preset frequency threshold and all application modules in the application need to be updated; If the application update is in the second scenario, the on-demand downtime update strategy is selected; the second scenario is the scenario where the number of application modules to be updated in the application is less than the preset number threshold; If the application update is in the third scenario, the immediate downtime update strategy is selected; the third scenario is a scenario in which only source files less than a preset number in the application are updated.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps in the application update startup method according to any one of claims 1 to 6 are implemented.

9. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps in the application update startup method according to any one of claims 1 to 6 are implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps in the application update startup method according to any one of claims 1 to 6 are implemented.

Images