Service invocation method and related device

Abstract

The application relates to the computer technical field and provides a service calling method applied to an RPC framework, which comprises the following steps: after a calling party registers a protocol through registration information on the RPC framework, receiving a calling request initiated by the calling party; serializing the request content through a packing function registered by the calling party to obtain a first binary stream; sending the first binary stream to a called party corresponding to a service identifier; receiving a data packet returned by the called party; the called party calls a service indicated by the service identifier to perform operation according to parameters indicated by the first binary stream, obtains an operation result, and generates a data packet according to the operation result; analyzing the data packet through an analysis function registered by the calling party to obtain a response structure; and sending the response structure to the calling party, so that the calling party obtains the operation result according to the response structure. The method realizes decoupling between the protocol and the RPC framework, and makes the RPC framework applicable to service calling between different language platforms.

Description

Service invocation methods and related equipment Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a service invocation method and related equipment. Background Technology

[0002] Remote service calls based on the RPC (Remote Procedure Call) protocol are widely used, and such remote services are implemented through the RPC framework.

[0003] In the existing technology, various RPC frameworks are self-contained and there is no unified RPC framework protocol standard, which makes it difficult to make RPC calls between different language platforms and different framework systems. Therefore, in order to achieve protocol compatibility between different language platforms and different framework systems in the RPC call process, it is necessary to redevelop the logic of service calls in the RPC framework. Moreover, after the redevelopment, the routing, coroutine and other framework features in the original RPC framework still have the problem of not being reusable.

[0004] As can be seen from the above, the inconsistency in RPC framework protocols leads to compatibility issues when making RPC calls between different framework systems, which is a technical problem that urgently needs to be solved in the existing technology. Summary of the Invention

[0005] The embodiments of this application provide a service invocation method and related equipment, thereby at least to some extent solving the compatibility problem in the prior art caused by the inconsistency of RPC framework protocols when making RPC calls between different framework systems.

[0006] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0007] According to one aspect of the embodiments of this application, a service invocation method is provided, applied to an RPC framework, the method comprising:

[0008] After the caller registers the protocol on the RPC framework using the registration information, the system receives the call request initiated by the caller. The call request includes the request content and service identifier, and the registration information includes the packet assembly function and the parsing function.

[0009] The request content is serialized using the packet assembly function registered by the caller to obtain a first binary stream;

[0010] Send the first binary stream to the callee corresponding to the service identifier;

[0011] The callee receives the data packet returned by the callee, and the callee calls the service indicated by the service identifier to perform a calculation according to the parameters indicated by the first binary stream, obtains the calculation result, and generates the data packet according to the calculation result;

[0012] The data packet is parsed using the parsing function registered by the caller to obtain a response structure;

[0013] The response structure is sent to the caller, and the caller obtains the calculation result based on the response structure.

[0014] According to another aspect of the embodiments of this application, a service invocation apparatus is provided, applied to an RPC framework, the apparatus comprising:

[0015] The call request receiving module is used to receive a call request initiated by the caller after the caller registers the protocol on the RPC framework through registration information. The call request includes request content and service identifier, and the registration information includes packet assembly function and parsing function.

[0016] The packet assembly function call module is used to serialize the request content through the packet assembly function registered by the caller to obtain a first binary stream;

[0017] A binary stream sending module is used to send the first binary stream to the callee corresponding to the service identifier;

[0018] A data packet receiving module is used to receive the data packet returned by the callee. The callee calls the service indicated by the service identifier to perform calculations according to the parameters indicated by the first binary stream, obtains the calculation result, and generates the data packet according to the calculation result.

[0019] The parsing function call module is used to call the parsing function registered by the caller to deserialize the data packet and obtain a response structure;

[0020] A response structure sending module is used to send the response structure to the caller, and the caller obtains the calculation result based on the response structure.

[0021] According to another aspect of the embodiments of this application, an electronic device is provided, comprising:

[0022] A processor; and a memory storing computer-readable instructions that, when executed by the processor, implement the methods described above.

[0023] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the method described above.

[0024] In the scheme disclosed herein, serialization is performed using the packet assembly function in the registration information registered by the caller on the RPC framework, and parsing is performed using the parsing function. The framework itself does not need to understand the request content in the call request or the data packet transmitted by the callee. The framework itself only processes the binary data stream. Thus, the protocol and the framework itself are decoupled. The caller can define the protocol in the RPC framework according to its own protocol needs to implement service calls with the help of the RPC framework.

[0025] Because the protocol is decoupled from the RPC framework itself, the RPC framework disclosed herein can be applied to service calls between different language platforms. It effectively solves the problem that existing technologies require secondary development of the RPC framework when making remote service calls between different language platforms and different framework systems due to protocol incompatibility, thus making the RPC framework disclosed herein widely applicable.

[0026] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0027] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0028] Figure 1 is a flowchart illustrating a service invocation method according to an embodiment;

[0029] Figure 2 is a flowchart of step 150 in one embodiment of the embodiment corresponding to Figure 1;

[0030] Figure 3 is a flowchart illustrating a service invocation method according to another embodiment;

[0031] Figure 4 is a flowchart of step 230 of the embodiment corresponding to Figure 2 in one embodiment;

[0032] Figure 5 is a flowchart of the steps preceding step 130 in one embodiment of the embodiment corresponding to Figure 1;

[0033] Figure 6 is a flowchart illustrating a service invocation method according to another embodiment;

[0034] Figure 7 is a block diagram of an RPC framework according to an embodiment;

[0035] Figure 8 is a flowchart illustrating a service invocation method in an RPC framework according to a specific embodiment;

[0036] Figure 9 is a block diagram of a service invocation device according to an embodiment;

[0037] Figure 10 shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application. Detailed Implementation

[0038] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0039] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0040] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0041] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0042] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0043] Figure 1 is a flowchart illustrating a service invocation method according to an embodiment, applied to an RPC framework. Referring to Figure 1, the service invocation method includes at least steps 110 to 160, which are described in detail below:

[0044] Step 110: After the caller registers the protocol on the RPC framework using the registration information, the system receives the call request initiated by the caller. The call request includes the request content and service identifier, and the registration information includes the packet assembly function and the parsing function.

[0045] RPC (Remote Procedure Call) is a protocol that allows a program on a remote computer to request services over a network without needing to understand the underlying network technology. This protocol allows a program running on one computer (the caller) to invoke a remote service (the callee) as if it were a local service.

[0046] Since the service being invoked is not a local service, parameters cannot be passed through memory when making remote service calls according to the RPC protocol. Furthermore, because the caller and callee may use different languages ​​(e.g., the caller uses Java or Python, and the callee uses C++), it is proposed that the information to be transmitted be converted into a binary data stream before transmission during remote service calls according to the RPC protocol.

[0047] Therefore, a crucial function of an RPC framework is to convert the information (such as data structures or objects) to be transmitted between the caller and the callee into a binary data stream, or to convert a binary data stream into a data structure or object that can be recognized by either the caller or the callee. The process of converting a data structure or object into a binary data stream is called serialization, and the process of converting a binary data stream back into a data structure or object is called deserialization. In other words, the essential functions of an RPC framework are serialization and deserialization.

[0048] It is understandable that the serialization and deserialization performed by an RPC framework are based on the protocol within that framework. For example, if the RPC framework uses the ProtoBuf protocol, then serialization and deserialization will be performed according to the ProtoBuf protocol.

[0049] In the current technology, there is no standard RPC framework protocol. Various RPC frameworks are self-contained, which makes it difficult to make RPC calls between different language platforms and different framework systems when upgrading the RPC framework. Therefore, secondary development is required to implement the RPC logic. Moreover, the routing, reporting and other framework features in the RPC framework cannot be reused.

[0050] Based on this, the proposed solution decouples the protocol and the RPC framework. In other words, the caller can register the protocol based on its own data format, so that the RPC framework can perform serialization and deserialization according to the protocol registered by the caller during the service call process.

[0051] Specifically, the caller describes the defined protocol through registration information. In this scheme, the registration information includes at least a packet assembly function and a parsing function. The packet assembly function in the registration information is used to convert the parameters passed from the caller to the callee into a binary stream; the parsing function in the registration information is used to deserialize the information passed from the callee to the caller into a response structure.

[0052] After the caller completes protocol registration with the RPC framework using registration information, the RPC framework can then process the call requests initiated by the caller. It is understood that the service identifier in the call request identifies the service to be invoked, and the request content indicates the passed-in call parameters, enabling the invoked service to perform calculations according to these parameters and obtain the result.

[0053] Step 120: Serialize the request content using the packet assembly function registered by the caller to obtain the first binary stream.

[0054] As described above, the packet assembly function is used to serialize the information passed from the caller to the callee into a binary data stream. The first binary stream refers to the binary data stream obtained by the packet assembly function after serializing the request content.

[0055] It is understandable that the parameter fields in the packet assembly function include at least the request content field. Therefore, when the packet assembly function is called to perform calculations, the request content field in the packet assembly function is assigned the request content in the call request.

[0056] In one embodiment, the parameter field in the packet assembly function further includes a storage address field, which indicates the address of the buffer where the obtained first binary stream is stored.

[0057] In one specific embodiment, the packet assembly function is SerializeRequestFunc(Req, Buf). Here, Req is the request content field, and Buf is the storage address field. When the packet assembly function is called for processing, the request content in the request is assigned to the request content field Req. After serializing the request using the packet assembly function to obtain the first binary stream, the first binary stream is stored in the buffer indicated by the storage address field Buf.

[0058] Step 130: Send the first binary stream to the callee corresponding to the service identifier.

[0059] An RPC framework acts as an intermediary between the caller and the callee. For a service on a computer device (the callee) to be invoked by other computer devices, that device needs to expose its services so that other devices can discover the callable services it provides. The RPC framework acts as a registry center; service providers (the callees) register their services within the framework, and the framework maintains information about these service providers, such as their addresses.

[0060] So, after the RPC framework receives the call request initiated by the caller, it determines the address of the callee based on the service identifier in the call request. Then, in step 130, the first binary stream is sent to the callee according to the determined address of the callee.

[0061] Step 140: Receive the data packet returned by the callee. The callee calls the service indicated by the service identifier to perform calculations according to the parameters indicated by the first binary stream, obtains the calculation result, and generates a data packet based on the calculation result.

[0062] For the caller, the desired result is the computation performed by the service indicated by the service identifier based on the caller's input. Therefore, after the callee receives the computation result, it transmits the result to the RPC framework in the form of a data packet.

[0063] It's worth noting that the data packets transmitted by the callee are binary data streams. That is, after obtaining the result of the computation, the caller serializes that result to obtain the data packet.

[0064] Step 150: Parse the data packet using the parsing function registered by the caller to obtain the response structure.

[0065] For the caller, due to language differences between the callee and the callee, the caller may not be able to recognize the data packets sent by the callee. Therefore, after the RPC framework receives the data packets transmitted by the callee, it parses the data packets using a parsing function registered by the caller. The resulting response structure, obtained by parsing the data packets, can then be recognized by the caller.

[0066] It is worth mentioning that the parsing function parses the data packets by deserializing them and constructing a response structure.

[0067] Step 160: Send the response structure to the caller, and the caller obtains the calculation result based on the response structure.

[0068] The response structure is sent to the caller, who then extracts the calculation result from the response structure, thus completing the service call.

[0069] In the scheme disclosed herein, serialization is performed using the packet assembly function in the registration information registered by the caller on the RPC framework, and parsing is performed using the parsing function. The framework itself does not need to understand the request content in the call request or the data packet transmitted by the callee. The framework itself only processes the binary data stream. Thus, the protocol and the framework itself are decoupled. The caller can define the protocol in the RPC framework according to its own protocol needs to implement service calls with the help of the RPC framework.

[0070] Because the protocol is decoupled from the RPC framework itself, the RPC framework disclosed herein can be applied to service calls between different language platforms. It effectively solves the problem of secondary development required due to protocol incompatibility caused by different protocols between RPC frameworks in the prior art, thus making the RPC framework disclosed herein widely applicable.

[0071] In one embodiment, the parsing function includes a packet header parsing function and a packet body parsing function. In this embodiment, as shown in FIG2, step 150 includes:

[0072] Step 210: Call the header parsing function to parse the header in the data packet and obtain the header parsing result.

[0073] The data packet transmitted by the callee includes a header and a body. The header contains control information, and the body contains the transmitted data. The control information in the header is used to control the parsing of the body. Therefore, upon receiving the data packet from the callee, the header parsing function is first called to parse the header and obtain the parsing result. It can be understood that the header parsing result indicates the control information included in the header.

[0074] Step 230: Call the packet body parsing function to parse the packet body in the data packet according to the packet header parsing result, and obtain the response structure.

[0075] After the header is successfully parsed, the packet body parsing function is called to parse the packet body in the data packet based on the header parsing result, and obtain the response structure.

[0076] In one embodiment, the registration information further includes a packet length function, as shown in Figure 3. The method also includes:

[0077] Step 310: Call the packet length function to obtain the first length parameter.

[0078] In one embodiment, the packet length function is GetDefaultSizeFunc(void), and the return value of the packet length function is a first length parameter. Therefore, when the packet length function is called, the first length parameter is obtained accordingly. The first length parameter can be represented as rSize.

[0079] The first length parameter is used to indicate the default read size when the RPC framework receives a packet for the first time, and the caller can set it according to the protocol characteristics.

[0080] In one specific embodiment, if the packet header in the protocol has a fixed size, the first length parameter can be set as the header size.

[0081] Step 320: During the process of receiving the data packet sent by the callee, determine whether the size of the received data packet reaches the size indicated by the first length parameter.

[0082] If the size of the received data packet reaches the size indicated by the first length parameter, then step 210 is executed: call the packet header parsing function to parse the packet header in the data packet and obtain the packet header parsing result.

[0083] If the size of the received data packet reaches the size indicated by the first length parameter, then data reading begins, and the header parsing function is called to parse the header in the data packet.

[0084] In one embodiment, the header parsing function is ParseRespHeaderFunc(Buf, HeaderResp, nrSize). The Buf field in this function indicates the storage address of the received data packet (which is a binary data stream); the HeaderResp field is the header parsing field, indicating the header parsing result; and the nrSize parameter indicates the length of the next packet to be received if header parsing fails.

[0085] In a specific embodiment, the packet header parsing result may include a packet body length field, such as a length field, to indicate the packet body length; the packet header parsing result may also include a field indicating the parsing method, which is not specifically limited here. This packet header parsing result is used in the packet body parsing function.

[0086] When the first length parameter rSize is used to indicate the size of the packet header, in step 330, if the size of the received data packet reaches rSize, the corresponding packet header parsing function is called to parse the packet header and obtain the packet header parsing result; if the size of the received data packet does not reach rSize, data packets are received until the size of the received data packet reaches rSize.

[0087] When the first length parameter `rSize` does not indicate the header size but only the size of the initial received packet, the header parsing function is still called to parse the header even when the received data packet reaches `rSize`. If header parsing fails, the header parsing function returns the parameter `nrSize`, which informs the RPC framework to continue receiving packets. If header parsing succeeds, the `nrSize` parameter returned by the header parsing function indicates the size of the entire packet.

[0088] In some protocols, such as HTTP / 2, the header size is not fixed. In this case, rSize is not used to indicate the header size, but only to indicate the size of the first packet received.

[0089] In one embodiment, the packet header parsing result includes a second length parameter, as shown in Figure 4. Step 230 includes:

[0090] Step 410: Determine whether the size of the received data packet reaches the size indicated by the second length parameter based on the second length parameter.

[0091] In this embodiment, the second length parameter included in the packet header parsing result is the nrSize obtained after successful packet header parsing by the packet header parsing function. As described above, when packet header parsing is successful, the nrSize returned by the packet header parsing function is used to indicate the size of the entire packet.

