CN115378809B

CN115378809B - Software version upgrading method and device

Info

Publication number: CN115378809B
Application number: CN202210994088.8A
Authority: CN
Inventors: 李华宏
Original assignee: China Construction Bank Corp
Current assignee: China Construction Bank Corp
Priority date: 2022-08-18
Filing date: 2022-08-18
Publication date: 2024-04-26
Anticipated expiration: 2042-08-18
Also published as: CN115378809A

Abstract

The application provides a software version upgrading method and a device, which relate to the field of software version upgrading and can be used in the financial field, wherein the method comprises the following steps: deploying each new software version to a corresponding first server cluster according to a service processing mode corresponding to the new software version so as to upgrade the software version of the first server cluster; the service during the software version upgrading is processed by running the old software version through the second server cluster; determining an optimal software version according to performance parameters of each first server cluster when the corresponding new software version is operated to process the service after the software version is upgraded; the optimal software version is one of the new software versions; and deploying the optimal software version to the second server cluster so as to upgrade the software version of the second server cluster. The application can select the optimal software version to upgrade the software version of the server cluster on the premise of no interruption of the current service processing.

Description

Software version upgrading method and device

Technical Field

The application relates to the field of software version upgrading, and can be used in the financial field, in particular to a method and a device for upgrading a software version.

Background

With the development and application of computer technology and internet technology in the financial field, more and more financial business system servers face upgrading from old software versions to new software versions. Generally, since new software versions are of various kinds, the speed of the replacement is high, and the use effect of the new software version is difficult to be expected by a financial institution before the new software version is delivered.

In this context, the software version upgrade process of the financial business system server needs to take at least the following two points into consideration:

first, since a part of financial services need to provide uninterrupted service for 7×24 hours to customers, if the server is shut down to complete the upgrade during the software version upgrade, normal service handling will be affected, inconvenience will be brought to customers, and financial institutions may be lost.

Second, since the use effect of the new software version is not clear before the new software version passes the market verification, if the old software version is replaced by the new software version, and the new software version is deployed on all servers, once the new software version is found to have a problem or not as good as the old software version, a great deal of manpower and material resources are wasted in version rollback.

Disclosure of Invention

Aiming at the problems in the prior art, the application provides a software version upgrading method and device, which can select an optimal software version to upgrade a server cluster on the premise of no interruption of current service processing.

In order to solve the technical problems, the application provides the following technical scheme:

in a first aspect, the present application provides a method for upgrading a software version, including:

Deploying each new software version to a corresponding first server cluster according to a service processing mode corresponding to the new software version so as to upgrade the software version of the first server cluster; the service during the software version upgrading is processed by running the old software version through the second server cluster;

Determining an optimal software version according to performance parameters of each first server cluster when the corresponding new software version is operated to process the service after the software version is upgraded; the optimal software version is one of the new software versions;

and deploying the optimal software version to the second server cluster so as to upgrade the software version of the second server cluster.

Further, before each new software version is deployed to the corresponding first server cluster according to the corresponding service processing mode of the new software version, so that the first server cluster performs software version upgrading, the method further comprises:

The service flow inlet of the first server cluster is closed;

Detecting whether a service in process exists in the first server cluster; and if not, deploying each new software version to the corresponding first server cluster according to the service processing mode corresponding to the new software version.

Further, the deploying each new software version to a corresponding first server cluster according to the service processing mode corresponding to the new software version, so that the first server cluster performs software version upgrading, including:

determining a first server cluster to be deployed by the new software version according to a service processing mode corresponding to the new software version;

and transmitting the software version upgrading parameters corresponding to the new software version to the first server cluster so that the first server cluster performs software version upgrading according to the software version upgrading parameters.

Further, before the second server cluster runs the old software version to process the service during the software version upgrade, the method further comprises:

The service flow inlet of the first server cluster is closed;

and changing the route configuration information so that all the service flows corresponding to the services in the software version upgrading period flow into the second server cluster.

Further, the determining an optimal software version according to the performance parameter of each first server cluster when running the corresponding new software version to process the service after the software version is upgraded includes:

Pulling a service flow corresponding to the service after the software version is upgraded to each first server cluster according to a preset service flow pulling strategy, so that each first server cluster runs a corresponding new software version to process the service after the software version is upgraded;

determining performance parameters corresponding to the first server clusters according to the service flow allocation amount and the service transaction amount of the first server clusters;

comparing the performance parameters corresponding to the first server clusters, and determining the new software version corresponding to the biggest one of the performance parameters as the optimal software version.

Further, the determining the performance parameter corresponding to each first server cluster according to the service flow allocation amount and the service transaction amount of each first server cluster includes:

Dividing the business transaction amount by the business flow distribution amount to obtain the efficiency parameter.

Further, before deploying the optimal software version to the second server cluster to enable the second server cluster to perform software version upgrade, the method further includes:

shutting down a traffic flow entry of the second server cluster;

Detecting whether the second server cluster has a service in process or not; and if not, deploying the optimal software version to the second server cluster.

Further, the deploying the optimal software version to the second server cluster to enable the second server cluster to perform software version upgrade includes:

And transmitting the software version upgrading parameters corresponding to the optimal software version to the second server cluster so that the second server cluster performs software version upgrading according to the software version upgrading parameters.

Further, the software version upgrading method further comprises the following steps:

and deploying the optimal software version to a first server cluster which does not run the optimal software version, so that the first server cluster performs software version upgrading.

In a second aspect, the present application provides a software version upgrade apparatus, including:

The first deployment unit is used for deploying each new software version to a corresponding first server cluster according to the corresponding service processing mode of the new software version so as to upgrade the software version of the first server cluster; the service during the software version upgrading is processed by running the old software version through the second server cluster;

The optimal version determining unit is used for determining an optimal software version according to the performance parameters of each first server cluster when the corresponding new software version is operated to process the business after the software version is upgraded; the optimal software version is one of the new software versions;

and the second deployment unit is used for deploying the optimal software version to the second server cluster so as to upgrade the software version of the second server cluster.

Further, the software version upgrading device further comprises:

A first shutdown unit, configured to shutdown a traffic flow entry of the first server cluster;

a first service detection unit, configured to detect whether there is a service in process in the first server cluster; and if not, deploying each new software version to the corresponding first server cluster according to the service processing mode corresponding to the new software version.

Further, the first deployment unit includes:

The version deployment determining module is used for determining a first server cluster to be deployed by the new software version according to the service processing mode corresponding to the new software version;

and the upgrade parameter issuing module is used for issuing the software version upgrade parameters corresponding to the new software version to the first server cluster so that the first server cluster performs software version upgrade according to the software version upgrade parameters.

Further, the software version upgrading device further comprises:

and the routing information changing unit is used for changing the routing configuration information so that all the service flows corresponding to the service during the software version upgrading flow into the second server cluster.

Further, the optimal version determination unit includes:

The traffic traction module is used for traction of traffic flow corresponding to the updated traffic of the software version to each first server cluster according to a preset traffic traction strategy so that each first server cluster runs a corresponding new software version to process the updated traffic of the software version;

The efficiency parameter determining module is used for determining efficiency parameters corresponding to the first server clusters according to the service flow allocation amount and the service transaction amount of the first server clusters;

And the performance parameter comparison module is used for comparing performance parameters corresponding to the first server clusters and determining a new software version corresponding to the maximum performance parameter as the optimal software version.

Further, the performance parameter determining module is specifically configured to divide the traffic transaction amount by the traffic flow allocation amount to obtain the performance parameter.

Further, the software version upgrading device further comprises:

The second turn-off unit is used for turning off the business flow inlet of the second server cluster;

A second service detection unit, configured to detect whether there is a service in process in the second server cluster; and if not, deploying the optimal software version to the second server cluster.

Further, the second deployment unit is specifically configured to issue a software version upgrade parameter corresponding to the optimal software version to the second server cluster, so that the second server cluster performs software version upgrade according to the software version upgrade parameter.

Further, the software version upgrading device further comprises:

And the third deployment unit is used for deploying the optimal software version to the first server cluster which does not run the optimal software version so as to upgrade the software version of the first server cluster. In a third aspect, the present application provides an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the software version upgrade method when executing the program.

In a fourth aspect, the present application provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the software version upgrade method.

In a fifth aspect, the present application provides a computer program product comprising computer programs/instructions which when executed by a processor implement the steps of the software version upgrade method.

Aiming at the problems in the prior art, the method and the device for upgrading the software version can select the optimal software version to upgrade the software version of the server cluster on the premise of no interruption of the current service processing; the service flow is not lost, the stability of service is guaranteed, the software version upgrading of the server cluster is completed under the condition that a client is not felt, and the client experience and the system robustness in the software version upgrading process are greatly improved; and meanwhile, the method can support the visualization, the management and the controllability of the service flow, and support the segmentation and the service contrast deployment of the service flow, so that the optimal software version is deployed on the server cluster.

Drawings

In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flowchart of a software version upgrade method according to an embodiment of the present application;

FIG. 2 is a second flowchart of a software version upgrade method according to an embodiment of the present application;

FIG. 3 is a flowchart of a first server cluster version deployment in an embodiment of the present application;

FIG. 4 is a third flowchart of a method for upgrading a software version according to an embodiment of the present application;

FIG. 5 is a flowchart of determining an optimal software version according to an embodiment of the present application;

FIG. 6 is a flowchart of a method for upgrading a software version according to an embodiment of the present application;

FIG. 7 is a block diagram of a software version upgrade apparatus according to an embodiment of the present application;

FIG. 8 is a second block diagram of a software version upgrade apparatus according to an embodiment of the present application;

FIG. 9 is a block diagram of a first upgrade unit according to an embodiment of the present application;

FIG. 10 is a third block diagram of a software version upgrade apparatus according to an embodiment of the present application;

FIG. 11 is a block diagram of an optimal version determination unit in an embodiment of the present application;

FIG. 12 is a diagram showing a software version upgrade apparatus according to an embodiment of the present application;

Fig. 13 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

fig. 14 is a schematic view of an application scenario in an embodiment of the present application;

Fig. 15 is a schematic diagram of an upgrade control process according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

It should be noted that, the software version upgrading method and device provided by the application can be used in the financial field and any field except the financial field, and the application field of the software version upgrading method and device provided by the application is not limited.

In an embodiment, referring to fig. 1, in order to select an optimal software version to upgrade a software version of a server cluster on the premise that current service processing is not interrupted, the application provides a software version upgrade method, which includes:

S101: deploying each new software version to a corresponding first server cluster according to a service processing mode corresponding to the new software version so as to upgrade the software version of the first server cluster; the business during the software version upgrading of the first server cluster is processed by the old software version operated by the second server cluster;

S102: determining an optimal software version according to performance parameters of each first server cluster when the corresponding new software version is operated to process the service after the software version is upgraded; the optimal software version is one of the new software versions; the service after the software version is upgraded refers to a service corresponding to a service processing request sent by a client to a bank after the first server cluster finishes the software version upgrade (in time sequence).

S103: and deploying the optimal software version to the second server cluster so as to upgrade the software version of the second server cluster.

It can be understood that, referring to fig. 14, the application scenario of the embodiment of the present application is as follows: financial institutions, typically banks, typically deploy multiple financial services servers to form a server cluster when providing financial services to customers. For example, both the first server cluster 200 and the second server cluster 300 in fig. 14 may provide financial business services, i.e., process financial business, to customers. Generally, both the first server cluster 200 and the second server cluster 300 may be controlled by the central control server 100 to sequentially complete financial business processes. In the embodiment of the present application, the central scheduling server 100 is further capable of controlling the first server cluster 200 and the second server cluster 300 to orderly complete the software version upgrade. The software is a program running on the server cluster and used for processing financial services.

In particular, with the development and application of computer technology and internet technology in the financial field, these financial service servers may face upgrades of software versions. However, considering that a part of financial services need to provide uninterrupted service for 7×24 hours to customers, if the server is shut down to complete the upgrade during the software version upgrade, normal service handling will be affected, inconvenience will be brought to customers, and financial institutions may be lost. In order to ensure the stability of the service on the premise that the current service processing is not interrupted, the embodiment of the application provides a central control server 100 for controlling the financial service server (including but not limited to the first server cluster 200 and the second server cluster 300) to complete the software version upgrade by using the method provided by the application. The processing principle is that a part of the financial service servers (for example, the first server cluster 200) is firstly subjected to software version upgrade, and then another part of the financial service servers (for example, the second server cluster 300) is subjected to software version upgrade, and a specific implementation method is described in detail below.

It should be noted that, considering that after the software version is upgraded, the use effect of the new software version is not obvious before the software version is verified by the market, if the old software version is replaced by the new software version, the new software version is deployed on all servers, and once the new software version is found to have a problem or not as good as the old software version, a great amount of manpower and material resources are wasted in carrying out version rollback. Therefore, the central control server in the embodiment of the present application is further configured to perform software version upgrade on a part (a small number of) of the financial service servers (belonging to the first server cluster) according to a preset new software version deployment policy (including, but not limited to, a service processing mode corresponding to the new software version), and deploy on other financial service servers (possibly belonging to the second server cluster or possibly belonging to the first server cluster) after selecting an optimal software version through the algorithm provided by the present application; wherein the optimal software version is one of the new software versions. From the description, the financial service server which is finally controlled by the central control server to finish the software version upgrading can be deployed with the optimal software version.

By the method, the server cluster can be updated by selecting the optimal software version on the premise of no interruption of current service processing.

As can be seen from the above description, the software version upgrading method provided by the present application can select an optimal software version to upgrade the software version of the server cluster on the premise that the current service processing is not interrupted; the service flow is not lost, the stability of service is guaranteed, the software version upgrading of the server cluster is completed under the condition that a client is not felt, and the client experience and the system robustness in the software version upgrading process are greatly improved; and meanwhile, the method can support the visualization, the management and the controllability of the service flow, and support the segmentation and the service contrast deployment of the service flow, so that the optimal software version is deployed on the server cluster.

In one embodiment, referring to fig. 2, before deploying each new software version to a corresponding first server cluster according to a service processing mode corresponding to the new software version, so that the first server cluster performs software version upgrade, the method further includes:

S201: the service flow inlet of the first server cluster is closed;

s202: detecting whether a service in process exists in the first server cluster; and if not, deploying each new software version to the corresponding first server cluster according to the service processing mode corresponding to the new software version.

It will be appreciated that in actual business processing, the financial business server to be upgraded may be currently processing the business. In order to ensure that the service traffic is lossless, that is, the processing of the current service is not affected, the central control server in the embodiment of the present application may first shut down the service traffic inlet of the first server cluster (the financial service server to be upgraded in the embodiment of the present application) by changing the route configuration, so that the central control server does not receive new service traffic any more, but only processes the service traffic already in the server. After the processing of the service flow in process is finished, the central control server can detect that no service flow in process exists in the first server cluster, and the software version upgrade can be performed. In other words, in the embodiment of the application, only when no service flow is being processed in the server, the software version upgrade can be performed. It should be noted that the first server cluster may include a plurality of financial service servers. The central control server can perform new software version deployment after the plurality of financial service servers process the 'service flow under processing', and can also perform new software version deployment on each financial service server separately in time sequence.

As can be seen from the above description, the software version upgrading method provided by the present application can detect whether there is a service in process in the first server cluster before the first server cluster performs software version upgrading.

In an embodiment, referring to fig. 3, the deploying each new software version to a corresponding first server cluster according to the service processing mode corresponding to the new software version, so that the first server cluster performs software version upgrade, includes:

S301: determining a first server cluster to be deployed by the new software version according to a service processing mode corresponding to the new software version;

S302: and transmitting the software version upgrading parameters corresponding to the new software version to the first server cluster so that the first server cluster performs software version upgrading according to the software version upgrading parameters.

It may be understood that, as already explained above, the central control server in the embodiment of the present application may perform software version upgrade on a part (a small number) of the financial service servers (belonging to the first server cluster) according to a preset new software version deployment policy (including but not limited to a service processing mode corresponding to the new software version), and then deploy on other financial service servers (possibly belonging to the second server cluster or possibly belonging to the first server cluster) after selecting an optimal software version through the algorithm provided by the present application.

In the above description, there may be a plurality of new software versions in the embodiments of the present application, and in particular, which new software versions are deployed to which first server cluster, or which new software versions are deployed to which financial service server, needs to be determined according to the deployment policy of the new software versions.

Specifically, the new software version deployment policy may include a service processing mode corresponding to the new software version; for example, a new software version a of the business processing mode "show financial products in static big words on the first page" is deployed on the first server cluster a; a new software version B with a business processing mode of "showing financial products in a dynamic floating manner on the second page" is deployed on the first server cluster B. The new software version deployment policy may further include: deploying a new software version A with a service processing mode of showing certain financial products on a primary page on a first server cluster A; a new software version B, with a business process mode of "show some financial products on secondary pages", is deployed on the first server cluster B. The new software version deployment strategy can be set according to actual needs.

After determining which first server cluster each new software version is deployed on, the software version upgrading parameters corresponding to the new software version can be issued to the first server cluster, so that the first server cluster performs software version upgrading according to the software version upgrading parameters. The software version upgrade parameters may include: path of the software installation package, file name, version number, operating system type, etc.

The specific step of upgrading the software version of the first server cluster (actually the financial service server) locally can be seen in the prior art, and the application is not limited to how to upgrade the software version locally, and can be implemented according to actual needs.

It should be noted that the above-mentioned new software version deployment policy is only an example, and in fact, the new software version deployment policy may be flexibly set according to the service requirement, which is not limited by the present application.

As can be seen from the above description, according to the software version upgrading method provided by the present application, each new software version can be deployed to a corresponding first server cluster according to a preset new software version deployment policy, so that the first server cluster performs software version upgrading.

In one embodiment, referring to fig. 4, before the second server cluster runs the old software version to process the service during the software version upgrade, the method further includes:

S401: the service flow inlet of the first server cluster is closed;

S402: and changing the route configuration information so that all the service flows corresponding to the services in the software version upgrading period flow into the second server cluster.

It will be appreciated that, in order to upgrade the software version of the first server cluster, it is necessary to make no "in-process" traffic exist in the first server cluster, i.e. to shut down the traffic entry of the first server cluster, and to load all traffic flowing into the financial institution to the second server cluster for processing.

At this time, the second server cluster runs an old software version. The old software version can normally process the business flow, so that the upgrading of the software version has no influence on the business handling of the customer, the customer is not feel, and the business flow is lossless.

Specifically, the step of performing traffic redistribution may be as shown in fig. 15. The first step: performing route configuration by using a flow controller; and a second step of: deploying and releasing a new software version to the server cluster to be upgraded, namely releasing upgrading service; and a third step of: reporting the readiness of upgrading to the flow controller by the server cluster to be upgraded; fourth step: reporting a flow distribution strategy to a proxy gateway by a flow controller; fifth step: the proxy gateway performs route switching; sixth step: the server cluster (corresponding to the first server cluster in S401 in this embodiment) where the old software version is located detects whether there is a transaction in process in the process, and waits for the transaction execution to end; seventh step: after all the transactions are executed, the server cluster where the old software version is located reports the state of the server cluster to the flow controller, namely all the transactions are executed.

As can be seen from the above description, the software version upgrading method provided by the present application can change the routing configuration information, so that the service flows corresponding to the current service all flow into the second server cluster.

In an embodiment, referring to fig. 5, the determining an optimal software version according to the performance parameter when each first server cluster runs a service after the corresponding new software version is processed to upgrade the software version includes:

S501: pulling a service flow corresponding to the service after the software version is upgraded to each first server cluster according to a preset service flow pulling strategy, so that each first server cluster runs a corresponding new software version to process the service after the software version is upgraded;

It is understood that the "new traffic" refers to the traffic received after the first server cluster has completed the software version upgrade. Each first server cluster is deployed with a different new software version. And enabling each first server cluster to receive the newly-added service flow according to a preset service flow traction strategy, and screening an optimal software version according to the processing effect of each first server cluster on the newly-added service flow.

