Application effective implementation method and device, storage medium and electronic device

Abstract

The embodiment of the invention provides an application effective implementation method and device, a storage medium and an electronic device, and the method comprises the steps: dividing a target middleware software process into a plurality of process groups under the condition that a to-be-implemented target application exists in a business system; according to the sequence of the number of middleware software processes included in the process groups from small to large, target operation is executed on the multiple process groups in sequence; wherein the target operation comprises the following steps: in a preset time window, performing transaction isolation operation on a target sub-middleware software process included in the process group, and after transaction isolation, performing an operation of updating a target application on the target sub-middleware software process; and verifying whether the target application takes effect or not under the condition that the target application is updated, and quitting execution of the target operation under the condition that the target application takes effect. By means of the method and device, the problem that safe and stable system operation cannot be effectively guaranteed during the application version effective period is solved, and then the effect of effectively guaranteeing safe and stable system operation is achieved.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computers, and in particular, to an implementation method, device, storage medium, and electronic device for application to take effect. Background Art

[0002] In the related art, due to the complex operation conditions of services during service maintenance, as well as problems such as the time window for application version to take effect, the technical solutions adopted for application version to take effect, and the quality of application program versions, the change of application version to take effect usually causes many production events.

[0003] It can be seen that there is a problem in the related art that the safe and stable operation of the system cannot be effectively guaranteed during the application version to take effect.

[0004] In view of the above problems existing in the related art, no effective solution has been proposed yet. Summary of the Invention

[0005] Embodiments of the present invention provide an implementation method, device, storage medium, and electronic device for application to take effect, so as to at least solve the problem in the related art that the safe and stable operation of the system cannot be effectively guaranteed during the application version to take effect.

[0006] According to an embodiment of the present invention, there is provided an implementation method for application to take effect, including: when there is a target application to be implemented in a service system, dividing a target middleware software process into multiple process groups, where the target middleware software process is an operation object for implementing the target application to take effect, and the number of middleware software processes included in each process group is different; sequentially performing a target operation on the multiple process groups in ascending order of the number of middleware software processes included in the process group, where the target operation is an operation for making the target application take effect; where the target operation includes: within a preset time window, performing a transaction isolation operation on a target sub-middleware software process included in the process group, and after the transaction isolation, performing an operation of updating the target application on the target sub-middleware software process; when the target application is updated, verifying whether the target application takes effect, and when the target application takes effect, exiting the execution of the target operation.

[0007] In an exemplary embodiment, dividing the target middleware software process into multiple process groups includes: determining the minimum number of processes that meet the verification requirements, where the update of the target application can be verified by the processes with the minimum number of processes to determine whether it has an impact on the business system; selecting the first processes with the minimum number of processes from the target middleware software process; determining the first processes with the minimum number of processes as the first process group; dividing the other processes included in the target middleware software process except the first processes into multiple groups according to a quantity gradient to obtain multiple second process groups; and determining the first process group and the multiple second process groups as the multiple process groups.

[0008] In an exemplary embodiment, selecting the first processes with the minimum number of processes from the target middleware software process includes: when the business system is a centralized architecture system, determining some or all of the middleware processes deployed in one or more virtual machines included in the business system as the first processes; when the business system is a distributed architecture system, determining the middleware processes deployed in one or more virtual machines included in the business system as the first processes.

[0009] In an exemplary embodiment, dividing the other processes included in the target middleware software process except the first processes into multiple groups according to a quantity gradient to obtain multiple second process groups includes: when the business system is a centralized architecture system, determining the first virtual machine in which the middleware software process has been divided and the second virtual machine in which the middleware software process has not been divided included in the business system; determining the undivided second processes included in the first virtual machine and the third processes in the second virtual machine as the other processes; dividing the other processes into multiple groups according to a quantity gradient to obtain multiple second process groups; when the business system is a distributed architecture system, determining the third virtual machine in which the middleware software process has not been divided included in the business system; dividing the third virtual machine into multiple groups according to a quantity gradient to obtain multiple virtual machine groups; and determining the processes deployed in each virtual machine group as the second process group to obtain multiple second process groups.

[0010] In an exemplary embodiment, performing transaction isolation operations on the target sub-middleware software processes included in the process group includes: when the business system is a centralized architecture system, setting the transaction processing function of the target sub-middleware software process to a static state; when the business system is a distributed architecture system, deleting the target sub-middleware software process from the transaction routing list of the business system, and shutting down the target sub-middleware software process after a predetermined period of time.

[0011] In an exemplary embodiment, the operation of updating the target application on the target sub-middleware software process includes: obtaining the application software package of the target application; pushing the application software package to the disk of the host where the target sub-middleware software process is located to update the target application on the host.

[0012] In an exemplary embodiment, verifying whether the target application takes effect includes: restoring the transaction processing function of the target sub-middleware software process; determining the sampling frequency based on the type of the business system; determining the target observation duration of the target sub-middleware software process; within the target observation duration, obtaining the target process transaction volume of the target sub-middleware software process according to the sampling frequency; determining the system success rate of all functions executed by the business system within the target observation duration; determining the system transaction success rate of the business system executing transactions within the target observation duration; determining the transaction response time of the business system within the target observation duration; verifying whether the target application takes effect based on the target process transaction volume, the system success rate, the system transaction success rate, and the transaction response time.

[0013] In an exemplary embodiment, restoring the transaction processing function of the target sub-middleware software process includes: in the case where the business system is a centralized architecture system, copying the application software package of the target application from the disk of the target sub-middleware software process to the memory of the target sub-middleware software process; in the case where the copying is completed, releasing the static state of the transaction processing function of the target sub-middleware software process to restore the transaction processing function of the target sub-middleware software process; in the case where the business system is a distributed architecture system, restarting the target sub-middleware software process to restore the transaction processing function of the target sub-middleware software process.

[0014] In an exemplary embodiment, determining the target observation duration of the target sub-middleware software process includes: determining the target number of multiple process groups; sorting the multiple process groups in ascending order according to the number of middleware software processes included in each process group to obtain a first sequence; determining the serial number of the process group where the target sub-middleware software process is located in the first sequence; determining a preset minimum observation duration and an optional duration control value; determining the target difference between the target number and the serial number; determining the ratio of the target difference to the target number; determining the product of the ratio and the optional duration control value; determining the sum value of the product and the minimum observation duration as the target observation duration.

[0015] In an exemplary embodiment, verifying whether the target application is effective based on the target process transaction volume, the system success rate, the system transaction success rate and the transaction response time includes: verifying whether the target process transaction volume meets a first preset condition to obtain a first verification result; verifying whether the system success rate meets a second preset condition to obtain a second verification result; verifying whether the system transaction success rate meets a third preset condition to obtain a third verification result; verifying whether the transaction response time meets a fourth preset condition to obtain a fourth verification result; when the first verification result, the second verification result, the third verification result and the fourth verification result all indicate successful verification, determining that the target application is effective; when there is a verification failure result among the first verification result, the second verification result, the third verification result and the fourth verification result, determining that the target application has failed to take effect.

[0016] In an exemplary embodiment, verifying whether the target process transaction volume satisfies a first preset condition and obtaining a first verification result includes: determining a historical time period that is concurrent with the time period in which the target observation duration is located; determining an average transaction volume of the target sub-middleware software process within the historical time period, and a first standard deviation of the transaction volume of the target sub-middleware software process; determining a first interval based on the average transaction volume and the first standard deviation; determining the first verification result as a successful verification if the target process transaction volume is within the first interval; and determining the first verification result as a failed verification if the target process transaction volume is outside the first interval.

[0017] In an exemplary embodiment, verifying whether the system success rate meets the second preset condition and obtaining the second verification result includes: determining a historical time period that is consistent with the time period of the target observation duration; determining the average system success rate of the business system within the historical time period, and the second standard deviation of the historical system success rate; determining a second interval based on the average system success rate and the second standard deviation; if the system success rate is within the second interval, determining the second verification result as a successful verification; if the system success rate is outside the second interval, determining the second verification result as a failed verification.

[0018] In an exemplary embodiment, verifying whether the system transaction success rate meets a third preset condition and obtaining a third verification result includes: determining a historical time period contemporaneous with the time period where the target observation duration is located; determining the average transaction success rate of the executed transactions of the service system and the third standard deviation of the historical transaction success rates within the historical time period; determining a third interval based on the average transaction success rate and the third standard deviation; determining that the third verification result is verification successful when the system transaction success rate is within the third interval; and determining that the third verification result is verification failed when the system transaction success rate is outside the third interval.

[0019] In an exemplary embodiment, verifying whether the transaction response time meets a fourth preset condition and obtaining a fourth verification result includes: determining a historical time period contemporaneous with the time period where the target observation duration is located; determining the average transaction response time of the service system and the fourth standard deviation of the historical transaction response times within the historical time period; determining a fourth interval based on the average transaction response time and the fourth standard deviation; determining that the fourth verification result is verification successful when the transaction response time is within the fourth interval; and determining that the fourth verification result is verification failed when the transaction response time is outside the fourth interval.

[0020] In an exemplary embodiment, after verifying whether the target application takes effect, the method further includes: in the case of failure to verify the effectiveness of the target application, locating a target location that causes the failure of the target application to take effect; repairing the target location, and after successful repair, determining the remaining duration of the preset time window; continuing to execute the target operation when the remaining duration is greater than or equal to a predetermined threshold; and determining a target process group for which the target application has taken effect and controlling processes included in the target process group to perform a rollback operation on the effectuation action of the target application in the case of repair failure or when the remaining duration is less than the predetermined threshold.

[0021] According to another embodiment of the present invention, there is provided an implementation device for application to take effect, including: a division module, configured to divide a target middleware software process into multiple process groups when there is a target application to be implemented in a business system, where the target middleware software process is an operation object for implementing the target application to take effect, and the number of middleware software processes included in each process group is different; an execution module, configured to sequentially perform a target operation on the multiple process groups in ascending order of the number of middleware software processes included in the process group, where the target operation is an operation for making the target application take effect; where the target operation includes: within a preset time window, performing a transaction isolation operation on a target sub-middleware software process included in the process group, and after the transaction isolation, performing an operation of updating the target application on the target sub-middleware software process; when the update of the target application is completed, verifying whether the target application takes effect, and when the target application takes effect, exiting the execution of the target operation.

[0022] According to still another embodiment of the present invention, there is also provided a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0023] According to still another embodiment of the present invention, there is also provided an electronic device, including a memory and a processor, where a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0024] According to still another embodiment of the present invention, there is also provided a computer program product, including a computer program, where the computer program realizes the steps of the methods in various embodiments of the present application when executed by a processor.

[0025] With the present invention, in the case where there is a target application to be implemented in a service system, the target middleware software process for realizing the effectiveness of the target application can be divided into multiple process groups each containing a different number of middleware software processes. The target operation is sequentially performed on the multiple process groups in ascending order of the number of middleware software processes included in the process group to achieve the real-time effectiveness of the target application. The target operation includes: within a preset time window, performing a transaction isolation operation on the target sub-middleware software processes included in the process group; after the transaction isolation, performing an operation to update the target application; and after the update of the target application is completed, verifying whether the target application is effective. Since the target middleware software processes can be grouped first, and the transaction isolation, target application update, and verification of the effectiveness of the target application are sequentially performed on the target sub-middleware software processes in each group in ascending order of the number, that is, the change verification is preferentially performed on the smallest operable unit (the process group with the smallest number), and the target application version is promoted to take effect in all target middleware software processes in the service system in the order of a small number of middleware, the remaining part of the middleware, and all the remaining middleware. Since each target middleware software process can also be verified, and starting from a small number of target middleware software processes, the number of target middleware software processes is gradually increased, which can ensure full verification while also ensuring the efficiency of the entire process of taking effect and verification. Therefore, the problem in the related art that the safe and stable operation of the system cannot be effectively ensured during the application version taking effect can be solved, and the effect of effectively ensuring the safe and stable operation of the system during the application version taking effect can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 is a hardware structure block diagram of a mobile terminal for an implementation method of application effectiveness according to an embodiment of the present invention;

[0027] Figure 2 is a flowchart of an implementation method of application effectiveness according to an embodiment of the present invention;

[0028] Figure 3 is a schematic diagram of a centralized architecture system according to an embodiment of the present invention;

[0029] Figure 4 is a schematic diagram of a distributed architecture system according to an embodiment of the present invention;

[0030] Figure 5 is a schematic diagram of pushing and copying an application version program according to an embodiment of the present invention;

[0031] Figure 6 is a schematic diagram of preheating and loading an application version program in memory according to an embodiment of the present invention;

[0032] Figure 7 is a schematic diagram of the process of the application version taking effect in the host within a group according to an embodiment of the present invention;

[0033] Figure 8 is a flowchart of an implementation method for the application to take effect according to a specific embodiment of the present invention;

[0034] Figure 9 is a structural block diagram of an implementation device for the application to take effect according to a specific embodiment of the present invention;

[0035] Figure 10 is a structural block diagram of an implementation device for the application to take effect according to an embodiment of the present invention. Detailed implementation manners

[0036] In the following, embodiments of the present invention will be described in detail with reference to the accompanying drawings and in conjunction with the embodiments.

[0037] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence.

[0038] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, Figure 1 is a hardware structural block diagram of a mobile terminal of an implementation method for an application to take effect according to an embodiment of the present invention. As Figure 1 shown, the mobile terminal may include one or more ( Figure 1 only one is shown in Figure 1 a processor 102 (the processor 102 may include, but is not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Among them, the above-mentioned mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those of ordinary skill in the art can understand that Figure 1 the structure shown in Figure 1 is only schematic and does not limit the structure of the above-mentioned mobile terminal. For example, the mobile terminal may further include more or fewer components than

[0039] The memory 104 can be used to store computer programs, such as software programs and modules of application software, such as the computer program corresponding to the implementation method for the application to take effect in the embodiments of the present invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, the above-mentioned method is implemented. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 104 may further include a memory remotely disposed relative to the processor 102, and these remote memories can be connected to the mobile terminal through a network. Examples of the above-mentioned network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0040] The transmission device 106 is used to receive or send data via a network. Specific examples of the above-mentioned network may include a wireless network provided by a communication provider of the mobile terminal. In one instance, the transmission device 106 includes a network adapter (Network Interface Controller, abbreviated as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one instance, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0041] In this embodiment, an implementation method for an application to take effect is provided. Figure 2 It is a flowchart of the implementation method for an application to take effect according to the embodiments of the present invention, as Figure 2 shown, and the process includes the following steps:

[0042] Step S202, when there is a target application to be implemented in the business system, divide the target middleware software process into multiple process groups, where the target middleware software process is the operation object for implementing the target application to take effect, and the number of middleware software processes included in each process group is different;

[0043] Step S204, sequentially perform a target operation on multiple process groups in ascending order of the number of middleware software processes included in the process group, where the target operation is an operation for making the target application take effect;

[0044] Among them, the target operation includes:

[0045] Within a preset time window, perform transaction isolation operations on the target sub-middleware software processes included in the process group, and after the transaction isolation, perform operations to update the target application on the target sub-middleware software processes; in the case where the update of the target application is completed, verify whether the target application takes effect, and in the case where the target application takes effect, exit the execution of the target operation.

[0046] In the above embodiment, the business system may be a bank core business system, that is, as one of the most important information-based infrastructure in a bank, it can meet the business processing requirements of high concurrency, high reliability, and high response speed, and has characteristics such as high system composition complexity and uninterrupted service. In the banking and other financial industries, the development department is responsible for the development and implementation of the transaction processing function programs required by customers, such as functions like deposit and withdrawal, card authorization, etc. The development department compiles the developed source program code and then delivers the executable program package to the operation and maintenance department, and the operation and maintenance department realizes the update and effectiveness of the information system application program in the form of an application version, achieving the release of new business functions or the repair of production operation problems. Therefore, in order to minimize the possible impacts in the application version effectiveness operation and follow the software specification of gray release, the target middleware software processes for the target application version effectiveness operation to be implemented in the business system can be grouped to ensure that the scope of the implementation object during the application version effectiveness process increases from small to large, achieving controllable scope. Among them, the middleware software process can be understood as being used to coordinate the interaction between the target application and the underlying system, that is, it can be understood as the operation object for implementing the effectiveness of the target application. Gray release can also be called canary release, which can be understood as a software version release method that can smoothly transition between black and white, ensuring the overall stability of the system, and being able to discover and adjust problems at the initial gray level to ensure that its impact level is controlled. Among them, the period from the start to the end of the gray release is called the gray period.

[0047] In the above embodiments, since the target middleware software process can be divided into multiple process groups containing different numbers of target middleware software processes, the target operation can be started from the process group with a small number first. After the application version activation operation of the above target middleware software process is completed, the activation solution has been observed and verified for correctness. Through the continuous observation process of the transactions of the target middleware software process for which the application version has been activated, the correctness of the application version function can be preliminarily verified, and the confidence in the application version activation solution and the application version quality can be enhanced. In the subsequent application version activation process of other middleware software processes, in order to complete the application version activation work of all middleware software processes within the limited activation window, the number of target middleware software processes that simultaneously perform the application version activation operation within a batch can be gradually increased to speed up the change implementation speed, that is, the target operation can be sequentially performed on multiple process groups in ascending order of the number of middleware software processes included in the process group.

[0048] In the above embodiments, in order to avoid the impact caused by the defects in the activation method and the defective application version that has been activated during the application version activation process, the time period with the smallest business system transaction volume (i.e., the above preset time window) can be actively selected for the selection of the application version activation window. The determination of the preset time window can ensure that the impact of the application version activation operation on the in-transit transactions of the system during the application version activation period is minimized. The time period for actively applying for the downtime window can be preferentially selected, and the time period with the smallest daily transaction volume of the system (relatively less system support transaction volume) can also be selected. Through the refined application version activation solution, the goal of minimizing the impact can be achieved to the greatest extent.

[0049] In the above embodiments, the all-day transaction volume analysis of the business system can be obtained by summarizing and analyzing the historical data of the business system. Combining with the all-day transaction volume distribution data of the business system, the implementation window selection for the system application version to take effect can be determined. To support the development of 7*24-hour services, the core domestic and overseas services can be managed in multiple time zones, that is, the core applications are deployed in a multi-time zone manner, which can improve the flexibility of carrying out planned operation and maintenance work such as infrastructure maintenance and application version effectiveness. For the core business system in China, the online period from 08:00 to 20:00 during the day is the high-water period of the system transaction volume, and 23:00 to 03:00 is usually the peak period of the end-of-day batch processing. Therefore, the above two periods cannot be selected as the optional windows for the application version to take effect, but only the lowest valley period of the all-day business processing should be selected. Therefore, for the operation window of the application version to take effect for the clusters in other time zones, the time period with the lowest transaction volume in the corresponding time zone should also be selected. In addition, for emergency versions that are not for resuming production, it is strictly prohibited to put them into production during the peak online periods in each time zone. Not only is it difficult to minimize the impact, but in case of emergencies during the application version effectiveness process, the affected area will be extremely enlarged due to the surge effect. For example, for the domestic branches, the window is from 08:00 to 20:00. Among them, non-resuming production issues can be understood as serious technical or business issues that seriously affect business continuity and normal service provision and are difficult to recover or solve in a short time. The time after the end of the core system's end-of-day batch processing can be preferentially selected. As shown in Table 1, that is, the core domestic business can be put into production at 03:30 - 06:00 in the early morning (the lowest valley period of the all-day business), and the core overseas business can be put into production in batches according to different time zones. That is, the Europe-Africa time zone can choose the window from 08:00 to 11:00, and the America time zone can choose the window from 14:00 to 17:00. At the same time, it is also possible to evaluate the versions that may or potentially affect the networked UnionPay services, such as quick payment, online consumption, cash withdrawal, refund, signing query, etc., and arrange them on the downtime day. Relevant transactions can be suspended in advance by issuing a notice.

[0050] Table 1

[0051] Business Function Time Zone Distribution Effective Window Domestic Core Asia 03：00-06：00 Overseas Core Asia 03：00-06：00 Overseas Core Europe and Africa 08：00-11：00 Overseas Core America 14：00-17：00

[0052] In the above embodiments, during the execution of the target operation for the application version of the middleware software process within a group to take effect, the operation of the application version taking effect on the in-transit transactions of the system can be made imperceptible through three steps: transaction isolation, application version taking effect, and transaction incorporation and recovery. That is, perform transaction isolation on the target sub-middleware software process in the process group, perform application version update on the target sub-middleware software process in the process group, and perform transaction incorporation on the target sub-middleware software process in the process group. During these three processes, continuously observe the running status of the target sub-middleware software process and the overall transactions of the business system (i.e., determine whether the target application takes effect as described above). Through a reliable and flexible window observation and verification mechanism, on the one hand, problems in the technical solution adopted for the application version to take effect and potential development quality deficiencies in the application version can be discovered in a timely manner, so that the action of the application version taking effect can be terminated in a timely manner, and the number of target middleware software processes affected by the application version taking effect can be controlled within the minimum range; on the other hand, after the quality of the application version is fully confirmed, setting a flexible adjustment of the observation window threshold can ensure an improvement in the operation efficiency of the application version taking effect for all target middleware software processes in the system within the restricted implementation window, and improve the completion rate of the application version taking effect work.

[0053] Through the present invention, in the case where there is a target application to be implemented in a business system, the target middleware software process for the operation object of the target application to take effect can be divided into multiple process groups containing different numbers of middleware software processes. The target operation is sequentially performed on the multiple process groups in ascending order of the number of middleware software processes included in the process group to achieve real-time effect of the target application. Among them, the target operation includes: within a preset time window, perform a transaction isolation operation on the target sub-middleware software process included in the process group. After the transaction isolation, perform an operation to update the target application. After the target application update is completed, verify whether the target application takes effect. Since the target middleware software process can be grouped first, and the operations of transaction isolation, target application update, and verification of the target application taking effect are sequentially performed on the target sub-middleware software process in each group in ascending order of the number, that is, the change verification is first performed on the smallest operable unit (the process group with the smallest number), and the target application version is promoted to all target middleware software processes in the business system in the order of a small number of middleware, the remaining part of the middleware, and all the remaining middleware. Since each target middleware software process can also be verified, and starting from a small number of target middleware software processes, the number of target middleware software processes is gradually increased, which can ensure full verification while also ensuring the efficiency of the entire process of taking effect and verification. Therefore, the problem in the related technology that the safe and stable operation of the system cannot be effectively guaranteed during the application version taking effect can be solved, and the effect of effectively guaranteeing the safe and stable operation of the system during the application version taking effect can be achieved.

[0054] Optionally, the execution entity of the above steps may be a processor, a terminal, or a server, etc., but is not limited thereto.

[0055] In an exemplary embodiment, dividing the target middleware software process into multiple process groups includes: determining the minimum number of processes that meet the verification requirements, where the update of the target application can be verified by the processes with the minimum number of processes to determine whether it has an impact on the business system; selecting the first processes with the minimum number of processes in the target middleware software process; determining the first processes with the minimum number of processes as the first process group; dividing the other processes included in the target middleware software process except the first processes into multiple groups according to a quantity gradient to obtain multiple second process groups; and determining the first process group and the multiple second process groups as the multiple process groups.

[0056] In the above embodiment, during the grouping process of all target middleware software processes for which the operation of the application version to be implemented takes effect, at the beginning stage, the process group of the middleware software processes with the minimum number (i.e., the above minimum number of processes) (i.e., the above first process group) can be selected to implement the minimum set of effective operations. That is, the minimum number of processes can be determined first, the first processes with the minimum number of processes in the target middleware software process are determined as the first process group, and the processes in the target middleware software process excluding the first processes are divided into multiple second process groups according to a quantity gradient. The quantity gradient can be a fixed gradient or a multiple gradient. For example, when the quantity gradient is a fixed gradient, the quantity gradient can be 5, that is, the multiple second process groups can be process groups respectively containing 10, 15, and 20 processes. When the quantity gradient is a multiple gradient, the quantity gradient can be 4, 8, 16, 32, 64... Through grouping, the verification of the effective scheme of the target application version can be completed within the minimum range, and at the same time, the risk of the impact range of post-effective failures caused by insufficient quality of the target application version can be eliminated. The number of processes in the process group containing the minimum number of processes can be random and is the minimum number of processes that can complete the verification of whether the update of the target application has an impact on the business system.

[0057] In an exemplary embodiment, selecting the first processes with the minimum number of processes in the target middleware software process includes: when the business system is a centralized architecture system, determining some or all of the middleware processes deployed in one or more virtual machines included in the business system as the first processes; when the business system is a distributed architecture system, determining the middleware processes deployed in one or more virtual machines included in the business system as the first processes.

[0058] In the above embodiments, different grouping methods may exist according to different business system architectures. Currently, the core business systems of banks mainly adopt two technical architectures: a centralized deployment solution represented by IBM (International Business Machines) mainframes (i.e., the above-mentioned centralized architecture system) and a distributed deployment solution independently developed by enterprises based on a distributed architecture (i.e., the above-mentioned distributed architecture system). Among them, the centralized architecture system can be understood as evenly distributing all the hardware devices of the core business system in multiple computer room modules in two buildings to reduce the risk of all devices being unavailable in the building-level failure scenario. Since the concurrent processing capabilities of a single hardware device and a single software process in the centralized architecture are relatively high, multiple virtual machines can be deployed on each physical machine, and multiple middleware software processes can be deployed on each virtual machine to meet the requirements of high-concurrency processing and high availability. Among them, the number of virtual machines can be much less than the number of middleware process instances. Figure 3 is a schematic diagram of a centralized architecture system according to an embodiment of the present invention. As Figure 3 shown, the centralized architecture system may include 2 buildings, each building contains 2 physical hosts, 2 virtual machines are deployed on each physical host, and 8 middleware processes are deployed in each virtual machine, that is, there are a total of 8 virtual machines and 16 middleware processes in the cluster. The distributed architecture system can be understood as that application virtual machines are evenly deployed on the host hardware devices in more computer room modules in at least three availability zones, which can minimize the coupling relationship between software and hardware, and between software and software, and at the same time solve the problem of relatively low processing capabilities of a single hardware device and a single software instance in a distributed environment. Among them, the availability zone AZ (Availability Zone) can be understood as an independent physical unit provided by cloud services within a geographical area. Each availability zone in cloud computing has independent power, network connections, and infrastructure, which can ensure high availability and disaster tolerance capabilities. When deploying applications in cloud services, an application deployment solution across multiple availability zones can be adopted to increase the reliability of data and the availability of services. Even after one availability zone fails and becomes unavailable, the application deployment units deployed in other availability zones can still continue to provide services externally, ensuring that business continuity is guaranteed. In a cluster based on a distributed architecture, virtual machines and middleware processes are usually paired one-to-one, that is, only one middleware software process is started on each virtual machine. Figure 4 is a schematic diagram of a distributed architecture system according to an embodiment of the present invention. As Figure 4 shown, the distributed architecture system may include three availability zones, each availability zone contains 2 computer room modules, each computer room module contains one virtual machine, and 1 middleware process is deployed in one virtual machine, that is, there are a total of 6 virtual machines and 6 middleware processes. Compared with the centralized architecture, the number of software and hardware in the system based on the distributed architecture becomes larger, and the system composition change is more complex.

[0059] In the above embodiments, when the service system is a centralized architecture system, since the number of physical hosts in the centralized architecture system is less than the number of virtual machines and the number of middleware software processes, in the process of grouping the target middleware software processes, a small number or all of the middleware in a small number of virtual machines can be first determined as the first processes. Example: Refer to Figure 3 , the middleware processes numbered 1 and 2 on virtual machine 11 of physical host 1 in Building 1 and the middleware processes numbered 1 and 2 on virtual machine 21 of physical host 2 in Building 2 can be selected as the first process group G1, that is, the first process group includes 4 middleware processes (accounting for 1 / 16).

[0060] In the above embodiments, when the service system is a distributed architecture system, it can be defaulted that the business processing functions of the target middleware processes on the virtual machines in each computer room module in all availability zones are the same. Combining the feature that the middleware software processes in multiple distributed availability zones are functionally equivalent, one or more middleware processes deployed on the virtual machines can be randomly selected as the first processes. Example: Refer to Figure 4 , the middleware software process of the virtual machine named 1xxx in computer room module 1 in availability zone 1 can be selected as the first process group G1, that is, the first process group includes 1 middleware process (accounting for 1 / 6).

[0061] In an exemplary embodiment, the other processes other than the first processes included in the target middleware software processes are divided into multiple groups according to a quantity gradient, and multiple second process groups are obtained, including: when the service system is a centralized architecture system, determining the first virtual machines including the middleware software processes that have been divided and the second virtual machines that have not been divided into middleware software processes in the service system; determining the second processes that have not been divided in the first virtual machines and the third processes in the second virtual machines as the other processes; dividing the other processes into multiple groups according to a quantity gradient to obtain multiple second process groups; when the service system is a distributed architecture system, determining the third virtual machines including the middleware software processes that have not been divided in the service system; dividing the third virtual machines into multiple groups according to a quantity gradient to obtain multiple virtual machine groups; determining the processes deployed in each virtual machine group as the second process groups to obtain multiple second process groups.

[0062] In the above embodiments, when the service system is a centralized architecture system, the second processes included in the first virtual machines that have not been fully divided in the first process group and the third processes included in the second virtual machines that have not been divided into the first process group can be selected as the other processes, and the other processes can be divided into multiple second process groups according to a quantity gradient. Example: Continuing to refer to Figure 3, the middleware processes numbered 3, 4, 5, 6, 7, and 8 on virtual machine 11 on physical host 1 of Building 1 and the middleware processes numbered 3, 4, 5, 6, 7, and 8 on virtual machine 21 on physical host 2 of Building 2 can be selected as the first subprocess group G2 in the second process group, that is, the first subprocess group G2 includes 12 processes (accounting for 3 / 16); the middleware processes numbered 1, 2, 3, 4, 5, 6, 7, and 8 on virtual machine 12 on physical host 1 of Building 1 and the middleware processes numbered 1, 2, 3, 4, 5, 6, 7, and 8 on virtual machine 22 on physical host 2 of Building 2 can also be selected as the second subprocess group G3 in the second process group, that is, the second subprocess group G3 includes 16 middleware processes (accounting for 1 / 4); the middleware processes numbered 1, 2, 3, 4, 5, 6, 7, and 8 on virtual machines 31 and 32 on physical host 3 of Building 1 and the middleware processes numbered 1, 2, 3, 4, 5, 6, 7, and 8 on virtual machines 41 and 42 on physical host 4 of Building 2 can also be selected as the third subprocess group G4 in the second process group, that is, the third subprocess group G4 includes 32 middleware processes (accounting for 1 / 2). Therefore, the 64 middleware software processes on 4 physical hosts and 8 virtual machines in the business system can be divided into 4 groups, and through the application version effectiveness control of the 4 groups, the application version gray effectiveness process with a total of 4 rounds is realized. Subsequently, the application version invalidation operation can be implemented in the order of the number of middleware processes in the group from small to large.

[0063] In the above embodiment, when the business system is a distributed architecture system, the third virtual machines not divided into the first process group can be divided into multiple virtual machine groups according to the quantity gradient, and then the processes deployed in each virtual machine group can be divided into multiple second process groups. Example: Continue to refer to Figure 4, the virtual machine named 2xxx in the second available zone computer room module 2 and the middleware software process of the virtual machine named 6xxx in the third available zone computer room module 6 can be selected from the remaining unpartitioned virtual machine groups as the first sub - process group G2 in the second process group; then, the middleware software processes on 10% of the total number of virtual machines can be selected from the remaining virtual machine groups as the second sub - process group G3 in the second process group, the middleware software processes on 20% of the total number of virtual machines as the third sub - process group G4 in the second process group, the middleware software processes on 30% of the total number of virtual machines as the fourth sub - process group G5 in the second process group, and the middleware software processes on 40% of the total number of virtual machines as the fifth sub - process group G6 in the second process group. Therefore, all the middleware software processes deployed in the business system can be divided into 6 groups. Through the application version effective control of the 6 groups, the application version gray - effective process divided into 6 rounds in total is realized. Subsequently, the application version invalidation can be implemented in the order of the number of middleware processes in the group from small to large.

[0064] In an exemplary embodiment, the transaction isolation operation for the target sub - middleware software process included in the process group includes: when the business system is a centralized architecture system, setting the transaction processing function of the target sub - middleware software process to a static state; when the business system is a distributed architecture system, deleting the target sub - middleware software process from the transaction routing list of the business system, and after a predetermined period of time, taking down the target sub - middleware software process.

[0065] In the above - mentioned embodiment, the key point of transaction isolation for the target sub - middleware software process for which the target application version is to take effect is to meet the requirement of non - perceptible transaction isolation, that is, the isolation operation has no impact on the in - transit transactions of the system.

[0066] In the above - mentioned embodiment, for the host platform transaction middleware software of a centralized architecture system, the transaction processing function of the target sub - middleware software process of the transaction can be set to a static state through the management - type command of the transaction middleware software. After being set to the static state, the corresponding target sub - middleware software process will no longer accept new transaction processing requests routed to this target sub - middleware software process, but the application processing requests that have been in progress in this process before the static state setting operation are not affected until the transaction is normally processed and completed. After the target sub - middleware software process set to the static state finishes processing the original in - transit transactions, this target sub - middleware software process will become an idle static state because it no longer accepts new transaction processing requests. Thereafter, according to the application version effective scenario, if necessary, this target sub - middleware software process can be selected to perform the operation of taking down and restarting to prepare for the subsequent application version effective operation. Here, taking down can be understood as a state where the service stops running or becomes unavailable.

[0067] In the above embodiments, for the middleware software process of the distributed architecture system, the target sub-middleware software process for upgrading the target application version can first be dynamically removed from the optional list of transaction routing by implementing registration in the transaction routing configuration center, and then the target sub-middleware software on the application virtual machine can be taken offline after waiting for a predetermined duration. The predetermined duration can be obtained through testing in a test environment or through analysis of historical data on the effectiveness of application versions repeatedly implemented in a production environment.

[0068] In an exemplary embodiment, the operation of updating the target application for the target sub-middleware software process includes: obtaining the application software package of the target application; pushing the application software package to the disk of the host where the target sub-middleware software process is located to update the target application on the host.

[0069] In the above embodiments, after completing the transaction isolation of the target sub-middleware software for the operation of implementing the target application version, the stage of updating the target application version can be entered, that is, pushing and copying the application software package of the target application version from the version management system to the disk of the host where the selected target sub-middleware software process is located for update. Figure 5 It is a schematic diagram of pushing and copying the application version program according to an embodiment of the present invention. As Figure 5 shown, the corresponding target application version software package can be copied to the target host through an operation and maintenance tool system such as a batch processing scheduling management system, and the ambiguity of the job submission order, that is, parallel submission or serial submission, can be eliminated by taking effect in an automated manner.

[0070] In an exemplary embodiment, verifying whether the target application takes effect includes: restoring the transaction processing function of the target sub-middleware software process; determining the sampling frequency based on the type of the business system; determining the target observation duration of the target sub-middleware software process; obtaining the target process transaction volume of the target sub-middleware software process at the sampling frequency within the target observation duration; determining the system success rate of all functions executed by the business system within the target observation duration; determining the system transaction success rate of transactions executed by the business system within the target observation duration; determining the transaction response time of the business system within the target observation duration; and verifying whether the target application takes effect based on the target process transaction volume, the system success rate, the system transaction success rate, and the transaction response time.

[0071] In the above embodiments, after the update of the application version in the target sub-middleware software process is completed, the transaction middleware process can be started, or the transaction processing function of the transaction middleware can be restored, so as to officially enable the transaction function of the target sub-middleware software process that has deployed the new application version program. According to the importance of the business system, different sampling frequencies can be determined, that is, it can be divided into second-level monitoring sampling and minute-level monitoring sampling. For example, for the bank core business system, in order to ensure the real-time requirement of observation, the more accurate sampling granularity of second-level monitoring sampling can be adopted. Among them, the sampled data can include the transaction volume of the target sub-middleware software process when the new application version takes effect (that is, the above-mentioned target process transaction volume), the overall system success rate, the overall business success rate (that is, the above-mentioned system transaction success rate), and the overall transaction response time.

[0072] In the above embodiments, during the process of the application version taking effect, the system operation situation during the process of the application version taking effect, especially the transaction processing situation, can be observed to ensure that the transaction processing of the system after the application version takes effect and the transactions are incorporated is not affected by the application version taking effect. Since the minimum business function management unit of the business system is the transaction code or interface, and the common features of each transaction are the transaction code, transaction volume, and response time, a continuous observation process of a certain time length (that is, the above-mentioned target observation duration) can be carried out on the transaction operation situation of the target sub-middleware software process for which the application version has taken effect and the transaction processing function has been restored. After determining the sampled data within the target observation duration (that is, the above-mentioned target process transaction volume, system success rate, system transaction success rate, and transaction response time), the target application can be verified based on the sampled data.

[0073] In an exemplary embodiment, restoring the transaction processing function of the target sub-middleware software process includes: in the case where the business system is a centralized architecture system, copying the application program software package of the target application from the disk of the target sub-middleware software process to the memory of the target sub-middleware software process; in the case where the copying is completed, releasing the static state of the transaction processing function of the target sub-middleware software process to restore the transaction processing function of the target sub-middleware software process; in the case where the business system is a distributed architecture system, restarting the target sub-middleware software process to restore the transaction processing function of the target sub-middleware software process.

[0074] In the above embodiments, when the business system is a centralized structure system, the new version of the application version file on the disk (i.e., the above application software package) can be first copied to the memory of the trading target sub-middleware software process through the memory refresh management command of the trading middleware, so as to implement the loading operation of the new version of the application version code into the memory. Then, the static state of the trading target sub-middleware software process can be lifted through the management command of the trading middleware. After the static state is lifted, the trading middleware on the host platform starts to resume receiving the trading processing requests routed and forwarded to this target sub-middleware software process.

[0075] In the above embodiments, when the business system is a distributed structure system, the virtual machine where the target sub-middleware software process that has completed the application version deployment is located can be restarted first. Also, on the virtual machine, the reloading operation of the new version of the application version code from the disk to the memory of the trading middleware process can be completed by restarting the trading target sub-middleware software process. Then, by restoring the registration of the target sub-middleware software process that has completed the application version update in the trading routing configuration center, the restoration of the trading processing function is realized.

[0076] In the above embodiments, the memory reloading operation of the target sub-middleware software process on the centralized platform before lifting the static state and the active memory reloading operation of the target sub-middleware software process on the distributed platform before restoring the registration in the trading routing configuration center are both to perform early warm start on the target sub-middleware software process before officially starting to receive trading processing. Figure 6 It is a schematic diagram of the early warm-up loading of the application version program memory according to the embodiments of the present invention. As Figure 6 shown, by implementing memory loading in advance, the problems of low performance of the last few trading processes and long trading processing duration caused by low memory hit rate in the initial stage of resuming trading processing of the target sub-middleware software process can be solved.

[0077] In an exemplary embodiment, determining the target observation duration of the target sub-middleware software process includes: determining the target number of multiple process groups; sorting the multiple process groups in ascending order according to the number of middleware software processes included in each process group to obtain a first sequence; determining the serial number of the process group where the target sub-middleware software process is located in the first sequence; determining a pre-set minimum observation duration and an optional duration control value; determining the target difference between the target number and the serial number; determining the ratio of the target difference to the target number; determining the product of the ratio and the optional duration control value; and determining the sum value of the product and the minimum observation duration as the target observation duration.

[0078] In the above embodiments, different target observation durations can be set for middleware software processes in different groups. The target observation duration can be determined by considering the system's own situation, historical data of the observation process during the application version activation process, the number of update programs for the current application version activation, etc. It can also use fixed time interval thresholds such as 5 minutes, 10 minutes, etc., or can be obtained by dynamic calculation methods. Example: Divide all target middleware software processes for which the target application version needs to be activated into m (i.e., the above-mentioned target quantity) process groups, sort the number of processes included in the m process groups in ascending order to obtain a first sequence and determine the sequence numbers of each process group in the first sequence. Then, the target observation duration of the i-th process group can be calculated using the following formula: where T0 can be understood as the minimum observation duration of the process group, T Δ can be understood as the optional duration control value, i is the above-mentioned sequence number, m - i is the above-mentioned target difference, is the above-mentioned ratio, is the above-mentioned product. Through this calculation method, it can be ensured that the sustainable observation of each process meets the requirement of being greater than T0. As more target middleware software processes in grouped target application versions are successfully activated, it can also be ensured that the target observation durations of subsequent grouped target middleware software processes will gradually decrease, thereby improving the implementation efficiency of the application version activation for information systems with a relatively large total number of deployed target middleware software processes.

[0079] In an exemplary embodiment, verifying whether the target application is activated based on the target process transaction volume, the system success rate, the system transaction success rate, and the transaction response time includes: verifying whether the target process transaction volume meets a first preset condition to obtain a first verification result; verifying whether the system success rate meets a second preset condition to obtain a second verification result; verifying whether the system transaction success rate meets a third preset condition to obtain a third verification result; verifying whether the transaction response time meets a fourth preset condition to obtain a fourth verification result; determining that the target application is activated when the first verification result, the second verification result, the third verification result, and the fourth verification result all indicate successful verification; and determining that the activation of the target application fails when there is a verification failure result among the first verification result, the second verification result, the third verification result, and the fourth verification result.

[0080] In the above embodiment, the sampled data can be verified one by one, that is, it can be verified whether the target process transaction volume meets the first preset condition, whether the system success rate meets the second preset condition, whether the system transaction success rate meets the third preset condition, and whether the transaction response time meets the fourth preset condition, and four verification results (namely the above-mentioned first verification result, second verification result, third verification result and fourth verification result) can be obtained. Figure 7 is a schematic diagram of the process of taking effect of the host application version in a group according to an embodiment of the present invention. Figure 7 As shown, only when the target middleware software process application version in a process group is effective and transaction incorporation is completed, and the above four verification results are all met at the same time during the target observation period, can it be determined that the target application version of the target middleware software process in the process group is effective. If one or more of the above four verification results do not meet the requirements, it is considered that the target application has failed to take effect.

[0081] In an exemplary embodiment, verifying whether the target process transaction volume satisfies a first preset condition and obtaining a first verification result includes: determining a historical time period that is concurrent with the time period in which the target observation duration is located; determining an average transaction volume of the target sub-middleware software process within the historical time period, and a first standard deviation of the transaction volume of the target sub-middleware software process; determining a first interval based on the average transaction volume and the first standard deviation; determining the first verification result as a successful verification if the target process transaction volume is within the first interval; and determining the first verification result as a failed verification if the target process transaction volume is outside the first interval.

[0082] In the above embodiment, since there are fewer system transactions during the business off-peak period, the proportion of fewer or individually successful or individually failed transactions is higher than that during the peak period, that is, the small sample may cause disturbance to the business success rate indicator. If the business success rate is used to determine whether the application version has an impact on the business, it may cause distortion in the judgment. After completing the application version validation operation and completing the transaction incorporation, the target process transaction volume on the selected middleware software process should be able to recover to the distribution before the application version is implemented, that is, the transaction volume p on the target child middleware software process satisfies the following formula to determine that the application version validation operation has not caused a significant change in the transaction volume of the middleware software process, that is, the first verification result is successfully verified: in, It can be understood as the average transaction volume of the target sub-middleware software process in the historical period of the target application version effective window, and τ can be understood as the first standard deviation of the transaction volume in the historical period of the target application version effective window. and constitute the above first interval, where n is a natural number.

[0083] In an exemplary embodiment, verifying whether the success rate of the system meets a second preset condition and obtaining a second verification result includes: determining a historical time period synchronous with the time period where the target observation duration is located; determining the average system success rate of the service system and the second standard deviation of the historical system success rate within the historical time period; determining a second interval based on the average system success rate and the second standard deviation; determining that the second verification result is a verification success when the system success rate is within the second interval; and determining that the second verification result is a verification failure when the system success rate is outside the second interval.

[0084] In the above embodiment, during the effective period of a specific application version, the change situation of the overall service system success rate can be judged whether there is a significant change by combining the historical data distribution of the service system operation, that is, when the service system success rate v1 satisfies the following formula, it can be judged that the effective operation of the target application version does not affect the transactions of the overall operation of the service system, that is, the second verification result is a verification success: where can be understood as the average system success rate of the service system in the historical time period, and σ1 can be understood as the second standard deviation of the historical system success rate in the historical time period. and constitute the above second interval, where n is a natural number.

[0085] In an exemplary embodiment, verifying whether the system transaction success rate meets a third preset condition and obtaining a third verification result includes: determining a historical time period synchronous with the time period where the target observation duration is located; determining the average transaction success rate of the executed transactions of the service system and the third standard deviation of the historical transaction success rate within the historical time period; determining a third interval based on the average transaction success rate and the third standard deviation; determining that the third verification result is a verification success when the system transaction success rate is within the third interval; and determining that the third verification result is a verification failure when the system transaction success rate is outside the third interval.

[0086] In the above embodiment, during the effective period of a specific application version, the change situation of the system transaction success rate can also be judged whether there is a significant change by combining the historical data distribution of the service system operation, that is, when the service system transaction success rate v2 satisfies the following formula, it can be judged that the effective operation of the target application version does not affect the transactions of the overall operation of the service system, that is, the third verification result is a verification success: where It can be understood as the average transaction success rate of the business system in the historical period, and σ2 can be understood as the third standard deviation of the historical transaction success rate in the historical period. and constitutes the third interval mentioned above, where n is a natural number.

[0087] In an exemplary embodiment, verifying whether the transaction response time satisfies a fourth preset condition and obtaining a fourth verification result includes: determining a historical time period that is concurrent with the time period in which the target observation duration is located; determining an average transaction response time of the business system and a fourth standard deviation of the historical transaction response time within the historical time period; determining a fourth interval based on the average transaction response time and the fourth standard deviation; determining the fourth verification result as a successful verification if the transaction response time is within the fourth interval; and determining the fourth verification result as a failed verification if the transaction response time is outside the fourth interval.

[0088] In the above embodiment, there are defects in the effectiveness of the target application version. The most intuitive manifestation in system transactions is that the processing time of transactions that can be completed within the normal processing response time will be processed, further causing transaction timeouts or even transaction failures. Similar to the overall system success rate and the overall transaction success rate, if the transaction response time t satisfies the following formula, it can be judged that the target application version effectiveness operation has no impact on the overall operation of the business system, that is, the fourth verification result is verified successfully: in, It can be understood as the average transaction response time of the business system in the historical time period, and s can be understood as the fourth standard deviation of the historical transaction response time in the historical time period. and It constitutes the fourth interval mentioned above, where n is a natural number.

[0089] In an exemplary embodiment, after verifying whether the target application is effective, the method also includes: in the event that verification of the effectiveness of the target application fails, locating the target position that caused the failure of the target application to take effect; repairing the target position, and after the repair is successful, determining the remaining duration of the preset time window; in the event that the remaining duration is greater than or equal to a predetermined threshold, continuing to execute the target operation; in the event that the repair fails or the remaining duration is less than a predetermined threshold, determining the target process group that has taken effect on the target application; and controlling the processes included in the target process group to implement a rollback operation on the effectiveness action of the target application.

[0090] In the above embodiments, if the verification result shows that the application of the target application fails to take effect, the application version activation operation of the subsequent grouped target middleware software processes can be immediately aborted, the target location where the application of the target application fails to take effect can be located, and the target location can be repaired. If the remaining duration of the preset time window after repair is greater than or equal to the predetermined threshold, the application version activation operation of the target middleware software process in the subsequent process group can be continued (i.e., the above target operation); if the remaining duration is less than the predetermined threshold, a rollback operation can be performed on the target middleware software process in the target process group that has already taken effect, and the continuation of the current target application version activation operation can be aborted. Among them, the predetermined threshold can be understood as sufficient time for the remaining implementation window duration. In this embodiment, since the goals and quantities of the target middleware process objects are clear, differentiated emergency rollback processes can be formulated for the implementation objects in each stage. By integrating the grouped target application version activation process and the emergency rollback process, precise rollback can be implemented to achieve the purpose of quickly resuming transaction processing. By combining the differentiated grouping of the activation objects, emergency recovery processes that meet different impact levels of the target application version emergency rollback can be formulated in advance, the granularity of the business system emergency plan formulation can be refined, and the emergency management level of the system can be improved.

[0091] The implementation method of application activation will be described below in conjunction with specific implementation manners:

[0092] Figure 8 It is a flowchart of the implementation method of application activation according to a specific embodiment of the present invention, as Figure 8 shown, and this process includes the following steps:

[0093] S802, divide all the target middleware software processes in the information system that need to perform the application version activation operation into multiple groups, and all the groups form an optional set of the application version activation operation;

[0094] S804, check whether the preset application version activation implementation window is satisfied. If so, execute step S806;

[0095] S806, select the group with the smallest number of middleware software processes from the optional set of the application version activation operation, and use all the middleware software processes in this group as the operation objects in one batch of the application version activation implementation;

[0096] S808, perform operations such as isolating the transaction processing function, activating the application version, incorporating the transaction processing function, and observing the transaction volume of the incorporated middleware software processes on the middleware software processes in the selected group;

[0097] S810. After the transaction operation status meets the requirements of the preset threshold and the observation duration reaches the preset duration threshold, remove the selected group from the optional set of application version activation operations.

[0098] S812. Determine whether the number of groups in the optional set of application version activation operations is zero. If it is, execute step S814; if not, execute step S806.

[0099] S814. The application version activation is normal and complete.

[0100] In the above embodiment, the target middleware software processes of all target application version activation operations to be implemented in the business system can be divided into multiple different process groups. The multiple process groups constitute the optional set of application version activation operations. The target middleware software processes within each process group serve as the operation objects in each batch of application version activation operations. After meeting the preset time window, the process group with the smallest number of middleware software processes can be selected from the optional set of target application version activation operations as the operation object in one batch of application version activation implementation. Perform transaction processing function isolation operations on all target middleware software processes in the selected group. After the successful return of the transaction processing function isolation, perform application version update operations on the target middleware software processes. After the successful application version activation, perform transaction processing function incorporation operations on the target middleware software processes, and continuously observe the trading volume situation of the middleware software processes with the completed application version activation that have been restored and incorporated and the overall transaction operation situation of the system.

[0101] In the above embodiment, when the transaction operation status of the current process group meets the verification result and the observation duration (i.e., the above-mentioned target observation duration) reaches the preset duration threshold, it can be determined that the application version activation of the middleware software processes in the selected process group is successful, and the selected process group is removed from the optional set of application version activation operations. In the next stage, the process group with the smallest number of middleware software processes can be reselected from the optional set of application version activation operations as the operation object in the next batch, and the four operations of transaction processing function isolation, application version update, transaction processing function incorporation, and observation of transaction operation status are sequentially performed on the middleware software processes in the newly selected process group until the application version activation operations of all target middleware software processes in the business system are completed.

[0102] In the foregoing embodiments, the implementation window for the target application version to take effect can be standardized to eliminate the potential risk impacts that may be brought about by performing the operation of the application version taking effect during peak business hours; following the order of a small number of middleware on a small number of hosts, the remaining middleware, and all the remaining middleware, the application version taking effect can be promoted to all middleware software processes in the system; by refining the specific quantitative criteria for determining the number of middleware software processes within the process group for different batches of operations, it is possible to control the scope of operation impacts during the application version taking effect, with clear numbers and targets for the implementation objects; within each stage, adhering to the three steps of transaction isolation, version update, and transaction incorporation can make the system transparent and insensitive to transactions during the process of the target application version taking effect, and through continuous observation, it is also possible to monitor the operation of system transactions during the application version taking effect. Among them, by defining the operation objects during the application version taking effect and multi-dimensional observation indicators for the overall operation state of the system, it is possible to ensure the realization of observing the operation state of the system during the application version taking effect. Prioritizing continuous and rapid observation and verification of the smallest operable unit can enhance confidence in the technical solution and version quality of the application version taking effect. The flexible observation window mechanism can also improve the implementation speed of the application version taking effect and enhance the implementation efficiency of the application version taking effect for complex systems within a limited implementation window. By combining different process groups, it is possible to formulate emergency rollback processes for different stages in advance, achieving precise rollback while improving the enterprise's emergency management level; in addition, the implementation method of the application version taking effect is not limited to the platform, and is applicable to both application systems under a centralized architecture and application systems under a distributed architecture.

[0103] Figure 9 is a structural block diagram of an implementation device for application taking effect according to a specific embodiment of the present invention, as Figure 9 shown, the device includes:

[0104] A window determination module 902, configured to standardize the implementation window for the application version of the information system to take effect, and determine the lowest valley period of the system transaction volume by analyzing the system's all-day transaction volume distribution data, and determine the lowest valley period of the transaction volume as the implementation window for the application version to take effect;

[0105] A middleware software process grouping module 904, configured to divide all middleware software processes constituting the information system into multiple groups to form a grouping set for the application version to take effect, and the middleware software processes within each group will be used as the operation objects for each batch during the application version taking effect;

[0106] A middleware software process selection module 906, configured to select the middleware software processes within the group with the smallest number of middleware software processes from the grouping set for the application version to take effect as the operation and maintenance objects for the next step of implementing the taking effect operation;

[0107] The transaction isolation module 908 is used for the seamless isolation of transactions of middleware software processes that pre-implement the application version effect operation. On the basis of blocking new transaction processing requests, it ensures that in-transit transactions are not affected;

[0108] The application version effect module 910 uses an automated batch method to complete the push and copy operation of the pre-effective application version file from the application version management system to the host where the selected target middleware software process is located;

[0109] The transaction incorporation module 912 is used for the recovery operation of transactions of middleware software processes that have completed the application version effect, and completes the warm-up operation of the application version program from the disk to the middleware process memory before the transaction routing is opened;

[0110] The monitoring and observation module 914 is used for the real-time continuous observation and monitoring of the middleware software process and the overall system operation during the implementation of the application version effect according to the monitoring indicators. After meeting the observation threshold, it gives a judgment conclusion that the application version effect has no impact and a conclusion that the subsequent batch of application version effects can continue to be executed.

[0111] In the foregoing embodiment, the window for the application version effect is standardized according to the distribution of the low-volume periods of the information system throughout the day, which solves the problem of insufficient implementation window management caused by manual judgment in the existing application version effect access process and eliminates the possible risk impacts of the application version effect operation; the specific number of application version effect release objects in different stages during the implementation of the application version effect is determined through a quantitative calculation method, which can ensure the orderly implementation of the overall application version effect; different emergency recovery processes are formulated in advance according to the scope of implementation objects in different stages, which can improve the accuracy of the application version rollback in the system emergency recovery implementation in extreme scenarios; the technical solution adopted for the application version effect is further optimized. By performing the four-step method of transaction isolation, version effect, transaction recovery, and transaction operation observation on the host that implements the application version effect operation, it can ensure that the system transactions are insensitive to the application version effect operation during and after the application version effect; by defining the effective operation objects and multi-dimensional observation indicators of the overall system operation state during the application version effect, the realization of the system operation state observation during the application version effect is ensured. Combining the continuous rapid observation and verification of the smallest operable unit with priority can enhance the confidence in the application version effect technical solution and version quality, and can also optimize the implementation efficiency of the application version effect of complex systems within the restricted implementation window.

[0112] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to enable a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of the present invention.

[0113] In this embodiment, an implementation device for an application to take effect is further provided. This device is used to implement the above embodiments and preferred implementation methods, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0114] Figure 10 is a structural block diagram of an implementation device for an application to take effect according to an embodiment of the present invention. As Figure 10 shown, this device includes:

