CN112351077B

CN112351077B - Application service operation method, system, device and storage medium

Info

Publication number: CN112351077B
Application number: CN202011133769.2A
Authority: CN
Inventors: 安卫杰; 孙陈娜
Original assignee: China Construction Bank Corp
Current assignee: China Construction Bank Corp
Priority date: 2020-10-21
Filing date: 2020-10-21
Publication date: 2022-07-29
Anticipated expiration: 2040-10-21
Also published as: CN112351077A

Abstract

The invention relates to the technical field of communication, and particularly discloses an application service operation method, system, device and storage medium. The method comprises the steps that a first server sends a first node logout request to a second server, so that the second server updates a locally stored first service list according to a node identifier carried in the first node logout request, and sends an update instruction to a third server based on first service list information after updating, so that the third server updates the locally stored second service list, and the first server stops working after the second list is updated, so that the node corresponding to the node identifier of the node requesting logout in the first server is always in a service state before the second service list is updated, and the phenomenon that when the third server sends a call request to the first server within the updating time of the second service list, the node is stopped to cause transaction processing failure and transaction jitter is avoided.

Description

Application service operation method, system, device and storage medium

Technical Field

The present invention relates to the field of communications technologies, and in particular, to a method, a system, an apparatus, and a storage medium for operating an application service.

Background

Currently, most financial business systems adopt an SOA architecture or a distributed microservice architecture. Both the SOA architecture and the microservice architecture generally involve procedures such as service registration, service addressing, service invocation, service registration information update, and the like. It has three main roles: the interactive relationship among the service provider (RPC Server), the service requester (RPC Client) and the service Registry (Registry) is shown in FIG. 1.

Specifically, a service provider (RPC Server) provides a service, registers its own service information, network address, and the like in a service registration center (Registry) according to configuration information issued by its own service when starting, and periodically sends a heartbeat report survival status to the Registry.

The method comprises the steps that a service request party (RPC Client) calls a service, when the service is started, the service is subscribed to a service registration center (Registry) according to configuration information of the service call, a service node list returned by the Registry is cached in a local memory, and one RPC server is selected from the service node list cached in the local memory based on a load balancing algorithm to initiate the service call.

When a service provider (RPC Server) node changes, a service registration center (Registry) discovers abnormal nodes through a heartbeat mechanism between the service registration center and the RPC Server, can update a registration node list of the service in a quasi-real-time manner, and informs a service subscriber (RPC Client) of the change information of the service node list, the service node list cached in a local memory can be refreshed after the RPC Client senses the change information, and service calling is carried out based on the updated node information.

However, in the process of starting and stopping the application, due to the existence of the service list of the service requester in the more detailed time, a call request is still sent to the service provider which is deactivated or not yet started safely in the process of updating the list, so that the transaction cannot be carried out, and the transaction is abnormal or jittered instantaneously. For a financial business system, the business volume is large, the instantaneous transaction jitter can cause that a few transactions are abnormal, and a few transactions are abnormal, namely dozens of transactions and a great number of transactions are abnormal, and the related transactions are capital financial affairs processing transactions, so that a large influence is caused on a customer, and even customer complaints are caused.

Aiming at the problem, the deep analysis of the problem and the optimization solution proposal are urgently needed, so that the application service is enabled to be started and stopped elegantly, and the transaction jitter generated in the application starting and stopping process is avoided.

Disclosure of Invention

The invention aims to solve the technical problem that in the prior art, when an application service is started or stopped, transaction jitter occurs.

In order to solve the technical problem, the invention discloses an application service operation method which is applied to an SOA or micro-service architecture and comprises the following steps:

the first server sends a first node logout request to the second server;

The second server updates a first service list according to the node identification carried by the first node logout request, wherein the first service list records the node identification of the node which can provide service in the first server;

the second server sends an updating instruction to a third server according to the updated first service list;

the third server updates a second service list stored locally according to the updating instruction;

the third server sends the updated state information of the second service list to the first server;

the first server controls a node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received update state information of the second service list;

and the third server selects at least one node identifier from the updated second service list as a target node identifier, and sends the target node identifier to the first server, so that the first server calls a node corresponding to the target node identifier to provide service for the third server.

Further, after the third server updates the second service list stored locally according to the update instruction, the method further includes:

The first server sends a second node deregistration request to the second server,

the second server updates a first service list according to the node identification carried by the second node logout request, wherein the first service list records the node identification of the node which can provide service in the first server;

the first server controls the node corresponding to the node identifier of the second node logout request to stop working after preset time according to the received update state information of the second service list;

In an implementable approach, the updating, by the third server, the locally stored second service list according to the update instruction includes:

the third server receives the first service list carried in the updating instruction sent by the first server;

and after replacing the second service list stored locally by the third server with the first service list, taking the replaced first service list as the updated second service list of the third server.

In another implementation, the updating, by the third server, the second service list stored locally according to the update instruction includes:

the third server receives a node identifier of a node requesting logout carried in the updating instruction sent by the first server;

and the third server deletes the node identification matched with the node identification of the node requesting logout in the second service list stored locally.

In one implementation, the update status information of the second service list includes an expected total update duration and/or an average update duration.

Further, before the first server sends a first node logout request to the second server, or after the third server updates the second service list stored locally according to the update instruction, the method further includes:

The first server sending a node registration request to the second server;

the second server sends a starting state obtaining request to the first server according to the node identification carried by the node registration request so as to obtain the current starting state information of the node requesting registration;

the first server sends the current starting state information of the node to the second server according to the starting state acquisition request;

the second server determines whether the node meets the registration condition according to the current starting state information of the node, and updates a first service list when the node meets the registration condition, wherein the first service list records the node identification of the node which can provide service in the first server;

In an implementation scheme, the current startup state information includes resource loading progress information and service port information.

Further, the present invention provides another application service operation method, where the method uses a first server as an execution subject, and specifically, the method includes:

sending a first node logout request to a second server, so that the second server updates a first service list according to a node identifier carried by the first node logout request, and sends an update instruction to a third server according to the updated first service list; the third server updates a second service list stored locally according to the update instruction, wherein the first service list records node identifiers of nodes which can provide services in the first server;

receiving updated state information of the second service list sent by a third server;

controlling a node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received update state information of the second service list;

and receiving a target node identifier sent by the third server, and calling a node corresponding to the target node identifier to provide service for the third server according to the target node identifier, wherein the target node identifier is generated by at least one node identifier selected by the second server in an updated second service list.

Further, the present invention provides another application service operation method, where the method uses a second server as an execution subject, and specifically, the method includes:

receiving a first node logout request sent by a first server;

updating a first service list according to a node identifier carried by the first node logout request, wherein the first service list records the node identifier of a node which can provide service in the first server;

sending an updating instruction to a third server according to the updated first service list, so that the third server updates a locally stored second service list according to the updating instruction, and sends updating state information of the second service list to the first server after updating; the first server controls the node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received update state information of the second service list; and the third service selects at least one node identifier from the updated second service list as a target node identifier, and sends the target node identifier to the first server, so that the first server calls the node corresponding to the target node identifier to provide service for the third server.

Further, the present invention provides another application service operation method, where the method uses a third server as an execution subject, and specifically, the method includes:

receiving an updating instruction sent by a second server, updating a second service list stored locally according to the updating instruction,

sending the update state information of the second service list to a first server, so that the first server controls a node corresponding to a node identifier of a first node logout request to stop working after a preset time according to the received update state information of the second service list, wherein the update instruction is generated according to an updated first service list after the second server updates the first service list according to the node identifier carried by the first node logout request sent by the first server, and the first service list records the node identifier of a node which can provide service in the first server;

and selecting at least one node identifier from the updated second service list as a target node identifier, and sending the target node identifier to the first server, so that the first server calls a node corresponding to the target node identifier to provide service for the third server.

Further, the present invention also provides an application service operating system, which includes:

the first server is used for sending a first node logout request to the second server;

the second server is used for updating a first service list according to the node identifier carried by the first node logout request, and sending an update instruction to a third server according to the updated first service list, wherein the first service list records the node identifier of the node which can provide service in the first server;

the third server is used for updating a second service list stored locally according to the updating instruction and sending the updating state information of the second service list to the first server after updating;

the first server is further used for controlling a node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received update state information of the second service list;

the third server is further configured to select at least one node identifier from the updated second service list as a target node identifier, and send the target node identifier to the first server, so that the first server calls a node corresponding to the target node identifier to provide a service for the third server.

Further, the present invention also provides an application service running apparatus, including:

a first node logout request module, configured to send a first node logout request to a second server, so that the second server updates a first service list according to a node identifier carried in the first node logout request, and sends an update instruction to a third server according to the updated first service list; the third server updates a second service list stored locally according to the update instruction, wherein the first service list records node identifiers of nodes which can provide services in the first server;

the update state information receiving module is used for receiving the update state information of the second service list sent by a third server;

the control module is used for controlling the node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received update state information of the second service list;

and the target node identifier receiving module is used for receiving a target node identifier sent by the third server, and calling a node corresponding to the target node identifier to provide service for the third server according to the target node identifier, wherein the target node identifier is generated by at least one node identifier selected by the third server in an updated second service list.

Further, the present invention also provides an application service running device, which includes a processor and a memory, where the memory stores at least one instruction, at least one program, a set of codes, or a set of instructions, and the at least one instruction, the at least one program, the set of codes, or the set of instructions is loaded and executed by the processor to implement the application service running method as described above.

Further, the present invention also provides a computer-readable storage medium having at least one instruction, at least one program, a set of codes, or a set of instructions stored therein, which is loaded and executed by a processor to implement the application service execution method as described above.

In the embodiment of the invention, a first server sends a first node logout request to a second server firstly, so that the second server updates a locally stored first service list according to a node identifier carried in the first node logout request, and sends an update instruction to a third server based on first service list information after updating, so that the third server updates a locally stored second service list. The first server stops the work of the node corresponding to the node identifier of the node requesting the main logout after the second service list is updated, so that the node corresponding to the node identifier of the node requesting the logout in the first server is always in a service state before the second service list is updated, and the phenomenon that the transaction processing fails and transaction jitter occurs due to the fact that the node in the first server is stopped when the third server sends a call request to the first server within the updating time of the second service list is avoided.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a schematic diagram of a hardware system for performing the application service execution method of the present invention;

fig. 2 is a flowchart of an application service running method according to an embodiment of the present invention;

fig. 3 is a flowchart of an application service execution method according to another embodiment of the present invention;

fig. 4 is a flowchart of an application service execution method according to another embodiment of the present invention;

fig. 5 is a flowchart of an application service operation method according to another embodiment of the present invention;

fig. 6 is a schematic structural diagram of an application service running apparatus according to an embodiment of the present invention;

fig. 7 is a flowchart of an application service execution method according to another embodiment of the present invention;

fig. 8 is a flowchart of an application service execution method according to another embodiment of the present invention;

Fig. 9 is a schematic hardware structure diagram of a server provided by the present invention for implementing the method provided by the embodiment of the present invention;

in the figure, 10-first server, 1010-central processor, 1020-storage medium, 1021-operating system, 1022-data, 1023-application, 1030-memory, 1040-input-output interface, 1050-wired or wireless network interface, 1060-power, 20-second server, 30-third server;

40-a first node logout request module, 50-an updated state information receiving module, 60-a control module, and 70-a target node identification receiving module.

Detailed Description

In order to make the technical solutions of the present invention better understood, 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 only a part of the embodiments of the present invention, and not all of the embodiments. 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.

Reference herein to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic may be included in at least one implementation of the invention. In describing the present invention, it is to be understood that the terms "first," "second," "third," and "fourth," etc. in the description and claims of the present invention and the above-described drawings are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.

The embodiment is as follows:

In order to solve the above technical problem, the present invention discloses an application service operation method, and first, an embodiment of the present invention discloses an implementation environment of an application service operation method described in a possible embodiment.

Referring to fig. 1, the embodiment environment includes a first server 10, a second server 20, and a third server 30. The first server 10 may send a first node logout request to the second server 20, and the second server 20 may update a first service list according to a node identifier carried in the first node logout request in response to the first node logout request, where the first service list records the node identifier of a node that can provide a service in the first server 10.

Further, the first server 10 may also send an update instruction to the third server 30 according to the updated first service list; the third server 30 may update the second service list stored locally according to the update instruction, and send the update status information of the second service list to the first server 10 after the update.

The first server 10 may also update the state information according to the received second service list, and control the node corresponding to the node identifier of the first node logout request to stop working after a preset time.

The third server 20 may further select at least one node identifier from the updated second service list as a target node identifier, and send the target node identifier to the first server 10, so that the first server 10 invokes a node corresponding to the target node identifier to provide a service for the third server 30.

It is understood that the first server 10, the second server 20 and the third server 30 may each comprise a server operating independently, or a distributed server, or a server cluster composed of a plurality of servers. The connection between the server and the server can be realized through a network, and it is understood that the network includes but is not limited to: a wide area network, a metropolitan area network, or a local area network.

Further, fig. 2 is a method for running an application service according to an embodiment of the present invention, specifically, the method includes:

s100, the first server sends a first node logout request to the second server.

Specifically, the first node logout request sent by the first server to the second server may be one node logout request sent within a certain time period, or multiple node logout requests sent within a certain time period, where the "first" is only a summarized description of the node logout requests sent within a certain time period. It is understood that the node refers to a node that can provide a service in the first server 10, and each node that can provide a service includes a node identifier of the node, so as to uniquely identify the node.

S102, the second server updates the first service list according to the node identification carried by the first node logout request.

It can be understood that, when the first server sends the first node logout request to the second server, the first node logout request carries the node identifier of the node requesting logout. And the second server updates a first service list according to the node identification carried in the first node logout request, wherein the node identification of the node which can provide the service in the first server is recorded in the first service list.

Specifically, the second server updates the first service list according to the node identifier carried in the first node logout request, where the second server deletes the node identifier, which is matched with the node identifier carried in the first node logout request, in the locally stored first service list to obtain the updated first service list.

And S104, the second server sends an updating instruction to the third server according to the updated first service list.

And S106, the third server updates the second service list stored locally according to the updating instruction.

Specifically, in an implementable scheme, the third server updates the locally stored second service list according to the update instruction, which may be implemented as follows.

And the third server receives the first service list carried in the updating instruction sent by the first server.

It is understood that, when the first server sends the update instruction to the third server, the updated first service list of the first server may be sent to the third server together with the update instruction.

Further, in another implementable scheme, the third server updates the locally stored second service list according to the update instruction, which may be implemented as follows.

And the third server receives the node identification of the node requesting logout carried in the updating instruction sent by the first server.

It can be understood that, after the first server sends the first node logout request to the second server, the second server may store the node identifier carried in the first node logout request, so that, when the second server sends the update instruction to the third server, the node identifier carried in the first node logout request is sent to the third server together, so that the third server can clearly determine the node identifier which needs to be deleted and is matched with the node identifier carried in the first node logout request.

And the third server deletes the node identification matched with the node identification of the node requesting logout in the locally stored second service list.

S108, the third server sends the updated state information of the second service list to the first server.

Specifically, the update status information of the second service list may include, but is not limited to, a total update duration and/or an average update duration. Wherein the expected total update duration is a total expected duration used for updating the entire second service list, and the average update duration is an average time used for updating the node identifier of one first logout request.

S110, the first server controls the node corresponding to the node identification of the first node logout request to stop working after preset time according to the received update state information of the second service list.

It is understood that the preset time may be determined according to the updated state information of the second service list. In some practical solutions, if the update status information of the second service list received by the first server is the expected total update duration of the second service list, the node corresponding to the node identifier of the logout request of the first node is controlled to stop working after waiting for at least a time equal to the expected total update duration, for example, waiting for 0 to 30ms again on the basis of the expected total update duration. That is, after receiving the update state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the first node logout request to stop working after waiting for the expected total update time, so as to ensure that the node corresponding to the node identifier of the first node logout request is always in a working state before the second service list is updated, thereby avoiding that the transaction processing fails and the transaction jitter phenomenon occur due to the node deactivation when the third server sends a call request to the first server within the update time of the second service list.

Or, after receiving the update state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the first node logout request to stop working after waiting for 30ms more than the expected total update time, so as to ensure that the node corresponding to the node identifier of the first node logout request is always in a working state before the second service list is updated, and avoid transaction jitter caused by failure of the node due to deactivation of the node when the third server sends a call request to the first server within the update time of the second service list.

It should be noted that, after waiting for 0 to 30m again on the basis of the expected total duration, controlling the node corresponding to the node identifier of the first node logout request to stop working is only a preselection mode, and in other implementable schemes, the node may wait for 0 to 20ms or 10 to 20ms again on the basis of the expected total duration, and may be set according to specific situations, which is not particularly limited.

Further, if the update state information of the second service list received by the first server is the average update duration, the first server may calculate a total duration consumed after the second service list is updated according to the number of the node identifiers corresponding to the sent first logout request and the received average update duration, at this time, the node identifier corresponding to the first logout request starts when the first logout request is sent, and after waiting for at least a time equal to the calculated total duration consumed, the node identifier corresponding to the first node logout request is controlled to stop working. For example, waiting for 0-30 ms again on the basis of the calculated total consumed time.

That is, after receiving the updated state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the first node logout request to stop working after waiting for the calculated total time consumption, so as to ensure that the node corresponding to the node identifier of the first node logout request is always in a working state before the second service list is updated, thereby avoiding that the transaction processing fails and the transaction jitter phenomenon occur due to the node deactivation when the third server sends a call request to the first server within the update time of the second service list.

Or, after receiving the updated state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the first node logout request to wait for 30ms more than the calculated total consumed time and then stop working, so as to ensure that the node corresponding to the node identifier of the first node logout request is always in a working state before the second service list is updated, and avoid that the transaction processing fails and the transaction jitter phenomenon occurs due to the node deactivation when the third server sends a call request to the first server within the update time of the second service list.

S112, the third server selects at least one node identifier from the updated second service list as a target node identifier, and sends the target node identifier to the first server, so that the first server calls a node corresponding to the target node identifier to provide service for the third server.

In the embodiment of the invention, the first server sends a first node logout request to the second server, so that the second server updates the locally stored first service list according to the node identifier carried in the first node logout request, and after the update, sends an update instruction to the third server based on the first service list information, so that the third server updates the locally stored second service list. The first server stops the node corresponding to the node identifier of the node requesting the main logout from stopping working after the second service list is updated, so that the node corresponding to the node identifier of the node requesting the logout in the first server is always in a service state before the second service list is updated, and the phenomenon that when a third server sends a calling request to the first server within the updating time of the second service list, the node is stopped, the transaction processing fails and the transaction jitter occurs is avoided.

Further, the present invention provides another application service operation method, as shown in fig. 3, the method includes steps S100 to S112 in the foregoing embodiment, and after the third server updates the locally stored second service list according to the update instruction, the method further includes:

s200, the first server sends a second node logout request to the second server.

It is to be understood that the second node deregistration request may be performed at any time after the third server updates the locally stored second service list according to the update instruction, that is, at any time after the first server has not sent the first deregistration request to the second server, the first server may send the second deregistration request to the second server at any time, so as to achieve deregistration of the node of the first service at any time.

Specifically, the second node logout request sent by the first server to the second server may be one node logout request sent within a certain time period, or multiple node logout requests sent within a certain time period, where the "second" is only a summarized explanation of the node logout request sent within a certain time period. It is understood that the node refers to a node that can provide a service in the first server, and each node that can provide a service includes a node identifier of the node, so as to uniquely identify the node.

S202, the second server updates the first service list according to the node identification carried by the second node logout request.

It can be understood that, when the first server sends the second node logout request to the second server, the second node logout request carries the node identifier of the node requesting logout. And the second server updates a first service list according to the node identification, and the node identification of the nodes which can provide the service in the first server is recorded in the first service list.

Specifically, the second server updates the first service list according to the node identifier carried in the second node logout request, where the second server deletes the node identifier, which is matched with the node identifier carried in the second node logout request, in the locally stored first service list to obtain the updated first service list.

And S204, the second server sends an updating instruction to the third server according to the updated first service list.

S206, the third server updates the second service list stored locally according to the updating instruction.

It is to be understood that, when the first server sends the update instruction to the third server, the updated first service list may be sent to the third server together with the update instruction.

And the third server receives the node identification of the node which requests logout and is carried in the updating instruction sent by the first server.

It can be understood that, after the first server sends the second node logout request to the second server, the second server may store the node identifier carried in the second node logout request, so that, when the second server sends the update instruction to the third server, the node identifier carried in the second node logout request is sent to the third server together, so that the third server can clearly determine the node identifier which needs to be deleted and is matched with the node identifier carried in the second logout request.

S208, the third server sends the updated state information of the second service list to the first server.

S210, the first server controls the node corresponding to the node identification of the second node logout request to stop working after preset time according to the received update state information of the second service list. (ii) a

It is understood that the preset time may be determined according to the updated state information of the second service list. In some practical solutions, if the update status information of the second service list received by the first server is the expected total update duration of the second service list, the node corresponding to the node identifier of the logout request of the second node is controlled to stop working after waiting for at least a time equal to the expected total update duration, for example, waiting for 0-30 ms again on the basis of the expected total update duration. That is, after receiving the update state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the second node logout request to stop working after waiting for the expected total update time, so as to ensure that the node corresponding to the node identifier of the second node logout request is always in a working state before the second service list is updated, thereby avoiding that the transaction processing fails and the transaction jitter phenomenon occur due to the node deactivation when the third server sends a call request to the first server within the update time of the second service list.

Or, after receiving the update state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the second node logout request to stop working after waiting for 30ms more than the expected total update time, so as to ensure that the node corresponding to the node identifier of the second node logout request is always in a working state before the second service list is updated, and avoid that the transaction processing fails and the transaction jitter phenomenon occurs due to the node deactivation when the third server sends the call request to the first server within the update time of the second service list.

It should be noted that, after waiting for 0 to 30m again on the basis of the expected total duration, controlling the node corresponding to the node identifier of the second node logout request to stop working is only a preselection mode, and in other implementable schemes, the node may wait for 0 to 20ms or 10 to 20ms again on the basis of the expected total duration, and may be set according to specific situations, which is not particularly limited.

Further, if the update state information of the second service list received by the first server is the average update duration, the first server may calculate a total duration consumed after the second service list is updated according to the number of the node identifiers corresponding to the sent second logout request and the received average update duration, at this time, the node identifier corresponding to the second logout request starts when the second logout request is sent, and after waiting for at least a time equal to the calculated total duration consumed, the node corresponding to the node identifier of the second logout request is controlled to stop working. For example, waiting for 0-30 ms again on the basis of the calculated total consumed time.

That is, after receiving the updated state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the second node logout request to stop working after waiting for the calculated total time consumption, so as to ensure that the node corresponding to the node identifier of the second node logout request is always in a working state before the second service list is updated, and avoid transaction processing failure and transaction jitter caused by node deactivation when the third server sends a call request to the first server within the update time of the second service list.

Or, after receiving the updated state information of the second service list sent by the second server, the first server may control the node corresponding to the node identifier of the second node logout request to wait for 30ms more than the calculated total consumed time and then stop working, so as to ensure that the node corresponding to the node identifier of the second node logout request is always in a working state before the second service list is updated, and avoid transaction jitter caused by failure of the node due to deactivation of the node when the third server sends the call request to the first server within the update time of the second service list.

It should be noted that, after waiting for 0 to 30m again on the basis of the expected total duration, controlling the node corresponding to the node identifier of the second node logout request to stop working is only a preselection mode, and in other implementable schemes, the node may wait for 0 to 20ms or 10 to 20ms again on the basis of the expected total duration, which may be set according to specific situations, and is not particularly limited here.

S212, the third server selects at least one node identifier from the updated second service list as a target node identifier, and sends the target node identifier to the first server, so that the first server calls a node corresponding to the target node identifier to provide service for the third server.

In the embodiment of the invention, the first server sends a first node logout request to the second server, so that the second server updates the locally stored first service list according to the node identifier carried in the first node logout request, and after the update, sends an update instruction to the third server based on the first service list information, so that the third server updates the locally stored second service list. The first server stops the work of the node corresponding to the node identifier of the node requesting the main logout only after the second service list is updated, so that the node corresponding to the node identifier of the node requesting the logout in the first server is always in a service state before the second service list is updated, and the phenomenon that the transaction processing fails and transaction jitter occurs due to the fact that the node is stopped when the third server sends a call request to the first server within the updating time of the second service list is avoided.

Furthermore, in the embodiment of the present invention, the update of the service list based on the first logout request does not affect the sending of other logout requests such as the second logout request, that is, in the embodiment of the present invention, the logout request of any node can be sent at any time, and the logout request is not required to be sent after the node that has sent the logout request stops working.

Further, the present invention provides another application service running method, as shown in fig. 4, the method is further executed on the basis of executing steps S100 to S112, or executing steps S200 to 212, or synchronously executing steps S100 to S112 and steps S200 to S212 in the above embodiment. Specifically, before the first server sends the node logout request to the second server, or after the third server updates the second service list stored locally according to the update instruction, the method further includes:

s300, the first server sends a node registration request to the second server.

Specifically, the node registration request sent by the first server to the second server may be one node registration request sent within a certain time period, or multiple node registration requests sent within a certain time period. It is understood that the node refers to a node that can provide a service in the first server, and each node that can provide a service includes a node identifier of the node, so as to uniquely identify the node.

S302, the second server sends a starting state obtaining request to the first server according to the node identification carried by the node registration request so as to obtain the current starting state information of the node requesting registration.

S304, the first server sends the current starting state information of the node to the second server according to the starting state obtaining request.

S306, the second server determines whether the node meets the registration condition according to the current starting state information of the node, and updates the first service list when the node meets the registration condition.

After receiving a node registration request sent by a first server, a second server needs to send a starting state acquisition request to the first server, so that after acquiring current starting state information of the node which is requested to be registered, a current starting state of the node corresponding to a node identifier carried by the registration request is checked in advance to judge whether the current starting state of the node meets a node registration condition, if the current starting state of the node meets the registration condition, the node is started completely, service can be provided, at this time, the second server can register and register the node identifier of the node and update a first service list, wherein the first service list records the node identifier of the node which can provide service in the first server.

If the current starting state of the node does not meet the registration condition, the node is not started completely and cannot provide service, and at the moment, the second server continues to acquire the current starting state information of the node until the node is completely started.

It will be appreciated that the current boot state information may include, but is not limited to, resource loading progress information and service port information. The resource loading progress refers to the loading progress of the resource information of the node corresponding to the node identifier requesting registration, and the service port information refers to the port providing the service to the outside corresponding to the node identifier requesting registration. The condition of meeting the registration at least means that the resource information loading of the node corresponding to the node identifier requesting the registration is completed and the port providing the service to the outside is normally opened.

S308, the second server sends an updating instruction to the third server according to the updated first service list.

And S310, the third server updates the second service list stored locally according to the updating instruction.

S312, the third server selects at least one node identifier from the updated second service list as a target node identifier, and sends the target node identifier to the first server, so that the first server calls a node corresponding to the target node identifier to provide service for the third server.

Specifically, in an implementable scheme, the third server updates the second service list stored locally according to the update instruction, which may be implemented as follows.

The third server receives a first service list carried in an updating instruction sent by the first server;

it is to be understood that, when the second server sends the update instruction to the third server, the updated first service list may be sent to the third server together with the update instruction.

And the third server receives the node identification of the node requesting registration carried in the updating instruction sent by the first server.

It can be understood that, after the first server sends the node registration request to the second server, the second server may store the node identifiers carried in the node registration request, so that, when the second server sends the update instruction to the third server, the node identifiers carried in the node registration request are sent to the third server together, so that the third server can clearly determine the node identifiers matched with the node identifiers carried in the registration request that needs to be added.

The third server adds the node identification of the node requesting registration to a second service list stored locally.

In the embodiment of the invention, before the second server updates the first service list based on the node registration request of the first server, the second server first obtains the current starting state of the node corresponding to the node identifier requested to be registered in the first server, registers the node identifier corresponding to the node registration request after the node is completely started, and updates the first service list based on the node identifier, so that when the third server sends a call request to the first server based on the updated second service list, the node requested to be registered in the first server is started completely, and thus the service can be provided normally, and the problem that when the third server sends the call request to the first server after the second service list is updated, a port of the node in the first server is closed, or the node is still in a resource loading state, so that transaction processing fails is avoided, a transaction jitter phenomenon occurs.

It can be understood that, in the embodiment of the present invention, the node registration request may be sent from the first server to the second server at any time, and the update of the service list of the first logout request and/or the update of the service list of the second logout request do not affect the sending of the registration request.

Further, in the embodiment of the present invention, the first server first sends a first node logout request to the second server, so that the second server updates the locally stored first service list according to the node identifier carried in the first node logout request, and after the update, sends an update instruction to the third server based on the first service list information, so that the third server updates the locally stored second service list. The first server stops the node corresponding to the node identifier of the node requesting the main logout from stopping working after the second service list is updated, so that the node corresponding to the node identifier of the node requesting the logout in the first server is always in a service state before the second service list is updated, and the phenomenon that when a third server sends a calling request to the first server within the updating time of the second service list, the node is stopped, the transaction processing fails and the transaction jitter occurs is avoided.

Further, the present invention also provides an application service system, which comprises:

The described system embodiment apparatus and method embodiment are based on the same inventive concept and are used to perform the method shown in fig. 2.

Further, the present invention also provides another application service operation method, where the method uses a first server as an execution subject, specifically, as shown in fig. 5, the method includes:

s400, sending a first node logout request to a second server so that the second server updates a first service list according to a node identifier carried by the first node logout request, and sends an update instruction to a third server according to the updated first service list; and the third server updates a second service list stored locally according to the updating instruction, wherein the first service list records the node identification of the node which can provide the service in the first server.

S402, receiving the updated state information of the second service list sent by the third server.

S404, controlling the node corresponding to the node identifier of the first node logout request to stop working after a preset time according to the received update state information of the second service list.

S406, receiving a target node identifier sent by the third server, and calling a node corresponding to the target node identifier to provide service for the third server according to the target node identifier, wherein the target node identifier is generated by at least one node identifier selected by the second server from the second service list.

Further, the present invention also provides an application service apparatus, as shown in fig. 6, the apparatus includes:

a first node logout request module 40, configured to send a first node logout request to a second server, so that the second server updates a first service list according to a node identifier carried in the first node logout request, and sends an update instruction to a third server according to the updated first service list; the third server updates a second service list stored locally according to the update instruction, wherein the first service list records node identifiers of nodes which can provide services in the first server;

an update status information receiving module 50, configured to receive update status information of the second service list sent by a third server;

a control module 60, configured to control, according to the received update state information of the second service list, a node corresponding to the node identifier of the first node logout request to stop working after a preset time;

a target node identifier receiving module 70, configured to receive a target node identifier sent by the third server, and invoke a node corresponding to the target node identifier to provide a service for the third server according to the target node identifier, where the target node identifier is generated by at least one node identifier selected by the third server in the updated second service list.

The described system embodiment apparatus and method embodiment are based on the same inventive concept and are used to perform the method shown in fig. 5.

Further, the present invention also provides another method for running an application service, where the method uses a second server as an execution subject, and specifically, as shown in fig. 7, the method includes:

S500, receiving a first node logout request sent by a first server;

s502, updating a first service list according to a node identifier carried by a first node logout request, wherein the first service list records the node identifier of a node which can provide service in the first server;

s504, sending an updating instruction to a third server according to the updated first service list, so that the third server updates a second service list stored locally according to the updating instruction, and sends updating state information of the second service list to the first server after updating; the first server controls the node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received update state information of the second service list; and the third service selects at least one node identifier from the updated second service list as a target node identifier, and sends the target node identifier to the first server, so that the first server calls the node corresponding to the target node identifier to provide service for the third server.

Further, the present invention also provides another method for running an application service, where the method uses a third server as an execution subject, and specifically, as shown in fig. 8, the method includes:

s600, receiving an updating instruction sent by a second server, and updating a second service list stored locally according to the updating instruction;

s602, sending update state information of a second service list to a first server, so that the first server controls a node corresponding to a node identifier of a first node logout request to stop working after a preset time according to the received update state information of the second service list, wherein an update instruction is generated according to the updated first service list after the second server updates the first service list according to the node identifier carried by the first node logout request sent by the first server, and the first service list records the node identifier of a node which can provide service in the first server;

s604, selecting at least one node identifier from the updated second service list as a target node identifier, and sending the target node identifier to the first server, so that the first server calls a node corresponding to the target node identifier to provide service for the third server.

Further, the present invention also provides an application service running device, which includes a processor and a memory, where the memory stores at least one instruction, at least one program, a code set, or a set of instructions, and the at least one instruction, the at least one program, the code set, or the set of instructions is loaded and executed by the processor to implement the application service running method according to the above embodiment.

Further, the present invention also provides a computer-readable storage medium, in which at least one instruction, at least one program, a code set, or a set of instructions is stored, and the at least one instruction, the at least one program, the code set, or the set of instructions is loaded and executed by a processor to implement the application service execution method according to the above embodiment.

Optionally, in this embodiment, the computer storage medium may include, but is not limited to: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

Further, the present invention also provides a hardware structure diagram of a server for implementing the method provided in the embodiment of the present invention, as shown in fig. 9, the server is configured to implement the application service operation method provided in the above embodiment, specifically:

the server in the embodiment is a generic name of a first server, a second server, and a third server, and the following description is made with reference to the first server 10 as the server in this embodiment:

the server arrangement may comprise means for identifying a proxy internet protocol, IP, address as described above. The server 10 may vary significantly depending on configuration or performance, and may include one or more Central Processing Units (CPUs) 1010 (e.g., one or more processors) and memory 1030, one or more storage media 1020 (e.g., one or more mass storage devices) storing applications 1023 or data 1022. Memory 1030 and storage media 1020 may be, among other things, transient or persistent storage. The program stored in the storage medium 1020 may include one or more modules, each of which may include a series of instruction operations for a server. Still further, the central processor 1010 may be configured to communicate with the storage medium 1020 to execute a series of instruction operations in the storage medium 1020 on the server 10. The server 10 may also include one or more power supplies 1060, one or more wired or wireless network interfaces 1050, one or more input-output interfaces 1040, and/or one or more operating systems 1021, such as Windows Server, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, and so forth.

In the above embodiments of the present invention, the description of each embodiment has its own emphasis, and reference may be made to the related description of other embodiments for parts that are not described in detail in a certain embodiment.

In the several embodiments provided in the present application, it should be understood that the disclosed client may be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed coupling or direct coupling or communication connection between each other may be an indirect coupling or communication connection through some interfaces, units or modules, and may be electrical or in other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit may be implemented in the form of hardware, or may also be implemented in the form of a software functional unit.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and decorations can be made without departing from the principle of the present invention, and these modifications and decorations should also be regarded as the protection scope of the present invention.

Claims

1. An application service running method, characterized in that the method comprises:

the first server sends a first node logout request to the second server;

the second server updates a first service list according to the node identification carried by the first node logout request to obtain an updated first service list, and the updated first service list records the node identification of the node which can provide service in the first server;

the second server sends an updating instruction to a third server, wherein the updating instruction carries an updated first service list;

The third server receives the updating instruction;

the third server replaces the second service list stored locally with the updated first service list, and takes the replaced updated first service list as the updated second service list;

the third server sends updating state information of a locally stored second service list to the first server, wherein the updating state information comprises the predicted total updating duration of the locally stored second service list;

the first server controls the node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received estimated total update duration;

2. The application service execution method according to claim 1, wherein after the third server updates the locally stored second service list according to the update instruction, the method further comprises:

3. The application service running method according to claim 1, wherein the third server updating the locally stored second service list according to the update instruction includes:

4. The application service running method according to claim 1 or 3, wherein before the first server sends a first node logout request to the second server, or after the third server updates the locally stored second service list according to the update instruction, the method further comprises:

the first server sending a node registration request to the second server;

5. The application service running method according to claim 4, wherein the current startup state information includes resource loading progress information and service port information.

6. An application service running method, characterized in that the method comprises:

sending a first node logout request to a second server, so that the second server updates a first service list according to a node identifier carried by the first node logout request to obtain an updated first service list; sending an updating instruction carrying the updated first service list to a third server; after receiving the update instruction, the third server replaces the second service list stored locally with the updated first service list, and takes the replaced updated first service list as the updated second service list; the updated first service list records node identifiers of nodes which can provide services in the first server;

Receiving update state information of a locally stored second service list sent by a third server, wherein the update state information comprises the estimated total update duration of the locally stored second service list;

controlling the node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received estimated total update duration;

and receiving a target node identifier sent by the third server, and calling a node corresponding to the target node identifier to provide service for the third server according to the target node identifier, wherein the target node identifier is generated by at least one node identifier selected by the third server in an updated second service list.

7. An application service execution system, the system comprising:

the second server is used for updating the first service list according to the node identifier carried by the first node logout request to obtain an updated first service list; sending an update instruction carrying an updated first service list to a third server, wherein the updated first service list records node identifiers of nodes which can provide services in the first server;

The third server is used for receiving the updating instruction, replacing a second service list stored locally with the first service list, and taking the replaced first service list as an updated second service list; sending update state information of a locally stored second service list to the first server, wherein the update state information comprises an estimated total update duration of the locally stored second service list;

the first server is further used for controlling the node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received estimated total update duration;

the third server is further configured to select at least one node identifier from the updated second service list as a target node identifier, and send the target node identifier to the first server, so that the first server invokes a node corresponding to the target node identifier to provide a service for the third server.

8. An application service execution apparatus, characterized in that the apparatus comprises:

a first node logout request module, configured to send a first node logout request to a second server, so that the second server updates a first service list according to a node identifier carried in the first node logout request, and obtains an updated first service list; sending an update instruction carrying the updated first service list to a third server, so that after receiving the update instruction, the third server replaces a second service list stored locally with the first service list, and takes the replaced updated first service list as the updated second service list; the updated first service list records node identifiers of nodes which can provide services in the first server;

The update state information receiving module is used for receiving update state information of a locally stored second service list sent by a third server, wherein the update state information comprises the estimated total update duration of the locally stored second service list;

the control module is used for controlling the node corresponding to the node identifier of the first node logout request to stop working after preset time according to the received estimated total update duration;

9. A computer readable storage medium having stored therein at least one instruction, at least one program, a set of codes, or a set of instructions, which is loaded and executed by a processor to implement the application service execution method of any one of claims 1 to 5 or claim 6.