Service call method and apparatus

Abstract

Disclosed are a service call method and apparatus, relating to the field of computers. When a call mode for a service needs to be changed, in a first aspect of the present application, a first node acquires a first call request for a first service, and changes a first call mode for the first service that is indicated by the first call request to a second call mode, so as to obtain a second call request. The first node sends the second call request to a second node without needing to manually write a file that provides support for a call mode and to manually modify a code associated with the call mode, thereby reducing the workload of an operator, improving the service call efficiency, lowering the professionalism requirements for the operator, and reducing the cost of changing a call mode for a service.

Description

A service invocation method and apparatus

[0001] This application claims priority to Chinese Patent Application No. 202410808993.9, filed on June 20, 2024, entitled "A Method and Apparatus for Dynamically Modifying Serialization Protocol Based on Bytecode Enhancement," and also claims priority to Chinese Patent Application No. 202411216671.1, filed on August 30, 2024, entitled "A Service Invocation Method and Apparatus," the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computers, and more particularly to a service invocation method and apparatus. Background Technology

[0003] A device (e.g., Device 1) can request services from another device (e.g., Device 2) using Remote Procedure Call (RPC). RPC can include various calling methods, such as the high-performance, lightweight RPC protocol Dubbo. Different calling methods may result in different service retrieval times. Typically, when it's necessary to change the first calling method to a second calling method, operators can manually write supporting documentation for the second calling method and manually modify the code associated with the calling method in both Device 1 and Device 2, enabling Device 1 to call Device 2's services using the second calling method.

[0004] The above process involves manually writing supporting files for the calling method and modifying the code associated with the calling method, which is tedious and inefficient. Summary of the Invention

[0005] This application provides a service invocation method and apparatus to solve the problem that manually modifying the invocation method is cumbersome and inefficient.

[0006] Firstly, this application provides a service invocation method. This method can be applied to a cloud management platform. The cloud management platform deploys multiple nodes. Each node deploys one or more services. The cloud management platform supports a first node invoking a service on a second node. The method is executed by the first node and includes: the first node generating a first invocation request in response to a request to obtain a first service. The first invocation request indicates that the first service deployed on the second node is invoked using a first invocation method. The first node generates a second invocation request based on the first invocation request. The second invocation request indicates that the first service on the second node is invoked using a second invocation method, which is different from the first invocation method. The first node sends the second invocation request to the second node.

[0007] In cases where a change in the method of invoking a service is required, in the first aspect of this application, a first node obtains a first invoice request for a first service and changes the first invoice method indicated by the first invoice request to a second invoice method, thus obtaining a second invoice request. The first node sends the invoice request with the changed invoice method (i.e., the second invoice request) to the second node. This eliminates the need to manually write supporting documents for the invoice method or manually modify the code associated with the invoice method, reducing the workload of operators and improving service invoicing efficiency. Eliminating the need for manually writing supporting documents and modifying associated code also reduces the professional requirements for operators and lowers the cost of changing the method of invoking a service.

[0008] In one possible implementation, the first invocation method supports a first serialization protocol, and the second invocation method supports a second serialization protocol. Furthermore, the time required to serialize the first object using the second serialization protocol is less than or equal to the time required to serialize the first object using the first serialization protocol. Thus, changing the first invocation method to the more efficient second invocation method improves the efficiency of service invocation.

[0009] In another possible implementation, the first node generates a second call request based on the first call request. This includes: the first node parsing the first call request to obtain a first identifier used to call the first service; the first node using the first identifier to generate a first binary file corresponding to the first call method; the first node modifying the first binary file into a second binary file; the second binary file indicating the second call method; and the first node generating a second call request based on the second binary file. The second call request includes a second identifier used to call the first service, and the second identifier corresponds to the second call method. In this way, the first node can modify the service call method without modifying the source code, facilitating program maintenance and upgrades and reducing costs.

[0010] In another possible implementation, before the first node modifies the first binary file to the second binary file, the method further includes: the first node obtaining interface information for calling the first service using the first calling method based on the first call request; the first node generating supporting files required for calling the first service using the second calling method based on the interface information; and the first node generating the second binary file based on the supporting files. Thus, the first node obtains interface information based on the first call request and generates supporting files required for calling the first service using the second calling method based on the interface information. This eliminates the need for operators to manually write the supporting files required for the second calling method, reducing workload and improving adjustment efficiency. It also lowers the requirements for operators and reduces costs.

[0011] In another possible implementation, the first node is a container. This allows the container's initialization process to obtain the supporting files required for the second invocation method.

[0012] In another possible implementation, the second invocation method includes one or more of the following: high-performance remote procedure call protocols gRPC and Thrift, unified RPC invocation protocol uRPC, high-performance lightweight RPC protocol Dubbo, RESTful API based on the REST (Representational State Transfer) architectural style, XML-RPC (using Extensible Markup Language (XML) to encode data and Hypertext Transfer Protocol (HTTP) as the transport protocol), and JSON-RPC (a lightweight and stateless remote procedure call protocol using JSON (JavaScript Object Notation) as the data format and HTTP or Transmission Control Protocol (TCP) as the transport protocol). In this way, the invocation method can be dynamically adjusted according to the actual application needs, so that the adjusted invocation method matches the actual application scenario and improves service invocation efficiency.

[0013] In another possible implementation, the method further includes: the first node receiving the call result sent by the second node. In this way, the first node can call services on other nodes (such as the second node) without needing to deploy the service using local resources, reducing the hardware requirements of the first node and lowering costs.

