CN107844343B - Upgrading system and method for complex server application system - Google Patents
Upgrading system and method for complex server application system Download PDFInfo
- Publication number
- CN107844343B CN107844343B CN201711192143.7A CN201711192143A CN107844343B CN 107844343 B CN107844343 B CN 107844343B CN 201711192143 A CN201711192143 A CN 201711192143A CN 107844343 B CN107844343 B CN 107844343B
- Authority
- CN
- China
- Prior art keywords
- upgrading
- task
- application
- upgrade
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses an upgrading system and method of a complex server application system, which comprises the steps of receiving and analyzing an upgrading data packet through an upgrading service management end, generating an application task information list, and sequencing all application type nodes in the application task information list according to application types; generating an application upgrading task list containing each upgrading subtask according to the application task information list, and the received application server configuration information and upgrading parameter configuration information; and according to a preset task scheduling strategy, sequentially acquiring upgrading subtasks from the application upgrading task list, and distributing the upgrading subtasks to corresponding upgrading service execution. According to the method and the device, the priority of the upgrading subtasks is determined according to the application types, and then the tasks are distributed according to the priority and the task scheduling strategy, so that the ordered upgrading of each application is coordinated, the upgrading tasks can be configured, the automatic upgrading of the application system of the complex server side is realized, and compared with manual upgrading, the efficiency is high, and the accuracy is good.
Description
Technical Field
The invention relates to the technical field of operation and maintenance, in particular to a system and a method for upgrading a complex server application system.
Background
With the advancement of cloud computing, how to automatically upgrade a complex server application system has become an operation and maintenance problem.
Referring to a typical structure of the existing complex server application system shown in fig. 1, the existing complex server application system may generally include an interface layer, a service layer, a data access layer, and a database layer, where each layer may be a group of cluster deployment modes, and when any one application is upgraded, the whole structure will be affected.
The existing complicated server application system is generally upgraded manually, and the system structure is complicated, which inevitably results in large workload, low upgrading efficiency and easy occurrence of errors. For example, each time the service requirement changes or the system problem is repaired, the application on the relevant server needs to be upgraded, and the system administrator needs to do the upgrade work on the relevant application server and the database server one by one. In addition, because the hierarchical deployment exists, the dependency relationship exists between the applications, and the upgrading sequence needs to be considered in the upgrading process. If no coordination work is done in the upgrading process, the system can not be normally used probably because the program versions of the applications in each layer are inconsistent. Therefore, how to realize the automatic upgrade of the complex server application system, improving the upgrade efficiency and upgrading orderly is a problem to be solved in the field.
Disclosure of Invention
The invention aims to provide an upgrading method and system of a complex server application system, so as to realize automatic upgrading of the complex server application system, improve upgrading efficiency and realize orderly upgrading.
In order to achieve the purpose, the invention provides the following technical scheme:
an upgrading system of a complex server application system comprises an upgrading service management end and upgrading services arranged in applications to be upgraded;
the upgrade service management terminal comprises: the system comprises an analysis module and a configuration interaction module;
the upgrade service management terminal is used for receiving an upgrade data packet, the analysis module is used for decompressing the upgrade data packet, acquiring an upgrade configuration file, generating the application task information list, and sequencing each application type node in the application task information list according to an application type; circularly processing the application task information list to obtain the application task configuration information and the upgrade file; according to the application task information list, packaging the upgrade files corresponding to the version information to generate an application upgrade package; obtaining application task configuration information, generating an application task information list, and sequencing each application type node in the application task information list according to an application type; the upgrading service management terminal generates an application upgrading task list containing each upgrading subtask according to the application task information list, and the application server configuration information and the upgrading parameter configuration information configured by the configuration interaction module user; according to a preset task scheduling strategy, sequentially acquiring the upgrading subtasks from the application upgrading task list, and distributing the upgrading subtasks to the corresponding upgrading services; the upgrade data package includes: the system comprises an upgrading script file, a database upgrading script file, an upgrading instruction file, an upgrading file and an upgrading configuration file; the upgrade configuration file comprises application task nodes, task names, application types, application root directories, old version information, new version information, update descriptions and update modes which are configured in advance;
and the upgrading service is used for receiving and executing the upgrading subtask.
Optionally, the upgrade service management end includes a task generation module, configured to generate an upgrade task node, and allocate a unique identifier ID to the upgrade task node; circularly processing the application task information list according to a preset task generation rule, and generating the application upgrading task list containing each upgrading subtask based on the application server configuration information and the upgrading parameter configuration information; dividing the upgrading subtasks belonging to the same application to be upgraded into the same task group, and dividing the task group belonging to the same application task into the same application task;
and each task group comprises a test subtask.
Optionally, the upgrade service management end includes a task scheduling module, configured to sequentially execute each application task according to the priority level of the application task;
wherein the application task comprises one or more of the task groups, each of the task groups comprising one or more of the upgrade subtasks and the test subtasks; the task scheduling process of each application task is as follows:
distributing the test subtasks to the corresponding upgrade services;
after the test subtask is successfully executed, distributing the upgrading subtask to the corresponding upgrading service according to a preset task scheduling rule;
the preset task scheduling rules specifically comprise a first scheduling rule, a second scheduling rule and a third scheduling rule; the first scheduling rule is to sequentially distribute and execute the upgrading subtasks of the same task group; the second scheduling rule is used for distributing all the upgrading subtasks of the same task group in parallel, and when the distribution of all the upgrading subtasks of the same task group is finished, the tasks of the next task group are distributed; the third scheduling rule is to distribute all the upgrading subtasks of the same application task in parallel.
Optionally, the upgrade service includes a receiving module and an executing module;
the receiving module is used for comparing the version information carried by the upgrading subtask with the version information of the application to be upgraded where the upgrading service is located and judging whether the version information is consistent with the version information of the application to be upgraded; if not, the receiving is failed, and a receiving failure result is returned;
and the execution module is used for executing the upgrading subtask and returning an execution result when the version information carried by the upgrading subtask is consistent with the version information of the application to be upgraded in which the upgrading service is positioned.
Optionally, the execution module includes a download submodule, a backup submodule, an upgrade submodule, a result return submodule, and a restart submodule;
the downloading submodule is used for downloading the application upgrading packet according to the upgrading subtask;
the backup submodule is used for executing application backup;
the upgrading submodule is used for decompressing the application upgrading packet, acquiring an upgrading file and executing application upgrading work; calling a database upgrading script file to perform database upgrading work;
the result returning submodule is used for generating a task execution result and returning the task execution result to the upgrading service management terminal;
the restarting submodule is used for determining whether restarting is needed or not according to restarting configuration information carried by the upgrading subtask; if the upgrade service management terminal needs to be restarted, calling a restart script file, restarting the application, and returning restart information to the upgrade service management terminal.
Optionally, the upgrade service further includes a rollback module, configured to receive a rollback request sent by the upgrade service management end; acquiring rollback information according to the rollback request; and executing rollback operation according to the rollback information.
Optionally, the upgrade service management end further includes a task state monitoring service, configured to monitor an upgrade task and a rollback task that are being executed;
the task state monitoring service comprises a first monitoring module and a second monitoring module;
the first monitoring module is used for monitoring the upgrading task which is being executed, and updating the state of the upgrading task to be a first preset state according to the execution time of the upgrading task and the size of a first time threshold;
the second monitoring module is used for monitoring the rollback task and updating the state of the rollback task to be a second preset state according to the execution time of the rollback task and the size of a second time threshold.
Optionally, the upgrade service management end further includes an upgrade log viewing module and an upgrade task query module;
the upgrading task query module is used for searching and displaying corresponding task information according to a query instruction;
the upgrade log management module is used for displaying corresponding upgrade log information or downloading corresponding upgrade logs according to log query or log downloading instructions.
An upgrade method for a complex server application system is applied to any one of the upgrade systems for the complex server application system, and the upgrade service management end includes: the system comprises an analysis module and a configuration interaction module; the method comprises the following steps:
the upgrading service management end receives an upgrading data packet, the analysis module is used for decompressing the upgrading data packet, acquiring an upgrading configuration file, generating an application task information list, and sequencing each application type node in the application task information list according to an application type; circularly processing the application task information list to obtain the application task configuration information and the upgrade file; according to the application task information list, packaging the upgrade files corresponding to the version information to generate an application upgrade package; obtaining application task configuration information, generating an application task information list, and sequencing each application type node in the application task information list according to an application type; according to the application task information list, receiving application server configuration information and upgrading parameter configuration information configured by a user through the configuration interaction module, and generating an application upgrading task list containing each upgrading subtask; according to a preset task scheduling strategy, sequentially acquiring the upgrading subtasks from the application upgrading task list, and distributing the upgrading subtasks to the corresponding upgrading services; the upgrade data package includes: the system comprises an upgrading script file, a database upgrading script file, an upgrading instruction file, an upgrading file and an upgrading configuration file; the upgrade configuration file comprises application task nodes, task names, application types, application root directories, old version information, new version information, update descriptions and update modes which are configured in advance;
and the upgrading service receives and executes the upgrading subtask.
The invention provides an upgrading system and method of a complex server application system, which are characterized in that an upgrading service management end receives and analyzes an upgrading data packet to obtain application task configuration information, an application task information list is generated, and application type nodes in the application task information list are sequenced according to application types; generating an application upgrading task list containing each upgrading subtask according to the application task information list, and the received application server configuration information and upgrading parameter configuration information; according to a preset task scheduling strategy, sequentially acquiring upgrading subtasks from an application upgrading task list, and distributing the upgrading subtasks to corresponding upgrading services; the upgrade service receives and executes the upgrade subtask. According to the method and the device, the priority of the upgrading subtasks is determined according to the application types, and then the tasks are distributed according to the priority and the task scheduling strategy, so that the ordered upgrading of each application is coordinated, the upgrading tasks can be configured, the automatic upgrading of the complex server application system is realized, and compared with manual upgrading, the efficiency is higher, and the accuracy is better.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a diagram illustrating an exemplary architecture of a complex server application system;
fig. 2 is a schematic block diagram of an upgrade system of a complex server application system according to an embodiment of the present invention;
fig. 3 is a schematic diagram of an upgrade configuration file structure according to an embodiment of the present invention;
FIG. 4 is a diagram illustrating a server profile structure according to an embodiment of the present invention;
fig. 5 is a schematic diagram illustrating results of an application type configuration file according to an embodiment of the present invention;
fig. 6 is a schematic diagram of an upgrade task information file structure provided in an embodiment of the present invention;
FIG. 7 is a diagram illustrating an upgrade task according to an embodiment of the present invention;
FIG. 8 is a diagram illustrating task state transitions provided by an embodiment of the present invention;
FIG. 9 is a schematic diagram of a shutdown upgrade of a tax administration system according to an embodiment of the present invention;
fig. 10 is a flowchart illustrating an upgrading method for a complex server application system according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Referring to fig. 2, fig. 2 is a schematic block diagram of an upgrade system of a complex server application system according to an embodiment of the present invention, where the upgrade system includes an upgrade service manager 21 and an upgrade service 22 disposed in each application to be upgraded;
the upgrade service management terminal 21 is configured to receive and analyze the upgrade data packet to obtain application task configuration information, generate an application task information list, and sort application type nodes in the application task information list according to application types; generating an application upgrading task list containing each upgrading subtask according to the application task information list, and the received application server configuration information and upgrading parameter configuration information; according to a preset task scheduling strategy, sequentially acquiring upgrading subtasks from an application upgrading task list, and distributing the upgrading subtasks to corresponding upgrading services;
It can be understood that the upgrade data package is uploaded to the upgrade service management end by the user, and the user specifically imports the corresponding upgrade data package into the upgrade service management end through an import interface provided by the upgrade service management end. The upgrade data package may be in the form of a compressed file, such as a Zip file.
The upgrade data package may include all files of one upgrade, which may include at least an upgrade script file app _ update.xml, a database upgrade script file, an upgrade specification file readme.txt, an upgrade file, and an upgrade configuration file updateconfig.xml. The upgrade description file comprises an upgrade description of the application, and the upgrade configuration file comprises basic information of the application required to be upgraded.
To better introduce the upgrade configuration file updateconfig.xml, please refer to a schematic diagram of the structure of the upgrade configuration file provided by the embodiment of the present invention shown in fig. 3. The upgrade configuration file may include related information such as a pre-configured application task node, a task name, an application type, an application root directory, old version information, new version information, an update description, and an update mode (whether to halt the upgrade).
The application task configuration information may include application type information, information indicating whether to restart after upgrading, and whether to upgrade the database.
Both the application server configuration information and the upgrade parameter configuration information may be configured manually. The system can specifically select and set corresponding server information through a server management interface, and then the system can correspondingly update the application server information.
The upgrade parameter configuration information may include information of an upgrade mode, a maximum upgrade time, a maximum backoff time, and the like. The upgrading mode comprises manual upgrading and automatic upgrading, wherein the manual upgrading refers to manual triggering of an upgrading task, and the automatic upgrading refers to automatic completion of the upgrading task by the system. The maximum upgrading time means that the upgrading task is considered to fail to be executed if the time is exceeded, and the current task is valid at the time.
The configuration information of the application server and the configuration information of the upgrade parameters both have corresponding default values, for example, the system default value of the maximum upgrade time is 10min, and a user can determine whether to modify the default values of the configuration information according to requirements.
And after receiving the application server configuration information configured by the user, the upgrade service management terminal updates the server configuration file serverconfig. Referring to fig. 4, a schematic diagram of a server profile structure is shown, where the server profile includes information about a server ID, a server name, a server IP, a server port, an application type, and the like.
In this embodiment, the upgrade service management end may include an analysis module and a configuration interaction module; the analysis module is used for decompressing the upgrade data packet, acquiring the upgrade configuration file, generating an application task information list, and sequencing each application type node in the application task information list according to the application type; circularly processing the application task information list to obtain application task configuration information and an upgrade file; according to the application task information list, packaging the upgrade files corresponding to the version information to generate an application upgrade package; the configuration interaction module is used for receiving the application server configuration information and the upgrading parameter configuration information configured by the user.
It can be understood that, according to the application type, the application type nodes in the application task information category are sorted, that is, according to the application type, the upgrading subtasks produced subsequently are sorted, and the priority and upgrading sequence of each task are determined.
And presetting the priority of each application type according to the application type of each application to be upgraded. Then, the priority of the task can be determined according to the priority of the application to be upgraded corresponding to each upgrading subtask.
For example, the highest priority of the class A application, the next to the class B application, and the next to the class C application may be preset. The priority of the upgrade subtask of the class a application is the highest, the priority of the upgrade subtask of the class B application is the next to the priority of the upgrade subtask of the class C application.
In particular, the parsing and configuration process will be further described below in conjunction with fig. 3 and 4. The analysis process specifically comprises the following steps:
generating a unique identification GUID, and establishing an empty folder by taking the GUID as a name under an application update directory;
decompressing the upgrade data packet, and storing the decompressed content in the directory where the empty folder is located;
xml is read to obtain an upgrade configuration file updateconfig, as shown in fig. 3, to obtain application task < apptask > node information therein, to generate an apptask information list, and to sort < appType > nodes in the apptask information list according to the priority of application types; the priority of the application type may be obtained by reading an application type configuration file appypecopic.xml shown in fig. 5, and more specifically, the priority of each application type is subject to a < priority > node in appypecopic.xml;
circularly processing the apptask information list, more specifically, checking whether a corresponding file directory exists according to an application root directory node in the apptask information, if not, returning error information, and if so, continuing to analyze;
checking whether a readme. txt file exists in the application root directory, if not, returning error information, and if so, continuing processing;
finding out corresponding application large-class information from an apptypeconfig. xml file shown in fig. 4 according to the content of the < appType > node in the appmaster information;
checking an upgrade file under an application root directory, and if the upgrade file is found to have a configuration file, indicating that the configuration file needs to be reloaded after the upgrade is finished; if the upgrade file is found to contain the class file, the jar package and the updated file (such as a web.xml file, which may exist in a plurality of files and is specified by system parameters) needing to restart the service, the application is restarted after the upgrade is finished; other conditions indicate that other operations are not needed after the upgrade is finished;
checking an applied updatescripts directory, if a database directory exists in the directory, ensuring that database _ update.sql and database _ rollback.sql files exist in the directory at the same time, if any one of the files is lacked, returning error information, and otherwise, adding a database mark in the updatent to indicate that the task needs to upgrade the database; then adding an app mark in the updatetectent node to indicate that the task needs to update the application file; secondly, checking an application update directory, if an app _ update. xml script exists in the directory, adding an appshell mark in an update node to indicate that the task needs to execute an application upgrading script;
and packaging the corresponding upgrade files to generate an application upgrade package according to the application root directory information and the version information in the apptast information, wherein the file name format is application root directory _ version information, zip, and the package name of the application upgrade package is recorded in the apptast information.
After the upgrade data packet is analyzed, the user can perform corresponding application server configuration and upgrade parameter configuration. The configuration of the application server needs to correspondingly update the configuration file of the application server, and the updating process specifically comprises the following steps:
reading all flow controller information in serverconfig.xml;
circularly processing the information of the flow controller;
acquiring information of a main flow controller, and acquiring an application server information list managed by the controller from the flow controller according to the IP address and the port setting of the flow controller;
if the information acquisition from the main flow controller fails, acquiring backup flow controller information, and acquiring an application server information list from the backup flow controller information;
if the application server information acquisition from the backup flow controller fails, an error message is returned, and at the moment, a user can be prompted to acquire relevant information such as 'failure to acquire application service information from the XXX flow controller and incapability of continuing to execute upgrading work';
if the application server list is obtained, whether the server information in the list exists in the server configuration. The application type setting rule may be: and acquiring effective application type information from apptypeconfig. If the application type information is only one, directly attributing the application server to the application type; if the application type information is multiple, searching whether the application type information has a type of 'notype', if so, setting the application type of the application server as 'notype', otherwise, adding a 'notype' application type, and setting the application type of the application server as a newly added application type; and finally, storing the serverconfig.xml, and finishing updating the serverconfig.xml.
Of course, after the information of the application servers in all the traffic controllers is acquired, if the application type of an application server is "notype", a server management interface is displayed to allow an administrator to configure the application type of the application server.
After the upgrade data packet is analyzed and the relevant information is configured, a corresponding upgrade task can be generated. In this embodiment, the upgrade service management may include a task generation module, configured to generate an upgrade task node and assign a unique identifier ID to the upgrade task node; circularly processing an application task information list according to a preset task generation rule, and generating an application upgrading task list containing each upgrading subtask based on application server configuration information and upgrading parameter configuration information; dividing upgrading subtasks which belong to the same application to be upgraded into the same task group, and dividing the task group which belongs to the same application task into the same application task; wherein each group of task groups comprises a test subtask.
It should be noted that the unique identification ID may be specifically a GUID. The preset task generation rule may specifically be: each application server generates an upgrading task; the application tasks with the same major category and the same minor category are divided into the same task group; generating a test node for each task group, and executing the test node for the first time in the upgrading process; and distributing the data upgrading script to the test nodes in the test group for execution.
More specifically, the structure of the upgrade task information file shown in fig. 6 will be further described. Xml is used for storing upgrade task information, including the upgrade task being executed and the upgrade task history information. It may include upgrade status information, task start/end times, application task information, upgrade sequence, new/old version information, upgrade content, and the like.
The task generation process may specifically be:
generating an upgrade task < updatetask > node, and generating an ID for the node, wherein the ID may be a GUID specifically;
the application task information list is processed in a loop to generate the ID of the application task, and for example,% update. If the < apptask > node of the generated ID does not exist in the < updatetask >, generating an < apptask > node and setting the ID, otherwise, acquiring the < apptask > node;
reading a readme txt file under an application root directory, and adding the content in the readme txt file into task description information; circularly processing the province where the application server appointed to the current apptask is located;
adding the province name into the task description information, and adding the < description > node content of the apptask into the task description information; using% apptask.id% -% provinceid% -% subtype% as ID to generate a < group > node; setting the index attribute of the < group > node as the index value of the current application server;
circularly processing the information of the application server of the current province, and adding the name and the address of the application server into the task description information;
acquiring state information of application in the server according to the address of the application server, and marking the state of the current task as 'service off-line' if the state acquisition fails; setting an index value of an index attribute of a < task > node of a current application server;
generating a < task > node, using% group.id% -% server index% as the id of the node, and setting an application server address and a port for the < task > node;
setting script information for the < task > node, and if the current apptask needs to execute database upgrading and the index of the current server is 0, adding database script information in the script node;
adding a < task > node into a < group > node, adding the < group > node into an < apptast > node, adding the < apptast > node into an < updatetask > node, and adding the content of the < updatetask > node into an updatetask.
And according to the application server information, the upgrading parameter information and the upgrading data packet configured by the user, generating all upgrading subtasks of one upgrading task at a time, dividing each upgrading subtask into corresponding task groups according to the application type, and dividing the corresponding task groups into corresponding application tasks.
After the tasks are generated, distributing each upgrading subtask to upgrading service according to the corresponding task priority and the task scheduling strategy, and orderly coordinating the upgrading of each application.
In this embodiment, the upgrade service manager may include a task scheduling module, configured to sequentially execute each application task according to the priority level of the application task; the application task comprises one or more task groups, and each task group comprises one or more upgrading subtasks and testing subtasks; the task scheduling process of each application task is as follows: distributing the test subtasks to corresponding upgrading services; after the test subtask is successfully executed, distributing the upgrading subtask to the corresponding upgrading service according to a preset task scheduling rule; the preset task scheduling rules specifically comprise a first scheduling rule, a second scheduling rule and a third scheduling rule; the first scheduling rule is to distribute and execute upgrading subtasks of the same task group in sequence; the second scheduling rule is that all upgrading subtasks of the same task group are distributed in parallel, and when the distribution of all upgrading subtasks of the same task group is completed, the tasks of the next task group are distributed; the third scheduling rule is to distribute all upgrade subtasks of the same application task in parallel.
To better describe the task scheduling process, a schematic diagram of one-time upgrade tasks is shown in conjunction with fig. 7. The upgrading task comprises an application task 0, an application task 1 and an application task 2, wherein the application task 0 has the highest priority, and the application tasks are 1 time and 2 times respectively; the application task 0 comprises a task group 0-0, and the task group 0-0 comprises an upgrading subtask 0-0-0, an upgrading subtask 0-0-1 and an upgrading subtask 0-0-2; the application task 1 comprises a task group 1-0 and a task group 1-1, wherein the task group 1-0 comprises an upgrading subtask 1-0-0, an upgrading subtask 1-0-1 and an upgrading subtask 1-0-2, and the task group 1-1 comprises an upgrading subtask 1-1-0, an upgrading subtask 1-1-1 and an upgrading subtask 1-1-2; the application task 2 comprises a task group 2-0 and a task group 2-1, the task group 2-0 comprises an upgrading subtask 2-0-0, an upgrading subtask 2-0-1 and an upgrading subtask 2-0-2, and the task group 2-1 comprises an upgrading subtask 2-1-0, an upgrading subtask 2-1-1 and an upgrading subtask 2-1-2. Wherein the upgrade subtask indicated by the dashed line of each task group is a test subtask.
The test subtask is executed first, and when the test subtask is successfully executed, the remaining tasks of the task group are executed. If the test subtask fails to execute, execution of the application task may be stopped, waiting for a rollback operation or other appropriate action.
After the test subtasks are successfully executed, the remaining tasks may be executed according to the first scheduling rule, the second scheduling rule, or the third scheduling rule. The first scheduling rule is a scheduling mode in a manual upgrading mode, and the second scheduling rule and the third scheduling rule are scheduling modes in an automatic upgrading mode.
When the subsequent task is executed by using the first scheduling rule, the specific process may be: distributing the rest tasks of the task group where the test subtask is located in sequence, and after the upgrading subtask of one task group is distributed, the user needs to manually select the next upgrading subtask; when the subsequent task is executed by using the second scheduling rule, the specific process may be: the rest upgrading subtasks in the same task group are automatically executed, when all upgrading subtasks in the same group are executed, the next task group is initiated to be executed, and if the current task group is the last group of the application task, the test task of the next application task is automatically initiated to be executed; when the subsequent task is executed by using the third scheduling rule, the specific process may be: and the rest subtasks of the same application task are executed in parallel in groups, each group is executed in sequence, and after all subtasks of the current application task are successfully executed, the execution of the test task of the next application task is automatically initiated.
For example, the scheduling order of the upgrade tasks described in fig. 7 may specifically be:
executing the test subtask 0-0-0, if the task fails to be executed, stopping the execution of the application task 0, and waiting for the rollback operation; if the task is successfully executed, continuing to execute the subtasks 0-0-1 and 0-0-2 in sequence;
when the application task 0 is completely executed, executing the test subtask 1-0-0 of the application task 1, if the task fails to be executed, stopping the execution of the application task 1, and waiting for the rollback operation; if the task is successfully executed, the rest tasks in the task group 1-0 can be initiated or the rest tasks in the application task 1 can be initiated (the grouping is executed in parallel and the sequence is carried out in the group);
when the application task 1 is completely executed, executing a test subtask 2-0-0 of the application task 2, and if the task fails to be executed, stopping the execution of the application task 2 and waiting for a rollback operation; if the task is successfully executed, the rest tasks in the task group 2-0 can be sent out or the rest tasks in the application task 2 can be sent out (the grouping is executed in parallel and the sequence is carried out in the group);
and finishing the upgrading task when all the upgrading subtasks of the application task 2 are successfully executed.
It can be seen that after the execution of the application task with high priority is completed, the upgrading of the next priority application is not started until all the upgrading subtasks in the upgrading task list are completed, so that the control of the upgrading process can be realized, and the upgrading sequence among the applications can be effectively coordinated. And the test subtask is set, and when the test subtask is successfully executed, subsequent upgrading work is carried out, so that the influence surface of the problem can be reduced. For example, if the execution of the test subtask fails, it indicates that the current node has a problem, and at this time, only the test node needs to be backed off to finish the upgrade task, thereby effectively controlling the influence caused by the upgrade failure within a small range.
After each upgrade subtask is distributed to the corresponding upgrade service, the upgrade service will execute the corresponding receiving and executing operations. The task receiving is an SOA service provided by the upgrade service and is responsible for preprocessing the task. And when the receiving fails, returning a corresponding processing report to the upgrading service management terminal, and when the receiving succeeds, executing the upgrading subtask.
In this embodiment, the upgrade service may include a receiving module and an executing module, where the receiving module is configured to compare version information carried by the upgrade subtask with version information of an application to be upgraded where the upgrade service is located, and determine whether the version information is consistent with the version information of the application to be upgraded; if not, the receiving is failed, and a receiving failure result is returned; and the execution module is used for executing the upgrading subtask and returning an execution result when the version information carried by the upgrading subtask is consistent with the version information of the application to be upgraded where the upgrading service is located.
It can be understood that the upgrade subtask sent by the upgrade service manager will carry the relevant upgrade task information. The upgrade task information may include, among other things, application old version information, upgrade package address information, and other relevant information.
After the upgrading service acquires corresponding upgrading task information of the upgrading subtasks, the upgrading service reads application version information from a current application version file, then compares the read application version information with the application old version information carried by the tasks, judges whether the application version information is consistent or not, executes the upgrading subtasks if the application version information is consistent, and generates a corresponding report and returns the report to an upgrading management end if the application version information is inconsistent.
Furthermore, the execution module may include a download submodule, a backup submodule, an upgrade submodule, a result return submodule, and a restart submodule; the downloading submodule is used for downloading the application upgrading packet according to the upgrading subtask; the backup submodule is used for executing application backup; the upgrading submodule is used for decompressing the application upgrading packet, acquiring an upgrading file and executing application upgrading work; calling a database upgrading script file to perform database upgrading work; the result returning submodule is used for generating a task execution result and returning the task execution result to the upgrading service management terminal; the restarting submodule is used for determining whether restarting is needed or not according to the restarting configuration information carried by the upgrading subtask; if the upgrade service management terminal needs to be restarted, calling the restart script file, restarting the application and returning restart information to the upgrade service management terminal.
Specifically, the upgrade service acquires an address of an upgrade package file from the upgrade task information, accesses the address,
and downloading to obtain a corresponding upgrade package. And when the upgrade package fails to be downloaded, corresponding failure information is returned to the upgrade service management terminal, and after the upgrade package is successfully downloaded, the upgrade package is decompressed to a corresponding directory. And then executing application backup operation, specifically creating a folder by taking the upgrade task ID as a name, and storing the application information into the folder. Then, if the upgrading subtask needs to upgrade the database, acquiring database link information, calling the database to update the script file, executing the database upgrading work, and writing the start/end time, the execution result and other related information into an upgrading log; after the database upgrading work is executed, the upgrading file can be copied to the corresponding directory of the application, and if the failure before upgrading the file is 'del-', the file is deleted from the application directory; if the corresponding file does not exist in the current application, directly copying the file and recording the file name; if the corresponding file exists in the current application, the file is overwritten.
After the copying is completed, the related information in the copying process can be written into the upgrade log, such as the start time, the end time, the file source directory, the file target directory, the file name, the copying result or the exception information.
After the task is successfully executed, the upgrade service may generate a task execution result as a report and return the report to the upgrade service management end. In addition, whether the upgrade server needs to be restarted or not can be judged, if yes, a restart script is called, the application is restarted, and corresponding restart information is returned to the upgrade service management terminal.
The upgrade service may or may not succeed when it executes the upgrade subtask. When the upgrade subtask fails to execute, the application may be rolled back to the version before the upgrade.
Therefore, in this embodiment, the upgrade service may further include a rollback module, configured to receive a rollback request sent by the upgrade service management end; acquiring rollback information according to the rollback request; and executing the rollback operation according to the rollback information.
The rollback process of the upgrade service may specifically be: and receiving a rollback request of an upgrading service management end, and according to version information, upgrading task ID and other related rollback information carried by the rollback request. If the data rollback script exists, the database configuration information is obtained, the database rollback script is executed, and relevant information such as the starting/ending time of database rollback, the rollback result and the like is written into the rollback log. And executing application rollback from the corresponding file in the backup directory, and recording related information to a rollback log. And when the rollback fails, notifying the upgrading service management terminal, restarting the application when the rollback succeeds, and sending rollback restart information to the upgrading service management terminal.
In addition, the upgrading service can also realize the functions of updating application version information, packaging logs, health check, suspending service interfaces and the like.
It can be understood that the rollback of multiple application tasks may be performed simultaneously, or the rollback of a single application task may be performed, and the rollback of an application task may be performed automatically or manually.
In this embodiment, the upgrade service management terminal may further include a task state monitoring service, configured to monitor an upgrade task and a rollback task that are being executed; the task state monitoring service comprises a first monitoring module and a second monitoring module; the first monitoring module is used for monitoring the upgrading task which is being executed, and updating the state of the upgrading task to be a first preset state according to the execution time of the upgrading task and the size of a first time threshold; and the second monitoring module is used for monitoring the rollback task and updating the state of the rollback task to be a second preset state according to the execution time of the rollback task and the size of a second time threshold.
It is to be understood that the task status monitoring service may be a timed monitoring or a non-timed monitoring, and is not limited herein. It may include an upgrade task monitoring, i.e. a first monitoring module, and a fallback task monitoring, i.e. a second monitoring module.
For the upgrade task monitoring, if the execution time of the upgrade task exceeds the manual intervention early warning time, the state of the upgrade task is updated to be a task abnormal state; and if the execution time of the upgrading task exceeds the maximum upgrading time, updating the state of the upgrading task to 'upgrading failure', and ending the current task. The first time threshold value comprises manual intervention early warning time and maximum upgrading time, and the first preset state comprises an abnormal state and a failure state.
For the rollback task monitoring, if the execution time of the rollback task exceeds the maximum rollback time, the state of the rollback task is updated to 'rollback failure', and the current rollback task is finished. The second time threshold refers to a maximum backoff time, and the second preset state refers to a backoff failure.
For better describing task state transition involved in the whole upgrading process, refer to a task state transition description schematic diagram shown in fig. 8, where the diagram includes task state transition from after the upgrade task is generated to during the rollback task is executed, and refer to corresponding description in the diagram for details, which is not described herein again.
Therefore, the task of the task upgrading process can be monitored by monitoring the task state, so that the accuracy of the task upgrading can be ensured, and the task can be known in time when the task is abnormal or fails, so that the corresponding measures can be taken in time.
In this embodiment, the upgrade service management end may further include an upgrade log viewing module and an upgrade task querying module; the upgrading task query module is used for searching and displaying corresponding task information according to the query instruction; the upgrade log management module is used for displaying corresponding upgrade log information or downloading corresponding upgrade logs according to log query or log downloading instructions.
That is, the user can input the information of the required query task through the query interface, and the system can query the corresponding upgrade task information meeting the conditions and display the upgrade task information correspondingly. And when receiving the log downloading instruction, the upgrading service correspondingly packs the upgrading log and returns the upgrading log to the upgrading service management terminal.
In addition, the upgrade service management terminal can also set functions of user login authority management, application server management and the like, and can receive the upgrade task processing report and the rollback task processing report and correspondingly update the task state according to the reports. For example, if the upgrade task processing report shows that the upgrade result is a failure, the upgrade status of the task is updated to "upgrade failure", and the log information corresponding to the task is updated accordingly.
According to the upgrading system of the complex server application system, the upgrading service management end receives and analyzes the upgrading data packet to obtain application task configuration information, an application task information list is generated, and each application type node in the application task information list is sequenced according to the application type; generating an application upgrading task list containing each upgrading subtask according to the application task information list, and the received application server configuration information and upgrading parameter configuration information; according to a preset task scheduling strategy, sequentially acquiring upgrading subtasks from an application upgrading task list, and distributing the upgrading subtasks to corresponding upgrading services; the upgrade service receives and executes the upgrade subtask. The system determines the priority of the upgrading subtasks according to the application types, distributes tasks according to the priority and the task scheduling strategy, further coordinates the orderly upgrading of each application, is configurable in upgrading tasks, achieves the automatic upgrading of a complex server application system, and is higher in efficiency and better in accuracy compared with manual upgrading.
In order to better describe the upgrading system of the complex server application system provided by the invention, an upgrading process is described below for an application scene by using a personal tax system.
The personal tax system comprises a central office deployment core application, a central office front-end application, a core web application, a provincial office front-end application, a hall application and a core web application, wherein the provincial office front-end application, the hall application and the core web application are all provided with corresponding database clusters, and the personal tax system has corresponding characteristics of a complex service application system.
In specific application, application upgrading can also be divided into halt upgrading and non-halt upgrading, wherein the non-halt upgrading mainly occurs in upgrading caused by service logic change, configuration change, page change and the like, and the upgrading does not need to restart a server; shutdown upgrades occur primarily when class files or jar packages change, which requires restarting the application.
Referring to fig. 9, a schematic diagram of a shut-down upgrade of a tax system is shown, which includes an upgrade service management end and upgrade services provided to respective applications, where the applications include a core application, a front-end application, and a lobby application. The core application has the highest priority, the front application is next, and the lobby application is next.
The specific process of shutdown upgrading can be specifically as follows: s1, uploading the upgrade file package by the system administrator; s2, analyzing the upgrade package; s3, configuring the upgrade server information by the system administrator; s4, generating an upgrade subtask according to the upgrade package and the upgrade server information; s5, sending a service stop instruction to the relevant lobby application, and the corresponding lobby application stops receiving user requests. If the core Web is not deployed separately and needs to be upgraded, a service stop instruction should be sent to the relevant core. If the core Web is separately deployed and the core Web needs to be upgraded, a service stopping instruction is sent to the relevant core Web application; s6, sending an isolation request to a flow controller at the front end of the central office to isolate the specified core application; s7, sending an upgrade task to the upgrade service of the specified core application; s8, the upgrade service receives the upgrade task and downloads the upgrade package from the management terminal; s9, if the database needs to be upgraded, the upgrade service initiates the upgrade of the core database; s10, executing application upgrading work, and restarting the application; s11, the upgrade service of the core application sends an upgrade report to the upgrade management terminal; s12, sending a cancel isolation request to the traffic controller, canceling the isolation core application; s13, sending an isolation request to the flow controller to isolate the appointed preposed application; s14, sending an upgrade task to the upgrade service of the specified front-end application; s15, the upgrade service receives the upgrade task and downloads the upgrade package from the management terminal; s16, if the database needs to be upgraded, the upgrade service initiates the upgrade of the preposed database; s17, executing application upgrading work, and restarting the front application; s18, the front application sends an upgrade report to the upgrade management terminal; s19, sending a cancel isolation request to the traffic controller to cancel the isolation of the specified core application; s20, sending an upgrade task to the lobby application; s21, the upgrade service receives the upgrade task and downloads the upgrade package from the management terminal; s22, if the database needs to be upgraded, the hall database upgrade is executed by the upgrade service; s23, executing application upgrading work, and restarting the hall application; s24, the hall application sends an upgrade report to the upgrade management terminal; and s25, displaying the upgrading result. Wherein, the step serial numbers correspond to the numbers in the figure one by one.
The process of the shutdown upgrading and the non-shutdown upgrading are similar, the most main difference step between the two steps is that the shutdown upgrading requires the step s5 to send the service stopping instruction to the relevant application, the step is not required for the non-shutdown upgrading, other steps are similar or identical, and detailed description is omitted here.
It can be stated that the detailed processes of the respective steps can be referred to the relevant contents of the above embodiments, and are not described herein again. For example, the process of the upgrade service manager parsing the upgrade data package may refer to the corresponding content of the data package parsing described above.
In the embodiment, the upgrading service management terminal initiates the upgrading task, and the orderly upgrading of each application is coordinated according to the application type and the task scheduling, and the upgrading task is configurable, so that the automatic upgrading of the complex server application system is realized, and the upgrading efficiency and the upgrading accuracy are improved.
The method for upgrading the complex server application system provided by the embodiment of the present invention is introduced below, and the method for upgrading the complex server application system described below and the method for upgrading the complex server application system described above may be referred to correspondingly.
Referring to fig. 10, fig. 10 is a schematic flowchart of an upgrade method of a complex server application system according to an embodiment of the present invention, where the method is applied to an upgrade system of any one of the complex server application systems according to the foregoing embodiments, and the method includes the following steps:
1001, receiving and analyzing an upgrade data packet by an upgrade service management terminal to obtain application task configuration information, generating an application task information list, and sequencing each application type node in the application task information list according to an application type; generating an application upgrading task list containing each upgrading subtask according to the application task information list, and the received application server configuration information and upgrading parameter configuration information; according to a preset task scheduling strategy, sequentially acquiring the upgrading subtasks from the application upgrading task list, and distributing the upgrading subtasks to the corresponding upgrading services;
step 1002, the upgrade service receives and executes the upgrade subtask.
According to the upgrading method of the complex server application system, the upgrading service management end receives and analyzes the upgrading data packet to obtain application task configuration information, an application task information list is generated, and each application type node in the application task information list is sequenced according to the application type; generating an application upgrading task list containing each upgrading subtask according to the application task information list, and the received application server configuration information and upgrading parameter configuration information; according to a preset task scheduling strategy, sequentially acquiring upgrading subtasks from an application upgrading task list, and distributing the upgrading subtasks to corresponding upgrading services; the upgrade service receives and executes the upgrade subtask. The method determines the priority of the upgrading subtasks according to the application types, distributes tasks according to the priority and the task scheduling strategy, further coordinates the orderly upgrading of each application, is configurable in upgrading tasks, achieves the automatic upgrading of a complex server application system, and is higher in efficiency and better in accuracy compared with manual upgrading.
The embodiments are described in a progressive manner in the specification, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The system and method for upgrading the complex server application system provided by the invention are described in detail above. The principles and embodiments of the present invention are explained herein using specific examples, which are presented only to assist in understanding the method and its core concepts. It should be noted that, for those skilled in the art, it is possible to make various improvements and modifications to the present invention without departing from the principle of the present invention, and those improvements and modifications also fall within the scope of the claims of the present invention.
Claims (9)
1. An upgrading system of a complex server application system is characterized by comprising an upgrading service management end and upgrading services arranged in applications to be upgraded;
the upgrade service management terminal comprises: the system comprises an analysis module and a configuration interaction module;
the upgrade service management terminal is used for receiving an upgrade data packet, the analysis module is used for decompressing the upgrade data packet, acquiring an upgrade configuration file, acquiring application task configuration information, generating an application task information list, and sequencing each application type node in the application task information list according to an application type; circularly processing the application task information list to obtain the application task configuration information and the upgrade file; according to the application task information list, packaging the upgrade files corresponding to the version information to generate an application upgrade package; the upgrading service management terminal receives application server configuration information and upgrading parameter configuration information configured by a user through the configuration interaction module according to the application task information list and generates an application upgrading task list containing each upgrading subtask; according to a preset task scheduling strategy, sequentially acquiring the upgrading subtasks from the application upgrading task list, and distributing the upgrading subtasks to the corresponding upgrading services; the upgrade data package includes: the system comprises an upgrading script file, a database upgrading script file, an upgrading instruction file, an upgrading file and an upgrading configuration file; the upgrade configuration file comprises application task nodes, task names, application types, application root directories, old version information, new version information, update descriptions and update modes which are configured in advance;
and the upgrading service is used for receiving and executing the upgrading subtask.
2. The system of claim 1, wherein the upgrade service manager comprises a task generation module configured to generate an upgrade task node and assign a unique identification ID to the upgrade task node; circularly processing the application task information list according to a preset task generation rule, and generating the application upgrading task list containing each upgrading subtask based on the application server configuration information and the upgrading parameter configuration information; dividing the upgrading subtasks which belong to the same application to be upgraded into the same task group, and dividing the task group which belongs to the same application task into the same application task;
and each task group comprises a test subtask.
3. The system of claim 2, wherein the upgrade service manager comprises a task scheduling module, configured to sequentially execute each of the application tasks according to a priority of the application task;
wherein the application task comprises one or more of the task groups, each of the task groups comprising one or more of the upgrade subtasks and the test subtasks; the task scheduling process of each application task is as follows:
distributing the test subtasks to the corresponding upgrade services;
after the test subtask is successfully executed, distributing the upgrading subtask to the corresponding upgrading service according to a preset task scheduling rule;
the preset task scheduling rules specifically comprise a first scheduling rule, a second scheduling rule and a third scheduling rule; the first scheduling rule is to sequentially distribute and execute the upgrading subtasks of the same task group; the second scheduling rule is used for distributing all the upgrading subtasks of the same task group in parallel, and when the distribution of all the upgrading subtasks of the same task group is finished, the tasks of the next task group are distributed; the third scheduling rule is to distribute all the upgrading subtasks of the same application task in parallel.
4. The system of claim 1, wherein the upgrade service comprises a receiving module and an executing module;
the receiving module is used for comparing the version information carried by the upgrading subtask with the version information of the application to be upgraded where the upgrading service is located and judging whether the version information is consistent with the version information of the application to be upgraded; if not, the receiving is failed, and a receiving failure result is returned;
and the execution module is used for executing the upgrading subtask and returning an execution result when the version information carried by the upgrading subtask is consistent with the version information of the application to be upgraded in which the upgrading service is positioned.
5. The system of claim 4, wherein the execution module includes a download submodule, a backup submodule, an upgrade submodule, a result return submodule, and a restart submodule;
the downloading submodule is used for downloading the application upgrading packet according to the upgrading subtask;
the backup submodule is used for executing application backup;
the upgrading submodule is used for decompressing the application upgrading packet, acquiring an upgrading file and executing application upgrading work; calling a database upgrading script file to perform database upgrading work;
the result returning submodule is used for generating a task execution result and returning the task execution result to the upgrading service management terminal;
the restarting submodule is used for determining whether restarting is needed or not according to restarting configuration information carried by the upgrading subtask; if the upgrade service management terminal needs to be restarted, calling a restart script file, restarting the application, and returning restart information to the upgrade service management terminal.
6. The system of claim 4, wherein the upgrade service further comprises a rollback module for receiving a rollback request sent by the upgrade service manager; acquiring rollback information according to the rollback request; and executing rollback operation according to the rollback information.
7. The system of any one of claims 1 to 6, wherein the upgrade service manager further comprises a task status monitoring service for monitoring the upgrade task and the rollback task being executed;
the task state monitoring service comprises a first monitoring module and a second monitoring module;
the first monitoring module is used for monitoring the upgrading task which is being executed, and updating the state of the upgrading task to be a first preset state according to the execution time of the upgrading task and the size of a first time threshold;
the second monitoring module is used for monitoring the rollback task and updating the state of the rollback task to be a second preset state according to the execution time of the rollback task and the size of a second time threshold.
8. The system of claim 7, wherein the upgrade service manager further comprises an upgrade log viewing module and an upgrade task querying module;
the upgrading task query module is used for searching and displaying corresponding task information according to a query instruction;
the upgrade log management module is used for displaying corresponding upgrade log information or downloading corresponding upgrade logs according to log query or log downloading instructions.
9. A method for upgrading a complex server application system, the method being applied to the upgrading system of the complex server application system according to any one of claims 1 to 8, the method comprising:
the upgrading service management end receives an upgrading data packet, decompresses the upgrading data packet, acquires an upgrading configuration file, obtains application task configuration information, generates an application task information list, and sorts each application type node in the application task information list according to an application type; circularly processing the application task information list to obtain the application task configuration information and the upgrade file; according to the application task information list, packaging the upgrade files corresponding to the version information to generate an application upgrade package; generating an application upgrading task list containing each upgrading subtask according to the application task information list and by receiving application server configuration information and upgrading parameter configuration information configured by a user; according to a preset task scheduling strategy, sequentially acquiring the upgrading subtasks from the application upgrading task list, and distributing the upgrading subtasks to the corresponding upgrading services; the upgrade data package includes: the system comprises an upgrading script file, a database upgrading script file, an upgrading instruction file, an upgrading file and an upgrading configuration file; the upgrade configuration file comprises application task nodes, task names, application types, application root directories, old version information, new version information, update descriptions and update modes which are configured in advance;
and the upgrading service receives and executes the upgrading subtask.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711192143.7A CN107844343B (en) | 2017-11-24 | 2017-11-24 | Upgrading system and method for complex server application system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711192143.7A CN107844343B (en) | 2017-11-24 | 2017-11-24 | Upgrading system and method for complex server application system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107844343A CN107844343A (en) | 2018-03-27 |
| CN107844343B true CN107844343B (en) | 2021-01-26 |
Family
ID=61679339
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711192143.7A Active CN107844343B (en) | 2017-11-24 | 2017-11-24 | Upgrading system and method for complex server application system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107844343B (en) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110427398A (en) * | 2018-04-28 | 2019-11-08 | 北京资采信息技术有限公司 | A kind of model management tool based on data mining and analysis |
| CN109189428A (en) * | 2018-09-06 | 2019-01-11 | 郑州云海信息技术有限公司 | A kind of the test environment automatically updating method and system of High Availabitity |
| CN110895487B (en) * | 2018-09-12 | 2023-03-10 | 北京奇虎科技有限公司 | Distributed task scheduling system |
| CN109857427A (en) * | 2018-12-29 | 2019-06-07 | 深圳云天励飞技术有限公司 | Configure update method and Related product |
| CN110209480B (en) * | 2019-05-17 | 2024-01-30 | 腾讯科技（深圳）有限公司 | Data packet operation method, device and system |
| CN110162325A (en) * | 2019-07-16 | 2019-08-23 | 四川驹马科技有限公司 | A kind of vehicle device unaware upgrade-system and upgrade method |
| WO2021072742A1 (en) * | 2019-10-18 | 2021-04-22 | Splunk Technology Consulting (Beijing) Co., Ltd. | Assessing an impact of an upgrade to computer software |
| CN111078250B (en) * | 2019-11-14 | 2023-08-04 | 新石器慧通（北京）科技有限公司 | Method and system for upgrading equipment firmware of movable carrier and unmanned vehicle |
| CN111478897A (en) * | 2020-04-03 | 2020-07-31 | 爱瑟福信息科技(上海)有限公司 | OTA (over the air) upgrading method and system for vehicle ECU (electronic control Unit) |
| CN113326052A (en) * | 2021-05-11 | 2021-08-31 | 华锐分布式(北京)技术有限公司 | Method and device for upgrading service component, computer equipment and storage medium |
| CN113434169B (en) * | 2021-06-22 | 2023-03-28 | 重庆长安汽车股份有限公司 | Method and system for generating air upgrading parallel task group based on dependency relationship |
| CN113885894B (en) * | 2021-09-15 | 2023-12-12 | 南京海泰医疗信息系统有限公司 | Method and system for packaging and updating background based on electronic medical record products |
| CN113961221A (en) * | 2021-10-20 | 2022-01-21 | 洛阳市众信佳智能网络科技有限公司 | Service management method based on registration center |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102572896A (en) * | 2012-02-23 | 2012-07-11 | 中兴通讯股份有限公司 | Upgrading method and upgrading device for wireless communication system |
| CN103997506A (en) * | 2013-02-19 | 2014-08-20 | 成都勤智数码科技股份有限公司 | Automatic deployment upgrading system suitable for software system |
| CN104639374A (en) * | 2015-03-03 | 2015-05-20 | 上海瀚银信息技术有限公司 | Application program deployment management system |
| CN105071971A (en) * | 2015-08-26 | 2015-11-18 | 广州云宏信息科技股份有限公司 | Method for automatically upgrading server side |
| CN106648725A (en) * | 2016-09-07 | 2017-05-10 | 努比亚技术有限公司 | Terminal, server and configuration file upgrading method |
| CN106817241A (en) * | 2015-12-02 | 2017-06-09 | 大唐移动通信设备有限公司 | A kind of updating management method, upgrade method and device |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080201388A1 (en) * | 2007-02-20 | 2008-08-21 | Luke Wood | System and method for equipment tracking and preventative maintenance scheduling and verification |
| CN104346185B (en) * | 2013-08-01 | 2019-08-13 | 腾讯科技（深圳）有限公司 | Application object attributes update method, device and application platform |
| US9306805B2 (en) * | 2013-11-07 | 2016-04-05 | International Business Machines Corporation | Dynamic conversion of hardware resources of a server system |
| CN104834537B (en) * | 2014-12-30 | 2018-04-27 | 沈阳东软医疗系统有限公司 | Data processing method, server and client |
| CN106469074B (en) * | 2015-08-20 | 2019-12-31 | 宁波舜宇光电信息有限公司 | Updating system and application method thereof |
-
2017
- 2017-11-24 CN CN201711192143.7A patent/CN107844343B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102572896A (en) * | 2012-02-23 | 2012-07-11 | 中兴通讯股份有限公司 | Upgrading method and upgrading device for wireless communication system |
| CN103997506A (en) * | 2013-02-19 | 2014-08-20 | 成都勤智数码科技股份有限公司 | Automatic deployment upgrading system suitable for software system |
| CN104639374A (en) * | 2015-03-03 | 2015-05-20 | 上海瀚银信息技术有限公司 | Application program deployment management system |
| CN105071971A (en) * | 2015-08-26 | 2015-11-18 | 广州云宏信息科技股份有限公司 | Method for automatically upgrading server side |
| CN106817241A (en) * | 2015-12-02 | 2017-06-09 | 大唐移动通信设备有限公司 | A kind of updating management method, upgrade method and device |
| CN106648725A (en) * | 2016-09-07 | 2017-05-10 | 努比亚技术有限公司 | Terminal, server and configuration file upgrading method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107844343A (en) | 2018-03-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107844343B (en) | Upgrading system and method for complex server application system | |
| CN110895487B (en) | Distributed task scheduling system | |
| CN110895484A (en) | Task scheduling method and device | |
| US8301935B2 (en) | Distributed batch runner | |
| CN110895488B (en) | Task scheduling method and device | |
| CN108170448B (en) | System for automatically and efficiently releasing software update version | |
| EP2474910B1 (en) | Setting program, workflow creating method, and work flow creating apparatus | |
| CN112506617A (en) | Mirror image updating method and device for sidecar container in Kubernetes cluster | |
| CN108255708B (en) | Method, device, storage medium and equipment for accessing production file in test environment | |
| CN111897558A (en) | Kubernets upgrading method and device for container cluster management system | |
| CN110895486B (en) | Distributed task scheduling system | |
| CN110007946B (en) | Method, device, equipment and medium for updating algorithm model | |
| CN110895483A (en) | Task recovery method and device | |
| CN102833101B (en) | Software upgrading method and equipment of distributed network system | |
| CN111162953A (en) | Data processing method, system upgrading method and server | |
| CN110063042A (en) | A kind of response method and its terminal of database failure | |
| CN110737670A (en) | cluster data consistency guarantee method, device and system | |
| CN110895485A (en) | Task scheduling system | |
| CN111082964B (en) | Distribution method and device of configuration information | |
| CN114546650A (en) | Method and device for upgrading microservice | |
| CN109240906B (en) | Database configuration information adaptation method and device, computer equipment and storage medium | |
| CN109672573B (en) | Configuration file deployment method, configuration file determination method, server and storage medium | |
| CN114253906A (en) | Method and device for managing configuration file, configuration distribution system and storage medium | |
| CN111078666A (en) | Method for automatically unloading and supplying data based on cross-center multi-database | |
| CN115372803B (en) | Motherboard test system, method, device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |