CN110933075B - Service calling method and device, electronic equipment and storage medium - Google Patents
Service calling method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN110933075B CN110933075B CN201911191980.7A CN201911191980A CN110933075B CN 110933075 B CN110933075 B CN 110933075B CN 201911191980 A CN201911191980 A CN 201911191980A CN 110933075 B CN110933075 B CN 110933075B
- Authority
- CN
- China
- Prior art keywords
- service
- module
- calling
- data
- call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- 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/133—Protocols for remote procedure calls [RPC]
-
- 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/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
Abstract
The embodiment of the invention discloses a method, a device, electronic equipment and a storage medium for calling a service, which are applied to a service grid, wherein the method comprises the following steps: when a service calling request aiming at a target service is detected, service calling data are obtained, wherein the service calling data comprise first calling data and second calling data; sending a service address acquisition request to the first module, wherein the service address acquisition request comprises the first calling data so that the first module acquires the address of the target service; receiving the address of the target service returned by the first module; initiating a remote procedure call to the target service through the second module according to the address of the target service and the second call data; and receiving a call return value returned by the target service. The service basic function is sunk to the first module and is stripped from the remote process calling framework, so that the decoupling of service logic and service management is realized, the memory consumption is reduced, and the time delay of single service calling is shortened.
Description
Technical Field
The present invention relates to the field of multimedia data technologies, and in particular, to a service invocation method, a service invocation apparatus, an electronic device, and a storage medium.
Background
SideCar module (SideCar) is a typical implementation of a Service Mesh that allows users to add many functions to an application without the configuration and code of additional third party components. In the current implementation scheme, the SideCar takes over all traffic (including all incoming traffic and all outgoing traffic) of the application program, which causes that data to arrive at the application program needs to be copied between a user mode and a kernel mode twice more than the original data, on one hand, more Central Processing Units (CPUs) are consumed, on the other hand, the time delay of single service call is increased, and the SideCar becomes a bottleneck of performance.
Disclosure of Invention
The technical problem to be solved by the embodiments of the present invention is to provide a service invocation method, device, electronic device, and storage medium, in which service basic functions are sunk to a sidecar module and stripped from a remote procedure invocation framework, so that decoupling of service logic and service management is realized, memory consumption is reduced, and time delay of single service invocation is shortened.
In one aspect, an embodiment of the present invention provides a service invocation method, where the method is applied in a service grid, where the service grid includes a first module and a second module; wherein, the first module is a sidecar module; the second module is a remote procedure calling module, and the service calling method comprises the following steps:
when a service calling request aiming at a target service is detected, service calling data are obtained, wherein the service calling data comprise first calling data and second calling data;
sending a service address acquisition request to the first module, wherein the service address acquisition request comprises the first calling data so that the first module acquires the address of the target service; receiving the address of the target service returned by the first module;
initiating a remote procedure call to the target service through the second module according to the address of the target service and the second call data;
and receiving a call return value returned by the target service.
Optionally, sending a service address obtaining request to the first module, so that the first module obtains the address of the target service, including:
and sending a service address acquisition request to the first module through the first interface so that the first module acquires the address of the target service from the service platform.
Optionally, when a service invocation request for the target service is detected, the service invocation method further includes: performing, by the first module, call control operations including one or more of service discovery, configuration discovery, fusing, throttling, and call chain monitoring operations.
Wherein the service discovery operation is to find the target service; the service discovery operation is used for finding a configuration center from which the target service obtains configuration and/or parameters; the fusing operation is used for closing the service calling request when detecting that the target service is frequently overtime; the throttling operation is used for setting a flow threshold value for the target service; the call chain monitoring operation is used for monitoring a call link for calling the target service, wherein the call link comprises each service which is required to be passed by the service call request to reach the target service.
Optionally, the service calling method further includes:
sending the first call data to the first module through the first interface to execute a call control operation through the first module, the first call data including one or more of service discovery data, configuration discovery data, fuse data, current limit data, and call chain monitoring data.
Optionally, the service calling method further includes:
and sending a calling result to the first module through the second interface so that the first module reports the calling result to the service platform.
Wherein the call result includes the call return value.
Optionally, the service address obtaining request includes a requestor identifier, a resource type and a resource name, and the resource type is a service.
Correspondingly, receiving the address of the target service returned by the first module includes: and receiving the resource value returned by the first module.
Wherein the resource value is an address of the target service.
The calling result also comprises one or more of caller identification, callee address, calling return code, calling time consumption and calling chain sequence number. The service calling method further comprises the following steps: and receiving the report result returned by the first module through the second interface.
In one aspect, an embodiment of the present invention provides a service invocation device, where the service invocation device is applied in a service grid, where the service grid includes a first module and a second module; wherein, the first module is a sidecar module; the second module is a remote procedure call module, and the service call device includes:
the device comprises a detection unit, a processing unit and a processing unit, wherein the detection unit is used for detecting a service calling request aiming at a target service;
the service calling data acquisition unit is used for acquiring service calling data when a service calling request aiming at a target service is detected, wherein the service calling data comprises first calling data and second calling data;
a sending unit, configured to send a service address obtaining request to the first module, where the service address obtaining request includes the first call data, so that the first module obtains an address of the target service;
the receiving unit is used for receiving the address of the target service returned by the first module;
the calling unit is used for initiating remote process calling to the target service through the second module according to the address of the target service and the second calling data;
the receiving unit is further configured to receive a call return value returned by the target service.
Optionally, the sending unit is configured to send a service address obtaining request to the first module, so that when the first module obtains the address of the target service, the sending unit is specifically configured to send the service address obtaining request to the first module through the first interface, so that the first module obtains the address of the target service from the service platform.
Optionally, the service invoking device further includes:
and the control unit is used for executing calling control operation through the first module.
Wherein the call control operations include one or more of service discovery, configuration discovery, fusing, throttling, and call chain monitoring operations.
Wherein the service discovery operation is to find the target service; the service discovery operation is used for finding a configuration center from which the target service obtains configuration and/or parameters; the fusing operation is used for closing the service calling request when detecting that the target service is frequently overtime; the throttling operation is used for setting a flow threshold value for the target service; the call chain monitoring operation is used for monitoring a call link for calling the target service, wherein the call link comprises each service which is required to be passed by the service call request to reach the target service.
Optionally, the sending unit is further configured to send the first call data to the first module through the first interface, so as to execute a call control operation through the first module, where the first call data includes one or more of service discovery data, configuration discovery data, fuse data, current limiting data, and call chain monitoring data.
Optionally, the sending unit is further configured to send the call result to the first module through the second interface, so that the first module reports the call result to the service platform.
Wherein the call result includes the call return value.
Optionally, the service address obtaining request includes a requestor identifier, a resource type and a resource name, and the resource type is a service.
Correspondingly, the receiving unit is specifically configured to receive the resource value returned by the first module when the receiving unit receives the address of the target service returned by the first module.
Wherein the resource value is an address of the target service.
Optionally, the call result further includes one or more of caller identification, callee address, call return code, call time consumption, and call chain sequence number.
Optionally, the receiving unit is further configured to receive, through the second interface, a report result returned by the first module.
In one aspect, an embodiment of the present invention provides an electronic device, including: a processor and a storage device;
the storage device stores computer program instructions, and the processor calls the computer program instructions to execute the following steps:
when a service calling request aiming at a target service is detected, service calling data are obtained, wherein the service calling data comprise first calling data and second calling data;
sending a service address acquisition request to the first module, wherein the service address acquisition request comprises the first calling data so that the first module acquires the address of the target service; receiving the address of the target service returned by the first module;
initiating a remote procedure call to the target service through the second module according to the address of the target service and the second call data;
and receiving a call return value returned by the target service.
In one aspect, an embodiment of the present invention provides a computer-readable storage medium, where computer program instructions are stored, and when executed, implement the following method:
when a service calling request aiming at a target service is detected, service calling data are obtained, wherein the service calling data comprise first calling data and second calling data;
sending a service address acquisition request to the first module, wherein the service address acquisition request comprises the first calling data so that the first module acquires the address of the target service; receiving the address of the target service returned by the first module;
initiating a remote procedure call to the target service through the second module according to the address of the target service and the second call data;
and receiving a call return value returned by the target service.
In the embodiment of the invention, service basic functions are sunk to a SideCar module (SideCar) and stripped from a remote process calling frame, thereby realizing the decoupling of service logic and service management, reducing the memory consumption, shortening the time delay of single service calling, and the SideCar only takes over the flow of control class, thus the bottleneck problem of the SideCar is solved easily.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a schematic flowchart of a service invocation method according to an embodiment of the present application;
fig. 2 is a schematic structural diagram of a service invocation system according to an embodiment of the present application;
fig. 3 is a schematic diagram of a call of a first interface according to an embodiment of the present application;
fig. 4 is a schematic diagram of a call of a second interface according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of a service invocation device according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of an electronic device according to 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. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The SideCar module (SideCar) is a high-performance web service based on Java Cryptographic Extension (JCE) protocol. Currently, the implementation schemes of the SideCar mainly include Envoy and SOFAMosn, and both of the implementation schemes take over all the traffic (including all the incoming traffic and all the outgoing traffic) of the application program.
Firstly, when all traffic passes through the SideCar, data needs to be copied between the user mode and the kernel mode twice more than the original data when the data reaches the application program, which consumes more CPUs on one hand and increases the time delay of single service call on the other hand, so that the SideCar becomes a bottleneck of performance.
Second, to make the granularity of monitoring applications finer and more complete, the SideCar needs to understand all the application layer protocols that go through it. And the SideCar has limited support for the protocol type of the application layer, wherein Envoy supports gRPC and Http protocol, and SOFAMosn supports Http, SOFARPC and Dubbo protocol. Supporting a new protocol requires that the protocol is realized in the SideCar once again, the workload is large, and the performance loss is increased by analyzing the protocol once more.
In order to solve the above problem, an embodiment of the present application provides a service calling method in which a SideCar and a Remote Procedure Call (RPC) framework are combined, and the method sinks a Call control operation (or called a service basic function) to the SideCar and strips the SideCar from the RPC framework, thereby implementing decoupling of service logic and service governance. The call control operation includes, but is not limited to, service discovery, configuration discovery, service monitoring reporting, fusing, current limiting, and call chain monitoring.
First, the method divides all data into control class data and data class data. Specifically, the method classifies data irrelevant to service logic, such as service discovery data, service monitoring reporting data, fusing data, current limiting data, call chain monitoring data, and the like, into control data, and classifies data relevant to service logic, such as remote procedure call data, into data. In the method, the control data passes through the SideCar, and the data does not directly carry out RPC calling without the SideCar, so that the performance problem of the SideCar and the time delay problem of single service calling are solved.
Secondly, the coding and decoding of the application layer protocol are already and necessarily supported by the existing RPC framework, so that no extra performance consumption and workload are added in the method, the SideCar does not need to understand the specific RPC protocol, and the RPC framework can realize the control of the service and the decoupling of the application program as long as the universal abstract interface defined by the SideCar is realized. The service invocation method provided by the embodiment of the present application is described in detail below with reference to fig. 1.
Fig. 1 is a schematic flow chart illustrating a service invoking method according to an embodiment of the present application. The method is applied to a service grid, and the service grid comprises a first module and a second module. Specifically, the method may be applied to a first electronic Device, which may be a Mobile phone, a tablet computer, a notebook computer, a palmtop computer, a Mobile Internet Device (MID), a wearable Device (e.g., a smart watch, a smart bracelet, etc.), a server, and the like, and the service invoking method may include steps S101 to S104.
S101, when a service calling request aiming at a target service is detected, service calling data are obtained, and the service calling data comprise first calling data and second calling data.
In an embodiment of the present application, the service invocation request is used to instruct the service a in the first electronic device 100 to invoke the service B in the second electronic device 200, as shown in fig. 1. The second electronic device 200 may be a mobile phone, a tablet computer, a notebook computer, a palm computer, an MID, a wearable device (e.g., a smart watch, a smart bracelet, etc.), a server, or the like. Service a and service B include respective business logic, and service B is the target service.
The first call data and the second call data may be control class data and data class data, respectively.
S102, sending a service address acquisition request to the first module so that the first module acquires the address of the target service and receives the address of the target service returned by the first module.
The first module is a SideCar module (SideCar) used for providing service grid service for the target service.
Wherein the service address acquisition request includes the first call data. In embodiments of the present application, the first call data may include one or more of service discovery data, configuration discovery data, fuse data, current limit data, and call chain monitoring data.
The first module may perform a call control operation when the service address acquisition request is received.
In embodiments of the present application, the call control operations include one or more of service discovery, configuration discovery, fusing, throttling, and call chain monitoring operations.
Specifically, the first electronic device 100 sends the service discovery data to the first module through the first port, so as to perform a service discovery operation through the first module. Wherein the service discovery operation is used to find the target service.
The first electronic device 100 sends the configuration discovery data to the first module through the first port to perform configuration discovery operation through the first module. Wherein the service discovery operation is used to find a configuration center from which the target service obtains various configurations, various parameters.
The first electronic device 100 sends the fusing data to the first module through the first port to perform a fusing operation through the first module. The fusing operation is used for short-circuiting the service calling request when detecting that the target service frequently times out, and directly returning a mock value without actually calling; and after the core service is stable, the target service is called again.
The first electronic device 100 sends the current limiting data to the first module through the first port to perform a current limiting operation through the first module. The throttling operation is used for setting a flow threshold value for the target service, namely the first module receives at most the flow of a specified value (namely the flow threshold value) from the target service.
The first electronic device 100 sends the call chain monitoring data to the first module through the first port, so as to execute a call chain monitoring operation through the first module. The call chain monitoring operation is used for monitoring a call link for calling the target service, and the call link comprises various services which are required to be passed by the service call request to reach the target service.
Further, when the call control operation is completed, the first module may acquire the address of the target service and return the address of the target service to the first electronic device 100.
In an embodiment of the present application, the sending, by the first electronic device 100, a service address obtaining request to the first module, so that the obtaining, by the first module, an address of the target service may specifically include: and sending a service address acquisition request to the first module through the first interface so that the first module acquires the address of the target service from the service platform.
The service platform can be a backend analysis and treatment platform, including but not limited to a registration center, a configuration center, a control center and a monitoring/warning center. The first interface is a resource discovery interface defined in the embodiment of the present application, and a specific call flow of the resource discovery interface is shown in fig. 2.
As shown in fig. 2, the service address acquisition request includes a requester identification, a resource type, and a resource name. In an embodiment of the present application, the requestor id is a device id of the first electronic device 100, the resource type is a service, and the resource name is an id of the target service. Correspondingly, the receiving, by the first electronic device 100, the address of the target service returned by the first module may specifically include: and receiving the resource value returned by the first module. Wherein the resource value is an address of a service indicated by the identity of the target service (i.e., the target service).
S103, according to the address of the target service and the second calling data, remote procedure calling is initiated to the target service through the second module.
Wherein the second call data includes, but is not limited to, remote procedure call data.
And S104, receiving a call return value returned by the target service.
In an embodiment of the present application, the service invocation method further includes: and sending a calling result to the first module through the second interface, so that the first module reports the calling result to the service platform 300, wherein the calling result comprises the calling return value.
The second interface is a call reporting interface defined in the embodiment of the present application, and a specific call flow of the call reporting interface is shown in fig. 3.
As shown in fig. 3, the call result may further include one or more of caller identification, callee address, call return code, call elapsed time, and call chain number (call chain ID). Correspondingly, the service calling method further comprises the following steps: and receiving a report result returned by the sidecar module through the second interface.
In summary, the RPC framework reports the call result to the SideCar, and the SideCar reports the call result to the service platform 300, so that decoupling of service administration and service logic is realized, and the service only needs to focus on realization of the service logic. The data (namely the second calling data) for calling the service logic by the service logic does not need to pass through the SideCar, so that chains for intermediate calling are reduced, and the calling time delay is shortened.
The RPC framework and the SideCar define a resource discovery interface and a service reporting interface, and SideCar and RPC frameworks in other modes can seamlessly access the SideCar or RPC framework in the embodiment of the application as long as the two interfaces are realized.
In the embodiment of the invention, the SideCar and the RPC framework perfectly separate the service management from the service logic by an abstract communication protocol, and the service part does not need to be changed no matter how the management scheme of the upper layer is changed, thereby realizing decoupling. Meanwhile, the SideCar only takes over the flow of the control class, and the performance bottleneck problem of the SideCar is solved easily. In addition, the SideCar does not need to understand the proprietary protocol of the service, and the complexity of the SideCar adapting to various proprietary protocols and the performance loss caused by the complexity are avoided.
Based on the above description, an embodiment of the present invention provides a schematic structural diagram of a service invocation device. The device is applied to a service grid, and the service grid comprises a first module and a second module. In particular, the service invocation apparatus may operate on an electronic device, where the electronic device may include a smartphone, a tablet computer, a notebook computer, a palm top computer, an MID, a wearable device (e.g., a smart watch, a smart bracelet, etc.), a server, and so on. As shown in fig. 5, the service invocation means includes:
a detecting unit 501, configured to detect a service invocation request for a target service.
The obtaining unit 502 is configured to obtain service invocation data when a service invocation request for a target service is detected, where the service invocation data includes first invocation data and second invocation data.
A sending unit 503, configured to send a service address obtaining request to the first module, where the service address obtaining request includes the first call data, so that the first module obtains an address of the target service.
The first module is a SideCar module (SideCar) used for providing service grid service for the target service.
A receiving unit 504, configured to receive an address of the target service returned by the first module.
And a calling unit 505, configured to initiate a remote procedure call to the target service through the second module according to the address of the target service and the second calling data.
Wherein the second module is a remote procedure call module.
The receiving unit 504 is further configured to receive a call return value returned by the target service.
Optionally, the sending unit 503 is configured to send a service address obtaining request to the first module through the first interface, so that the first module obtains the address of the target service from the service platform.
Optionally, the service invoking device further includes: a control unit 506 for performing call control operations by the first module, the call control operations including one or more of service discovery, configuration discovery, blowing, throttling, and call chain monitoring operations.
Wherein the service discovery operation is to find the target service; the service discovery operation is used for finding a configuration center from which the target service obtains configuration and/or parameters; the fusing operation is used for closing the service calling request when detecting that the target service is frequently overtime; the throttling operation is used for setting a flow threshold value for the target service; the call chain monitoring operation is used for monitoring a call link for calling the target service, wherein the call link comprises each service which is required to be passed by the service call request to reach the target service.
Optionally, the sending unit 503 is further configured to send the first call data to the first module through the first interface, so as to execute a call control operation through the first module, where the first call data includes one or more of service discovery data, configuration discovery data, fusing data, current limiting data, and call chain monitoring data.
Optionally, the sending unit 503 is further configured to send a call result to the first module through the second interface, so that the first module reports the call result to the service platform, where the call result includes the call return value.
Optionally, the service address obtaining request includes a requestor identifier, a resource type and a resource name, and the resource type is a service. The receiving unit 504 is configured to receive a resource value returned by the first module, where the resource value is an address of the target service.
Optionally, the call result further includes one or more of caller identification, callee address, call return code, call time consumption, and call chain sequence number. The receiving unit 504 is further configured to receive a report result returned by the first module through the second interface.
In the embodiment of the invention, the SideCar and the RPC framework perfectly separate the service management from the service logic by an abstract communication protocol, and the service part does not need to be changed no matter how the management scheme of the upper layer is changed, thereby realizing decoupling. Meanwhile, the SideCar only takes over the flow of the control class, and the performance bottleneck problem of the SideCar is solved easily. In addition, the SideCar does not need to understand the proprietary protocol of the service, and the complexity of the SideCar adapting to various proprietary protocols and the performance loss caused by the complexity are avoided.
Referring to fig. 6, a schematic structural diagram of an electronic device according to an embodiment of the present invention is shown, where the electronic device 1000 includes: the processor 1001, the user interface 1003, the network interface 1004, and the storage device 1005 are connected to each other via the bus 1002.
A user interface 1003 for implementing human-computer interaction, which may include a display screen or a keyboard, etc. A network interface 1004 for performing communication connection with an external device. A storage device 1005 is coupled to the processor 1001 for storing various software programs and/or sets of instructions. In particular implementations, storage 1005 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The storage device 1005 may store an operating system (hereinafter, referred to as a system), such as an operating system of Android, iOS, or Linux. The storage 1005 may also store a network communication program that may be used to communicate with one or more additional devices, one or more terminal devices, and one or more network devices. The storage device 1005 may further store a user interface program, which may vividly display the content of the application program through a graphical operation interface, and receive a control operation of the application program by a user through an input control such as a menu, a dialog box, and a button. The storage 1005 may also store one or more application programs.
In one embodiment, the storage 1005 may also be used to store one or more computer program instructions; the processor 1001 may be capable of executing the service invocation method when invoking the one or more computer program instructions, and specifically, the processor 1001 invokes the computer program instructions to perform the following steps:
when a service calling request aiming at a target service is detected, service calling data are obtained, wherein the service calling data comprise first calling data and second calling data;
sending a service address acquisition request to the first module, wherein the service address acquisition request comprises the first calling data so that the first module acquires the address of the target service; receiving the address of the target service returned by the first module;
initiating a remote procedure call to the target service through the second module according to the address of the target service and the second call data;
and receiving a call return value returned by the target service.
The first module is a SideCar module (SideCar), and the second module is a remote procedure call module.
Optionally, the processor 1001 may call the computer program instruction, and execute to send a service address acquisition request to the first module, so that when the first module acquires the address of the target service, the following steps are specifically executed:
and sending a service address acquisition request to the first module through the first interface so that the first module acquires the address of the target service from the service platform.
Optionally, when a service call request for a target service is detected, the processor 1001 may further call the computer program instructions to perform the following steps: performing, by the first module, call control operations including one or more of service discovery, configuration discovery, fusing, throttling, and call chain monitoring operations.
Wherein the service discovery operation is to find the target service; the service discovery operation is used for finding a configuration center from which the target service obtains configuration and/or parameters; the fusing operation is used for closing the service calling request when detecting that the target service is frequently overtime; the throttling operation is used for setting a flow threshold value for the target service; the call chain monitoring operation is used for monitoring a call link for calling the target service, wherein the call link comprises each service which is required to be passed by the service call request to reach the target service.
Optionally, the processor 1001 may also call the computer program instructions to perform the following steps:
sending the first call data to the first module through the first interface to execute a call control operation through the first module, the first call data including one or more of service discovery data, configuration discovery data, fuse data, current limit data, and call chain monitoring data.
Optionally, the processor 1001 may also call the computer program instructions to perform the following steps:
and sending a calling result to the first module through the second interface so that the first module reports the calling result to the service platform, wherein the calling result comprises the calling return value.
Optionally, the service address obtaining request includes a requestor identifier, a resource type and a resource name, and the resource type is a service. Accordingly, the processor 1001 may call the computer program instruction to execute, when receiving the address of the target service returned by the first module, specifically:
and receiving a resource value returned by the first module, wherein the resource value is the address of the target service.
Optionally, the call result further includes one or more of caller identification, callee address, call return code, call time consumption, and call chain sequence number. The processor 1001 may also invoke the computer program instructions to perform the following steps:
and receiving the report result returned by the first module through the second interface.
In the embodiment of the invention, the SideCar and the RPC framework perfectly separate the service management from the service logic by an abstract communication protocol, and the service part does not need to be changed no matter how the management scheme of the upper layer is changed, thereby realizing decoupling. Meanwhile, the SideCar only takes over the flow of the control class, and the performance bottleneck problem of the SideCar is solved easily. In addition, the SideCar does not need to understand the proprietary protocol of the service, and the complexity of the SideCar adapting to various proprietary protocols and the performance loss caused by the complexity are avoided.
In one embodiment, the processor 1001 may be configured to read and execute computer program instructions to implement a service invocation method as described in FIG. 1 herein. The principle of the electronic device provided in the embodiment of the present invention for solving the problem is similar to that of the method embodiment described in fig. 1, so the implementation manner and the advantageous effects of the electronic device may refer to the implementation manner and the advantageous effects of the method embodiment, and repeated details are not repeated.
An embodiment of the present invention further provides a computer-readable storage medium, where a computer program is stored, and the implementation and the beneficial effects of the program for solving the problem may refer to the implementation and the beneficial effects of the service invoking method described in fig. 1, and repeated details are not described again.
The above disclosure is intended to be illustrative of only some embodiments of the invention, and is not intended to limit the scope of the invention.
Claims (10)
1. A service calling method is applied to a service grid, wherein the service grid comprises a first module and a second module; the first module is a sidecar module; the second module is a remote procedure call module; characterized in that the method comprises:
when a service calling request aiming at a target service is detected, service calling data are obtained, wherein the service calling data comprise first calling data and second calling data; the first calling data are control data irrelevant to service logic, and the second calling data are data relevant to the service logic;
sending a service address acquisition request to the first module, wherein the service address acquisition request comprises the first calling data, so that the first module acquires the address of the target service; receiving the address of the target service returned by the first module;
initiating a remote procedure call to the target service through the second module according to the address of the target service and the second call data;
and receiving a call return value returned by the target service.
2. The method of claim 1, wherein sending a service address acquisition request to the first module to cause the first module to acquire the address of the target service comprises:
and sending a service address acquisition request to the first module through the first interface so that the first module acquires the address of the target service from a service platform.
3. The method according to claim 1 or 2, wherein when a service invocation request for a target service is detected, the method further comprises:
executing, by the first module, a call control operation, the call control operation including one or more of a service discovery, a configuration discovery, a fusing, a current limiting, and a call chain monitoring operation;
the service discovery operation is used for finding the target service;
the service discovery operation is used for finding a configuration center, and the target service acquires configuration and/or parameters from the configuration center;
the fusing operation is used for closing the service calling request when detecting that the target service is frequently overtime;
the flow limiting operation is used for setting a flow threshold value for the target service;
and the call chain monitoring operation is used for monitoring a call link for calling the target service, wherein the call link comprises each service which is required to pass by when the service call request reaches the target service.
4. The method of claim 3, further comprising:
sending the first call data to the first module through a first interface to execute a call control operation through the first module, the first call data including one or more of service discovery data, configuration discovery data, fuse data, current limit data, and call chain monitoring data.
5. The method of claim 1, further comprising:
and sending a calling result to the first module through a second interface so that the first module reports the calling result to a service platform, wherein the calling result comprises the calling return value.
6. The method of claim 1, wherein the service address obtaining request includes a requestor identifier, a resource type and a resource name, the resource type is a service, and the receiving the address of the target service returned by the first module includes:
and receiving a resource value returned by the first module, wherein the resource value is the address of the target service.
7. The method of claim 5, wherein the call result further comprises one or more of caller identification, callee address, call return code, call time consumption, and call chain sequence number, and wherein the method further comprises:
and receiving a reporting result returned by the first module through the second interface.
8. A service invocation device is applied to a service grid, wherein the service grid comprises a first module and a second module; the first module is a sidecar module; the second module is a remote procedure call module; characterized in that the device comprises:
the device comprises a detection unit, a processing unit and a processing unit, wherein the detection unit is used for detecting a service calling request aiming at a target service;
the service calling data acquisition unit is used for acquiring service calling data when a service calling request aiming at a target service is detected, wherein the service calling data comprises first calling data and second calling data; the first calling data are control data irrelevant to service logic, and the second calling data are data relevant to the service logic;
a sending unit, configured to send a service address obtaining request to the first module, where the service address obtaining request includes the first call data, so that the first module obtains an address of the target service;
the receiving unit is used for receiving the address of the target service returned by the first module;
the calling unit is used for initiating remote process calling to the target service through the second module according to the address of the target service and the second calling data;
the receiving unit is further configured to receive a call return value returned by the target service.
9. An electronic device, characterized in that the electronic device comprises:
a processor adapted to implement one or more computer program instructions; and the number of the first and second groups,
storage means storing one or more computer program instructions adapted to be loaded by a processor and to perform the service invocation method according to any of claims 1-7.
10. A computer-readable storage medium having one or more instructions stored thereon, the one or more instructions adapted to be loaded by a processor and to perform the service invocation method according to any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911191980.7A CN110933075B (en) | 2019-11-28 | 2019-11-28 | Service calling method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911191980.7A CN110933075B (en) | 2019-11-28 | 2019-11-28 | Service calling method and device, electronic equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110933075A CN110933075A (en) | 2020-03-27 |
| CN110933075B true CN110933075B (en) | 2022-01-11 |
Family
ID=69847447
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911191980.7A Active CN110933075B (en) | 2019-11-28 | 2019-11-28 | Service calling method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110933075B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113094269A (en) * | 2021-04-12 | 2021-07-09 | 中国工商银行股份有限公司 | Application program test exception analysis method and device |
| CN114025370B (en) * | 2021-11-04 | 2023-08-08 | 杭州朗和科技有限公司 | Data message transmission method, medium, system and computing equipment |
| CN114389851B (en) * | 2021-12-17 | 2023-07-18 | 苏州浪潮智能科技有限公司 | Switch maintenance service identity verification method, system, terminal and storage medium |
| CN114979285B (en) * | 2022-05-10 | 2024-02-27 | 百果园技术(新加坡)有限公司 | Service calling method, device, equipment, system, storage medium and product |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8555297B1 (en) * | 2008-09-29 | 2013-10-08 | Emc Corporation | Techniques for performing a remote procedure call using remote procedure call configuration information |
| CN108667925A (en) * | 2018-05-04 | 2018-10-16 | 北京天元创新科技有限公司 | A kind of method and system of WEB application seamless access distributed system |
| CN109815025A (en) * | 2018-12-17 | 2019-05-28 | 顺丰科技有限公司 | Business model call method, device and storage medium |
| CN110119322A (en) * | 2019-05-08 | 2019-08-13 | 北京三快在线科技有限公司 | Data capture method, device, computer equipment and readable storage medium storing program for executing |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8266639B2 (en) * | 2009-12-04 | 2012-09-11 | International Business Machines Corporation | Remote procedure call (RPC) bind service with physical interface query and selection |
-
2019
- 2019-11-28 CN CN201911191980.7A patent/CN110933075B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8555297B1 (en) * | 2008-09-29 | 2013-10-08 | Emc Corporation | Techniques for performing a remote procedure call using remote procedure call configuration information |
| CN108667925A (en) * | 2018-05-04 | 2018-10-16 | 北京天元创新科技有限公司 | A kind of method and system of WEB application seamless access distributed system |
| CN109815025A (en) * | 2018-12-17 | 2019-05-28 | 顺丰科技有限公司 | Business model call method, device and storage medium |
| CN110119322A (en) * | 2019-05-08 | 2019-08-13 | 北京三快在线科技有限公司 | Data capture method, device, computer equipment and readable storage medium storing program for executing |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110933075A (en) | 2020-03-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110933075B (en) | Service calling method and device, electronic equipment and storage medium | |
| CN109101335B (en) | Extending functionality of a host device | |
| US7877091B2 (en) | Method and system for executing a container managed application on a processing device | |
| CN106575222B (en) | Js application monitoring | |
| WO2019001074A1 (en) | Remote process calling method and apparatus, and computer device | |
| EP3637771A1 (en) | Cloud desktop system, and image sequence compression and encoding method, and medium therefor | |
| US11360737B2 (en) | Method and apparatus for providing speech service | |
| CN104301443A (en) | Method and system for calling end capacity ports on web page | |
| EP3720094A1 (en) | Information processing method, apparatus, device and system | |
| CN108696523B (en) | Response method and device for call service | |
| CN112260853B (en) | Disaster recovery switching method and device, storage medium and electronic equipment | |
| CN112055072A (en) | Cloud audio input method and device, cloud system, electronic equipment and storage medium | |
| CN111737022A (en) | Interface calling method, system, equipment and medium based on micro-service | |
| CN111200606A (en) | Deep learning model task processing method, system, server and storage medium | |
| CN109889468B (en) | Network data transmission method, system, device, equipment and storage medium | |
| KR20220091441A (en) | Data synchronization method and device, electronic device, storage media, and computer program | |
| CN112835632A (en) | Method and device for calling end capability and computer storage medium | |
| CN115550354A (en) | Data processing method and device and computer readable storage medium | |
| CN109218371B (en) | Method and equipment for calling data | |
| CN113535020B (en) | Method, apparatus, device, medium and product for generating application icons | |
| CN114595080A (en) | Data processing method and device, electronic equipment and computer readable storage medium | |
| CN109660585B (en) | Method, device, equipment and storage medium for calling AOP enhanced object service | |
| CN104346228A (en) | Application program sharing method and terminal | |
| CN114039981A (en) | Message processing method, device, server and storage medium | |
| CN112818336A (en) | Data access method, data access device and computer 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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |