CN114172821A - Service state synchronization method and device and server - Google Patents
Service state synchronization method and device and server Download PDFInfo
- Publication number
- CN114172821A CN114172821A CN202210117635.4A CN202210117635A CN114172821A CN 114172821 A CN114172821 A CN 114172821A CN 202210117635 A CN202210117635 A CN 202210117635A CN 114172821 A CN114172821 A CN 114172821A
- Authority
- CN
- China
- Prior art keywords
- request
- service
- parameter
- abstract
- target
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
Abstract
The embodiment of the application provides a method, a device and a server for synchronizing service states, wherein the method comprises the following steps: intercepting the cooperative service request from the plurality of service requests according to a preset interception rule by the main node; when the host node successfully executes the collaborative service request, converting the service calling parameter of the collaborative service request into abstract request description, and uploading the abstract request description to a message middleware; reading and analyzing the target abstract request description from the node to obtain a target service calling interface parameter, and executing a collaborative service request according to the target service calling interface parameter; when the slave node fails to execute, sending the request processing state of the slave node to message middleware; and re-executing the cooperative service request according to the target service call interface parameter until the cooperative service request is successful. Therefore, the final consistency of the service state between the master node and the slave node is ensured by sequencing the abstract description of the requests of the nodes, and the service cooperation is completed.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for synchronizing service states, and a server.
Background
With the continuous development of digital technology, various group enterprises and factories face the challenge of digital transformation. Particularly, a large number of group-type industrial enterprises have a very urgent digital transformation demand, and due to the complex data of the group-type industrial enterprises, the digital transformation of the group-type industrial enterprises is more complex than that of a single factory, and in the actual transaction processing process, the business interaction demands among a group headquarters, a division and a multi-region park make the industrial internet platform have a corresponding flexible distributed deployment architecture and a coordination scheme. The prior distributed system has poor cooperativity and consistency of business services, and cannot cooperate to complete the business services.
Disclosure of Invention
In order to solve the above technical problem, embodiments of the present application provide a method, an apparatus, and a server for synchronizing service states.
In a first aspect, an embodiment of the present application provides a method for synchronizing service states, where the method includes:
determining a cooperative service request from a plurality of service requests according to a preset interception rule through a request interceptor of a main node, and intercepting the cooperative service request;
when the main node successfully executes the collaborative service request, converting the service calling parameter of the collaborative service request into abstract request description through the request interceptor, and uploading the abstract request description to a request success theme of a message middleware;
reading a target abstract request description from the request success theme through a request executor of a slave node, analyzing the target abstract request description to obtain a target service calling interface parameter, and executing the collaborative service request according to the target service calling interface parameter;
when the request executor of the slave node fails to execute the cooperative service request, sending the request processing state of the slave node to a request failure subject of the message middleware through the request executor;
and re-executing the cooperative service request according to the target service call interface parameter by the request executor until the request executor successfully executes the cooperative service request.
In a second aspect, an embodiment of the present application provides an apparatus for synchronizing service statuses, where the apparatus includes:
the system comprises an interception module, a service request processing module and a service request processing module, wherein the interception module is used for determining a cooperative service request from a plurality of service requests according to a preset interception rule through a request interceptor of a main node and intercepting the cooperative service request;
a conversion module, configured to, when the master node successfully executes the collaborative service request, convert a service invocation parameter of the collaborative service request into an abstract request description by the request interceptor, and upload the abstract request description to a request success theme of a message middleware;
the analysis module is used for reading a target abstract request description from the request success theme through a request executor of a slave node, analyzing the target abstract request description to obtain a target service calling interface parameter, and executing the collaborative service request according to the target service calling interface parameter;
a sending module, configured to send, by the request executor, a request processing state of the slave node to a request failure topic of the message middleware when the request executor of the slave node fails to execute the collaborative service request;
and the execution module is used for re-executing the cooperative service request according to the target service calling interface parameter through the request executor until the request executor successfully executes the cooperative service request.
In a third aspect, an embodiment of the present application provides a server, including a memory and a processor, where the memory is used to store a computer program, and the computer program executes, when the processor runs, the synchronization method for the service state provided in the first aspect.
In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which, when running on a processor, performs the synchronization method for service states provided in the first aspect.
According to the service state synchronization method, the service state synchronization device and the service state synchronization server, the request interceptor of the main node determines the cooperative service request from the plurality of service requests according to the preset interception rule, and intercepts the cooperative service request; when the main node successfully executes the collaborative service request, converting the service calling parameter of the collaborative service request into abstract request description through the request interceptor, and uploading the abstract request description to a request success theme of a message middleware; reading a target abstract request description from the request success theme through a request executor of a slave node, analyzing the target abstract request description to obtain a target service calling interface parameter, and executing the collaborative service request according to the target service calling interface parameter; when the request executor of the slave node fails to execute the cooperative service request, sending the request processing state of the slave node to a request failure subject of the message middleware through the request executor; and re-executing the cooperative service request according to the target service call interface parameter by the request executor until the request executor successfully executes the cooperative service request. Therefore, assistance and synchronization of service calling among a plurality of micro service nodes are realized, service states and data which are only needed by cooperative service of the micro service nodes can be synchronized according to preset interception rules configured by service rules so as to ensure the autonomy of each service node, and in a master-slave multi-node service system, the final consistency of the service states among the master node and the slave node is ensured by the abstract description and sequencing of requests of the nodes, so that service cooperation is completed.
Drawings
In order to more clearly explain the technical solutions of the present application, the drawings needed to be used in the embodiments are briefly introduced below, and it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope of protection of the present application. Like components are numbered similarly in the various figures.
FIG. 1 shows a schematic structural diagram of a prior art distributed system;
FIG. 2 shows another schematic diagram of a prior art distributed system;
FIG. 3 is a schematic diagram of a prior art database;
fig. 4 is a flow chart illustrating a synchronization method of service states provided by an embodiment of the present application;
FIG. 5 is a schematic diagram illustrating a distribution of data nodes provided by an embodiment of the present application;
fig. 6 is another flow chart of a synchronization method for service status provided by an embodiment of the present application;
fig. 7 is a schematic structural diagram of a synchronization apparatus for service status provided by an embodiment of the present application.
Detailed Description
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.
The components of embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present invention, presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present invention without making any creative effort, shall fall within the protection scope of the present invention.
Hereinafter, the terms "including", "having", and their derivatives, which may be used in various embodiments of the present invention, are only intended to indicate specific features, numbers, steps, operations, elements, components, or combinations of the foregoing, and should not be construed as first excluding the existence of, or adding to, one or more other features, numbers, steps, operations, elements, components, or combinations of the foregoing.
Furthermore, the terms "first," "second," "third," and the like are used solely to distinguish one from another and are not to be construed as indicating or implying relative importance.
Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which various embodiments of the present invention belong. The terms (such as those defined in commonly used dictionaries) should be interpreted as having a meaning that is consistent with their contextual meaning in the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein in various embodiments of the present invention.
The existing mass group type industrial enterprises face the digital transformation requirement, and the digital transformation of the mass group type industrial enterprises is more complicated than the digital transformation of a single factory. For a group type industrial enterprise, a group and each campus can be an independent service node, please refer to fig. 1, a group head office has a master node 10, a campus 1 has a first slave node 11, a campus 2 has a second slave node 12, a campus 3 has a third slave node 13, and there can be N campuses, and there are no limitations here. The master node 10 is capable of communicating and service cooperation with the slave nodes. The first user 14 can realize the control management of the group service through the master node 10, the second user 15 can realize the control management of the group service through the first slave node 11, and the third user 16 can realize the state of each park service through the second slave node 12.
In order to solve the problems of data synchronization and service state synchronization of a master node and a slave node, a federal architecture is introduced, the federal architecture is widely submitted in a big data component and a alliance block chain, the federal architecture only can have a plurality of centers, each center can be independent and autonomous, and the centers can communicate with each other, so that a complex digital cooperative task is completed. Referring to fig. 2, fig. 2 is a simplified illustration of a federated architecture of multiple data centers, in fig. 2, a group data center 24 is in communication connection with a campus a data center 25 and a campus B data center 26, a group user 21 communicates with the group data center 24 through a group micro service 23, a campus B user 22 communicates with a campus B data center 26 through a campus B micro service 27, and the federated architecture includes multiple data centers, each of which is autonomous.
For Data synchronization, a database log synchronization mode is adopted, specifically, Data synchronization based on Change Data Capture (CDC) is adopted. The data synchronization software framework of the CDC includes 2 parts: a data operation listener and a data operation executor. Referring to fig. 3, a Data operation listener (CDC) 32 is deployed with a master database 31, directly obtains a Data Change operation message stream from the master database 31 through a Data Change Capture (CDC) software framework, and broadcasts the Data Change operation message stream to all slave node Data centers through a network medium (e.g., a message queue 33), and a Data operation executor of each slave node Data center receives the Data Change operation and performs the operation on the slave node Data center, thereby completing Data synchronization with the master node Data center. As shown in fig. 3, the first and second data operation executors 34 and 35 receive data change operations and perform operations on the first and second slave databases 36 and 37, thereby completing data synchronization with the master database 31. Although data synchronization on a database level can be achieved based on the CDC technology, in a federal architecture scenario, nodes need to cooperate to complete a unified business goal. The data synchronization on the data layer is difficult to realize service triggering, so that service coordination cannot be completed, and all micro-service states in each node still cannot reach the final consistency required by a service scene.
Example 1
The embodiment of the disclosure provides a service state synchronization method.
Specifically, referring to fig. 4, the method for synchronizing the service states includes the following steps:
step S401, determining a cooperative service request from a plurality of service requests according to a preset interception rule through a request interceptor of the main node, and intercepting the cooperative service request.
The synchronization method of the service state of this embodiment can be applied to a master-slave multi-service node system, which includes 2 mutually exclusive roles, and each node has an independent and unique data center ID. There are 1 master data center and a plurality of slave data centers.
In an embodiment, the preset interception rule includes a white list, a target service type, a request service interface path, an exception path, and a service interface request method.
Specifically, the preset interception rule of the request interceptor may adopt a white list mode, and the preset interception rule is loaded in the initialization process of the request interceptor. The main codes of the preset interception rules are as follows:
"whiteListEntries": [
{
"requestPath": "/api/v1/auth/*",
"exceptionalPaths":
["/api/v1/auth/login","/api/v1/auth/login/*"],
"requestMethod": "POST",
"serviceType": "IAM",
},...
] }
wherein whiteListEntries: a white list; request interceptor only intercepts white list
The service interface of (1). serviceType: the requested target service type; requestPath: request service interface path (through all sub paths under the overlay interface path); exceptinotalpaths: and the exception path is not intercepted any more if the request simultaneously matches the reqeustPath and the exception path. String, service interface request method (for example, POST, PUT, etc. according to http interface standard); string, the requested target service type.
In this embodiment, the cooperative service request refers to an interface request that is given to be executed synchronously between nodes. The main node executes the request, if the request is successful, the request is stored in a message queue, and each slave node reads the service interface requests from the message queue in sequence and executes the service interface requests in sequence respectively. Finally, the effect of synchronizing the micro-service states of all the nodes is achieved, and the capability of acquiring the synchronous states of the service states of all the nodes is provided at the main node.
In this embodiment, the request interceptor is a proxy service deployed at an upper layer of the real service, so that the external request can reach the real service through the interceptor.
In an embodiment, the step S401 of determining, by the request interceptor of the master node, a cooperative service request from a plurality of service requests according to a preset interception rule includes the following steps:
judging whether the service calling parameter of each service request is matched with the white list, the target service type, the request service interface path, the exception path and the service interface request method;
and determining the service request with the service call parameter matched with the white list, the target service type, the request service interface path, the exception path and the service interface request method as a cooperative service request.
In this embodiment, the service request that does not meet the "preset interception rule" is directly forwarded to the target service for execution, and a result is returned. The service request which accords with the preset interception rule is forwarded to the target service to be executed, if the execution is successful, the data of the external request is analyzed, the parameter part called by the interface is analyzed and converted to obtain abstract request description, and then the abstract request description is uploaded to the message middleware, and then the execution result of the service request is returned.
It should be further added that not all service requests of the master node need to be intercepted, and for business needs, only service requests whose "service states between multiple nodes need to be synchronized" need to be intercepted, for example: the service request "modifying the existing equipment on-demand probability index calculation model" is expected to be applied to all service nodes from the aspect of service requirements, so that the request can be considered to be put into a preset interception rule of a request interceptor in terms of service, and the request interceptor can actively intercept the request. The request interceptor can "translate" the service interface call parameters of the intercepted collaborative service request into an "abstract request description" which the request interceptor then uploads to the message middleware, a sequence of "abstract request descriptions" queued in the message middleware, referred to as a "master node request.
The service interface call parameter is a parameter of actual service call, and the service may be http service, for example, "defining a device on-time probability index flow calculation model" may correspond to an http request. The parameters of the request include definition information of a 'index calculation model' (from a requester (body), identity authentication of a requester (from a header), request path '/workflow' (from a full request path)).
Therefore, the cooperative service request can be quickly determined to belong to, and the synchronous execution operation of the subsequent slave nodes is facilitated.
Step S402, when the main node successfully executes the collaborative service request, converting the service calling parameter of the collaborative service request into abstract request description through the request interceptor, and uploading the abstract request description to the request success theme of the message middleware.
In this embodiment, the request interceptor filters the service request according to the configured preset interception rule, converts the filtered collaborative service request into an "abstract request description", and pushes the "abstract request description" to a "request success topic" of the message middleware. The request success theme is a target theme of ' uploading ' abstract request description to message middleware '; because the subject receives requests that have been successfully executed by the master node, the subject is referred to as a "request success subject".
In one embodiment, the abstract request description comprises a request unique ID, a target service type, a target service interface, a query request parameter, a request header parameter, a request body parameter, and an interface request parameter; the service calling parameters comprise a request full path, a request body and a request head.
It should be noted that the service interface call parameter, taking http request as an example, includes 3 parts, a full request path (full request path), a request body (request body), and a request header (header). The service interface calling parameter contains a large amount of redundant information which is irrelevant to the service, for example, a request header (header) contains information such as a request initiator IP and the like, and a full request path (full request path) contains a domain name address of a main node and the like, which are required to be modified according to the context of each slave node or are not required to be stored in the process of requesting each slave node, so that the required part is extracted as an abstract request description before being stored in a 'request success subject', and a request executor of each slave node can reconstruct an 'actual service calling interface parameter' according to the information of the slave node to request.
In particular, the abstract request description may be represented in a variety of formats, and in one embodiment, may be in json format, with the main contents being as shown by way of example:
{
"requestId": "VPTGAWZEOMBUDQJU",
"serviceType": "CMS",
"requestPath": "/workflow",
"requestMethod": "POST",
"requestBody": "",
"requestHeader": {
"Accept": "*/*",
"Accept-Encoding": "gzip",
"Authorization": "eyJhbGciOiJ...",
},
"queryParameters": {}
}
wherein, the requestId is the request unique ID; serviceType, the requested target service type; requestPath: the requested target service interface; queryParameters query request parameters (optional); json format, request header parameters (such as authentication token, etc.); json format, interface request parameter.
It is supplementary to be noted that the message middleware is configured to queue the service requests of the master node according to the operation sequence of the master node, and Kafka is taken as an example in an actual scenario. The determined order is formed by the queuing of the requests, which ensures that the requests are executed in this determined order at each slave node. Abstract request descriptions are extracted by a request interceptor at the primary node and maintained in order through message middleware.
In one embodiment, the step S402 of converting the service call parameter of the collaborative service request into an abstract request description by the request interceptor includes the following steps:
analyzing the request body through the request interceptor to obtain the target service interface, the query request parameter and the interface request parameter;
analyzing the request header through the request interceptor to obtain the unique ID of the request and the request header parameters;
and analyzing the request full path through the request interceptor to obtain the target service type.
Step S403, reading a target abstract request description from the request success theme by a request executor of the slave node, analyzing the target abstract request description to obtain a target service invocation interface parameter, and executing the collaborative service request according to the target service invocation interface parameter.
Step S404, when the request executor of the slave node fails to execute the cooperative service request, sending the request processing state of the slave node to the request failure topic of the message middleware through the request executor.
In this embodiment, the "request failure topic" refers to that after the slave node executes the "abstract request description" from the "request success topic", if the slave node fails to execute the request, the ID in the corresponding "abstract request description" and the slave node ID are uploaded to the "request failure topic".
In this embodiment, the request processing state includes: requesting a unique ID, synchronously executing the ID of the data center of the cooperative service request, synchronously executing the execution result of the cooperative service request by the slave node, and processing a time stamp.
Specifically, the request processing status may be represented by a plurality of formats, and in an embodiment, a json format may be adopted, and the main contents are as follows:
{
"requestId": "VPTGAWZEOMBUDQJU",
"dataCenterId": "dataCenter1",
"requestStatus": “failed”,
“reqeustTime”: “2021-12-25T06:46:44.755Z”
}
wherein, the requestId is the request unique ID; datacentrld: the data center ID that synchronously executes the request; the requestStatus is the request state, wherein the request states are 2, respectively success/failed. Process timestamp.
Step S405, the request executor re-executes the collaborative service request according to the target service call interface parameter until the request executor successfully executes the collaborative service request.
In one embodiment, the method for synchronizing the service states further comprises the following steps:
and when the request executor successfully executes the collaborative service request, sending a state updating message to a request failure subject of the message middleware, and marking a request processing state corresponding to the request failure subject as success.
In an embodiment, marking the request processing status corresponding to the request failure topic as successful includes the following steps:
updating the execution result in the request processing state to be execution success.
It should be noted that there are various services in which the states of all the microservices in each node reach the final consistency required by the service scenario, and the invention is not limited thereto. For example, the index calculation model is a way for defining real-time stream calculation provided by the platform of the internet of things through the API interface. The index calculation model can be updated and activated on the platform through API interface calls. The following describes an example of the synchronization process of the index calculation service with reference to fig. 5. In a group type industrial enterprise, the general requirement is that the real-time modification of the index calculation model can be synchronously updated at all nodes and execute a new real-time calculation flow, namely, a main node at the group side can modify the existing index calculation model; the park slave node needs to update the computation model running on the slave node in real time and execute a new computation flow. For example, the index calculation model may be a device on-time index calculation model. The distribution and the updating of the index calculation model need to ensure the final consistency.
As shown in fig. 5, the master node 43 on the campus side provides an index calculation service, which can be realized by an index calculation model, and the first slave node 41 and the second slave node 42 on the campus side provide an index calculation service simultaneously, which is also realized by the same index calculation model. In one embodiment, the index calculation model needs to be updated in the order of the version edited by the user, and at time t1, the index calculation model is version 1; at time t2, the index calculation model is version 2; ...; at time tn, the index calculation model is version N. In an actual scene, the user slave master node 43 may edit and issue a new index calculation model for multiple times, and issue the new index calculation model to the first slave node 41 and the second slave node 42 of the campus, so that it is ensured that the versions of the index calculation models executed by the first slave node 41 and the second slave node 42 are consistent after synchronization is completed, that is, final consistency, and collaboration and consistency of multi-node master-slave distributed services are achieved.
In one embodiment, the method for synchronizing the service states further comprises the following steps: reading the abstract request description of the request success theme and the request processing state of the request failure theme from the message middleware through a synchronous request monitor of the main node;
and storing the read abstract request description and the request processing state into a database.
Specifically, the database maintains 2 data tables, 1 stores the abstract request description message in the 'request success subject' (the primary key is the requestId: request unique ID); 1 message "request process status" is stored in the "request failure topic" (primary key is requestId; datacentrId as federated primary key).
The synchronization request monitor may improve the following functions: (1) the data in the 'request success theme' and the 'request failure theme' are consumed and written into the corresponding database table, wherein the data in the 'request success theme' can be written into the corresponding database table one by one. For the data of the "subject of request failure", the request retried by each slave node is written in the data table in a manner of updating by the master key. (2) And the system is responsible for providing query capability for the outside, querying whether the current master node and the slave node have the service request of 'request synchronization failure' or not, and displaying the 'abstract request description' corresponding to the failed service request.
In this embodiment, the request status includes "success"/"failure", 2 statuses, and what needs to be paid attention to is a service request for which a synchronous request fails on each node, so that only a request failure topic is maintained to enable each slave node to upload a currently failed request to the request failure topic; meanwhile, each node retries the failed request until the request is successful, and also pushes a status update message to the failed subject of the request after the request is successful, and marks the status of the failed request as successful.
In one embodiment, the method for synchronizing the service states further comprises the following steps:
sending a notification message to a client through the request interceptor, wherein the notification message is a message used for indicating that the main node successfully executes the collaborative service request;
determining, by the synchronization request monitor, an execution success status or an execution failure status of the collaborative service request at the master node and the slave nodes.
The synchronization process of the service states is illustrated below with reference to fig. 6. Referring specifically to fig. 6, the synchronization of the service state may include the steps of:
in step 1, the client 65 sends a plurality of service requests to the master node 66, and the request interceptor 661 of the master node 66 intercepts the cooperative service request according to a preset interception rule.
Step 2, the request interceptor 661 converts the cooperative service request into an abstract request description according to the configured preset interception rule, and sends the abstract request description to the request success topic of the message middleware 64 when the master node 66 successfully executes the cooperative service request.
Step 3.1, the request executer 601 of each slave node 60 reads the data of the successful request topic of the message middleware 64 in sequence, and calls the service corresponding to the slave node 60 after analysis.
Step 3.2, if the request executor 601 of each slave node 60 fails to execute the cooperative service request; and pushing the request processing state to the request failure subject of the message middleware 64, and repeatedly retrying to execute the cooperative service request until the cooperative service request is successfully executed.
In step 4, the synchronous request monitor 662 of the master node 66 reads the "request failure topic/request success topic" of the message middleware 64, and stores the request processing status of the request failure topic and/or the abstract request description of the request success topic in the database 69.
In step 5, the request interceptor 661 of the master node 66 returns the execution result of the cooperative service request executed at the master node 66 to the client 65. In addition, the synchronization request monitor 662 provides an interface to the third party monitoring presence module 610 for the operation and maintenance personnel to monitor the status of the synchronization request between the various nodes.
In this way, the end user knows that the request initiated by the end user has been successfully executed at the master node and is added to the queue of "success subject of request", and after all slave nodes execute the request in sequence, the request action effect will take effect on all slave nodes, and the effect of final consistency of state on the service is achieved.
In the synchronization method for service states provided by this embodiment, a request interceptor of a host node determines a cooperative service request from a plurality of service requests according to a preset interception rule, and intercepts the cooperative service request; when the main node successfully executes the collaborative service request, converting the service calling parameter of the collaborative service request into abstract request description through the request interceptor, and uploading the abstract request description to a request success theme of a message middleware; reading a target abstract request description from the request success theme through a request executor of a slave node, analyzing the target abstract request description to obtain a target service calling interface parameter, and executing the collaborative service request according to the target service calling interface parameter; when the request executor of the slave node fails to execute the cooperative service request, sending the request processing state of the slave node to a request failure subject of the message middleware through the request executor; and re-executing the cooperative service request according to the target service call interface parameter by the request executor until the request executor successfully executes the cooperative service request. Therefore, assistance and synchronization of service calling among a plurality of micro service nodes are realized, service states and data which are only needed by cooperative service of the micro service nodes can be synchronized according to preset interception rules configured by service rules so as to ensure the autonomy of each service node, and in a master-slave multi-node service system, the final consistency of the service states among the master node and the slave node is ensured by the abstract description and sequencing of requests of the nodes, so that service cooperation is completed.
Example 2
In addition, the embodiment of the disclosure provides a service state synchronization device.
Specifically, referring to fig. 7, the service state synchronization apparatus 700 includes:
the intercepting module 701 is configured to determine a cooperative service request from a plurality of service requests according to a preset intercepting rule by a request interceptor of the master node, and intercept the cooperative service request;
a conversion module 702, configured to, when the master node successfully executes the collaborative service request, convert the service invocation parameter of the collaborative service request into an abstract request description by the request interceptor, and upload the abstract request description to a request success theme of a message middleware;
an analyzing module 703, configured to read a target abstract request description from the request success topic by a request executor of a slave node, analyze the target abstract request description to obtain a target service invocation interface parameter, and execute the collaborative service request according to the target service invocation interface parameter;
a sending module 704, configured to send, by the request executor, the request processing status of the slave node to a request failure topic of the message middleware when the request executor of the slave node fails to execute the collaborative service request;
the executing module 705 is configured to re-execute the collaborative service request according to the target service call interface parameter by the request executor until the request executor successfully executes the collaborative service request.
In one embodiment, the device 700 for synchronizing service states further includes:
and the marking module is used for sending a state updating message to the request failure theme of the message middleware when the request executor successfully executes the collaborative service request, and marking the request processing state corresponding to the request failure theme as success.
In one embodiment, the preset interception rule includes a white list, a target service type, a request service interface path, an exception path, and a service interface request method;
the intercepting module 701 is further configured to determine whether a service invocation parameter of each service request matches the white list, the target service type, the request service interface path, the exception path, and the service interface request method;
and determining the service request with the service call parameter matched with the white list, the target service type, the request service interface path, the exception path and the service interface request method as a cooperative service request.
In one embodiment, the abstract request description comprises a request unique ID, a target service type, a target service interface, a query request parameter, a request header parameter, a request body parameter, and an interface request parameter;
the service calling parameters comprise a request full path, a request body and a request head;
the conversion module 702 is further configured to analyze the request object through the request interceptor to obtain the target service interface, the query request parameter, and the interface request parameter;
analyzing the request header through the request interceptor to obtain the unique ID of the request and the request header parameters;
and analyzing the request full path through the request interceptor to obtain the target service type.
In one embodiment, the request processing state includes: requesting a unique ID, synchronously executing the ID of the data center of the cooperative service request, synchronously executing the execution result of the cooperative service request by a slave node, and processing a timestamp;
the marking module is further configured to update the execution result in the request processing state to be successful in execution.
In one embodiment, the synchronization apparatus 700 for service status comprises:
a reading module, configured to read, by a synchronization request monitor of the master node, an abstract request description of the request success topic and a request processing state of the request failure topic from the message middleware;
and storing the read abstract request description and the request processing state into a database.
In one embodiment, the synchronization apparatus 700 for service status comprises:
a processing module, configured to send a notification message to a client through the request interceptor, where the notification message is a message used to indicate that the host node successfully executes the collaborative service request;
determining, by the synchronization request monitor, an execution success status or an execution failure status of the collaborative service request at the master node and the slave nodes.
The synchronization apparatus for service states provided in this embodiment can implement the steps of the synchronization method for service states provided in embodiment 1, and is not described herein again to avoid repetition.
In the synchronization apparatus for service status provided in this embodiment, a request interceptor of the master node determines a cooperative service request from a plurality of service requests according to a preset interception rule, and intercepts the cooperative service request; when the main node successfully executes the collaborative service request, converting the service calling parameter of the collaborative service request into abstract request description through the request interceptor, and uploading the abstract request description to a request success theme of a message middleware; reading a target abstract request description from the request success theme through a request executor of a slave node, analyzing the target abstract request description to obtain a target service calling interface parameter, and executing the collaborative service request according to the target service calling interface parameter; when the request executor of the slave node fails to execute the cooperative service request, sending the request processing state of the slave node to a request failure subject of the message middleware through the request executor; and re-executing the cooperative service request according to the target service call interface parameter by the request executor until the request executor successfully executes the cooperative service request. Therefore, assistance and synchronization of service calling among a plurality of micro service nodes are realized, service states and data which are only needed by cooperative service of the micro service nodes can be synchronized according to preset interception rules configured by service rules so as to ensure the autonomy of each service node, and in a master-slave multi-node service system, the final consistency of the service states among the master node and the slave node is ensured by the abstract description and sequencing of requests of the nodes, so that service cooperation is completed.
Example 3
Furthermore, an embodiment of the present disclosure provides a server, including a memory and a processor, where the memory stores a computer program, and the computer program, when running on the processor, executes the synchronization method for service states provided in the above method embodiment 1.
The server provided in this embodiment may implement the steps of the method for synchronizing the service states provided in embodiment 1, and details are not described herein for avoiding repetition.
Example 4
Further, the disclosed embodiments provide a computer-readable storage medium storing a computer program that, when run on a processor, performs the synchronization method of the service state provided in embodiment 1.
The computer-readable storage medium provided in this embodiment may implement the steps of the service state synchronization method provided in embodiment 1, and is not described herein again to avoid repetition.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or terminal. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or terminal that comprises the element.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present application.
While the present embodiments have been described with reference to the accompanying drawings, it is to be understood that the invention is not limited to the precise embodiments described above, which are meant to be illustrative and not restrictive, and that various changes may be made therein by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (10)
1. A method for synchronizing service states, the method comprising:
determining a cooperative service request from a plurality of service requests according to a preset interception rule through a request interceptor of a main node, and intercepting the cooperative service request;
when the main node successfully executes the collaborative service request, converting the service calling parameter of the collaborative service request into abstract request description through the request interceptor, and uploading the abstract request description to a request success theme of a message middleware;
reading a target abstract request description from the request success theme through a request executor of a slave node, analyzing the target abstract request description to obtain a target service calling interface parameter, and executing the collaborative service request according to the target service calling interface parameter;
when the request executor of the slave node fails to execute the cooperative service request, sending the request processing state of the slave node to a request failure subject of the message middleware through the request executor;
and re-executing the cooperative service request according to the target service call interface parameter by the request executor until the request executor successfully executes the cooperative service request.
2. The method for synchronizing service states according to claim 1, further comprising:
and when the request executor successfully executes the collaborative service request, sending a state updating message to a request failure subject of the message middleware, and marking a request processing state corresponding to the request failure subject as success.
3. The method according to claim 1, wherein the preset interception rule comprises a white list, a target service type, a request service interface path, an exception path, a service interface request method;
determining, by the request interceptor of the master node, a cooperative service request from the plurality of service requests according to a preset interception rule, includes:
judging whether the service calling parameter of each service request is matched with the white list, the target service type, the request service interface path, the exception path and the service interface request method;
and determining the service request with the service call parameter matched with the white list, the target service type, the request service interface path, the exception path and the service interface request method as a cooperative service request.
4. The method for synchronizing service states according to claim 1, wherein the abstract request description comprises a request unique ID, a target service type, a target service interface, a query request parameter, a request header parameter, a request body parameter, an interface request parameter;
the service calling parameters comprise a request full path, a request body and a request head;
converting, by the request interceptor, the service invocation parameter of the collaborative service request into an abstract request description, including:
analyzing the request body through the request interceptor to obtain the target service interface, the query request parameter and the interface request parameter;
analyzing the request header through the request interceptor to obtain the unique ID of the request and the request header parameters;
and analyzing the request full path through the request interceptor to obtain the target service type.
5. The method of synchronizing service states according to claim 2, wherein the request processing state comprises: requesting a unique ID, synchronously executing the ID of the data center of the cooperative service request, synchronously executing the execution result of the cooperative service request by a slave node, processing a timestamp, and marking the request processing state corresponding to the request failure subject as success, including:
updating the execution result in the request processing state to be execution success.
6. The method for synchronizing service states according to claim 1, further comprising:
reading the abstract request description of the request success theme and the request processing state of the request failure theme from the message middleware through a synchronous request monitor of the main node;
and storing the read abstract request description and the request processing state into a database.
7. The method for synchronizing service states of claim 6, further comprising:
sending a notification message to a client through the request interceptor, wherein the notification message is a message used for indicating that the main node successfully executes the collaborative service request;
determining, by the synchronization request monitor, an execution success status or an execution failure status of the collaborative service request at the master node and the slave nodes.
8. An apparatus for synchronizing service states, the apparatus comprising:
the system comprises an interception module, a service request processing module and a service request processing module, wherein the interception module is used for determining a cooperative service request from a plurality of service requests according to a preset interception rule through a request interceptor of a main node and intercepting the cooperative service request;
a conversion module, configured to, when the master node successfully executes the collaborative service request, convert a service invocation parameter of the collaborative service request into an abstract request description by the request interceptor, and upload the abstract request description to a request success theme of a message middleware;
the analysis module is used for reading a target abstract request description from the request success theme through a request executor of a slave node, analyzing the target abstract request description to obtain a target service calling interface parameter, and executing the collaborative service request according to the target service calling interface parameter;
a sending module, configured to send, by the request executor, a request processing state of the slave node to a request failure topic of the message middleware when the request executor of the slave node fails to execute the collaborative service request;
and the execution module is used for re-executing the cooperative service request according to the target service calling interface parameter through the request executor until the request executor successfully executes the cooperative service request.
9. A server, characterized in that it comprises a memory and a processor, said memory storing a computer program which, when run by said processor, performs the synchronization method of the service states of any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that it stores a computer program which, when run on a processor, performs the method of synchronization of service states of any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210117635.4A CN114172821B (en) | 2022-02-08 | 2022-02-08 | Service state synchronization method and device and server |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210117635.4A CN114172821B (en) | 2022-02-08 | 2022-02-08 | Service state synchronization method and device and server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114172821A true CN114172821A (en) | 2022-03-11 |
| CN114172821B CN114172821B (en) | 2022-05-24 |
Family
ID=80489532
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210117635.4A Active CN114172821B (en) | 2022-02-08 | 2022-02-08 | Service state synchronization method and device and server |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114172821B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150039734A1 (en) * | 2013-08-05 | 2015-02-05 | The Trustees Of The University Of Pennsylvania | Methods, systems, and computer readable media for enabling real-time guarantees in publish-subscribe middleware using dynamically reconfigurable networks |
| CN111258723A (en) * | 2019-12-05 | 2020-06-09 | 东软集团股份有限公司 | Transaction processing method, device, system, medium and equipment of distributed system |
| CN113505012A (en) * | 2021-09-13 | 2021-10-15 | 北京宇信科技集团股份有限公司 | Message queue processing method, medium, device and system |
| CN114004701A (en) * | 2021-11-05 | 2022-02-01 | 中国工商银行股份有限公司 | Method and device for generating transaction result, electronic equipment and storage medium |
-
2022
- 2022-02-08 CN CN202210117635.4A patent/CN114172821B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150039734A1 (en) * | 2013-08-05 | 2015-02-05 | The Trustees Of The University Of Pennsylvania | Methods, systems, and computer readable media for enabling real-time guarantees in publish-subscribe middleware using dynamically reconfigurable networks |
| CN111258723A (en) * | 2019-12-05 | 2020-06-09 | 东软集团股份有限公司 | Transaction processing method, device, system, medium and equipment of distributed system |
| CN113505012A (en) * | 2021-09-13 | 2021-10-15 | 北京宇信科技集团股份有限公司 | Message queue processing method, medium, device and system |
| CN114004701A (en) * | 2021-11-05 | 2022-02-01 | 中国工商银行股份有限公司 | Method and device for generating transaction result, electronic equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 徐进等: "基于消息通信的分布式系统最终一致性平台", 《计算机应用》 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114172821B (en) | 2022-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103460203B (en) | cluster unique identifier | |
| US6665674B1 (en) | Framework for open directory operation extensibility | |
| CN111078504A (en) | Distributed call chain tracking method and device, computer equipment and storage medium | |
| CN102880475A (en) | Real-time event handling system and method based on cloud computing in computer software system | |
| US9152441B2 (en) | Systems and methods involving virtual machine host isolation over a network via a federated downstream cluster | |
| CN112698838B (en) | Multi-cloud container deployment system and container deployment method thereof | |
| CN111338893A (en) | Process log processing method and device, computer equipment and storage medium | |
| CN113691635B (en) | Method and device for calling microservice, electronic equipment and readable storage medium | |
| CN110334147A (en) | A kind of method of data synchronization and device | |
| CN109451078A (en) | Transaction methods and device under a kind of distributed structure/architecture | |
| CN114448686B (en) | Cross-network communication device and method based on micro-service | |
| CN104270432B (en) | Based on drilling well industry Real-time Data Service system and data interactive method | |
| CN114172821B (en) | Service state synchronization method and device and server | |
| CN111399749B (en) | Data processing system and method | |
| CN115632815A (en) | Data updating method and device, electronic equipment and storage medium | |
| CN113055461B (en) | ZooKeeper-based unmanned cluster distributed cooperative command control method | |
| US11582345B2 (en) | Context data management interface for contact center | |
| CN113032477B (en) | Long-distance data synchronization method and device based on GTID and computing equipment | |
| CN114968617A (en) | API conversion system, access request processing method thereof, electronic device and medium | |
| US7912922B2 (en) | Globally unique instance identification | |
| CN112787868A (en) | Information synchronization method and device | |
| CN107528797B (en) | Data processing method, device and system | |
| CN109784709A (en) | IT application in enterprises collaboration applications method and system | |
| CN116708595A (en) | Method, device, equipment and storage medium for constructing protocol chain | |
| CN117632445B (en) | Request processing method and device, task execution method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |