Application update publishing method and device, computer equipment and storage medium

Abstract

The invention relates to the field of base frame operation and maintenance, finance and medical science and technology, and discloses an application update publishing method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring an access request, and guiding the acquired access request to an initial system; when an application updating instruction is received, releasing the target system and updating the target system to the target version; switching the preset number of access requests to a target system through a preset shunting rule; and judging whether the target system reaches a preset running state or not, and if so, switching the remaining access requests to the target system. According to the method and the device, the preset number of access requests can be automatically switched to the target system through the preset shunting rule, so that the manual operation link is reduced, and the application updating and publishing efficiency is greatly improved; by gradually switching the access request to the target system, the stability of the target system can be tested in a small range, problems can be found and solved in time, the influence on a user is reduced, and the use experience and satisfaction of the user are improved.

Description

Technical Field

[0001] The present invention relates to the fields of infrastructure operation and maintenance, finance, and medical technology, and particularly to an application update and release method, device, computer device, and storage medium. Background Art

[0002] In today's digital age, the update and release of applications have become extremely common and frequent tasks for maintaining application systems. Whether it is to fix vulnerabilities, add new features, or optimize performance, applications need to be continuously updated to adapt to the ever-changing business requirements and user expectations. For various companies, especially financial, medical, and their related service enterprises, ensuring the stable operation of application services is of utmost importance. Financial operations involve a large number of fund transactions, customer sensitive information, and complex business logics. The stability of application services is directly related to the smooth progress of transactions, the security of customer funds, as well as the reputation and compliance of enterprises. Once the application services become unstable, it may lead to serious consequences such as transaction failures, data loss or leakage, which will not only cause huge economic losses to customers but also expose enterprises to legal risks and trust crises, greatly damaging the market image and competitiveness of enterprises; while the instability of medical application systems will disrupt the continuity of medical services, such as affecting links like registration, consultation, and treatment, and is prone to data loss and leakage, and will also damage the enterprise's reputation, reduce patient trust, and even endanger the life safety of patients, causing immeasurable losses.

[0003] The existing application update and release method is as follows: the application is updated by adopting a node-by-node release method, that is, after each node is released and verified without errors, then other nodes are updated. Such operations are complex and error-prone, resulting in low efficiency of application update and release, and also consuming a large amount of labor costs; and after all nodes are successfully released, if there are major defects or incompatibilities in the updated version, it takes a long time to urgently fix the problems or roll back the version, affecting the user experience and resulting in a poor usage experience. Summary of the Invention

[0004] The present invention provides an application update and release method, device, computer device, and storage medium to solve the technical problems of low efficiency and poor user experience of the existing application update and release method.

[0005] In a first aspect, an application update and release method is provided, including:

[0006] Obtain an access request and direct the obtained access request to the initial system;

[0007] When receiving an application update instruction, release the target system and update the target system to the target version;

[0008] Switch a predetermined number of access requests to the target system through a preset traffic splitting rule;

[0009] Determine whether the target system reaches a preset operating state. If it does, switch the remaining access requests to the target system.

[0010] In a second aspect, an application update and release device is provided, including:

[0011] An acquisition module, configured to acquire access requests and direct the acquired access requests to an initial system;

[0012] An update module, configured to release a target system and update the target system to a target version when receiving an application update instruction;

[0013] A shunt module, configured to switch a predetermined number of access requests to the target system according to a preset shunt rule;

[0014] A transfer module, configured to determine whether the target system reaches a preset operating state. If it does, switch the remaining access requests to the target system.

[0015] In a third aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the above application update and release method are implemented.

[0016] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above application update and release method are implemented.

[0017] The beneficial effects of the present invention compared with the prior art are as follows: By presetting a shunt rule, the present invention can flexibly adapt to different project release requirements, and can also automatically switch a predetermined number of access requests to the target system, reducing the manual operation link and avoiding the process of configuring and verifying each node one by one, thereby greatly improving the efficiency of application update and release and enabling the new system to be put into use faster; By gradually switching access requests to the target system, the stability of the target system can be tested in a small range to timely discover and solve problems, reducing the impact on users. Even if problems occur in the target system, only the shunt rule needs to be adjusted to switch part or all of the traffic back to the initial system, and the service can be quickly restored, avoiding long-term impact on user use and improving the user experience and satisfaction.

[0018] The above description is only an overview of the technical solution of the present invention. In order to understand the technical means of the present invention more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present invention more obvious and understandable, the following preferred embodiments are specifically described in detail as follows. Description of the Drawings

[0019] Figure 1 It is a schematic diagram of an application environment for applying the update and release method in an embodiment of the present invention;

[0020] Figure 2 It is a schematic flowchart of applying the update and release method in an embodiment of the present invention;

[0021] Figure 3 is Figure 2 a schematic flowchart of a specific implementation manner of step S10 in;

[0022] Figure 4 is Figure 2 a schematic flowchart of a specific implementation manner of step S20 in;

[0023] Figure 5 is Figure 2 a schematic flowchart of a specific implementation manner of step S30 in;

[0024] Figure 6 It is a schematic structural diagram of an update and release device in an embodiment of the present invention;

[0025] Figure 7 It is a schematic structural diagram of a computer device in an embodiment of the present invention;

[0026] Figure 8 It is another schematic structural diagram of a computer device in an embodiment of the present invention. Specific Embodiment

[0027] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0028] It should be understood that when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or their combinations.

[0029] It should also be understood that the terms used in the specification of the present invention are merely for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include the plural forms.

[0030] It should be further understood that the term "and / or" used in the specification of the present invention and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0031] Please refer to Figure 1 and Figure 2 , Figure 1 FIG. is a schematic diagram of an application scenario of the application update and release method provided by an embodiment of the present invention. The user sends an access request to the server through the client and the network. The server obtains the access request and directs the access request to the corresponding application system. The server can also manage, update and release the application system for the user to access the initial system or the target system on the client. Among them, the client can be, but is not limited to, various personal computers, laptop computers, smart phones, tablet computers and portable wearable devices. The server can be implemented by an independent server or a server cluster composed of multiple servers. The present invention will be described in detail below through specific embodiments.

[0032] Please refer to Figure 2 as shown in Figure 2 FIG. is a schematic flowchart of the application update and release method provided by an embodiment of the present invention. The application update and release method includes the following steps:

[0033] S10: Obtain an access request and direct the obtained access request to the initial system.

[0034] The application update and release method described in this embodiment is applicable to various types of application systems, especially financial and medical application systems with high requirements for service stability and continuity, such as online banking systems, securities trading systems, payment and settlement systems, insurance business systems, financial data platforms, patient information management systems, electronic medical record systems, medical imaging archiving and communication systems, remote medical systems, etc.

[0035] The user sends an access request to access the application system through the client. The server receives the access request and directs it to the initial system, enabling the user to make functional requests through the initial system. It can be understood that the initial system is an application system whose version is to be updated. The server manages the application system and the access request for subsequent version update and release of the application system.

[0036] For example, an investor sends access requests such as login, fund query, stock purchase, order cancellation, and securities position quantity query to the server through the client of a securities trading system with version number V2.0. When the server detects that the new version of the securities trading system has not been successfully released, it redirects all the obtained access requests to the initial securities trading system, that is, the securities trading system with version number V2.0.

[0037] Also for example, medical staff send access requests such as viewing patient medical records, entering diagnosis information, modifying doctor's orders, querying inspection reports, and uploading imaging materials to the server through the client of an electronic medical record system with version number V3.0. When the server detects that the new version of the electronic medical record system has not been successfully released, it redirects all the obtained access requests to the initial electronic medical record system, that is, the electronic medical record system with version number V3.0.

[0038] Among them, as Figure 3 shown, step S10, that is, obtaining access requests and redirecting the obtained access requests to the initial system, includes the following steps S11 - S15.

[0039] S11: Configure and manage the initial system using the API interface.

[0040] Step S11 can comprehensively and uniformly configure and manage the initial system, ensuring that the initial system is in a state where it can normally receive and process access requests, laying a foundation for subsequent application updates and releases.

[0041] Among them, the API (full name: Application Programming Interface) interface is the application programming interface, which is a set of definitions, protocols, and tools for building interactions between application systems. Through the API interface, system administrators can conveniently adjust and manage various parameters, functional modules, permission settings, etc. of the initial system, realizing flexible configuration and efficient operation and maintenance of the application system; at the same time, the API interface provides a standardized interaction method, facilitating integration with other systems or components. In this embodiment, both the initial system and the target system are configured and managed through the API interface, making the redirection operation of access requests efficient and convenient.

[0042] S12: Obtain access requests through a proxy server.

[0043] The proxy server is located between the client and the server, can receive requests from the client, forward the requests to the target server, and then return the response of the target server to the client, providing functions of caching, filtering, and acceleration, improving the efficiency and security of network access.

[0044] In this embodiment, the proxy server is an Nginx proxy server. Nginx is an open-source high-performance HTTP and web reverse proxy server, with high performance, high concurrency processing ability, and load balancing function. It can effectively distribute access requests, avoid overloading of a single server, and can be secondary developed and encapsulated, which is conducive to adjustment according to different project requirements and application systems, enhancing the flexibility and adaptability of the application update and release method. In addition, the Nginx proxy server can hide the real server address, isolate the communication between the client and the server, and enhance the security of the system operation and the application update and release process.

[0045] S13: Configure the initial access rules through the API interface and pass the initial access rules to the Lua script.

[0046] System administrators can flexibly define the processing rules for access requests through the API interface, ensuring that access requests can be allocated to application systems according to predetermined rules, reducing labor costs, and improving the automation and controllability of application update and release. The initial access rules, that is, define that all access requests are directed to the initial system. Compared with the target system, the initial system has higher stability and can handle various conventional access requests and business scenarios. Directing all access requests to the initial system can ensure the normal operation of the application system during version update and release, avoid unknown problems caused by directly introducing the target system and affecting the stability of the service, and ensure the stability and continuity of the application system service.

[0047] Among them, the Lua script is a lightweight and efficient scripting language. In the application update and release method of this embodiment, the Lua script is used to implement the logical processing and rule matching of access requests, and determine the routing and processing method of requests according to the initial access rules. The Lua script can implement asynchronous operations when processing access requests, without blocking the processing of other requests, thus making full use of system resources and further enhancing the system's concurrency processing ability. Moreover, through the Lua script, the processing rules of access requests can be dynamically configured and adjusted according to different types of application systems, business requirements, and business scenarios, that is, system administrators can quickly change the application system to which access requests are allocated by modifying the code in the Lua script, without recompiling and deploying the entire application program, simplifying the difficulty of version update and greatly improving the efficiency of application update and release.

[0048] S14: The Lua script matches the access request with the initial system according to the initial access rules and the access request.

[0049] According to the initial access rules, each access request is analyzed and judged to determine whether the request meets the access conditions of the initial system, and the qualified requests are associated with the initial system, so that the proxy server can return the response of the access request to the client, improving the security and stability of the application system.

[0050] S15: The proxy server directs the access requests that match the initial system to the initial system through the API interface.

[0051] In step S15, the Nginx proxy server communicates with the initial system through the API interface according to the matching result of the Lua script, and passes the access request to the initial system, ensuring that the user's request can be processed and responded to in a timely manner, and also facilitating the monitoring and management of the forwarding process of the access request.

[0052] For example, in a securities trading system, investors send access requests such as querying stock quotes, buying stocks, selling stocks, and canceling orders on the client side. The server manages the initial securities trading system through the API interface. After receiving the request, the Nginx proxy server passes it to the initial access rules of the Lua script according to the API interface configuration. The Lua script matches the request with the initial system, and the Nginx proxy server directs the matched request to the initial securities trading system, such as the securities trading system with version number V2.0, enabling investors to successfully complete operations such as querying stock quotes, placing trading orders, and canceling orders.

[0053] For example, in an electronic medical record system, medical staff send access requests such as viewing patients' past medical records and adding the latest diagnosis records on the client side. The server also configures and manages the initial electronic medical record system through the API interface. After receiving the request, the Nginx proxy server passes it to the initial access rules of the Lua script according to the API interface configuration. The Lua script matches the request with the initial system, and the Nginx proxy server directs the matched request to the initial electronic medical record system, such as the electronic medical record system with version number V3.0, enabling medical staff to successfully complete operations such as viewing medical records and updating records.

[0054] S20: When receiving an application update instruction, publish the target system and update the target system to the target version.

[0055] Step S20 is a key link in the application update and release process. When receiving an application update instruction, it means that the application system needs to introduce new functions, fix known vulnerabilities, or perform performance optimization, etc. At this time, the target system needs to be deployed and updated to the target version to facilitate the transfer of access requests, thereby meeting business development and user needs.

[0056] For example, when the electronic medical record system needs to be updated from version V3.0 to V3.1, after the server receives the application update instruction, a new electronic medical record system, i.e., the target system, is deployed. The target system is independent of the initial system with version number V3.0. Then, the new electronic medical record system is updated to version V3.1 to await the transfer of subsequent access requests between the two systems.

[0057] Among them, as Figure 4 shown, step S20, that is, when receiving the application update instruction, publish the target system and update the target system to the target version, including the following steps S21 - S22.

[0058] S21: Receive the application update instruction through the API interface and pass the application update instruction to the Lua script.

[0059] The API interface, as a standardized channel for interaction between application systems, can receive the application update instruction; pass the received instruction to the Lua script to utilize the flexible programming ability and high - performance execution of the Lua script to further process and parse the update instruction, preparing for the configuration and release of the subsequent target system.

[0060] S22: The Lua script deploys and publishes the target system according to the application update instruction and updates the target system to the target version.

[0061] It can be understood that the target system of this embodiment drives the Lua script for configuration and management through the API interface, so that the Lua script can conveniently guide the access request from the initial system to the target system through the API interface. The Lua script has high flexibility and can perform dynamic logical processing according to different update instructions. By passing the update instruction to the Lua script, the automation of the update process can be achieved, reducing manual intervention, reducing incorrect operations caused by manual intervention, and improving the efficiency and accuracy of application updates.

[0062] For example, the securities trading system with version number V2.0 is the initial system, and the securities trading system with version number V2.1 is the target system. Both versions of the securities trading system are configured under the API interface. The system administrator can change the system parameter configuration through the API interface to adjust trading events, change the opening time, and set the price limit. The administrator can also import historical trading data, import financial reports of listed companies, export trading records of investors, and export investor account information through data management operations. Additionally, the version release and transfer of access requests can be achieved through the API interface in combination with Lua scripts and the Nginx proxy server. Another example is that the electronic medical record system with version number V3.0 is the initial system, and the electronic medical record system with version number V3.1 is the target system. This version of the electronic medical record system is configured under the API interface. The system administrator can change the system parameter configuration through the API interface to adjust the medical record display format, set the query time limit for inspection reports, and modify the medical record storage period. The administrator can also enable a new medical record template function and disable an outdated medical record statistics module through function module management operations. Moreover, the version release and transfer of access requests can be realized through the API interface in conjunction with Lua scripts and the Nginx proxy server.

[0063] S30: Switch a predetermined number of access requests to the target system according to a preset traffic splitting rule.

[0064] There may be some potential problems in the target system during the initial release period, such as code vulnerabilities, configuration errors, or performance bottlenecks. By first introducing some access requests to the target system, a comprehensive verification and testing of the new system can be carried out on a small scale. In this process, the target system can withstand relatively small pressure, facilitating the timely discovery and resolution of potential problems, avoiding serious system failures after a large-scale traffic switch, and ensuring the stability of the entire application system. And directly switching all access requests to the target system may cause the target system to instantly bear a huge load pressure, thus affecting the performance and stability of the system. By adopting the method of gradually switching the traffic, the target system can gradually adapt to and process the increasing access requests, achieving a smooth transition of the application system load. The initial system can still share a part of the traffic during this process, ensuring the normal operation of the entire application system.

[0065] Among them, the traffic splitting rule can be set diversely and customized according to the specific project requirements.

[0066] Preferably, the traffic splitting rule is the weight of the obtained access requests directed to the initial system and the target system. For example, the ratio of the number of access requests switched to the target system to the number of access requests maintained in the initial system is 1:9. Specifically, in an electronic medical record system, according to the preset traffic splitting rule, 10% of the access requests of medical staff to query medical records are first switched to the target system to test the stability of the new version function and service in a small range. Most access requests are maintained in the initial system, while a small part of access requests are directed to the target system. By importing access requests to the target system in a small range, it is possible to avoid the system crash of the target system due to a sudden increase in traffic. And if there are problems during the operation of the target system, since only a small number of users are affected, the losses and negative impacts can be controlled within a small range. At the same time, it is conducive to the development team to quickly take measures, such as rolling back to the initial system or urgently fixing problems, to restore the normal operation of the service, ensuring the service stability of the application system.

[0067] Preferably, the traffic splitting rule is the number of access requests switched to the target system per unit time. For example, a predetermined number of access requests are directed to the target system every minute. Specifically, in a securities trading system, according to the rule of 500 access requests per minute, trading query requests are gradually switched to the target system. The target system may experience performance fluctuations during operation, such as a longer response time or a short-term failure during a certain period. By setting the number of access request switches per unit time, it is possible to adjust the switching speed in a timely manner when detecting performance fluctuations of the target system, or even pause the traffic splitting of access requests. For example, when it is found that the response time of the target system exceeds the preset threshold, the number of access requests switched to the target system per unit time can be immediately reduced, and then continue to switch after the target system returns to normal, effectively ensuring the service stability and availability of the application system.

[0068] Among them, as Figure 5 shown, step S30, that is, switching a predetermined number of access requests to the target system through the preset traffic splitting rule, includes the following steps S31 - S33.

[0069] S31: Configure the traffic splitting rule through the API interface and pass the traffic splitting rule to the Lua script.

[0070] With the standardized interaction characteristics of the API interface, system administrators can flexibly and conveniently configure traffic splitting rules, achieving the adaptability and customization of traffic splitting rule configuration. And both the initial system and the target system are configured on the API interface, facilitating the traffic splitting of access requests using the standardization of the API interface, simplifying the difficulty of application update and release, and further improving the efficiency of application update and release.

[0071] S32: The Lua script matches a predetermined number of access requests with the target system according to the traffic splitting rule.

[0072] Match the access requests with the target system according to time, weight or other traffic splitting rules, which helps to achieve automatic switching of a predetermined number of access requests, avoiding the process of manually configuring and verifying each node one by one, thus greatly improving the efficiency of application update and release, and enabling the new system to be put into use faster.

[0073] S33: The proxy server directs the access requests matched with the target system to the target system through the API interface.

[0074] The Nginx proxy server communicates with the target system using the API interface based on the matching results of the Lua script, and accurately transfers the access requests that have been matched with the target system to the target system, thus realizing the switching of access requests from the initial system to the target system, ensuring that the user's access requests can be directed to the target system in a timely and accurate manner, enabling the target system to start processing these requests, and ensuring the smooth progress of traffic switching during the application update and release process; and communicating through the API interface facilitates the monitoring and management of the forwarding process of access requests, improving the maintainability and stability of the application system.

[0075] S40: Determine whether the target system reaches the preset operating state. If it does, switch the remaining access requests to the target system.

[0076] Step S40 ensures appropriate quality control and risk control of the target system to avoid major problems and hidden dangers in the target version. In the early stage of the application update and release operation, some access requests have been introduced into the target system for small-scale testing. By determining whether the target system reaches the preset operating state, it is possible to comprehensively evaluate the stability, performance and correctness of business logic of the target system in the actual operating environment. The preset operating state includes but is not limited to indicators such as response time, throughput, and error rate. Only when the target system meets these preset conditions will the remaining access requests be switched to the target system to ensure high reliability of the application system when used by a large number of users.