[0115] A division module 1002, configured to divide a target middleware software process into multiple process groups when there is a target application to be implemented in the service system. Among them, the target middleware software process is an operation object for implementing the target application to take effect, and the number of middleware software processes included in each process group is different;

[0116] An execution module 1004, configured to sequentially execute a target operation on multiple process groups in ascending order of the number of middleware software processes included in the process groups, where the target operation is an operation to make the target application take effect;

[0117] Among them, the target operation includes:

[0118] Within a preset time window, perform a transaction isolation operation on the target sub-middleware software processes included in the process group, and after the transaction isolation, perform an operation to update the target application on the target sub-middleware software processes; when the target application update is completed, verify whether the target application takes effect, and when the target application takes effect, exit the execution of the target operation;

[0119] Among them, the partitioning module 1002 corresponds to the middleware software process grouping module 904 described above, and the execution module 1004 corresponds to the middleware software process selection module 906, the transaction isolation module 908, the application version effect module 910, the transaction incorporation module 912, and the monitoring and observation module 914 described above.

[0120] In an exemplary embodiment, the partitioning module 1002 can implement partitioning the target middleware software process into multiple process groups in the following manner: determining the minimum number of processes that meet the verification requirements, where the update of the target application can be verified whether it has an impact on the business system through the processes with the minimum number of processes; selecting the first processes with the minimum number of processes in the target middleware software process; determining the first processes with the minimum number of processes as the first process group; dividing the other processes included in the target middleware software process except the first processes into multiple groups according to a quantity gradient to obtain multiple second process groups; and determining the first process group and the multiple second process groups as the multiple process groups.