For example, the preset traffic traction policy may include, but is not limited to: and (3) carrying out random division according to the account number tail number of the client (for example, distributing the service flow corresponding to the client with the account number tail number of 1 to the first server cluster A, corresponding to the new software version A), carrying out division according to the age group and the like. After determining the division manner, the corresponding service traffic can be pulled, that is, the corresponding service traffic is distributed to the corresponding first server cluster, and the specific pulling manner can be realized by changing the route configuration.

It should be noted that, during the traffic flow pulling process, the web service interface may be exposed externally. The web service interface is an externally exposed application interface, can be directly accessed by a third party system, plays a role of a bridge, and finally routes the access traffic to a downstream service for processing.

The service is a system internal service, and provides an interface for the web service interface to call. The service is often composed of a plurality of services of the same type, each service is responsible for the business logic processing of the own business domain, and a plurality of service services can be connected in series to process a complete transaction flow.

In addition, the web service can adopt a proxy gateway to take charge of nondestructive control of the flow; the service may employ custom "flow controllers" to accomplish flow lossless control.

With reference to the foregoing description about fig. 15, in an embodiment of the present application, the flow controller may perform routing configuration, may perform flow allocation policy configuration, and may also monitor actual flows of each server cluster; in addition, the flow controller may issue a pre-configured flow allocation policy to the proxy gateway, so that the proxy gateway actually performs the flow delivery. In addition, the method provided by the application not only can realize the flow distribution of the web service, but also can realize the flow distribution of each service.

Specifically, each service keeps a routing configuration with version number release each time. The service maintains the routing information transfer capability between services. After the software is updated successfully, the upstream service can be informed that the current service uses a new software version, the upstream service switches the route, the newly added service flow is completely sent to the service running the new software version, and meanwhile, the service self-protection mechanism of the service ensures that the service flow which is being executed on the old software version can be continuously executed until the transaction corresponding to the service flow is ended.

It will be appreciated that the flow controller may be deployed on a central controller in embodiments of the present application. The flow controller is not only the general control of global flow access, but also an observation room of global flow distribution; by the method, the current flow access condition of each service can be observed, the flow is reduced to zero, and the software version upgrade can be safely performed.

S502: determining performance parameters corresponding to the first server clusters according to the service flow allocation amount and the service transaction amount of the first server clusters;

It can be understood that this step is the business gray scale contrast process. For example, there are two new software versions, a and B, deployed to the first server cluster a and the first server cluster B, respectively. At present, the newly added service flow is assigned to the first server cluster A and the first server cluster B according to the single number and the double number of the tail number of the service transaction account. In the actual service processing process, it is assumed that the client transaction success rate of the first server cluster a is 80%, and the client transaction success rate of the first server cluster B is only 30%, so that it can be concluded that the performance parameter corresponding to the first server cluster a is higher than the performance parameter corresponding to the first server cluster B. The performance parameter may be a percentage, or may be other values having a mapping relationship with the percentage, which is not limited in the present application.

S503: comparing the performance parameters corresponding to the first server clusters, and determining the new software version corresponding to the biggest one of the performance parameters as the optimal software version.

It can be appreciated that comparing the performance parameters corresponding to each of the first server clusters can determine which new software version is the optimal software version.

As can be seen from the above description, the software version upgrading method provided by the present application can determine an optimal software version according to the performance parameter when each first server cluster runs the corresponding new software version processing service.

In an embodiment, the determining the performance parameter corresponding to each first server cluster according to the traffic allocation amount and the traffic transaction amount of each first server cluster includes:

It is understood that the business transaction amount may include, but is not limited to, a customer click amount, a transaction amount, and the like. And then the service traffic allocated by the service traffic management system is combined, so that the service transaction amount is high or low relative to the service traffic, and the efficiency of the corresponding software version is reflected.

In one embodiment, referring to fig. 6, before deploying the optimal software version to the second server cluster to enable the second server cluster to perform software version upgrade, the method further includes:

S601: shutting down a traffic flow entry of the second server cluster;

S602: detecting whether the second server cluster has a service in process or not; and if not, deploying the optimal software version to the second server cluster.

It will be appreciated that, similar to the previous embodiments (steps S201 to S202), it is also necessary to detect whether there is a service in process in the second server cluster before the second server cluster is upgraded with a software version. The specific processing manner is the same as steps S201 to S202, and will not be described here again.

As can be seen from the above description, the software version upgrading method provided by the present application can detect whether there is a service in process in the second server cluster.

In an embodiment, the deploying the optimal software version to the second server cluster to enable the second server cluster to perform software version upgrade includes:

It can be understood that after the optimal software version is determined, the software version upgrading parameter corresponding to the optimal software version can be issued to the second server cluster, so that the second server cluster performs software version upgrading according to the software version upgrading parameter. The software version upgrade parameters may include: path of the software installation package, file name, version number, operating system type, etc.

The specific step of upgrading the software version of the second server cluster (actually the financial service server) locally can be seen in the prior art, and the application is not limited to how to upgrade the software version locally, and can be implemented according to actual needs.

As can be seen from the above description, the software version upgrading method provided by the present application can issue the software version upgrading parameters corresponding to the optimal software version to the second server cluster, so that the second server cluster performs software version upgrading according to the software version upgrading parameters.

In one embodiment, the software version upgrading method further includes:

It will be appreciated that since not all the first server clusters are deployed with the optimal software version in determining which new software version is the optimal software version, after the optimal software version is determined, a software version upgrade is required for the first server clusters not running the optimal software version. The specific software version upgrade method is described above, and is not particularly limited by the present application.

As can be seen from the above description, the software version upgrading method provided by the present application can deploy the optimal software version to the first server cluster which does not run the optimal software version, so that the first server cluster performs software version upgrading.

In an embodiment, in order to complete the software version upgrade under the condition of no loss of the flow, the method specifically may be implemented as follows:

Step 1, route pre-configuration is carried out, and the route pre-configuration is not effective in practice;

Step 2, deploying and releasing a new service version;

step 3, reporting that the service is ready to access the transaction flow if the step 2 is successful;

step 4, the step 3 succeeds in validating the route configuration and issuing the route configuration;

Step 5, step 4 is successful, the route is switched, and all transaction traffic is switched to the upgraded service

And 6, successfully detecting whether the transaction in process exists in the old version service, and waiting for ending the execution of the transaction.

And 7, the step 6 is successful, the current service upgrading is finished, and the old version service can be downloaded.

Step3, reporting is continued until success;

And step 4, continuing issuing if the step fails, and providing a compensation mechanism, namely actively acquiring the route information by the upstream service if the step fails.

And 7, completing the lossless flow upgrading if the step 7 is successful.

In summary, the software version upgrading method provided by the application has at least the following beneficial effects:

1. The routing direction of the service flow is controlled through the switch, so that the flow is not lost, the stability of the service is guaranteed, namely, the software version upgrading is completed under the condition that the client is not feel, and the use experience of the client and the robustness of the system in the software version upgrading process are greatly improved.

2. This traffic lossless scheme is transparent to the traffic layer, i.e. non-intrusive to the traffic.

3. The lossless service flow can realize configuration and standardization, support the butt joint of the main stream monitoring system, and realize the visualization, the manageability and the controllability of flow information.

4. And the new software version corresponding to different realization modes supporting the similar service is subjected to service flow segmentation and service comparison deployment on a production line, so that an optimal software version is obtained and is used for upgrading the subsequent software version.

Based on the same inventive concept, the embodiment of the present application also provides a software version upgrade apparatus, which can be used to implement the method described in the above embodiment, as described in the following embodiment. Since the principle of the software version upgrading device for solving the problem is similar to that of the software version upgrading method, the implementation of the software version upgrading device can be referred to the implementation of the method based on the software performance benchmark, and the repetition is omitted. As used below, the term "unit" or "module" may be a combination of software and/or hardware that implements the intended function. While the system described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

In an embodiment, referring to fig. 7, in order to select an optimal software version to upgrade a software version of a server cluster on the premise that current service processing is not interrupted, the application provides a software version upgrade device, which includes: a first deployment unit 701, an optimal version determination unit 702, and a second deployment unit 703.

A first deployment unit 701, configured to deploy each new software version to a corresponding first server cluster according to a service processing mode corresponding to the new software version, so that the first server cluster performs software version upgrade; the service during the software version upgrading is processed by running the old software version through the second server cluster;

An optimal version determining unit 702, configured to determine an optimal software version according to performance parameters of each of the first server clusters when running the service after the corresponding new software version is processed by the software version upgrade; the optimal software version is one of the new software versions;

A second deployment unit 703, configured to deploy the optimal software version to the second server cluster, so that the second server cluster performs software version upgrade.

In an embodiment, referring to fig. 8, the software version upgrade apparatus further includes: the first shutdown unit 801 and the first traffic detection unit 802.

A first shutdown unit 801, configured to shutdown a traffic inlet of the first server cluster;

A first service detection unit 802, configured to detect whether there is a service in process in the first server cluster; and if not, deploying each new software version to the corresponding first server cluster according to the service processing mode corresponding to the new software version.

In one embodiment, referring to fig. 9, the first deployment unit 701 includes: version deployment determination module 901 and upgrade parameter issuing module 902.

The version deployment determining module 901 is configured to determine a first server cluster to be deployed by the new software version according to a service processing mode corresponding to the new software version;

And the upgrade parameter issuing module 902 is configured to issue a software version upgrade parameter corresponding to the new software version to the first server cluster, so that the first server cluster performs a software version upgrade according to the software version upgrade parameter.

In an embodiment, referring to fig. 10, the software version upgrade apparatus further includes: first shutdown section 1001 and routing information change section 1002.

A first shutdown unit 1001, configured to shutdown a traffic inlet of the first server cluster;

and a routing information changing unit 1002, configured to change routing configuration information, so that all the service flows corresponding to the services during the software version upgrade flow into the second server cluster.

In one embodiment, referring to fig. 11, the optimal version determining unit 702 includes: a flow pulling module 1101, a performance parameter determination module 1102, and a performance parameter comparison module 1103.

The traffic traction module 1101 is configured to traction a traffic flow corresponding to a software version-upgraded traffic to each of the first server clusters according to a preset traffic traction policy, so that each of the first server clusters runs a corresponding new software version to process the software version-upgraded traffic;

The performance parameter determining module 1102 is configured to determine a performance parameter corresponding to each first server cluster according to the traffic flow allocation amount and the traffic transaction amount of each first server cluster;

The performance parameter comparison module 1103 is configured to compare performance parameters corresponding to each of the first server clusters, and determine a new software version corresponding to a maximum one of the performance parameters as the optimal software version.

In an embodiment, the performance parameter determining module 1102 is specifically configured to divide the traffic transaction amount by the traffic flow allocation amount to obtain the performance parameter.

In one embodiment, referring to fig. 12, the software version upgrade apparatus further includes: the second turn-off unit 1201 and the second traffic detection unit 1202.

A second turn-off unit 1201, configured to turn off a traffic inlet of the second server cluster;

A second service detection unit 1202, configured to detect whether there is a service in process in the second server cluster; and if not, deploying the optimal software version to the second server cluster.

In an embodiment, the second deployment unit 703 is specifically configured to issue a software version upgrade parameter corresponding to the optimal software version to the second server cluster, so that the second server cluster performs a software version upgrade according to the software version upgrade parameter.

In an embodiment, the software version upgrade device further includes:

and the third deployment unit is used for deploying the optimal software version to the first server cluster which does not run the optimal software version so as to upgrade the software version of the first server cluster.

In order to achieve software version upgrade of a server cluster by selecting an optimal software version on the premise of no interruption of current service processing from a hardware level, the application provides an embodiment of an electronic device for realizing all or part of contents in the software version upgrade method, wherein the electronic device specifically comprises the following contents:

A Processor (Processor), a Memory (Memory), a communication interface (Communications Interface), and a bus; the processor, the memory and the communication interface complete communication with each other through the bus; the communication interface is used for realizing information transmission between the software version upgrading device and related equipment such as a core service system, a user terminal, a related database and the like; the logic controller may be a desktop computer, a tablet computer, a mobile terminal, etc., and the embodiment is not limited thereto. In this embodiment, the logic controller may refer to an embodiment of the software version upgrade method and an embodiment of the software version upgrade apparatus in the embodiment, and the contents thereof are incorporated herein, and the repetition is omitted.

It is understood that the user terminal may include a smart phone, a tablet electronic device, a network set top box, a portable computer, a desktop computer, a Personal Digital Assistant (PDA), a vehicle-mounted device, a smart wearable device, etc. Wherein, intelligent wearing equipment can include intelligent glasses, intelligent wrist-watch, intelligent bracelet etc..

In practical applications, part of the software version upgrade method may be executed on the electronic device side as described above, or all operations may be completed in the client device. Specifically, the selection may be made according to the processing capability of the client device, and restrictions of the use scenario of the user. The application is not limited in this regard. If all operations are performed in the client device, the client device may further include a processor.

The client device may have a communication module (i.e. a communication unit) and may be connected to a remote server in a communication manner, so as to implement data transmission with the server. The server may include a server on the side of the task scheduling center, and in other implementations may include a server on an intermediate platform, such as a server on a third party server platform having a communication link with the task scheduling center server. The server may include a single computer device, a server cluster formed by a plurality of servers, or a server structure of a distributed device.

Fig. 13 is a schematic block diagram of a system configuration of an electronic device 9600 according to an embodiment of the present application. As shown in fig. 13, the electronic device 9600 may include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. Notably, this fig. 13 is exemplary; other types of structures may also be used in addition to or in place of the structures to implement telecommunications functions or other functions.

In one embodiment, the software version upgrade method functionality may be integrated into the central processor 9100. The central processor 9100 may be configured to perform the following control:

S101: deploying each new software version to a corresponding first server cluster according to a service processing mode corresponding to the new software version so as to upgrade the software version of the first server cluster; the service during the software version upgrading is processed by running the old software version through the second server cluster;

s102: determining an optimal software version according to performance parameters of each first server cluster when the corresponding new software version is operated to process the service after the software version is upgraded; the optimal software version is one of the new software versions;

In another embodiment, the software version upgrade apparatus may be configured separately from the central processor 9100, for example, the data composite transmission apparatus software version upgrade apparatus may be configured as a chip connected to the central processor 9100, and functions of the software version upgrade method are implemented through control of the central processor.

As shown in fig. 13, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is noted that the electronic device 9600 need not include all of the components shown in fig. 13; in addition, the electronic device 9600 may further include components not shown in fig. 13, and reference may be made to the related art.

As shown in fig. 13, the central processor 9100, sometimes referred to as a controller or operational control, may include a microprocessor or other processor device and/or logic device, which central processor 9100 receives inputs and controls the operation of the various components of the electronic device 9600.

The memory 9140 may be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. The information about failure may be stored, and a program for executing the information may be stored. And the central processor 9100 can execute the program stored in the memory 9140 to realize information storage or processing, and the like.