[0014] Secondly, this application provides a service invocation apparatus. The apparatus includes modules for executing the service invocation method described in the first aspect or any possible design of the first aspect.

[0015] Thirdly, this application provides a service invocation system. This service invocation system is deployed with multiple nodes. Each node deploys one or more services. The service invocation system supports a first node invoking a service on a second node. In response to a request to obtain a first service, the first node generates a first invocation request. The first invocation request instructs the invocation of the first service deployed on the second node using a first invocation method. Based on the first invocation request, the first node generates a second invocation request. The second invocation request instructs the invocation of the first service on the second node using a second invocation method, which is different from the first invocation method. The first node sends the second invocation request to the second node.

[0016] Fourthly, this application provides a processor. The processor is used to execute the operational steps of the service invocation method in the first aspect or any possible design of the first aspect.

[0017] Fifthly, this application provides a computing device. The computing device includes at least one processor and a memory, the memory storing a set of computer instructions; when the processor executes the set of computer instructions as an execution device in the first aspect or any possible implementation of the first aspect, it executes the operational steps of the service invocation method in the first aspect or any possible implementation of the first aspect.

[0018] Sixthly, this application provides a computer-readable storage medium, comprising: computer software instructions; which, when executed in a computing device, cause the computing device to perform operational steps of the method as described in the first aspect or any possible implementation thereof.

[0019] In a seventh aspect, this application provides a computer program product. When the computer program product is run on a computer, it causes a computing device to perform the operational steps of the method as described in the first aspect or any possible implementation thereof.

[0020] The beneficial effects of aspects two through seven above can be described with reference to the first aspect or any implementation thereof, and will not be repeated here. Based on the implementations provided in the above aspects, this application can be further combined to provide more implementations. Attached Figure Description

[0021] Figure 1 is a comparative example of the call performance of different RPC protocols;

[0022] Figure 2 is a schematic diagram of the structure of a service invocation system provided in this application;

[0023] Figure 3 is a schematic diagram of the structure of a computing device provided in this application;

[0024] Figure 4 is a flowchart illustrating a service invocation method provided in this application;

[0025] Figure 5 is a comparison diagram of one invocation method provided in this application;

[0026] Figure 6 is an example diagram of a service invocation method provided in this application;

[0027] Figure 7 is an example diagram of container creation provided in this application;

[0028] Figure 8 is an example diagram of an initialization provided in this application;

[0029] Figure 9 is an example diagram of obtaining supporting documents provided in this application;

[0030] Figure 10 is an example diagram of a Java Agent storage provided in this application;

[0031] Figure 11 is a schematic diagram of a service invocation device provided in this application;

[0032] Figure 12 is a schematic diagram of the structure of a computing device cluster provided in this application;

[0033] Figure 13 is a schematic diagram of a possible connection method for a computing device cluster provided in this application. Detailed Implementation

[0034] To ensure clarity and brevity in the description of the following embodiments, some concepts that may be involved in this application will be briefly introduced first.

[0035] Serialization is the process of converting an object into a form that can be stored or transmitted (such as a sequence of bytes).

[0036] Deserialization is the process of converting a sequence of bytes into an object.

[0037] Remote Procedure Call (RPC): Allows a program to request services from a remote computer. During a RPC, the electronic device receiving the service (or the called device) converts the code file implementing the service into a transmittable sequence of bytes and sends that sequence to the calling device. The calling device receives the sequence of bytes and converts it back into the code file implementing the service to provide the service.

[0038] RPC has various protocols, such as the High Performance Remote Procedure Call protocol (Google). TM Remote Procedure Call (gRPC). Different RPC protocols can support different serialization protocols, and the time required for different serialization protocols to serialize the same object may vary. In other words, different RPC protocols may have different call performance.

[0039] Figure 1 is a comparative example of the call performance of different RPC protocols. As shown in Figure 1, the server calls service 1 from the client using the first and second calling protocols respectively. Service 1 can be implemented using code file 1, which includes four objects (e.g., object 1 to object 4). The first and second calling protocols support different serialization frameworks; the first calling protocol requires changes to the data structure, while the second calling protocol does not.

[0040] When the server invokes service 1 on the client using the first invocation protocol, the invocation process is as follows: The client serializes objects 1 to 4 using serialization protocol 1 supported by the first invocation protocol, obtaining a serialized byte sequence. The client then sends this byte sequence to the server using the Hypertext Transfer Protocol (HTTP). The server receives the byte sequence and deserializes it using serialization protocol 1 supported by the first invocation protocol, obtaining objects 1 to 4. The server then obtains code file 1 based on objects 1 to 4 and uses code file 1 to retrieve service 1.

[0041] When the server uses the second invocation protocol to call service 1 on the client, the serialization framework of the second invocation protocol differs from that of the first invocation protocol. During the serialization of code file 1 using the second invocation protocol, no data format conversion is required, thus improving serialization efficiency. The second invocation protocol can be implemented based on Unified Remote Memory access (URMA), which has lower transmission latency compared to the first invocation protocol. In some possible scenarios, URMA can also be referred to as Unified Memory Semantics.

[0042] Different RPC protocols have different call performance. The RPC protocol used can be changed according to the needs of the actual application to change the way services are called. Typically, when it is necessary to change the first call method to the second call method, the operator can manually write supporting files (or dependency files) for the second call method, and manually modify the code associated with the call method in the calling device and the called device, so that the calling device can use the second call method to request services from the called device.

[0043] In the above process, operators manually write dependency files and modify the code associated with the calling method, which is tedious and inefficient.

[0044] Based on this, this application provides a service invocation method. In this method, when it is necessary to change the way a service is invoked, a first node obtains a first invocation request for a first service, and changes the first invocation method indicated by the first invocation request to a second invocation method, thus obtaining a second invocation request. The first node sends the invocation request with the changed invocation method (i.e., the second invocation request) to the second node. This eliminates the need to manually write supporting documents for the invocation method or manually modify the code associated with the invocation method, reducing the workload of operators and improving service invocation efficiency. Eliminating the need for manually writing supporting documents and modifying associated code lowers the professional requirements for operators.

[0045] Figure 2 is a schematic diagram of the structure of a service invocation system provided in this application. As shown in Figure 2, the service invocation system 200 may include multiple nodes 210. Each node 210 has one or more services deployed on it. The service invocation system 200 supports mutual service invocation between multiple nodes 210. Specifically, a node 210 can invoke one or more services deployed on another node 210 in the service invocation system 200. A node 210 can also simultaneously invoke services deployed on multiple other nodes 210 in the service invocation system 200; this application does not limit this. For example, services 1 and 2 are deployed on node 2, and service 3 is deployed on node 3. If node 1 can receive a request to invoke service 1, node 1 can use RPC to invoke service 1 on node 2 based on this request. Similarly, if node 1 can receive requests to invoke services 1 through 3, node 1 can use RPC to invoke services 1 and 2 on node 2, and service 3 on node 3 based on this request.

[0046] Node 210 in the service call system 200 can be a computing device or computing device cluster with a physical entity, or it can be a container, virtual machine, etc. without a physical entity. The following describes node 210 in different cases.

[0047] In scenario 1, node 210 is a computing device that has a physical entity.

[0048] In this scenario, node 210 can refer to the computing device shown in Figure 3. Figure 3 is a schematic diagram of the structure of a computing device provided in this application. As shown in Figure 3, the computing device 300 includes a communication interface 314, a processor 311, and a memory 312. The communication interface 314 is used to communicate with devices located outside the computing device 300. For example, a user inputs a request to obtain a first service to the computing device 300 through the communication interface 314 to obtain the first service. The computing device 300 obtains the processing result (such as the first service) based on the received request. This communication interface can be an input / output (I / O) interface. In some possible examples, the user can also use a client device 310 to input a request to obtain the first service to the computing device 300. The client device 310 can be a terminal device, including but not limited to a personal computer, server, mobile phone, tablet computer, or smart car. For example, the client device 310 can be terminal 1, terminal 2, terminal 3, etc. in Figure 3.

[0049] Processor 311 is the core of computing device 300 for both computation and control. It may include: a central processing unit (CPU), a specific integrated circuit, other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. In practical applications, computing device 300 may also include multiple processors. Processor 311 may include one or more processor cores. An operating system and other software programs are installed in processor 311, enabling it to access memory 312 and various peripheral component interconnect (PCIe) devices.

[0050] The processor 311 is connected to the memory 312 via a bus 315. The bus 315 can be a double data rate (DDR) bus or other types of bus. The memory 312 is the main memory of the computing device 300. The memory 312 is typically used to store various running software in the operating system. To improve the access speed of the processor 311, the memory 312 needs to have a high access speed. In traditional computer devices, dynamic random access memory (DRAM) is typically used as the memory 312. Besides DRAM, the memory 312 can also be other random access memories, such as static random access memory (SRAM). Alternatively, the memory 312 can also be a read-only memory (ROM). For example, a read-only memory could be a programmable read-only memory (PROM) or an erasable programmable read-only memory (EPROM). This embodiment does not limit the number or type of memory 312.

[0051] Scenario 2: Node 210 is a cluster of computing devices that have physical entities.

[0052] In this scenario, node 210 may include a cluster of computing devices comprising multiple computing devices as described in scenario 1. The multiple computing devices in this cluster may communicate via wired or wireless means.

[0053] The aforementioned wired communication methods can include: Ethernet, fiber optic, and various peripheral component interconnect express (PCIe) buses installed within the data access system to connect computing devices in a computing device cluster.

[0054] The aforementioned wireless communication methods can include: the Internet, wireless fidelity (WIFI), and ultra-wideband (UWB) technology, etc.

[0055] Scenario 3: Node 210 does not have a physical entity.

[0056] In this scenario, node 210 can be a container, virtual machine, etc. A virtual machine is a virtual device obtained by virtualizing physical computing, storage, and network resources using virtualization technology. In one possible example, a host may run one or more virtual machines (VMs), such as two VMs running on computer 1 and one VM running on computer 2. In another possible example, a VM may run on multiple computers, such as a VM utilizing the processing resources of computer 1 and the storage resources of computer 2.

[0057] In some possible scenarios, the service invocation system 200 may also include client equipment 220 (such as terminal 1, terminal 2, and terminal 3). In this case, the user uses client equipment 220 to send a request to node 210 to obtain the first service. Details regarding client equipment 220 can be found in the description above and will not be repeated here.

[0058] The service invocation system provided by this application has been described above with reference to the accompanying drawings. The service invocation method provided by this application is described below with reference to Figure 4. Figure 4 is a flowchart illustrating a service invocation method provided by this application, which can be applied to the service invocation system described in Figure 2. The service invocation system is deployed with multiple nodes. Each node deploys one or more services. The service invocation system supports a first node in multiple nodes invoking a service on a second node, and this method may include the following steps S410 to S450.

[0059] S410, the first node responds to the request to obtain the first service by generating the first call request.

[0060] In some possible scenarios, the first node can obtain the request for the first service in multiple ways. Examples of two possible methods are given below.

[0061] Example 1: The first node receives a request from a user to obtain the first service.

[0062] For example, the first node can receive a request from a user using a client device to obtain the first service.

[0063] Example 2: The first node generates a request to obtain the first service based on the execution process of its internal program.

[0064] For example, a first node executes a first program deployed within itself, and during the execution of this first program, the execution of the first program depends on a first service. In this scenario, the first node can generate a request to obtain the first service.

[0065] The above provides examples of two possible ways for the first node to obtain the request for the first service. Depending on the needs of the actual application, the first node may also use other methods to obtain the request for the first service, which is not limited in this application.

[0066] In some possible scenarios, after obtaining a request for the first service, the first node may detect that the first service is not deployed on the first node. In this case, the first node can generate a first invocation request based on the request to obtain the first service. The first node can then send this first invocation request to other nodes (such as the second node) where the first service is deployed to invoke the first service on the second node. The first invocation request instructs the use of a first invocation method to invoke the first service deployed on the second node. The first invocation method can refer to the defined method by which the first node invokes services on other nodes. The first invocation request may include a first identifier indicating the first invocation method. The first identifier can be the name, code, or identification code of the first invocation method, etc.

[0067] In some possible scenarios, the methods by which the first node invokes services on other nodes may include, but are not limited to: gRPC, Apache... TM Provides cross-language calling protocols Thrift, uRPC, and Alibaba Cloud. TM It provides open-source, high-performance, lightweight RPC protocol Dubbo; RESTful API (Representational State Transfer application programming interface) based on the REST (Representational State Transfer) architecture style; XML-RPC (Remote Procedure Call Protocol) which uses Extensible Markup Language (XML) to encode data and Hypertext Transfer Protocol (HTTP) as the transport protocol; and JSON-RPC (JavaScript Object Notation RPC) (Lightweight and stateless Remote Procedure Call Protocol) which uses JSON (JavaScript Object Notation) as the data format and HTTP and TCP as the transport protocols, among others.

[0068] Typically, different invocation methods support different serialization protocols. The time required to serialize the same object may vary depending on the serialization protocol. Table 1 shows the correspondence between the serialization protocols supported by several possible invocation methods.

[0069] Table 1 provides an example of the correspondence between invocation methods and serialization protocols.

[0070] The first invocation method set on the first node may not meet the needs of actual applications. For example, the first invocation method set on the first node supports a first serialization protocol, but the serialization efficiency provided by the first serialization protocol is low and cannot meet the needs of actual applications. In this case, the first invocation method set on the first node can be adjusted to a second invocation method. The second invocation method supports a second serialization protocol. The serialization efficiency provided by the second serialization protocol is higher than that provided by the first serialization protocol, which can meet the needs of actual applications. Furthermore, the first node can execute the following S420 to change the way the first node invokes services on other nodes.

[0071] S420, the first node generates a second call request based on the first call request.

[0072] The second call request is used to instruct the invocation of the first service on the second node using the second call method. The second call method differs from the first call method.

[0073] In some possible scenarios, the first invocation method supports the first serialization protocol. The second invocation method supports the second serialization protocol. The time required to serialize the first object using the second serialization protocol is less than or equal to the time required to serialize the first object using the first serialization protocol.

[0074] In some possible scenarios, the first node may perform the following (1) to (4) to generate a second call request that indicates the use of a second call method based on the first call request that indicates the use of a first call method.

[0075] (1) The first node parses the first call request and obtains the first identifier used to call the first service.

[0076] In this scenario, an agent, such as a Java Agent, can be installed on the first node. The first node uses the Java Agent to intercept the first call request sent from the first node to the second node. The first node parses the first call request and obtains the first identifier in the first call request that indicates the first calling method (such as Dubbo). For example, the first node parses call request 1 and obtains code 1 in call request 1, which is used to indicate the calling method Dubbo.

[0077] (2) The first node uses the first identifier to generate the first binary file corresponding to the first calling method.

[0078] In this scenario, the first node can obtain the supporting file (or dependency file) corresponding to the first calling method (such as Dubbo) based on the first identifier, and the first node can perform serialization on the supporting file to obtain the first binary file.

[0079] (3) The first node modifies the first binary file to the second binary file.

[0080] The second binary file is used to indicate the second invocation method.

[0081] In some possible scenarios, before modifying the first binary file to the second binary file, the first node can also execute the following steps ① to ③ to obtain the supporting files corresponding to the second invocation method. The supporting files corresponding to the second invocation method can refer to files needed during the process of invoking the service using the second invocation method, such as library files.

[0082] ① The first node obtains the interface information for calling the first service using the first calling method based on the first calling request.

[0083] In this scenario, the first node obtains the address of the interface that calls the first service using the first calling method, the communication method of the interface, the parameters of the interface (such as path parameters, query parameters, etc.), the interface response format, the interface status code, the interface timeout, the interface security, the interface performance indicators, the interface exception handling, the interface dependencies, etc., based on the first call request.

[0084] For example, the first node can obtain the interface information for calling the first service using the first calling method based on the class file of the first calling method indicated by the first calling request.

[0085] ② The first node generates the supporting files required for the second invocation method to invoke the first service based on the interface information.

[0086] Before executing step ②, the first node can determine the second invocation method based on the actual application requirements. In this case, the first interface can generate the supporting files required for the second invocation method to call the first service based on the interface information obtained in step ①.

[0087] For example, the first node can generate a serialized file (or binary file) based on the interface information in ①. For instance, the first node generates a Flowbuf serialized file 1 with the format ".fb" based on the interface information in ①. And based on file 1 with the format ".fb", the first node generates the support file 1 required for the first node to call the first service using the second calling method.

[0088] ③ The first node generates the second binary file based on the supporting file.

[0089] The first node can serialize the supporting files required for calling the first service using the second calling method generated in ②, and obtain the second binary file.

[0090] After generating the second binary file supporting the second invocation method for calling the first service using methods ① to ③ above, the first node can further modify the first binary file to the second binary file, thereby changing the way the first node calls the first service on the second node from the first invocation method to the second invocation method. The first node can modify the first binary file to the second binary file in various ways, such as using bytecode enhancement. The first node can also utilize a Java Agent to modify the first binary file to the second binary file.

[0091] (4) The first node generates a second call request based on the second binary file.

[0092] The second call request includes: the second identifier used to call the first service. The second identifier corresponds to the second call method.

[0093] After modifying the first binary file into the second binary file, the first node can also generate a second invocation request based on the invocation methods supported by the second binary file. The second invocation request is used to instruct the first service on the second node to be invoked using the second invocation method.

[0094] S430, the first node sends a second call request to the second node.

[0095] After generating the second call request, the first node can also send the second call request to the second node to invoke the first service on the second node using the second call method.

[0096] S440, the second node receives the second call request and sends the call result to the first node.

[0097] After receiving the second call request from the first node, the second node parses the second call request. The second node then invokes the first service deployed on the second node using the second call method indicated in the second call request, and sends the call result back to the first node.

[0098] S450: The first node receives the call result sent by the second node.

[0099] The first node receives the call result sent by the second node based on the second call request, and obtains the first service based on the call result.

[0100] The service invocation method provided by this application has been described above with reference to Figure 4. Figure 5 is a comparison diagram of one invocation method provided by this application. As shown in Figure 5, before using the service invocation method provided by this application, the first node uses the first invocation method to invoke the first service on the second node. After using the service invocation method provided by this application, the first node uses a proxy (such as a Java Agent) to intercept the first invocation request indicating that the first invocation method should be used to invoke the first service on the second node, and generates a second invocation request based on the first invocation request to indicate that the second invocation method should be used to invoke the first service on the second node. Finally, the first node uses the second invocation method to invoke the first service on the second node.

[0101] The above section, with reference to Figure 4, explained the service invocation method provided by this application, and Figure 5, with reference to Figure 5, showed the differences in service invocation between using the service invocation method provided by this application and not using the service invocation method provided by this application. The following section, with reference to Figure 6, provides an exemplary description of the service invocation method provided by this application.

[0102] Figure 6 is an example diagram of a service invocation method provided in this application. The first node and the second node are both containers, and the first service is deployed on the second node. The first node and the second node are deployed on a cloud platform and are managed by Kubernetes (K8s). The invocation method set on the first node and the second node needs to be changed from the first invocation method (or AA) to the second invocation method (or BB). The serialization protocol supported by BB is FlowBuf. The first node and the second node can execute (1) to (4) shown in Figure 6(a) to change the set invocation method from AA to BB, and the first node and the second node can change AA to BB according to the architecture diagram shown in Figure 6(b).

[0103] Taking the process shown in Figure 6(a) and Figure 6(b) as an example, where the calling method of the first node is changed from AA to BB, the service calling method provided in this application is illustrated by way of example.

[0104] (1) The first node obtains the container creation request.

[0105] In this scenario, the first node can use the Operator to obtain the container creation request. This Operator can be customized by the user according to the needs of the actual application; this application does not impose any restrictions on it.

[0106] (2) The first node creates a container.

[0107] The first node can create a container based on the received Pod creation request.

[0108] For example, Figure 7 is an example diagram of container creation provided by this application. As shown in Figure 7, the first node can receive the command "kunectl apply -f AA.yaml" sent by the user, and send a Pod creation request using a YAML file based on the command. The first node uses "kube-apiserver" to execute the Pod creation request to create a Pod, and then creates a container based on the Pod.

[0109] (3) The first node obtains the supporting files required by BB.

[0110] This process may include the following ① to ③.

[0111] ① The first node performs initialization.

[0112] During the creation of a Pod using "kube-apiserver", the first node's Operator intercepts the Pod creation process and injects a container for initialization into the Pod. In some possible scenarios, this initialization container can be called an Init container. Figure 8 shows an example of initialization provided in this application. As shown in Figure 8, the first node uses the Operator to inject an Init container into the Pod. Depending on the needs of the actual application, the first node can also use the Operator to inject more (such as two Init containers) into the Pod, etc., which is not limited in this application.

[0113] ②The first node obtains the supporting files required by BB.

[0114] In this scenario, the Init container in the first node can mount the Java Agent to start AA. Figure 9 is an example diagram of obtaining support files provided by this application. As shown in Figure 9, the Init container in the first node can pull the original application image including AA from the image repository, perform serialization preprocessing on the original AA image to obtain the serialized preprocessed application image, and write the serialized preprocessed application image into the image repository. The specific process can be described as follows.

[0115] The Java Agent can enhance the `parse` function of `AABeanDefinitionParser` in the AA (Application Analyzer) to obtain the interface information parsed by the AA. When the first node is the service caller (or client), it can obtain the `HelloService` interface method information. And when the first node is the service recipient (or server), it can obtain the `HelloServiceImpl` interface method information.

[0116] If the first node is the service caller, the first node can use steps 1 to 3 below to obtain the support files required by BB.

[0117] 1. The first node can generate a file in the format ".fb" (such as the Hello.fb file) based on the HelloService interface method information. The Hello.fb file can include the pseudocode shown in Table 2.

[0118] Table 2 shows an example of the Hello.fb file.

[0119] 2. The first node can execute the command "flowc-tjava-gBB_d hello.fb" to generate the support files required for BB serialization.

[0120] 3. The first node can execute "javac Hello.java" to generate the bytecode file Hello.class, and execute "javac HelloBB.java" to generate the bytecode file HelloBB.class, and create the implementation class HelloAllocator of FlowBuffer.Allocator, which can be implemented using the pseudocode shown in Table 3 below.

[0121] Table 3 shows an example of a client obtaining BB support files.

[0122] The first node obtains the pre-serialized application image based on the class HelloAllocator, and pulls the pre-serialized application image to the image repository.

[0123] When the first node is the server, the first node can execute step 4 to obtain the support files required by BB.

[0124] 4. Modify the bytecode file corresponding to HelloServiceImpl in the first node to make it inherit HelloBB.HelloService, and add sayHello(Hello.Request req) and parameterized constructor. The first node can implement the above functions using the pseudocode shown in Table 4 below.

[0125] Table 4 shows an example of how the server obtains BB support files.

[0126] After implementing the above functions, the first node can also obtain the flowbuf-test-SNAPSHOT.jar and BB-java-test-SNAPSHOT.jar that BB depends on. Based on the obtained files that BB depends on, the first node obtains the serialized preprocessed application image and outputs the serialized preprocessed application image to the original image.

[0127] ③ The first node stores the Java Agent in the Pod shared storage.

[0128] Figure 10 is an example diagram of storing a Java Agent provided by this application. As shown in Figure 10, after storing the application image after serialization preprocessing to the image repository, the first node can also pull the Java Agent image from the image repository to the Init containor, and store the Java Agent image in the Init containor to the Pod shared storage so that it can be obtained when the main container starts.

[0129] After the first node executes steps (1) to (3) above to obtain the support file for the second invocation method and obtains the request for the first service, the first node can generate a first invocation request and modify the first invocation method indicated by the first invocation request to the second invocation method based on the support file for the second invocation method obtained using the above process. The first node can modify the first invocation method indicated by the first invocation request to the second invocation method using the method described in step (4) below to obtain the second invocation request. The first node then sends the second invocation request to the second node to obtain the first service.

[0130] (4) Change the first node AA to BB.

[0131] In this process, the first node pulls the Java Agent image from the Pod's shared storage and the pre-serialized application image from the image repository, and starts the main container. During the call, it modifies the calling method used. This modification changes the serialization protocol. In some possible scenarios, the main container can also be called the user container. This process can specifically include the following ① to ③.

[0132] ① The first node can use bytecode enhancement to intercept the startup methods of the Allocator (AA) on both the client and server sides, performing Allocator registration and initialization during the AA startup process. In some possible scenarios, the AA can also be referred to as the AA service.

[0133] Depending on the location of the first node, the first node can use different methods to intercept the AA's startup method, which will be explained below.

[0134] In scenario 1, the first node is the client.

[0135] In this scenario, the first node can execute the intercept service startup class ConsumerApplication to intercept the startup method of AA. The first node can also implement this function using the pseudocode in Table 5 below before the main method is executed.

[0136] Table 5. Methods for Client-Side Interception of AA Startup

[0137] In scenario 2, the first node is the server.

[0138] In this scenario, the first node can execute the intercept service startup class ProviderApplication to intercept the startup method of AA. The first node can also implement this function using the pseudocode in Table 6 below before the main method is executed.

[0139] Table 6. Server-side interception of AA startup methods

[0140] ② The first node intercepts the XML parsing interface of AA, and when the first node is the server, it parses the service information, namely the HelloServiceImpl information, for the server (or provider), and registers the service based on the service information. The first node can implement the registration using the pseudocode in Table 7 below.

[0141] Table 7 Server Registration

[0142] In some possible scenarios, the steps required to initiate a call method will differ depending on the calling method itself. For calling methods that require registration (such as BlackBerry), a registration process must be performed; for calling methods that do not require registration, this process is unnecessary.

[0143] ③ The first node intercepts the AA's API call.

[0144] For example, the first node intercepts the invoke method of MonitorFilter, and when calling the sayHello method of HelloService, it changes the calling method to BB calling method, executes the pseudocode shown in Table 8 below, and does not execute the pseudocode associated with AA, and directly returns the result.

[0145] Table 8 shows the modified calling method as BB.

[0146] In the above embodiments, when it is necessary to change the way a service is invoked, the first node obtains a first invocation request for the first service and changes the first invocation method indicated by the first invocation request to a second invocation method, thus obtaining a second invocation request. The first node sends the invocation request with the changed invocation method (i.e., the second invocation request) to the second node. This eliminates the need to manually write supporting files for the invocation method and manually modify the code associated with the invocation method, reducing the workload of operators, improving service invocation efficiency, and lowering the professional requirements for operators.

[0147] The above, with specific examples, further illustrates the service invocation method provided in this application. It is understood that, to implement the functions in the above embodiments, the first node includes the corresponding hardware structure and / or software module for executing each function. Those skilled in the art should readily recognize that, based on the units and method steps described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed through hardware or computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0148] The service invocation method provided by this application has been described above with reference to Figures 3 to 10. The service invocation apparatus provided by this application is described below with reference to Figure 11. Figure 11 is a schematic diagram of the structure of a service invocation apparatus provided by this application. The service invocation apparatus 1100 includes a processing module 1110 and a transceiver module 1120. The service invocation apparatus 1100 can implement the function of the first node in the method embodiments described in Figures 4 to 10.

[0149] Processing module 1110 is configured to: generate a first call request in response to a request to obtain a first service. The first call request indicates that the first service deployed on the second node is invoked using a first call method. Processing module 1110 is further configured to: generate a second call request based on the first call request. The second call request indicates that the first service on the second node is invoked using a second call method. The second call method differs from the first call method. Transceiver module 1120 is configured to: send the second call request to the second node.

[0150] In one possible scenario, the first invocation method supports the first serialization protocol. The second invocation method supports the second serialization protocol. The time required to serialize the first object using the second serialization protocol is less than or equal to the time required to serialize the first object using the first serialization protocol.

[0151] In one possible scenario, processing module 1110 is specifically configured to: parse the first call request to obtain the first identifier used to call the first service. Processing module 1110 is also specifically configured to: generate a first binary file corresponding to the first calling method using the first identifier. Processing module 1110 is further specifically configured to: modify the first binary file into a second binary file. The second binary file is used to indicate the second calling method.

[0152] The processing module 1110 is further specifically used to: generate a second invocation request based on the second binary file. The second invocation request includes: a second identifier used to invoke the first service. The second identifier corresponds to the second invocation method.

[0153] In one possible scenario, processing module 1110 is further configured to: obtain interface information for calling the first service using the first calling method based on the first calling request. Processing module 1110 is further configured to: generate support files required for calling the first service using the second calling method based on the interface information. Processing module 1110 is further configured to: generate a second binary file based on the support files.

[0154] In one possible scenario, the first node is a container.

[0155] In one possible scenario, the second invocation method includes one or more of the following: gRPC, Thrift, uRPC, Dubbo, RESTful API, XML-RPC, and JSON-RPC.

[0156] In one possible scenario, the transceiver module 1120 is also used to: receive the call result sent by the second node.

[0157] Both the processing module 1110 and the transceiver module 1120 can be implemented in software or in hardware. For example, the implementation of the processing module 1110 will be described below. Similarly, the implementation of the transceiver module 1120 can be referenced from that of the processing module 1110.

[0158] As an example of a software functional unit, processing module 1110 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, processing module 1110 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0159] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0160] As an example of a hardware functional unit, the processing module 1110 may include at least one computing device, such as a server. Alternatively, module A may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0161] The processing module 1110 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the processing module 1110 can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the processing module 1110 can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0162] It should be noted that, in other embodiments, the processing module 1110 can be used to execute any step in the service invocation method, and the sending and receiving module 1120 can be used to execute any step in the service invocation method. The steps implemented by the processing module 1110 and the sending and receiving module 1120 can be specified as needed. The processing module 1110 and the sending and receiving module 1120 respectively implement different steps in the service invocation method to realize all the functions of the service invocation device.

[0163] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0164] Figure 12 is a schematic diagram of a computing device cluster provided in this application. As shown in Figure 12, the computing device cluster includes at least one computing device 300 as described in Figure 3. When the computing device cluster includes two computing devices, and the two computing devices are a server and a terminal with a client deployed, respectively, the computing device cluster can constitute the service invocation system 200 described in Figure 2. In other words, the service invocation system 200 described in Figure 2 is a specific example of the computing device cluster shown in Figure 12.

[0165] The memory 312 of one or more computing devices in a computing device cluster may contain the same instructions for executing service call methods.

[0166] In some possible implementations, the memory 312 of one or more computing devices in the computing device cluster may also each store a portion of the instructions for executing the service invocation method. In other words, a combination of one or more computing devices can jointly execute the instructions for executing the service invocation method.

[0167] In some other possible implementations, the memories in different computing devices within the computing device cluster can store different instructions, each used to execute a portion of the functions of the service invocation device. That is, the instructions stored in the memories of different computing devices can implement the functions of one or more modules in processing module 1110 and transceiver module 1120.

[0168] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 13 is a schematic diagram of a possible connection method for a computing device cluster provided in this application. As shown in Figure 13, two computing devices 300A and 300B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this type of possible implementation, the memory in computing device 300A stores instructions for executing the functions of processing module 1110. Simultaneously, the memory in computing device 300B stores instructions for executing the functions of transceiver module 1120.

[0169] The connection method between the computing device clusters shown in Figure 13 can be considered as follows: taking into account that the service calling method provided in this application needs to store a large amount of data (such as the support file for the second calling method), the function implemented by the transceiver module 1120 is to be executed by the computing device 300B.

[0170] It should be understood that the functions of computing device 300A shown in Figure 13 can also be performed by multiple computing devices. Similarly, the functions of computing device 300B can also be performed by multiple computing devices.

[0171] This application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similarly referred to the connection method of the computing device cluster shown in Figures 12 and 13. The difference is that the memory of one or more computing devices in this computing device cluster can store the same instructions for executing service invocation methods.

[0172] In some possible implementations, the memory of one or more computing devices in the computing device cluster may also store partial instructions for executing the service invocation method. In other words, a combination of one or more computing devices can jointly execute the instructions for executing the service invocation method.

[0173] In a computing device cluster, the memories of different computing devices can store different instructions to execute parts of the service call system's functions. That is, the instructions stored in the memories of different computing devices can implement one or more functions deployed on the client and server sides of the terminal.

[0174] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a computing device. Of course, the processor and storage medium can also exist as discrete components in a network device or terminal device.

[0175] This application also provides a chip system including a processor for implementing the functions of the first node and / or the second node in the above-described method. In one possible design, the chip system further includes a memory for storing program instructions and / or data. This chip system may be composed of chips or may include chips and other discrete devices.

[0176] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computing device, the processes or functions described in the embodiments of this application are performed entirely or partially. The computing device can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0177] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A service invocation method, characterized in that, The method is applied to a cloud management platform, which has multiple nodes deployed, each node deploying one or more services. The cloud management platform supports a first node among the multiple nodes calling services on a second node. The method is executed by the first node and includes: In response to a request to obtain a first service, a first invocation request is generated; the first invocation request is used to instruct the first service deployed in the second node to be invoked using a first invocation method; Based on the first call request, a second call request is generated; the second call request is used to indicate that the first service on the second node is called using a second call method, which is different from the first call method. Send the second call request to the second node.

2. The method according to claim 1, characterized in that, The first invocation method supports a first serialization protocol, and the second invocation method supports a second serialization protocol. The time required to serialize the first object using the second serialization protocol is less than or equal to the time required to serialize the first object using the first serialization protocol.

3. The method according to claim 1 or 2, characterized in that, The step of generating a second call request based on the first call request includes: Parse the first call request to obtain the first identifier used to call the first service; The first binary file corresponding to the first invocation method is generated using the first identifier; Modify the first binary file to a second binary file; the second binary file is used to indicate the second invocation method; Based on the second binary file, a second call request is generated. The second call request includes a second identifier used to call the first service, and the second identifier corresponds to the second call method.

4. The method according to claim 3, characterized in that, Before modifying the first binary file into a second binary file, the method further includes: Based on the first call request, obtain the interface information for calling the first service using the first call method; Based on the interface information, generate the support files required for the second invocation method to invoke the first service; The second binary file is generated based on the supporting file.

5. The method according to any one of claims 1-4, characterized in that, The first node is a container.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Receive the call result sent by the second node.

7. The method according to any one of claims 1-6, characterized in that, The second invocation method includes one or more of the following: high-performance remote procedure call protocol gRPC, Thrift, unified RPC call protocol uRPC, high-performance lightweight RPC protocol Dubbo, RESTful API based on REST architecture style application programming interface, XML-RPC remote procedure call protocol that uses Extensible Markup Language to encode data and Hypertext Transfer Protocol as the transport protocol, and JSON-RPC, a lightweight and stateless remote procedure call protocol that uses JSON as the data format and HTTP and TCP as the transport protocol.

8. A service invocation device, characterized in that, The device includes: The processing module is configured to: generate a first invocation request in response to a request to obtain a first service; the first invocation request is configured to instruct the first service deployed in the second node to be invoked using a first invocation method; The processing module is further configured to: generate a second call request based on the first call request; the second call request is used to indicate that the first service on the second node is called using a second call method, the second call method being different from the first call method; The transceiver module is used to send the second call request.

9. The apparatus according to claim 8, characterized in that, The first invocation method supports a first serialization protocol, and the second invocation method supports a second serialization protocol. The time required to serialize the first object using the second serialization protocol is less than or equal to the time required to serialize the first object using the first serialization protocol.

10. The apparatus according to claim 8 or 9, characterized in that, The processing module is specifically used to: parse the first call request to obtain the first identifier used to call the first service; The processing module is further specifically used to: generate a first binary file corresponding to the first calling method using the first identifier; The processing module is further specifically used to: modify the first binary file into a second binary file; the second binary file is used to indicate the second calling method; The processing module is further specifically configured to: generate the second call request based on the second binary file, the second call request including: a second identifier used to call the first service, the second identifier corresponding to the second call method.

11. The apparatus according to claim 10, characterized in that, The processing module is further configured to: obtain interface information for calling the first service using the first calling method based on the first calling request; The processing module is further configured to: generate, based on the interface information, the supporting files required for the second invocation method to invoke the first service; The processing module is further configured to: generate the second binary file based on the supporting file.

12. The apparatus according to any one of claims 8-11, characterized in that, The transceiver module is also used to: receive the call result sent by the second node.

13. A service invocation system, characterized in that, The service invocation system is deployed with multiple nodes, and each node deploys one or more services. The service invocation system supports a first node in one of the multiple nodes in calling a service on a second node. In response to a request to obtain a first service, the first node generates a first invocation request; the first invocation request is used to instruct the first service deployed in the second node to be invoked using a first invocation method; The first node generates a second call request based on the first call request; the second call request is used to indicate that the first service on the second node is called using a second call method, which is different from the first call method. The first node sends the second call request to the second node.

14. A processor, characterized in that, The processor includes an interface circuit and a control circuit; the interface circuit is used to acquire a component integration request and, in conjunction with the control circuit, execute the method of any one of claims 1-7.

15. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, and each computing device includes a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-7.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions; when the computer instructions are executed in a computing device, the computing device performs the method of any one of claims 1-7.

17. A computer program product, characterized in that, When the computer program product is run in a computing device, the computing device performs the method of any one of claims 1-7.

Images