[0092] Step 420: If the condition is met, the packet body parsing function is called to parse the packet body in the received data packet and obtain the response structure.

[0093] After completing the header parsing, the RPC framework continues to receive packets. If the size of the received data reaches the size indicated by the second length parameter (at this point, the received data is equivalent to the packet body), the packet body parsing function is called to parse the received packet body and obtain the corresponding response structure.

[0094] In one embodiment, the packet body parsing function is ParseRespBodyFunc(Buf, HeaderResp, Resp). In this packet body parsing function, the Buf field is used to indicate the storage address of the received data packet (binary data stream), the HeaderResp is used to indicate the packet header parsing result obtained by packet header parsing, and the Resp field is used to indicate the response structure obtained by packet body parsing.

[0095] In one embodiment, as shown in FIG5, before step 130, the method further includes:

[0096] Step 510: Obtain the routing indication information corresponding to the caller.

[0097] Step 530: Determine the routing method indicated by the routing indication information in the routing method configured in the RPC framework.

[0098] In this embodiment, step 130 includes:

[0099] The first binary stream is sent to the callee corresponding to the service identifier according to the routing method indicated by the routing information.

[0100] In one embodiment, before step 510, the user configures routing indication information on the RPC framework, so that after receiving a call request sent by the caller, the RPC framework obtains the routing indication information corresponding to the caller.

[0101] The solution in this embodiment not only decouples the protocol corresponding to the caller from the RPC framework, but also allows for the customization of routing indication information corresponding to the caller.

[0102] In one embodiment, the method further includes:

[0103] Obtain the response indication information from the caller.

[0104] In this embodiment, after step 110, the method further includes:

[0105] The call request shall be responded to in accordance with the response method indicated by the response indication information.

[0106] The response indication information sent by the caller is used to indicate how the RPC framework should respond to the call request sent by the caller.

[0107] In some RPC frameworks, there may be a situation where the protocol and framework features are coupled. In this case, if it is necessary to use this part of the framework feature in the RPC framework, it needs to be determined based on the user fields and field parameter values. Since the framework does not understand the request content in the call request sent by the caller, the RPC framework cannot extract parameters from it and understand them.

[0108] To address this issue, extended parameters can be configured within the RPC framework to utilize certain framework features based on these parameters. These extended parameters can be used to indicate routing indication information, response indication information, etc., as described in the above embodiments.

[0109] In one embodiment, the RPCExtPram structure is used to indicate the routing and response information corresponding to the caller. The RPCExtPram is defined as follows:

[0110]

[0111] In the RPCExtPram structure, RouteID is used to represent routing indication information, and NorspFlag is used as a flag to indicate response indication information.

[0112] If the NorspFlag flag indicates an immediate response, then upon receiving the call request, the system does not wait for the computation result to return; it responds to the call request first, and then processes the code. The computation result is asynchronously returned to the caller via a callback interface. In one embodiment, the RPC framework is configured with a ClientCall API, which is used by users to pass in parameters related to RPCExtPram, parameters corresponding to the request structure Req, and parameters corresponding to the response structure Resp. The request content sent by the caller is presented in the form of a request structure.

[0113] In one embodiment, the RPC framework includes a callback function setting interface, as shown in Figure 6. The method further includes:

[0114] Step 610: Receive the registration information sent to the caller through the callback function setting interface.

[0115] Step 620: Register the protocol in the RPC framework according to the registration information.

[0116] In this embodiment, a callback function setting interface is configured in the RPC framework. Through this interface, the user can send the registration information of the caller to the RPC framework for registration. Registration information includes, for example, the packet assembly function, header parsing function, body parsing function, and packet length reading function described in the previous embodiment.

[0117] Figure 7 is a block diagram of an RPC framework according to a specific embodiment. As shown in Figure 7, before making a service call, after registering the corresponding protocol of the caller in step 710 and passing the request / response / control parameters to the RPC framework in step 720, the RPC framework can make a service call according to the method in any of the above embodiments.

[0118] As shown in Figure 7, the RPC framework is configured with a registration API and a ClientCall API. The registration API is used to register the protocol in step 710, and the ClientCall API is used to pass in the request / response / control parameters in step 720. The request parameters are the parameters corresponding to the request structure Req mentioned above, the response parameters are the parameters corresponding to the response structure Resp, and the control parameters can be parameters related to the RPCExtPram structure (such as RouteID and NorspFlag).

[0119] In the RPC framework, common functions other than those defined by the protocol are implemented by the framework feature modules, which implement functions such as routing, coroutine management, and configuration management.

[0120] The network I / O module in the RPC framework is used to communicate with other computer devices, such as the communication with the callee mentioned above, and is not specifically limited here.

[0121] Figure 8 is a flowchart illustrating a service invocation method in an RPC framework according to a specific embodiment. As shown in Figure 8, it includes the following steps 810-819.

[0122] Step 810: The caller invokes ClientCall(Req, Resp). Invoking ClientCall(Req, Resp) is considered as the caller initiating a call request.

[0123] Step 811: The RPC framework calls the packet assembly function SerializeRequestFunc to serialize the request content in the request, obtain the first binary stream, and write the serialized first binary stream into the buffer buf.

[0124] Step 812: Send the first binary stream to the callee over the network.

[0125] Step 813: Call the packet length function GetDefaultSizeFunc to obtain the first length parameter rSize.

[0126] Step 814: The RPC framework receives the data packet sent by the callee.

[0127] Step 815: Determine whether the size of the data received in the buffer reaches the first length parameter rSize. If not, proceed to step 814 to continue receiving data packets; if so, proceed to step 816.

[0128] Step 816: Call the packet header parsing function ParseRespHeaderFunc to parse the received packet header and obtain the second length parameter ndsize.

[0129] Step 817: Continue receiving data packets.

[0130] Step 818: Determine whether the size of the data packet received in the buffer reaches the second length parameter ndsize, or whether the second length parameter ndsize is always zero; if not, proceed to step 817 to continue receiving data packets; if yes, proceed to step 819.

[0131] Step 819: Call the packet body parsing function to parse the packet body received in the buffer and obtain the response structure Resp.

[0132] In practice, the solution disclosed herein was applied to WeChat documentation, which enabled cross-language platform RPC calls to be encapsulated based on the RPC framework. Furthermore, the operation system, configuration system, and routing strategy of the RPC framework were reused, reducing development costs and improving operational efficiency.

[0133] The following describes an apparatus embodiment of this application, which can be used to perform the methods described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the method embodiments described in the above embodiments of this application.

[0134] Figure 9 is a block diagram illustrating a service invocation apparatus according to an embodiment, which is applied to an RPC framework. As shown in Figure 9, the apparatus includes:

[0135] The call request receiving module 910 is used to receive a call request initiated by the caller after the caller registers the protocol on the RPC framework through registration information. The call request includes request content and service identifier, and the registration information includes packet assembly function and parsing function.

[0136] The packet assembly function call module 920 is used to serialize the request content through the packet assembly function registered by the caller to obtain a first binary stream.

[0137] The binary stream sending module 930 is used to send the first binary stream to the callee corresponding to the service identifier.

[0138] The data packet receiving module 940 is used to receive the data packet returned by the callee. The callee calls the service indicated by the service identifier to perform calculations according to the parameters indicated by the first binary stream, obtains the calculation result, and generates the data packet according to the calculation result.

[0139] The parsing function call module 950 is used to call the parsing function registered by the caller to deserialize the data packet and obtain a response structure.

[0140] The response structure sending module 960 is used to send the response structure to the caller, and the caller obtains the calculation result based on the response structure.

[0141] In one embodiment, the parsing function includes a packet header parsing function and a packet body parsing function, and the parsing function calling module 950 includes:

[0142] The header parsing function call unit is used to call the header parsing function to parse the header in the data packet and obtain the header parsing result.

[0143] The packet body parsing function call unit is used to call the packet body parsing function to parse the packet body in the data packet according to the packet header parsing result, and obtain the response structure.

[0144] In one embodiment, the registration information further includes a packet length function, and the device further includes:

[0145] The packet length call module is used to call the packet length function to obtain the first length parameter.

[0146] The jump module is used to jump to the packet header parsing function call unit when receiving a data packet sent by the callee and the size of the received data packet reaches the size indicated by the first length parameter.

[0147] In one embodiment, the packet header parsing result includes a second length parameter, and the packet body parsing function call unit includes:

[0148] The judgment unit is used to determine whether the size of the received data packet reaches the size indicated by the second length parameter based on the second length parameter;

[0149] The packet body parsing unit is used to call the packet body parsing function to parse the packet body in the received data packet and obtain the response structure if the judgment unit determines that the size of the received data packet reaches the size indicated by the second length parameter.

[0150] In one embodiment, the device further includes:

[0151] The routing indication information acquisition module is used to acquire the routing indication information corresponding to the caller.

[0152] The routing mode determination module is used to determine the routing mode indicated by the routing indication information from the routing modes configured in the RPC framework;

[0153] In this embodiment, the binary stream sending module 930 is further configured to:

[0154] The first binary stream is sent to the callee corresponding to the service identifier according to the routing method indicated by the routing instruction information.

[0155] In one embodiment, the device further includes:

[0156] The response indication information acquisition module is used to acquire the response indication information corresponding to the caller.

[0157] The response information sending module is used to send response information to the caller if the response indication information indicates that an immediate response is required;

[0158] The second jump module is used to jump to the packet assembly function call module 920 when the response information is to be sent.

[0159] In one embodiment, the RPC framework includes a callback function setting interface, and the device further includes:

[0160] The registration information receiving module is used to receive registration information transmitted to the caller through the callback function setting interface;

[0161] The protocol registration module is used to register protocols in the RPC framework according to the registration information.

[0162] The specific implementation process of the functions and roles of each module / unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0163] It is understood that these modules can be implemented through hardware, software, or a combination of both. When implemented in hardware, these modules can be implemented as one or more hardware modules, such as one or more application-specific integrated circuits (ASICs). When implemented in software, these modules can be implemented as one or more computer programs that execute on one or more processors.

[0164] Figure 10 shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application.

[0165] It should be noted that the computer system 1000 of the electronic device shown in Figure 10 is only an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0166] As shown in Figure 10, the computer system 1000 includes a Central Processing Unit (CPU) 1001, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 1002 or programs loaded from storage portion 1008 into Random Access Memory (RAM) 1003. The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An Input / Output (I / O) interface 1005 is also connected to the bus 1004.

[0167] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. Removable media 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1010 as needed so that computer programs read from them can be installed into storage section 1008 as needed.

[0168] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs various functions defined in the system of this application.

[0169] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0170] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0171] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0172] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable storage medium stores computer-readable instructions that, when executed by a processor, such as a processor in the above electronic device, implement the methods in any of the above embodiments.

[0173] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0174] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0175] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0176] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0177] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A service invocation method, applied to an RPC framework, characterized in that, The RPC framework is configured with a callback function setting interface. The method includes: receiving registration information transmitted to the caller through the callback function setting interface; the registration information includes a packet assembly function and a parsing function, and the caller uses the registration information to describe the defined protocol; registering the protocol in the RPC framework according to the registration information and based on the data format that the caller can process, so that the RPC framework performs serialization and deserialization according to the protocol registered by the caller during the service call for the caller; wherein, serialization refers to the RPC framework converting the data structure or object to be transmitted between the caller and the callee into a binary data stream; deserialization refers to the RPC framework converting the binary data stream into a data structure or object that can be recognized by the caller or the callee; after the caller registers the protocol on the RPC framework through the registration information, receiving a call request initiated by the caller; the call request includes The process involves: requesting content and a service identifier; serializing the request content using the packet assembly function to obtain a first binary stream; obtaining routing indication information configured by the caller on the RPC framework; determining the routing method indicated by the routing indication information among the routing methods configured in the RPC framework; sending the first binary stream to the callee corresponding to the service identifier according to the routing method; receiving a data packet returned by the callee, the data packet being a binary data stream; the callee using the service identifier to invoke the service, performing calculations based on the parameters indicated by the first binary stream to obtain a calculation result, and serializing the calculation result to obtain the data packet; parsing the data packet using the parsing function to deserialize the data packet to obtain a response structure recognizable by the caller; and sending the response structure to the caller so that the caller can obtain the calculation result based on the response structure.

2. The method according to claim 1, characterized in that, The parsing function includes a header parsing function and a body parsing function. The step of parsing the data packet using the parsing function to deserialize the data packet and obtain a response structure recognizable by the caller includes: calling the header parsing function to parse the header in the data packet and obtain a header parsing result; and calling the body parsing function to parse the body in the data packet based on the header parsing result to obtain the response structure.

3. The method according to claim 2, characterized in that, The registration information also includes a packet length function, and the method further includes: calling the packet length function to obtain a first length parameter; during the process of receiving the data packet sent by the callee, if the size of the received data packet reaches the size indicated by the first length parameter, then the step of calling the packet header parsing function to parse the packet header in the data packet and obtaining the packet header parsing result is executed.

4. The method according to claim 2 or 3, characterized in that, The packet header parsing result includes a second length parameter. The step of calling the packet body parsing function to parse the packet body in the data packet according to the packet header parsing result and obtain the response structure includes: determining whether the size of the received data packet reaches the size indicated by the second length parameter according to the second length parameter; if it does, calling the packet body parsing function to parse the packet body in the received data packet and obtain the response structure.

5. The method according to claim 1, characterized in that, The method further includes: obtaining response indication information corresponding to the caller; after receiving the call request initiated by the caller, the method further includes: responding to the call request according to the response method indicated by the response indication information.

6. A service invocation device, the device being configured within an RPC framework, characterized in that, The RPC framework is configured with a callback function setting interface. The device includes: a registration information receiving module, used to receive registration information transmitted to the caller through the callback function setting interface; the registration information includes a packet assembly function and a parsing function, and the caller uses the registration information to describe the defined protocol; a protocol registration module, used to register the protocol in the RPC framework according to the registration information and based on the data format that the caller can process, so that the RPC framework performs serialization and deserialization according to the protocol registered by the caller during the service call for the caller; wherein, serialization refers to the RPC framework converting the data structure or object that needs to be transmitted between the caller and the callee into a binary data stream; deserialization refers to the RPC framework converting the binary data stream into a data structure or object that can be recognized by the caller or the callee; a call request receiving module, used to receive the call request initiated by the caller after the caller registers the protocol on the RPC framework through the registration information; the call request includes request content and service identifier; and a packet assembly function calling module, used to... The request content is serialized by the packet assembly function to obtain a first binary stream; a routing indication information acquisition module is used to acquire the routing indication information configured by the caller on the RPC framework; a routing mode determination module is used to determine the routing mode indicated by the routing indication information among the routing modes configured in the RPC framework; a binary stream sending module is used to send the first binary stream to the callee corresponding to the service identifier according to the routing mode; a data packet receiving module is used to receive the data packet returned by the callee, the data packet being a binary data stream; the callee is used to call the service indicated by the service identifier, perform calculations according to the parameters indicated by the first binary stream, obtain the calculation result, and serialize the calculation result to obtain the data packet; a parsing function call module is used to parse the data packet through the parsing function to deserialize the data packet and obtain a response structure that can be recognized by the caller; a response structure sending module is used to send the response structure to the caller so that the caller can obtain the calculation result based on the response structure.

7. An electronic device, characterized in that, include: processor; And a memory storing computer-readable instructions that, when executed by the processor, implement the method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions that, when executed by a processor, implement the method as described in any one of claims 1-5.

9. A computer program product, characterized in that, Includes a computer program carried on a computer-readable medium, which, when executed by a processor, implements the method as described in any one of claims 1-5.

Images