CN113010330A - Method and terminal for retrying micro-service request - Google Patents
Method and terminal for retrying micro-service request Download PDFInfo
- Publication number
- CN113010330A CN113010330A CN202110233846.XA CN202110233846A CN113010330A CN 113010330 A CN113010330 A CN 113010330A CN 202110233846 A CN202110233846 A CN 202110233846A CN 113010330 A CN113010330 A CN 113010330A
- Authority
- CN
- China
- Prior art keywords
- calling
- component
- retry
- call
- called
- 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.)
- Withdrawn
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Retry When Errors Occur (AREA)
Abstract
A method and terminal for micro-service request retry are disclosed, wherein a call chain set is obtained, the call chain set comprises a plurality of call chains, and each call chain is composed of more than one component arranged according to a call sequence; receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times; judging whether the calling failure times are smaller than a preset maximum retry time or not, and if not, acquiring a first calling chain including the first calling component ID and a first called component ID in a calling chain set; returning a retry stopping identifier to a second calling component which is positioned in the first calling chain and is positioned in front of the first calling component corresponding to the calling component ID; under the condition that the called component is abnormally called but the calling component can be normally called, the upstream component of the calling component can not continuously call the calling component to cause repeated accumulation of requests and further cause system crash, and system blockage caused by retry of component nesting requests is avoided.
Description
Technical Field
The present invention relates to the field of micro services, and in particular, to a method and a terminal for micro service request retry.
Background
Today, the mobile internet is developed vigorously, and various system applications are developed, and many of the system applications have various data interactions with other system applications. The data interaction mode is various, data access is carried out through an interface, interaction access is directly carried out through a database, message communication is carried out through MQ, and the like.
The most common mode is to use http protocol or RPC or other modes to call an interface to perform data interaction. By using the method, multi-system data interaction can be rapidly carried out, and the efficiency is improved. However, the use of such an interface calling method has a problem of call failure. At this time, the network may fail, the opposite system may fail due to slow response, the timeout time of the network may be set too short, but the interface processing time is long, which may cause timeout failure, and the like. In this case, a general system sets a retry request policy according to its own service characteristics, and the simplest is to repeat the retry request policy. Because the existing service end adopts a micro-service architecture mode, a plurality of components are arranged on the upstream and the downstream to provide services, when a certain upstream component 1 calls a component 2, and the component 2 calls a component 3, and the component 2 repeatedly calls the component 3 for a plurality of times and then returns call failure information to the component 1, at the moment, the component 1 also executes the repeated calling of the component 2, and under the scene, in fact, the component 2 calls a component 3 interface m x n times, the request quantity of the downstream component is suddenly increased, so that the slow response or downtime of the component is caused, and finally the whole system is caused to be unavailable.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: a method and a terminal for micro-service request retry are provided to avoid system deadlock caused by retry.
In order to solve the technical problems, the invention adopts a technical scheme that:
a method of microservice request retry, comprising the steps of:
s1, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence;
s2, receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times;
s3, judging whether the calling failure times are smaller than the preset maximum retry times, if not, acquiring a first calling chain including the first calling component ID and the first called component ID in the calling chain set;
and S4, returning a stop retry identifier to a second calling component of the first calling chain, wherein the calling sequence is positioned before the first calling component corresponding to the calling component ID.
In order to solve the technical problem, the invention adopts another technical scheme as follows:
a terminal for micro-service request retries, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:
s1, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence;
s2, receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times;
s3, judging whether the calling failure times are smaller than the preset maximum retry times, if not, acquiring a first calling chain including the first calling component ID and the first called component ID in the calling chain set;
and S4, returning a stop retry identifier to a second calling component of the first calling chain, wherein the calling sequence is positioned before the first calling component corresponding to the calling component ID.
The invention has the beneficial effects that: the method includes the steps that calling relations among all components are stored to form a calling chain set, when a calling failure message is received and the calling failure times of calling the called component by the calling component exceed the preset maximum retry times, a retry stopping identification is directly sent to a component located at the upstream of the calling component in the calling chain including the calling component and the called component, and under the condition that the called component is abnormally called and the calling component can be normally called, the upstream component of the calling component can not continuously call the calling component to cause repeated accumulation of requests and further cause system crash, and system blocking caused by retry of component nesting requests is avoided.
Drawings
FIG. 1 is a flowchart illustrating steps of a method for micro-service request retry according to an embodiment of the present invention;
fig. 2 is a schematic structural diagram of a terminal for micro service request retry according to an embodiment of the present invention;
description of reference numerals:
1. a terminal for micro-service request retry; 2. a processor; 3. a memory.
Detailed Description
In order to explain technical contents, achieved objects, and effects of the present invention in detail, the following description is made with reference to the accompanying drawings in combination with the embodiments.
Referring to fig. 1, a method for micro-service request retry includes the steps of:
s1, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence;
s2, receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times;
s3, judging whether the calling failure times are smaller than the preset maximum retry times, if not, acquiring a first calling chain including the first calling component ID and the first called component ID in the calling chain set;
and S4, returning a stop retry identifier to a second calling component of the first calling chain, wherein the calling sequence is positioned before the first calling component corresponding to the calling component ID.
From the above description, the beneficial effects of the present invention are: the method includes the steps that calling relations among all components are stored to form a calling chain set, when a calling failure message is received and the calling failure times of calling the called component by the calling component exceed the preset maximum retry times, a retry stopping identification is directly sent to a component located at the upstream of the calling component in the calling chain including the calling component and the called component, and under the condition that the called component is abnormally called and the calling component can be normally called, the upstream component of the calling component can not continuously call the calling component to cause repeated accumulation of requests and further cause system crash, and system blocking caused by retry of component nesting requests is avoided.
Further, the S1 is preceded by:
obtaining a retry strategy, wherein the retry strategy comprises a calling component ID, a called component ID, a maximum retry number and a retry identifier;
the step of determining whether the call failure number is smaller than a preset maximum retry number in S3 is specifically:
acquiring a first retry strategy corresponding to the first calling component ID and the first called component ID;
acquiring a first maximum retry number in the first retry strategy;
and judging whether the calling failure times are less than the first maximum retry times or not.
According to the above description, the retry strategy is configured for the calls between different components individually, and the call relation between two components can be controlled individually, so that the retry strategy is more flexible.
Further, the S4 specifically includes:
acquiring second calling failure information with a second called component ID being the same as the first calling component ID, and acquiring a second calling component ID in the second calling failure information;
and returning the retry stopping identification to the second calling component corresponding to the second calling component ID.
As can be seen from the above description, the second calling component calls the first calling component, and if the number of times of failure of the first calling component to call the first called component reaches the upper limit, the retry stop flag is directly returned to the second calling component, and the second calling component does not re-execute the operation of calling the first calling component, thereby avoiding that the first calling component repeatedly requests to call the first called component again, and avoiding the repetition of useless retry.
Further, the step S4 is followed by:
receiving a component calling request, wherein the component calling request comprises a third calling component ID and a third passive component ID;
and if the third called component ID is the same as the first calling component ID, returning a stop retry identifier.
As can be seen from the above description, in the preset time period after the first stop retry flag is sent out, if a call request to the first calling component is received, the stop retry flag is also directly returned, and the call request is not sent to the first called component any more, so that the number of times of useless retries is further reduced.
Further, the retry flag includes 0 and 1, where 0 represents stop retry flag and 1 represents continue retry flag.
As can be seen from the above description, setting simple 0 and 1 identifies whether retry is required to be continued, the occupied bytes in message transmission are small, and the performance of hardware is less affected.
A terminal for micro-service request retries, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:
s1, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence;
s2, receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times;
s3, judging whether the calling failure times are smaller than the preset maximum retry times, if not, acquiring a first calling chain including the first calling component ID and the first called component ID in the calling chain set;
and S4, returning a stop retry identifier to a second calling component of the first calling chain, wherein the calling sequence is positioned before the first calling component corresponding to the calling component ID.
The invention has the beneficial effects that: the method includes the steps that calling relations among all components are stored to form a calling chain set, when a calling failure message is received and the calling failure times of calling the called component by the calling component exceed the preset maximum retry times, a retry stopping identification is directly sent to a component located at the upstream of the calling component in the calling chain including the calling component and the called component, and under the condition that the called component is abnormally called and the calling component can be normally called, the upstream component of the calling component can not continuously call the calling component to cause repeated accumulation of requests and further cause system crash, and system blocking caused by retry of component nesting requests is avoided.
Further, before the processor executes the computer program implementation S1, the method further includes:
obtaining a retry strategy, wherein the retry strategy comprises a calling component ID, a called component ID, a maximum retry number and a retry identifier;
the step of determining whether the call failure number is smaller than a preset maximum retry number in S3 is specifically:
acquiring a first retry strategy corresponding to the first calling component ID and the first called component ID;
acquiring a first maximum retry number in the first retry strategy;
and judging whether the calling failure times are less than the first maximum retry times or not.
According to the above description, the retry strategy is configured for the calls between different components individually, and the call relation between two components can be controlled individually, so that the retry strategy is more flexible.
Further, the S4 specifically includes:
acquiring second calling failure information with a second called component ID being the same as the first calling component ID, and acquiring a second calling component ID in the second calling failure information;
and returning the retry stopping identification to the second calling component corresponding to the second calling component ID.
As can be seen from the above description, the second calling component calls the first calling component, and if the number of times of failure of the first calling component to call the first called component reaches the upper limit, the retry stop flag is directly returned to the second calling component, and the second calling component does not re-execute the operation of calling the first calling component, thereby avoiding that the first calling component repeatedly requests to call the first called component again, and avoiding the repetition of useless retry.
Further, after the processor executes the computer program to implement S4, the method further includes:
receiving a component calling request, wherein the component calling request comprises a third calling component ID and a third passive component ID;
and if the third called component ID is the same as the first calling component ID, returning a stop retry identifier.
As can be seen from the above description, in the preset time period after the first stop retry flag is sent out, if a call request to the first calling component is received, the stop retry flag is also directly returned, and the call request is not sent to the first called component any more, so that the number of times of useless retries is further reduced.
Further, the retry flag includes 0 and 1, where 0 represents stop retry flag and 1 represents continue retry flag.
As can be seen from the above description, setting simple 0 and 1 identifies whether retry is required to be continued, the occupied bytes in message transmission are small, and the performance of hardware is less affected.
Referring to fig. 1, a first embodiment of the present invention is:
a method of microservice request retry, comprising the steps of:
s1, obtaining a retry strategy, wherein the retry strategy comprises a calling component ID, a called component ID, a maximum retry number and a retry identifier;
in an alternative embodiment, the retry flag includes 0 and 1, where 0 indicates a stop retry flag and 1 indicates a continue retry flag.
S2, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence;
s3, receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times;
the specific step of judging whether the call failure times are smaller than a preset maximum retry time is as follows:
acquiring a first retry strategy corresponding to the first calling component ID and the first called component ID; acquiring a first maximum retry number in the first retry strategy; judging whether the calling failure times are smaller than the first maximum retry times or not;
s4, determining whether the number of call failures is less than a preset maximum retry number, and if not, acquiring a first call chain including the first call component ID and the first called component ID in the call chain set, specifically:
acquiring second calling failure information with a second called component ID being the same as the first calling component ID, and acquiring a second calling component ID in the second calling failure information; returning a retry stopping identifier to a second calling component corresponding to the second calling component ID;
s5, returning a retry stopping identifier to a second calling component of which the calling sequence is positioned before the first calling component corresponding to the calling component ID in the first calling chain;
in an alternative embodiment, the retry identification is returned at the same time as the exception code is returned;
s6, receiving a component calling request, wherein the component calling request comprises a third calling component ID and a third passive component ID;
if the ID of the third called component is the same as the ID of the first calling component and the first calling component needs to call the first called component to realize the component calling request, returning a retry stopping identifier;
in an optional embodiment, the method further comprises: setting a retry common component, wherein calling requests among the components are processed by the retry common component, if the first calling component calls the first called component, the operation of calling the interface of the first called component is executed through an interface calling method provided by the retry common component;
the retry common component internally comprises an http thread pool, and externally exposes a common http request method, namely the interface calling method.
The second embodiment of the invention is as follows:
the method for retrying the micro-service request is applied to an actual scene:
s1, obtaining a retry strategy configured by a management background through a Redis cache server, wherein the retry strategy comprises an application ID, a calling component ID, a called component ID, a maximum retry number and a retry identifier;
such as (1) X application, component A, component B, component 3 and 0 or 1, (2) X application, component B, component C, component 3 and 0 or 1;
the operations of adding, deleting and modifying the retry strategy in the management background are synchronized to a Redis cache server, and the data in the Redis cache server is kept consistent with the data in the management background database;
s2, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence; if the first call chain component → B component → C component and the second call chain component → F component → C component are included in the call chain set;
when the component is started, a corresponding retry strategy is loaded from the Redis cache server to a local memory;
s3, receiving first call failure information: b, acquiring retry strategies corresponding to the ID of the component B and the ID of the component C, wherein the number of call failures 3 is equal to the maximum number of retry strategies 3; at the moment, second calling failure information A component ID, B component ID and calling failure times 1 are obtained, and when an abnormal code is returned to the A component, a retry stopping identifier is returned at the same time, so that the A component does not call the B component any more;
although the failure frequency of calling the B component by the component A does not reach the maximum retry frequency set in the retry strategy (i), the component B is not continuously called, and useless retry frequency is reduced;
and S4, in a preset time period after the first retry stopping identification is sent out, if a component calling request for calling the component B is received and the component B executes the calling component C required by the request, directly returning the retry stopping identification.
Referring to fig. 2, the second embodiment of the present invention is:
a terminal 1 for micro-service request retry, comprising a processor 2, a memory 3 and a computer program stored on the memory 3 and operable on the processor 2, wherein the processor 2 implements the steps of the first embodiment or the second embodiment when executing the computer program;
in an alternative embodiment, a terminal for micro-service request retries is a pre-defined common component.
In summary, the present invention provides a method and a terminal for retrying microservice request, which store the request sequence relationship among components, when the retry number of the request of a calling component to a called component reaches a preset maximum number, send a retry stop identifier to the component at the upper stage of the calling component, so that the upstream component does not repeatedly call a call change component, avoid repeated retrying of the called component under the condition that the access condition of the called component is known to be different, by setting the retry common component to uniformly process the call request among the components, each component which needs retry control can select whether to access by itself, that is, all places which need to call other components use the retry common component to perform interface call, provide interface call inside the common component, retry policy acquisition, execute operations such as interface retry call, and the like, meanwhile, the retry strategy can be dynamically configured by the background server side and informs the corresponding component, the retry strategy is realized by the public component, the retry strategy can be dynamically loaded, meanwhile, the request storm of the upstream component to the downstream component is controlled by adopting a uniform return code under an abnormal scene, and then only when which component fails to request the downstream component, the retry request is carried out on the component, repeated requests for many times are not caused, and the risk of slow response or downtime of the downstream component is reduced.
The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all equivalent changes made by using the contents of the present specification and the drawings, or applied directly or indirectly to the related technical fields, are included in the scope of the present invention.
Claims (10)
1. A method for microservice request retry, comprising the steps of:
s1, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence;
s2, receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times;
s3, judging whether the calling failure times are smaller than the preset maximum retry times, if not, acquiring a first calling chain including the first calling component ID and the first called component ID in the calling chain set;
and S4, returning a stop retry identifier to a second calling component of the first calling chain, wherein the calling sequence is positioned before the first calling component corresponding to the calling component ID.
2. The method of claim 1, wherein the step S1 is preceded by the step of:
obtaining a retry strategy, wherein the retry strategy comprises a calling component ID, a called component ID, a maximum retry number and a retry identifier;
the step of determining whether the call failure number is smaller than a preset maximum retry number in S3 is specifically:
acquiring a first retry strategy corresponding to the first calling component ID and the first called component ID;
acquiring a first maximum retry number in the first retry strategy;
and judging whether the calling failure times are less than the first maximum retry times or not.
3. The method of claim 1, wherein the S4 is specifically configured to:
acquiring second calling failure information with a second called component ID being the same as the first calling component ID, and acquiring a second calling component ID in the second calling failure information;
and returning the retry stopping identification to the second calling component corresponding to the second calling component ID.
4. The method of claim 3, wherein the step S4 is followed by the step of:
receiving a component calling request, wherein the component calling request comprises a third calling component ID and a third called component ID;
and if the third called component ID is the same as the first calling component ID, returning a stop retry identifier.
5. The method of claim 1, wherein the retry flag comprises 0 and 1, wherein 0 represents stop retry flag and 1 represents continue retry flag.
6. A terminal for micro-service request retry, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:
s1, obtaining a call chain set, wherein the call chain set comprises a plurality of call chains, and each call chain is formed by arranging more than one component according to a call sequence;
s2, receiving first calling failure information, wherein the first calling failure information comprises a first calling component ID, a first called component ID and calling failure times;
s3, judging whether the calling failure times are smaller than the preset maximum retry times, if not, acquiring a first calling chain including the first calling component ID and the first called component ID in the calling chain set;
and S4, returning a stop retry identifier to a second calling component of the first calling chain, wherein the calling sequence is positioned before the first calling component corresponding to the calling component ID.
7. The terminal of claim 6, wherein the processor, before executing the computer program implementing S1, further comprises:
obtaining a retry strategy, wherein the retry strategy comprises a calling component ID, a called component ID, a maximum retry number and a retry identifier;
the step of determining whether the call failure number is smaller than a preset maximum retry number in S3 is specifically:
acquiring a first retry strategy corresponding to the first calling component ID and the first called component ID;
acquiring a first maximum retry number in the first retry strategy;
and judging whether the calling failure times are less than the first maximum retry times or not.
8. The terminal of claim 6, wherein the S4 is specifically configured to:
acquiring second calling failure information with a second called component ID being the same as the first calling component ID, and acquiring a second calling component ID in the second calling failure information;
and returning the retry stopping identification to the second calling component corresponding to the second calling component ID.
9. The terminal of claim 8, wherein the processor, after executing the computer program implementation S4, further comprises:
receiving a component calling request, wherein the component calling request comprises a third calling component ID and a third called component ID;
and if the third called component ID is the same as the first calling component ID, returning a stop retry identifier.
10. The terminal of claim 6, wherein the retry flag comprises 0 and 1, where 0 indicates stop retry flag and 1 indicates continue retry flag.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110233846.XA CN113010330A (en) | 2021-03-03 | 2021-03-03 | Method and terminal for retrying micro-service request |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110233846.XA CN113010330A (en) | 2021-03-03 | 2021-03-03 | Method and terminal for retrying micro-service request |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113010330A true CN113010330A (en) | 2021-06-22 |
Family
ID=76403392
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110233846.XA Withdrawn CN113010330A (en) | 2021-03-03 | 2021-03-03 | Method and terminal for retrying micro-service request |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113010330A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113360321A (en) * | 2021-06-23 | 2021-09-07 | 平安普惠企业管理有限公司 | Micro-service retry calling method and device, electronic equipment and storage medium |
| CN114449034A (en) * | 2022-01-28 | 2022-05-06 | 湖南快乐阳光互动娱乐传媒有限公司 | Service calling system and method |
-
2021
- 2021-03-03 CN CN202110233846.XA patent/CN113010330A/en not_active Withdrawn
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113360321A (en) * | 2021-06-23 | 2021-09-07 | 平安普惠企业管理有限公司 | Micro-service retry calling method and device, electronic equipment and storage medium |
| CN113360321B (en) * | 2021-06-23 | 2023-02-07 | 平安普惠企业管理有限公司 | Micro-service retry calling method and device, electronic equipment and storage medium |
| CN114449034A (en) * | 2022-01-28 | 2022-05-06 | 湖南快乐阳光互动娱乐传媒有限公司 | Service calling system and method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111277639B (en) | Method and device for maintaining data consistency | |
| CN113010330A (en) | Method and terminal for retrying micro-service request | |
| CN111258723B (en) | Transaction processing method, device, system, medium and equipment of distributed system | |
| CN111897633A (en) | Task processing method and device | |
| CN107645476B (en) | Request processing method and device | |
| US20030158883A1 (en) | Message processing | |
| CN111552577B (en) | Method for preventing invalid request from occurring and storage medium | |
| US8082339B2 (en) | Electronic device network having graceful denial of service | |
| CN111984388A (en) | Method, device and medium for coordinating data consistency in distributed transactions of cloud environment | |
| CN111124717A (en) | Message delivery method, system and computer storage medium | |
| CN111447262A (en) | Request sending method, client and storage medium | |
| CN117032987A (en) | Distributed task scheduling method, system, equipment and computer readable medium | |
| CN112637121B (en) | Data port updating method and device, electronic equipment and readable storage medium | |
| CN106294408B (en) | The method and apparatus that the Asynchronous Request of dynamic web page is monitored | |
| CN110704208B (en) | Message processing method for multiple systems, server and storage medium | |
| CN111782364A (en) | Service calling method and device, electronic equipment and storage medium | |
| CN115037606B (en) | Network data acquisition method and terminal | |
| CN110716972A (en) | Method and device for processing error of high-frequency calling external interface | |
| CN113220491B (en) | Remote call self-adaptive load balancing method, device and system and computer equipment | |
| CN111078311A (en) | Middleware control operation method and system | |
| CN111654480B (en) | RPC connection establishment method, device and storage medium | |
| CN116643733B (en) | Service processing system and method | |
| CN113783908B (en) | Service calling method, device, equipment and storage medium | |
| CN114090194A (en) | Method and device for realizing distributed transaction consistency | |
| CN117675728A (en) | Service request processing method, device, electronic equipment and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20210622 |
|
| WW01 | Invention patent application withdrawn after publication |