[0077] Specifically, in the target system of the electronic medical record system, the system administrator can set up a problem feedback module to collect user feedback within 24 hours of the target system running, so that the system administrator can promptly repair the corresponding problems. If no major system problems are collected, it can be confirmed that the target system has reached the preset operating state; the system administrator can also regularly check the integrity of the medical record data to check whether there are any missing key information fields in each medical record, such as patient name, age, diagnosis result, etc. If there is no data loss or damage caused by system problems, it can be confirmed that the target system has reached the preset operating state; the system administrator can also perform data association verification between different modules of the running target system, such as whether the test report data of the patient is associated and consistent with the diagnosis result in the medical record, and whether the doctor's order information matches the pharmacy drug dispensing record. If the data association inconsistency rate needs to be controlled below 0.1%, it can be confirmed that the target system has reached the preset operating state.

[0078] S50: Update the initial system to the target version.

[0079] In specific implementation, such as in the process of the electronic medical record system from version V3.0 to the release of version V3.1, after some users access the target system with version number V3.1 and the target system with version number V3.1 has reached the preset operating state, update the initial system with version number V3.0 to version V3.1 to synchronize the versions of the two systems.

[0080] After the target system has been used by some users and tested by the system administrator, and all access requests have been switched to the target system, updating the initial system to the target version helps to achieve the unification and standardization of the application system, keep the versions of the initial system and the target system consistent, facilitate the subsequent maintenance and management of the application system, and prepare for the next application update and release, ensuring that the entire application system is always in the latest state.

[0081] It can be seen that in the above solution, through the preset diversion rules, it can flexibly adapt to different project release requirements, and can also automatically switch a predetermined number of access requests to the target system, reducing the manual operation link and avoiding the process of configuring and verifying each node one by one, thus greatly improving the efficiency of the application update and release, enabling the new system to be put into use faster; by gradually switching the access requests to the target system, it can test the stability of the target system in a small range, discover and solve problems in a timely manner, reduce the impact on users. Even if there are problems with the target system, it only needs to adjust the diversion rules and switch part or all of the traffic back to the initial system to quickly resume the service, avoiding long-term impact on user use and enhancing the user experience and satisfaction.

[0082] It should be understood that the sequence numbers of the steps in the above embodiments do not imply the order of execution. The execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0083] In one embodiment, the present invention provides an application update and release device, which corresponds to the application update and release method in the above embodiment one by one. As Figure 6 shown, the application update and release device includes an acquisition module 101, an update module 102, a shunt module 103, and a transfer module 104. The detailed description of each functional module is as follows:

[0084] The acquisition module 101 is used to acquire an access request and direct the acquired access request to the initial system.

[0085] The update module 102 is used to release the target system and update the target system to the target version when receiving an application update instruction.

[0086] The shunt module 103 is used to switch a predetermined number of access requests to the target system according to a preset shunt rule.

[0087] The transfer module 104 is used to determine whether the target system reaches a preset operating state. If so, switch the remaining access requests to the target system.

[0088] In one embodiment, the acquisition module 101 is specifically used for:

[0089] Configure and manage the initial system using an API interface;

[0090] Acquire an access request through a proxy server;

[0091] Configure an initial access rule through an API interface and pass the initial access rule to a Lua script;

[0092] The Lua script matches the access request with the initial system according to the initial access rule and the access request;

[0093] The proxy server directs the access request that matches the initial system to the initial system through an API interface.

[0094] In one embodiment, the update module 102 is specifically used for:

[0095] Receive an application update instruction through an API interface and pass the application update instruction to a Lua script;

[0096] The Lua script configures and releases the target system according to the application update instruction and updates the target system to the target version.

[0097] In one embodiment, the shunt module 103 is specifically configured to: configure shunt rules through an API interface and pass the shunt rules to a Lua script;

[0098] The Lua script matches a predetermined number of access requests with a target system according to the shunt rules;

[0099] The proxy server directs the access requests that match the target system to the target system through the API interface.

[0100] In one embodiment, the application update and release device further includes:

[0101] The unified module 105 is used to update the initial system to the target version.

[0102] For the specific limitations of the application update and release device, reference may be made to the limitations on the application update and release method in the foregoing text, which will not be elaborated herein. Each module in the above application update and release device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor in the computer device in hardware form or be independent of it, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.

[0103] In one embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 7 shown. The computer device includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client through a network connection. When the computer program is executed by the processor, it realizes the functions or steps of an application update and release method for the server.

[0104] In one embodiment, a computer device is provided. The computer device can be a client, and its internal structure diagram can be as Figure 8As shown in the figure. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the client side of an application update and release method.

[0105] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the following steps are realized:

[0106] Obtain an access request and direct the obtained access request to the initial system;

[0107] When an application update instruction is received, release the target system and update the target system to the target version;

[0108] Switch a predetermined number of access requests to the target system through a preset shunting rule;

[0109] Determine whether the target system reaches a preset operating state. If it reaches, switch the remaining access requests to the target system.

[0110] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, the following steps are realized:

[0111] Obtain an access request and direct the obtained access request to the initial system;

[0112] When an application update instruction is received, release the target system and update the target system to the target version;

[0113] Switch a predetermined number of access requests to the target system through a preset shunting rule;

[0114] Determine whether the target system reaches a preset operating state. If it reaches, switch the remaining access requests to the target system.

[0115] It should be noted that for the functions or steps that the above computer-readable storage medium or computer device can achieve, reference can be made to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0116] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0117] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0118] The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention and should all be included in the protection scope of the present invention.

Claims

1. An application update publishing method, characterized in that: include: Obtaining an access request, and directing the obtained access request to an initial system; When receiving an application update instruction, publishing the target system and updating the target system to the target version; Switching a predetermined number of access requests to the target system through preset diversion rules; It is determined whether the target system has reached a preset operating state, and if so, the remaining access requests are switched to the target system.

2. The application update publishing method according to claim 1, characterized in that: The obtaining of the access request and directing the obtained access request to the initial system includes: Using an API interface to configure and manage the initial system; Get access requests through a proxy server; Configure initial access rules through an API interface, and pass the initial access rules to a Lua script; The Lua script matches the access request with the initial system according to the initial access rule and the access request; The proxy server directs the access request matching the initial system to the initial system through the API interface.

3. The application update publishing method according to claim 2, characterized in that: When receiving the application update instruction, publishing the target system and updating the target system to the target version includes: Receive application update instructions through the API interface, and pass the application update instructions to the Lua script; The Lua script deploys and releases the target system according to the application update instruction, and updates the target system to the target version.

4. The application update publishing method according to claim 3, characterized in that: The switching of a predetermined number of access requests to the target system by using a preset diversion rule includes: Configure the diversion rules through the API interface and pass the diversion rules to the Lua script; The Lua script matches a predetermined number of access requests with the target system according to the diversion rule; The proxy server directs the access request matching the target system to the target system through the API interface.

5. The application update publishing method according to claim 1, characterized in that: The diversion rule is the weight of the obtained access request directed to the initial system and the target system.

6. The application update publishing method according to claim 1, characterized in that: The diversion rule is the number of access requests switched to the target system within a unit time.

7. The application update publishing method according to claim 1, characterized in that: The step of determining whether the target system has reached a preset operating state, and if so, switching the remaining access requests to the target system, further includes: Update the initial system to the target version.

8. An application update publishing device, characterized in that: include: An acquisition module, used for acquiring access requests and directing the acquired access requests to an initial system; An update module, for releasing a target system and updating the target system to a target version when receiving an application update instruction; A diversion module, used to switch a predetermined number of access requests to a target system according to a preset diversion rule; The transfer module is used to determine whether the target system has reached a preset operating state, and if so, switch the remaining access requests to the target system.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the application update publishing method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the application update publishing method according to any one of claims 1 to 7 are implemented.

Images