The input unit 9120 provides input to the central processor 9100. The input unit 9120 is, for example, a key or a touch input device. The power supply 9170 is used to provide power to the electronic device 9600. The display 9160 is used for displaying display objects such as images and characters. The display may be, for example, but not limited to, an LCD display.

The memory 9140 may be a solid state memory such as Read Only Memory (ROM), random Access Memory (RAM), SIM card, etc. But also a memory which holds information even when powered down, can be selectively erased and provided with further data, an example of which is sometimes referred to as EPROM or the like. The memory 9140 may also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application/function storage portion 9142, the application/function storage portion 9142 storing application programs and function programs or a flow for executing operations of the electronic device 9600 by the central processor 9100.

The memory 9140 may also include a data store 9143, the data store 9143 for storing data, such as contacts, digital data, pictures, sounds, and/or any other data used by an electronic device. The driver storage portion 9144 of the memory 9140 may include various drivers of the electronic device for communication functions and/or for performing other functions of the electronic device (e.g., messaging applications, address book applications, etc.).

The communication module 9110 is a transmitter/receiver 9110 that transmits and receives signals via an antenna 9111. The communication module (transmitter/receiver) 9110 is coupled to the central processor 9100 to provide an input signal and receive an output signal, which may be the same as in the case of a conventional mobile communication terminal.

Based on different communication technologies, a plurality of communication modules 9110, such as a cellular network module, a bluetooth module, and/or a wireless lan module, may be provided in the same electronic device. The communication module (transmitter/receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and to receive audio input from the microphone 9132 to implement usual telecommunications functions. The audio processor 9130 can include any suitable buffers, decoders, amplifiers and so forth. In addition, the audio processor 9130 is also coupled to the central processor 9100 so that sound can be recorded locally through the microphone 9132 and sound stored locally can be played through the speaker 9131.

The embodiment of the present application further provides a computer readable storage medium capable of implementing all the steps in the software version upgrade method in which the execution subject is a server or a client, and the computer readable storage medium stores a computer program thereon, and the computer program when executed by a processor implements all the steps in the software version upgrade method in which the execution subject is a server or a client, for example, the processor implements the following steps when executing the computer program:

It will be apparent to those skilled in the art that embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The principles and embodiments of the present invention have been described in detail with reference to specific examples, which are provided to facilitate understanding of the method and core ideas of the present invention; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in accordance with the ideas of the present invention, the present description should not be construed as limiting the present invention in view of the above.

Claims

1. A method for upgrading a software version, comprising:

Deploying the optimal software version to the second server cluster so as to upgrade the software version of the second server cluster;

The determining an optimal software version according to the performance parameter of each first server cluster when the corresponding new software version is operated to process the service after the software version is upgraded includes:

2. The software version-up method of claim 1, further comprising, before deploying each new software version to a corresponding first server cluster according to a service processing mode corresponding to the new software version to cause the first server cluster to perform the software version-up:

The service flow inlet of the first server cluster is closed;

3. The software version upgrade method according to claim 1, wherein the deploying each new software version to a corresponding first server cluster according to the service processing mode corresponding to the new software version, so that the first server cluster performs the software version upgrade, includes:

4. The software version-up method of claim 1, further comprising, before the second server cluster runs the old software version to handle traffic during the software version-up:

The service flow inlet of the first server cluster is closed;

5. The method for upgrading a software version according to claim 1, wherein determining the performance parameter corresponding to each of the first server clusters according to the traffic flow allocation amount and the traffic transaction amount of each of the first server clusters comprises:

6. The software version upgrade method according to claim 1, further comprising, before deploying the optimal software version to the second server cluster to cause the second server cluster to perform a software version upgrade:

shutting down a traffic flow entry of the second server cluster;

7. The software version upgrade method according to claim 1, wherein said deploying the optimal software version to the second server cluster to cause the second server cluster to perform software version upgrade comprises:

8. The software version-up method of claim 1, further comprising:

9. A software version upgrade apparatus, comprising:

the second deployment unit is used for deploying the optimal software version to the second server cluster so as to upgrade the software version of the second server cluster;

wherein the optimal version determination unit includes:

10. The software version-up device of claim 9, further comprising:

11. The software version-up device of claim 9, wherein the first deployment unit comprises:

12. The software version-up device of claim 9, further comprising:

13. The software version upgrade apparatus according to claim 9, wherein the performance parameter determination module is specifically configured to divide the traffic transaction volume by the traffic flow allocation volume to obtain the performance parameter.

14. The software version-up device of claim 9, further comprising:

15. The software version upgrade apparatus according to claim 9, wherein the second deployment unit is specifically configured to issue a software version upgrade parameter corresponding to the optimal software version to the second server cluster, so that the second server cluster performs a software version upgrade according to the software version upgrade parameter.

16. The software version-up device of claim 9, further comprising:

17. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the steps of the software version upgrade method of any one of claims 1 to 8 when the program is executed by the processor.

18. A computer readable storage medium having stored thereon a computer program, characterized in that the computer program when executed by a processor implements the steps of the software version upgrade method of any one of claims 1 to 8.

19. A computer program product comprising computer programs/instructions which when executed by a processor implement the steps of the software version upgrade method of any one of claims 1 to 8.