[0121] In an exemplary embodiment, the partitioning module 1002 can implement selecting the first processes with the minimum number of processes in the target middleware software process in the following manner: in the case where the business system is a centralized architecture system, determining some or all of the middleware processes deployed in one or more virtual machines included in the business system as the first processes; in the case where the business system is a distributed architecture system, determining the middleware processes deployed in one or more virtual machines included in the business system as the first processes.

[0122] In an exemplary embodiment, the partitioning module 1002 can implement dividing the other processes included in the target middleware software process except the first processes into multiple groups according to a quantity gradient to obtain multiple second process groups in the following manner: in the case where the business system is a centralized architecture system, determining the first virtual machine in which the middleware software process has been partitioned and the second virtual machine in which the middleware software process has not been partitioned included in the business system; determining the unpartitioned second processes included in the first virtual machine and the third processes in the second virtual machine as the other processes; dividing the other processes into multiple groups according to a quantity gradient to obtain multiple second process groups; in the case where the business system is a distributed architecture system, determining the third virtual machine in which the middleware software process has not been partitioned included in the business system; dividing the third virtual machine into multiple groups according to a quantity gradient to obtain multiple virtual machine groups; and determining the processes deployed in each virtual machine group as the second process groups to obtain multiple second process groups.

[0123] In an exemplary embodiment, the execution module 1004 may implement transaction isolation operations for the target sub-middleware software process included in the process group in the following manner: when the service system is a centralized architecture system, set the transaction processing function of the target sub-middleware software process to a static state; when the service system is a distributed architecture system, delete the target sub-middleware software process from the transaction routing list of the service system, and after a predetermined duration, take down the target sub-middleware software process.

[0124] In an exemplary embodiment, the execution module 1004 may implement an operation of updating the target application for the target sub-middleware software process included in the process group by implementing transaction isolation operations for the target sub-middleware software process: obtain the application software package of the target application; push the application software package to the disk of the host where the target sub-middleware software process is located to update the target application on the host.

[0125] In an exemplary embodiment, the execution module 1004 may implement transaction isolation operations for the target sub-middleware software process included in the process group to verify whether the target application takes effect: restore the transaction processing function of the target sub-middleware software process; determine the sampling frequency based on the type of the service system; determine the target observation duration of the target sub-middleware software process; within the target observation duration, obtain the target process transaction volume of the target sub-middleware software process according to the sampling frequency; determine the system success rate of the service system when executing all functions within the target observation duration; determine the system transaction success rate of the service system when executing transactions within the target observation duration; determine the transaction response time of the service system within the target observation duration; verify whether the target application takes effect based on the target process transaction volume, the system success rate, the system transaction success rate, and the transaction response time.

[0126] In an exemplary embodiment, the execution module 1004 may implement transaction isolation operations for the target sub-middleware software process included in the process group to restore the transaction processing function of the target sub-middleware software process: when the service system is a centralized architecture system, copy the application software package of the target application from the disk of the target sub-middleware software process to the memory of the target sub-middleware software process; when the copying is completed, release the static state of the transaction processing function of the target sub-middleware software process to restore the transaction processing function of the target sub-middleware software process; when the service system is a distributed architecture system, restart the target sub-middleware software process to restore the transaction processing function of the target sub-middleware software process.

[0127] In an exemplary embodiment, the execution module 1004 can implement the transaction isolation operation of the target sub-middleware software process included in the process group to determine the target observation duration of the target sub-middleware software process in the following manner: determine the target number of the multiple process groups; sort the multiple process groups in ascending order of the number of middleware software processes included in each of the process groups to obtain a first sequence; determine the sequence number of the process group to which the target sub-middleware software process belongs in the first sequence; determine a preset minimum observation duration and an optional duration control value; determine a target difference between the target number and the sequence number; determine a ratio of the target difference to the target number; determine the product of the ratio and the optional duration control value; and determine the sum of the product and the minimum observation duration as the target observation duration.

[0128] In an exemplary embodiment, the execution module 1004 can implement the transaction isolation operation of the target sub-middleware software process included in the process group in the following manner to verify whether the target application is effective based on the target process transaction volume, the system success rate, the system transaction success rate and the transaction response time: verify whether the target process transaction volume meets the first preset condition to obtain a first verification result; verify whether the system success rate meets the second preset condition to obtain a second verification result; verify whether the system transaction success rate meets the third preset condition to obtain a third verification result; verify whether the transaction response time meets the fourth preset condition to obtain a fourth verification result; when the first verification result, the second verification result, the third verification result and the fourth verification result all indicate that the verification is successful, determine that the target application is effective; when there is a verification failure result among the first verification result, the second verification result, the third verification result and the fourth verification result, determine that the target application fails to take effect.

[0129] In an exemplary embodiment, the execution module 1004 can implement the transaction isolation operation of the target sub-middleware software process included in the process group to verify whether the target process transaction volume meets the first preset condition and obtain a first verification result in the following manner: determine a historical time period that is consistent with the time period in which the target observation duration is located; determine the average transaction volume of the target sub-middleware software process in the historical time period, and the first standard deviation of the transaction volume of the target sub-middleware software process; determine a first interval based on the average transaction volume and the first standard deviation; if the target process transaction volume is within the first interval, determine the first verification result as verification success; if the target process transaction volume is outside the first interval, determine the first verification result as verification failure.

[0130] In an exemplary embodiment, the execution module 1004 may verify whether the system success rate meets the second preset condition by performing transaction isolation operation verification on the target sub-middleware software process included in the process group, and obtain a second verification result: determine a historical time period synchronous with the time period where the target observation duration is located; determine the average system success rate of the business system and the second standard deviation of the historical system success rate within the historical time period; determine a second interval based on the average system success rate and the second standard deviation; when the system success rate is within the second interval, determine that the second verification result is verification success; when the system success rate is outside the second interval, determine that the second verification result is verification failure.

[0131] In an exemplary embodiment, the execution module 1004 may verify whether the system transaction success rate meets the third preset condition by performing transaction isolation operation verification on the target sub-middleware software process included in the process group, and obtain a third verification result: determine a historical time period synchronous with the time period where the target observation duration is located; determine the average transaction success rate of the executed transactions of the business system and the third standard deviation of the historical transaction success rate within the historical time period; determine a third interval based on the average transaction success rate and the third standard deviation; when the system transaction success rate is within the third interval, determine that the third verification result is verification success; when the system transaction success rate is outside the third interval, determine that the third verification result is verification failure.

[0132] In an exemplary embodiment, the execution module 1004 may verify whether the transaction response time meets the fourth preset condition by performing transaction isolation operation verification on the target sub-middleware software process included in the process group, and obtain a fourth verification result: determine a historical time period synchronous with the time period where the target observation duration is located; determine the average transaction response time of the business system and the fourth standard deviation of the historical transaction response time within the historical time period; determine a fourth interval based on the average transaction response time and the fourth standard deviation; when the transaction response time is within the fourth interval, determine that the fourth verification result is verification success; when the transaction response time is outside the fourth interval, determine that the fourth verification result is verification failure.

[0133] In an exemplary embodiment, after verifying whether the target application becomes effective, the device is configured to: in case the verification that the target application becomes effective fails, locate a target position that causes the failure of the target application to become effective; repair the target position, and after the repair is successful, determine the remaining duration of the preset time window; in case the remaining duration is greater than or equal to a predetermined threshold, continue to execute the target operation; in case the repair fails or the remaining duration is less than the predetermined threshold, determine a target process group for which the target application has become effective; and control processes included in the target process group to perform a rollback operation on the action of the target application becoming effective.

[0134] It should be noted that the above-mentioned respective modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited thereto: the above-mentioned modules are all located in the same processor; or, the above-mentioned respective modules are separately located in different processors in any combination form.

[0135] An embodiment of the present invention also provides a computer-readable storage medium, in which a computer program is stored. Wherein, the computer program is configured to execute the steps in any one of the above method embodiments when running.

[0136] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: various media such as USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical discs that can store computer programs.

[0137] An embodiment of the present invention also provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0138] In an exemplary embodiment, the above electronic device may further include a transmission device and an input / output device. Wherein, the transmission device is connected to the above processor, and the input / output device is connected to the above processor.

[0139] An embodiment of the present invention also provides a computer program product, including a computer program, and the steps of the methods in various embodiments of the present application are implemented when the computer program is executed by a processor.

[0140] Specific examples in this embodiment may refer to the examples described in the above embodiments and exemplary embodiments, and will not be elaborated herein.

[0141] Obviously, those skilled in the art should understand that the above-mentioned modules or steps of the present invention can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. They can be implemented by program codes executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a sequence different from that here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the present invention is not limited to any specific combination of hardware and software.

[0142] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. An implementation method for an application to take effect, characterized in that, Including: When there is a target application to be implemented in the business system, divide the target middleware software process into multiple process groups, where the target middleware software process is the operation object for implementing the target application to take effect, and the number of middleware software processes included in each process group is different; Perform a target operation on multiple process groups in ascending order of the number of middleware software processes included in the process group, where the target operation is an operation for making the target application take effect; Among them, the target operation includes: Within a preset time window, perform a transaction isolation operation on the target sub-middleware software processes included in the process group, and after the transaction isolation, perform an operation of updating the target application on the target sub-middleware software processes; when the target application update is completed, verify whether the target application takes effect, and when the target application takes effect, exit the execution of the target operation.

2. The method according to claim 1, wherein Dividing the target middleware software process into multiple process groups includes: Determine the minimum number of processes that meet the verification requirements, where the update of the target application can be verified whether it has an impact on the business system through the processes with the minimum number of processes; Select the first process with the minimum number of processes from the target middleware software processes; Determine the first process group with the minimum number of processes; Divide the other processes included in the target middleware software processes except the first process into multiple groups according to a quantity gradient to obtain multiple second process groups; Determine the first process group and multiple second process groups as multiple process groups.

3. The method according to claim 2, wherein Selecting the first process with the minimum number of processes from the target middleware software processes includes: When the business system is a centralized architecture system, determine some or all of the middleware processes deployed in one or more virtual machines included in the business system as the first process; When the business system is a distributed architecture system, determine the middleware processes deployed in one or more virtual machines included in the business system as the first process.

4. The method according to claim 2, wherein Dividing the other processes included in the target middleware software processes except the first process into multiple groups according to a quantity gradient to obtain multiple second process groups includes: When the business system is a centralized architecture system, determine the first virtual machine that has already divided middleware software processes and the second virtual machine that has not divided middleware software processes included in the business system; Determine the undivided second processes included in the first virtual machine and the third processes in the second virtual machine as the other processes; Divide the other processes into multiple groups according to a quantity gradient to obtain multiple second process groups; When the business system is a distributed architecture system, determine the third virtual machine that has not divided middleware software processes included in the business system; Divide the third virtual machine into multiple groups according to a quantity gradient to obtain multiple virtual machine groups; Determine the processes deployed in each virtual machine group as the second process group to obtain multiple second process groups.

5. The method according to claim 1, wherein The transaction isolation operation on the target sub-middleware software process included in the process group includes: In the case where the business system is a centralized architecture system, setting the transaction processing function of the target sub-middleware software process to a static state; In the case where the business system is a distributed architecture system, the target sub-middleware software process is deleted from the transaction routing list of the business system, and the target sub-middleware software process is shut down after a predetermined period of time.

6. The method according to claim 1, wherein The operation of updating the target application on the target sub-middleware software process includes: Obtaining an application software package of the target application; The application software package is pushed to the disk of the host where the target sub-middleware software process is located, so as to update the target application on the host.

7. The method according to claim 1, wherein Verifying whether the target application is effective includes: Restoring the transaction processing function of the target sub-middleware software process; Determining a sampling frequency based on the type of the business system; Determining a target observation duration of the target sub-middleware software process; Acquiring the target process transaction volume of the target sub-middleware software process according to the sampling frequency within the target observation time; Determine the system success rate of executing all functions of the business system within the target observation time; Determine the system transaction success rate of the business system executing transactions within the target observation time; Determine the transaction response time of the business system within the target observation time; Whether the target application is effective is verified based on the target process transaction volume, the system success rate, the system transaction success rate, and the transaction response time.

8. The method according to claim 7, characterized in that, Restoring the transaction processing function of the target sub-middleware software process includes: In the case where the business system is a centralized architecture system, copying the application software package of the target application from the disk of the target sub-middleware software process to the memory of the target sub-middleware software process; When the copying is completed, releasing the quiescent state of the transaction processing function of the target sub-middleware software process to restore the transaction processing function of the target sub-middleware software process; In the case where the business system is a distributed architecture system, the target sub-middleware software process is restarted to restore the transaction processing function of the target sub-middleware software process.

9. The method according to claim 7, characterized in that, Determining the target observation duration of the target sub-middleware software process includes: determining a target number of a plurality of said process groups; Sorting the plurality of process groups in ascending order of the number of middleware software processes included in each process group to obtain a first sequence; Determine the sequence number of the process group to which the target sub-middleware software process belongs in the first sequence; Determine the preset minimum observation duration and optional duration control value; determining a target difference between a target quantity and the sequence number; determining a ratio of the target difference to the target amount; Determining a product of the ratio and the selectable duration control value; The sum of the product and the minimum observation duration is determined as the target observation duration.

10. The method according to claim 7, characterized in that Verifying whether the target application is effective based on the target process transaction volume, the system success rate, the system transaction success rate, and the transaction response time includes: Verifying whether the target process transaction volume meets a first preset condition, and obtaining a first verification result; Verifying whether the system success rate meets a second preset condition, and obtaining a second verification result; Verifying whether the system transaction success rate meets a third preset condition, and obtaining a third verification result; Verifying whether the transaction response time satisfies a fourth preset condition, and obtaining a fourth verification result; When the first verification result, the second verification result, the third verification result, and the fourth verification result all indicate that the verification is successful, determining that the target application is effective; When there is a verification failure result among the first verification result, the second verification result, the third verification result, and the fourth verification result, it is determined that the target application fails to take effect.

11. The method according to claim 10, characterized in that, Verifying whether the target process transaction volume meets a first preset condition, and obtaining a first verification result includes: Determine the historical time period that is the same as the time period during which the target observation duration occurs; Determine an average transaction volume of the target sub-middleware software process during the historical time period, and a first standard deviation of the transaction volume of the target sub-middleware software process; determining a first interval based on the average transaction volume and the first standard deviation; When the target process transaction volume is within the first interval, determining the first verification result as verification success; When the transaction volume of the target process is outside the first interval, the first verification result is determined to be a verification failure.

12. The method according to claim 10, wherein Verifying whether the system success rate meets the second preset condition, and obtaining the second verification result includes: Determine the historical time period that is the same as the time period during which the target observation duration occurs; Determine an average system success rate of the business system during the historical time period, and a second standard deviation of the historical system success rate; determining a second interval based on the average system success rate and the second standard deviation; When the system success rate is within the second interval, determining the second verification result as verification success; When the system success rate is outside the second interval, the second verification result is determined to be a verification failure.

13. The method according to claim 10, wherein Verifying whether the system transaction success rate meets the third preset condition, and obtaining the third verification result includes: Determine the historical time period that is the same as the time period during which the target observation duration occurs; Determine an average transaction success rate of transactions executed by the business system during the historical time period and a third standard deviation of the historical transaction success rate; determining a third interval based on the average transaction success rate and the third standard deviation; When the system transaction success rate is within the third interval, determining the third verification result as verification success; When the system transaction success rate is outside the third interval, the third verification result is determined to be a verification failure.

14. The method according to claim 10, wherein Verifying whether the transaction response time satisfies a fourth preset condition, and obtaining a fourth verification result includes: Determine the historical time period that is the same as the time period during which the target observation duration occurs; Determine the average transaction response time of the business system and the fourth standard deviation of the historical transaction response time within the historical time period; Determine a fourth interval based on the average transaction response time and the fourth standard deviation; When the transaction response time is within the fourth interval, determine that the fourth verification result is verification successful; When the transaction response time is outside the fourth interval, determine that the fourth verification result is verification failed.

15. The method according to claim 1, characterized in that, After verifying whether the target application takes effect, the method further includes: When the verification that the target application takes effect fails, locate the target location that causes the failure of the target application to take effect; Repair the target location, and after the repair is successful, determine the remaining duration of the preset time window; When the remaining duration is greater than or equal to a predetermined threshold, continue to execute the target operation; When the repair fails or the remaining duration is less than the predetermined threshold, determine the target process group for which the target application has taken effect; Control the processes included in the target process group to perform a rollback operation on the operation of making the target application take effect.

16. An implementation device for an application to take effect, characterized in that, including: A division module, configured to divide the target middleware software process into multiple process groups when there is a target application to be implemented in the business system, where the target middleware software process is the operation object for implementing the target application to take effect, and the number of middleware software processes included in each process group is different; An execution module, configured to sequentially execute a target operation on multiple process groups in ascending order of the number of middleware software processes included in the process group, where the target operation is an operation to make the target application take effect; wherein, the target operation includes: Within a preset time window, perform a transaction isolation operation on the target sub-middleware software process included in the process group, and after the transaction isolation, perform an operation of updating the target application on the target sub-middleware software process; when the target application update is completed, verify whether the target application takes effect, and when the target application takes effect, exit the execution of the target operation.

17. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program is configured to execute the method described in any one of claims 1 to 15 when running.

18. An electronic device, comprising a memory and a processor, characterized in that, A computer program is stored in the memory, and the processor is configured to run the computer program to execute the method described in any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, the steps of the method described in any one of claims 1 to 15 are implemented.

Images