Service calling method and device and related equipment

Abstract

The invention provides a service calling method, which is used for realizing service calling of the same process and cross-process service by using the same calling mode. The service calling method comprises the steps that in response to calling of a second service in the running process of a first service, whether the second service is included in a local process or not is judged, and the first service is the service in the local process; if the local process comprises the second service, calling the second service in the local process; if the local process does not include the second service, acquiring a remote calling address of the second service, and calling the second service based on the remote calling address of the second service. The invention further provides a corresponding device, a computing device cluster, a computer readable storage medium and a computer program product.

Description

Technical Field

[0001] This application relates to the field of distributed technology, and in particular to a service invocation method, apparatus and related equipment. Background Technology

[0002] In a distributed architecture, an application can be broken down into multiple small, relatively independent services. For example, it can be split according to specific business functions. Each service can be developed, deployed, and scaled independently. Different services can be distributed within the same process or across different processes. Optionally, different services of the same application can be deployed on different physical machines or virtual machines.

[0003] During application execution, services can call each other to achieve the application's functionality. Since different services can belong to the same process or different processes, a service may need to call services within the same process as well as services in other processes. These two calling methods can be referred to as intra-process service calls and cross-process service calls, respectively.

[0004] Currently, different services need to be deployed for service calls within the same process and service calls across processes, and different methods need to be used for these calls, which leads to complex development and a large amount of code. Summary of the Invention

[0005] In view of this, this application provides a service invocation method for implementing intra-process service invocation and cross-process service invocation using the same invocation method. This application also provides corresponding apparatus, computing device clusters, computer-readable storage media, and computer program products.

[0006] Firstly, this application provides a service invocation method. During the execution of a first service, if it is found that the first service needs to invoke a second service, it can first determine whether the local process corresponding to the first service includes the second service. The local process corresponding to the first service refers to the process to which the first service belongs, i.e., the local process includes the first service. If the local process includes the second service, then the first service can invoke the second service in the local process using a same-process invocation method. If the local process does not include the second service, then the first service can obtain the remote invocation address of the second service and invoke the second service based on that address. In other words, whether to use a same-process or cross-process invocation method for the second service is determined during the execution of the first service, not during its development. Therefore, when developing the first service, it is not necessary to concern oneself with whether the first and second services belong to the same process at runtime. This simplifies the development process of the first service by eliminating the need for developers to understand the specific implementation and deployment location of the service. For the second service, since the first service does not need to distinguish between same-process and cross-process invocation methods, it is not necessary to develop different versions of the second service for different invocation methods. This reduces the amount of code required during development and lowers the development difficulty.

[0007] Furthermore, when the second service needs to be called, the first service first checks whether the local process includes the second service. If not, it then uses the remote call address of the second service to make a cross-process call. In this way, regardless of whether the second service runs in the local process or another process, the first service can complete the call to the second service. This ensures the normal operation of the first service.

[0008] In some possible implementations, the remote call address of the second service can be obtained through a registry center. The registry center records the remote call addresses of each service. After a service is loaded, the association between the service's identifier and its remote call address can be recorded in the registry center. Correspondingly, the first service can use the identifier of the second service to look up the association stored in the registry center, thereby obtaining the remote call address of the second service.

[0009] In some possible implementations, service calls can be implemented using pass-by-value. Specifically, when the first service calls the second service, it can run the second service based on the second service's remote call address. Furthermore, the first service can pass the second service its input parameters as values. After execution, the second service can return the values ​​required by the first service as return values. During its execution, the second service does not modify the input parameters. In this way, by implementing service calls through pass-by-value, the service does not need to access the memory space of other services based on memory addresses, thus resolving the semantic inconsistency between intra-process and cross-process calls.

[0010] In some possible implementations, the modification of input parameters by the second service can be prevented by restricting its code. Specifically, the second service's code may not include write operation code. Write operation code is used to perform write operations on the first service's memory space during the second service's execution. In this way, since no write operation code is included, the second service does not need to access the first service's memory space, nor does it need to modify the data stored in the first service's memory space, ensuring semantic consistency between intra-process and cross-process calls.

[0011] In some possible implementations, to avoid semantic inconsistencies between intra-process and cross-process calls, the service code can be scanned. Specifically, before deploying the first service, its corresponding code can be obtained. Then, this code can be scanned to determine if it contains cross-service parameter access statements. Cross-service parameter access statements are used to access parameters outside the first service. If the code for the first service contains cross-service parameter access statements, it indicates that the first service may need to access the memory of other services during its operation. Thus, the execution result of the first service will differ depending on whether the accessed service belongs to the same process as the first service, or whether they belong to different processes, resulting in semantic inconsistencies. Therefore, after determining that the code for the first service does not contain cross-service parameter access statements, the first service can be deployed as a plugin.

[0012] In some possible implementations, different programming languages ​​can be used for service development. Specifically, when developing the code for the first service, developers can first input the interface description information of the first service. The interface description information describes the relevant information involved in calling the first service, such as the input parameters and return values. Next, multiple interface call codes corresponding to various programming languages ​​can be generated based on the interface description information. After obtaining the logic code corresponding to the first service, the target interface call code can be determined from the multiple interface call codes based on the programming language corresponding to the logic code. Then, the code corresponding to the first service can be obtained based on the target interface call code and the logic code. In this way, interface call code matching different programming languages ​​can be automatically generated, achieving support for multiple programming languages.

[0013] In some possible implementations, the target API call code can be determined based on the user's triggered action. Specifically, after generating multiple API call codes, several language selection controls can be displayed to the user. Each language selection control corresponds to a programming language. Developers can select the language selection control corresponding to their programming language (hereinafter referred to as the target language selection control) from among the multiple language selection controls. Based on the actions triggered by the developer on the target language selection control, the API call code corresponding to the programming language of the target language selection control can be determined as the target API call code.

[0014] Secondly, this application provides a service invocation apparatus, the apparatus comprising: a judgment module, configured to, in response to a call to a second service during the operation of a first service, determine whether the second service is included in a local process, wherein the first service is a service in the local process; a local invocation module, configured to, if the local process includes the second service, invoke the second service in the local process; and a remote invocation module, configured to, if the local process does not include the second service, obtain the remote invocation address of the second service, and invoke the second service based on the remote invocation address of the second service.

[0015] In some possible implementations, the remote call module is specifically used to look up the remote call address of the second service from the registry center based on the identifier of the second service; wherein, the registry center records the association between the identifier of the second service and the remote call address of the second service, and the association is recorded in the registry center after the second service is loaded.

[0016] In some possible implementations, the remote call module is specifically used to run the second service according to the remote call address of the second service; during the operation of the second service, the input parameters are not modified, and the input parameters are the parameters passed to the second service when the first service calls the second service.

[0017] In some possible implementations, the code for the second service does not include write operation code, which is used to perform write operations on the memory space of the first service during runtime.

[0018] In some possible implementations, the apparatus further includes a service deployment module; the service deployment module is configured to obtain the code corresponding to the first service; determine whether the code corresponding to the first service includes a cross-service parameter access statement, the cross-service parameter access statement being used to access parameters other than the first service; and, in response to the code corresponding to the first service not including the cross-service parameter access statement, deploy the first service as a plugin based on the code corresponding to the first service.

[0019] In some possible implementations, the apparatus further includes a code acquisition module; the code acquisition module is configured to acquire interface description information of a first service, the interface description information of the first service being used to describe the relevant information involved in calling the first service; generate multiple interface call codes based on the interface description information, the multiple call interfaces corresponding to multiple programming languages; acquire logic code corresponding to the first service; and obtain code corresponding to the first service based on the logic code and the target interface call code, the target interface call code being the interface call code among the multiple interface call codes whose programming language matches the logic code.

[0020] In some possible implementations, the code acquisition module is further configured to display the plurality of language selection controls, each language selection control corresponding to one of the plurality of programming languages; in response to an operation triggered by a target language selection control among the plurality of language selection controls, the module determines the target interface call code, wherein the programming language corresponding to the target language selection control is consistent with the programming language corresponding to the target interface call code.

[0021] Thirdly, this application provides a computing device, the computing device including at least one processor and at least one memory; the at least one memory is used to store instructions, and the at least one processor executes the instructions stored in the at least one memory to cause the computing device to perform the method in the first aspect or any possible implementation thereof. It should be noted that the memory may be integrated into the processor or may be independent of the processor. The at least one computing device may also include a bus. The processor is connected to the memory via the bus. The memory may include readable storage and random access memory.

[0022] Fourthly, this application provides a computing device cluster, the computing device including at least one computing device, the at least one computing device including at least one processor and at least one memory; the at least one memory is used to store instructions, and the at least one processor executes the instructions stored in the at least one memory to cause the computing device cluster to perform the method in the first aspect or any possible implementation of the first aspect. It should be noted that the memory can be integrated into the processor or can be independent of the processor. The at least one computing device may also include a bus. The processor is connected to the memory via the bus. The memory may include readable storage and random access memory.

[0023] Fifthly, this application provides a computer-readable storage medium storing instructions that, when executed on at least one computing device, cause the at least one computing device to perform the method described in the first aspect or any implementation thereof.

[0024] In a sixth aspect, this application provides a computer program product containing instructions that, when run on at least one computing device, cause the at least one computing device to perform the method described in the first aspect or any implementation thereof.

[0025] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0027] Figure 1 A schematic diagram illustrating an application scenario provided in this application embodiment;

[0028] Figure 2 A flowchart of a service invocation method provided in the embodiments of this application;

[0029] Figure 3 A flowchart of a service development method provided in the embodiments of this application;

[0030] Figure 4 A schematic diagram of the structure of a service invocation device provided in an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0032] Figure 6 This application provides a schematic diagram of the structure of a computing device cluster.

[0033] Figure 7 This is a schematic diagram of another structure of a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0034] The solutions in the embodiments provided in this application will now be described with reference to the accompanying drawings.

[0035] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application.

[0036] First, let me introduce some of the terms used in this application.

[0037] Distributed architecture: Distributed architecture refers to a technique that breaks down an application into multiple services and develops, deploys, and scales them on a service-by-service basis. In a distributed architecture, complex applications can be broken down into relatively simple services, facilitating development and deployment. Different services can belong to different processes, and these processes can run on different virtual or physical devices.

[0038] Service invocation: A service invocation is when one service calls another service, such as one service requesting data from another. Service invocation is the foundation for implementing distributed architectures. Calls between services belonging to the same process are called intra-process service invocations. Calls between services belonging to different processes are called cross-process service invocations.

[0039] Platform: In a distributed architecture, a platform can refer to a collection of basic, general-purpose services and tools. The services and tools within a platform support the various services that enable applications to be developed and run on that platform.

[0040] In a distributed architecture, an application can be broken down into multiple services. During the operation of one service, it may need specific data from other services. To do this, the current service can call the required service to provide the specific data.

[0041] Currently, intra-process and cross-process calls require different service implementations. In other words, for the same functionality, two sets of services need to be designed for intra-process and cross-process calls. Correspondingly, when other services within the same process call, they can invoke the service designed for intra-process calls. When services in other processes call, they can invoke the service designed for cross-process calls.

[0042] This necessitates writing different services for different calling scenarios, and requiring different methods for invocation. On one hand, writing different services increases the amount of application code and development costs. On the other hand, since services in the local process and services in the non-local process need to be invoked in different ways, during service development, if a service call is required, developers also need to determine whether the called service belongs to the same process as the current service, and set different invocation methods in the service based on the determination result. Thus, developers need to pay attention to the specific implementation and deployment location of the service, further increasing development costs.

[0043] For example, suppose application X includes services A, B, and C, where services A and C belong to the same process, while services B and C belong to different processes. Both services A and B need to call service C during their execution. Therefore, to facilitate calls to service C from services within the same process (such as service A) and services across processes (such as service B), different versions of the service need to be developed for intra-process and cross-process calls. In other words, service C1 needs to be developed for intra-process calls, and service C2 needs to be developed for cross-process calls. Developing different versions of code for the same service increases the amount of code and development costs.

[0044] Furthermore, because service C1 is used for intra-process calls while service C2 is used for remote calls, when developing services A and B, it's necessary to understand the relationships between services A and C, as well as the relationships between services B and C, beforehand. This means that when developing service A, code calling service C1 is used, and when developing service B, code calling service C2 is used. This not only requires developing different versions of the called service for different calling methods, but also necessitates understanding the deployment relationship between the calling service and the called service. For example, assuming services A and C are deployed on device 1, and service B is deployed on device 2, developers need to know the deployment methods of the services beforehand to determine whether service A calls service C via intra-process calls or whether service B calls service C via cross-process calls. This further increases the development difficulty by requiring developers to understand the specific implementation and deployment location of the services.

[0045] Based on this, embodiments of this application provide a service invocation method. This method can implement both intra-process and cross-process service invocations using the same invocation method. Specifically, during the execution of a first service, if it is found that the execution of the first service requires invocation of a second service, it can first determine whether the local process corresponding to the first service includes the second service. The local process corresponding to the first service refers to the process to which the first service belongs, that is, the local process includes the first service. If the local process includes the second service, then the first service can invoke the second service in the local process using the intra-process invocation method. If the local process does not include the second service, then the first service can obtain the remote invocation address of the second service and invoke the second service based on the remote invocation address of the second service. In other words, whether to invoke the second service using the intra-process or cross-process invocation method is determined during the execution of the first service, not during the development of the first service. Therefore, when developing the first service, it is not necessary to concern oneself with whether the first service and the second service belong to the same process at runtime. In this way, developers do not need to understand the specific implementation and deployment location of the service, simplifying the development process of the first service. For the second service, since the first service does not need to distinguish between intra-process and cross-process invocation methods, it is not necessary to develop different versions of the second service for different invocation methods. This reduces the amount of code that needs to be developed and lowers the development difficulty.

[0046] Furthermore, when the second service needs to be called, the first service first checks whether the local process includes the second service. If not, it then uses the remote call address of the second service to make a cross-process call. In this way, regardless of whether the second service runs in the local process or another process, the first service can complete the call to the second service. This ensures the normal operation of the first service.

[0047] Next, various non-limiting implementation methods of the service invocation process will be described in detail.

[0048] First, we will introduce some exemplary application scenarios.

[0049] See Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of the service invocation method provided in an embodiment of this application. Figure 1 The application scenario shown includes user A, device 10, device 20, and server 30. Device 10 runs client 11, device 20 runs client 21, and server 30 runs server 31. Device 10 also runs process 12, which includes services 121 and 122. Device 20 runs process 22, which includes service 221. User A is a user of device 10. User A can develop services through client 11 on device 10 or run processes on device 10 through client 11. Optionally, client 11 and client 21 can be clients of the platform. Server 31 can be a server of the platform. Optionally, server 31 can be a registry center of the platform, used to implement service discovery capabilities.

[0050] Server 30 can be a single server or a server cluster consisting of multiple servers. Similarly, device 10 and device 20 can be a single device or a device cluster consisting of multiple devices.

[0051] User A can run service 121 on device 10 via client 11. If service 121 needs to call service 122 during its operation, client 11 can determine whether the process to which service 121 belongs (i.e., process 12) includes service 122. Since both service 122 and service 121 belong to process 12, service 122 can be called in the same process call manner to continue running service 121. If service 121 needs to call service 221 during its operation, client 11 can determine whether the process to which service 121 belongs (i.e., process 12) includes service 221. Since process 12 does not include service 221, client 11 can obtain the remote call address of service 221 and, based on the remote call address of service 221, remotely call client 21 on device 20 to run service 221, thereby realizing the call to service 221. Optionally, client 11 can send an address retrieval request to server 30. Server 30 can query the remote call address of service 221 based on the address retrieval request and return it to client 21.

[0052] The preceding text introduced some implementation methods for calling other services during service operation. Before service operation, users can also develop and deploy services through the client. Specifically, when developing service 121, user A can input the corresponding code for service 121 on client 11. After completing the development of service 121, user A can deploy service 121 to device 10. Optionally, user A can also input the code for service 221 on client 11 and, after completing the development of service 221, deploy service 221 to device 20.

[0053] For an introduction to service development and service deployment, please refer to the following text; it will not be repeated here.

[0054] The following section provides a detailed introduction to the specific implementation methods in the service invocation process.

[0055] See Figure 2 , Figure 2 This is a flowchart illustrating a service invocation method provided in an embodiment of this application. This method can be applied to... Figure 1 The application scenario shown can also be applied to other applicable application scenarios. If this method is applied to... Figure 1 Given the application scenario shown, this method can be executed by client 11.

[0056] It should be noted that the service invocation method provided in this application embodiment is used in application scenarios where one service invokes other services. Figure 2 In a corresponding embodiment, the service that calls other services can be referred to as the first service, and the service being called can be referred to as the second service. That is to say, Figure 2 The method shown can be applied to application scenarios where the first service needs to call the second service during its operation. Optionally, the first service can be... Figure 1 In the implementation shown, service 121, the second service can be... Figure 1 The implementation shown is either service 122 or service 221.

[0057] Specifically, Figure 2 The service invocation methods shown may specifically include:

[0058] S201: In response to a call to the second service during the operation of the first service, determine whether the second service is included in the local process.

[0059] During the execution of the first service, if the first service needs to call the second service, it can be determined whether the second service is included in the local process. Here, the local process refers to the process to which the first service belongs. For example, in... Figure 1 In the implementation shown, if the first service is service 121, the local process is process 12.

[0060] First, we can determine whether the second service needs to be called during the operation of the first service.

[0061] In this embodiment, "the first service calling the second service" means that the first service requires parameters from the second service during its operation. In other words, the parameters input to the first service include parameters from the second service; that is, the output parameters of the second service are the input parameters of the first service.

[0062] Therefore, it can be determined from the code of the first service that the second service needs to be called during the operation of the first service. For example, the code of the first service can be analyzed before or during its operation to determine whether the first service requires parameters from the second service.

[0063] Optionally, when the first service starts running, it can be determined that the second service needs to be called during its operation. For example, the declaration of the code corresponding to the first service may include declarations of input parameters. When the first service runs, based on the declarations of input parameters for the first service in the code, it can be determined that the first service needs parameters from the second service as input parameters during its operation, thus determining that the second service needs to be called during the operation of the first service.

[0064] After determining that the first service needs to call the second service, it can be checked whether the second service is included in the local process. If the second service is included in the local process, step S202 can be executed to call the second service using a same-process call method. If the second service is not included in the local process, steps S203 and S204 can be executed to call the second service using a cross-process call method. In other words, if the first service needs to call the second service during its operation, it can first be determined whether the second service can be called using a same-process call method. Thus, if the second service exists in both the local and non-local processes, a same-process call method can be prioritized, reducing cross-process service calls. Since the overhead of a same-process call is less than that of a cross-process call, the service overhead is reduced, and the efficiency of service calls is improved.

[0065] It should be noted that the "local" in "local process" refers to locality relative to the first service, not locality relative to the device running the first service. In other words, if multiple processes are running on the device running the first service, and one process includes the first service while another process includes the second service, then the process including the second service is not the local service corresponding to the first service.

[0066] S202: If the local process includes a second service, call the second service in the local process.

[0067] If it is determined that the local process includes a second service, the second service in the local process can be invoked through a same-process call to run the first service.

[0068] In some possible implementations, the second service can be invoked within the same process based on the parameter values. Specifically, when invoking the second service, the second service can be run to obtain the parameter values ​​required by the first service during its operation, and these parameter values ​​can be passed to the first service to invoke the first service.

[0069] Combination Figure 1 The application scenarios shown are explained.

[0070] Suppose service 121 requires parameter d1 during its operation. Parameter d1 comes from service 122, which runs in the same process as service 121. Therefore, when calling service 122, service 122 can be run to obtain the value of parameter d1. Then, the value of parameter d1 can be passed to service 121, causing service 121 to run according to the value of parameter d1, thus completing the call to service 122.

[0071] Specifically, when developing services 121 and 122, the input parameters of service 121 can be set to include parameter d1, and the output parameters of service 122 can be set to include parameter d2. Thus, when running service 121, since its input parameters include parameter d1, service 122 can be run first to obtain the specific value of parameter d2. Then, the value of parameter d2 can be assigned to parameter d1, and service 121 can be run using parameter d1. In this way, parameter passing is achieved through the passing of parameter values, and the input and output parameters are confused, thus realizing the service invocation.

[0072] Alternatively, in some other possible implementations, same-process calls to the second service can be implemented based on memory addresses. Specifically, when the first service calls the second service, the first service can pass the memory address of the parameters required by the second service (i.e., the input parameters of the second service) to the second service. The second service can access the memory address to obtain the required input parameters. In other words, if the first service calls the second service during its operation, the first service can send the memory address of the second service's input parameters to the second service. The second service can then query the value of the parameter from the corresponding memory address and execute the operation. In this implementation, since the first and second services belong to the same process (i.e., a local process), they can access the same memory address space. Thus, the second service can access the memory address space of a parameter in the first service based on the memory address, enabling inter-service calls.

[0073] S203: If the local process does not include the second service, obtain the remote call address of the second service.

[0074] If the local process does not include the second service, it cannot be obtained and invoked through intra-process calls. Therefore, the second service can be invoked through cross-process calls. To invoke a service outside the local process, the address of that service must first be determined before the corresponding service can be invoked. In this embodiment, if the local process corresponding to the first service does not include the second service, the remote call address of the second service can be obtained to invoke it.

[0075] Optionally, the remote call address of the second service can be the address of the code corresponding to the second service. Therefore, after obtaining the remote call address of the second code, the code corresponding to the second service can be accessed based on the remote call address, thereby executing the code to invoke the second service.

[0076] Combination Figure 1 The application scenario shown will be introduced. Suppose that service 121 needs to call service 221, then service 121 can obtain the remote call address of service 221. The remote call address of service 221 can be the address of the code of service 221, for example, it can be the storage address of the code of service 221 in device 20, or it can be the address of the code of service 221 in memory.

[0077] The remote call address of the second service has been introduced above. The following describes how to obtain the remote call address of the second service.

[0078] In one possible implementation, the remote call address of the second service can be pre-recorded.

[0079] Specifically, during the development and deployment of the program, relevant service information (including remote call addresses) can be recorded synchronously. That is, when developing a second service, its relevant information (including remote call addresses) can be synchronously recorded on multiple devices used for program development. In this way, each device can record the relevant information of the second service. Thus, when a service running on a certain device needs to call the second service, it can obtain the remote call address of the second service based on the information recorded on that device.

[0080] In the second possible implementation, the remote call address of the second service can be obtained by querying the registry center.

[0081] The registry center is a software module used to record the remote call addresses of services. Specifically, the registry center records the association between service identifiers and their remote call addresses. When a client needs to query the remote call address of a service, it can send a query request to the registry center, which can include the identifier of the service to be called. The registry center can then find the remote call address corresponding to the identifier of the service to be called from the association and return it to the client. In other words, the registry center can also record the association between the identifier of a second service and its remote call address. When a client running the first service needs to call the second service, it can send a query request to the registry center including the identifier of the second service and obtain the remote call address of the second service returned by the registry center. In this way, by managing the remote call addresses of services through the registry center, unified management of services can be achieved in a distributed architecture, especially in scenarios with a large number of services, facilitating service invocation.

[0082] Optionally, the registry center can run on the server side. For example, if multiple users develop programs on a platform using multiple devices, the registry center can run on the platform's server. After a user completes the development and deployment of a service using the platform's client on their device, the client can determine the service's remote call address and send that address to the server. The server-side registry center can record the service's remote call address. Thus, during program execution, if a remote service call is needed, the user can request the service's remote call address from the server to achieve the remote service call.

[0083] Combination Figure 1 The application scenarios shown are explained.

[0084] Assume the first service is service 121 and the second service is service 221. During the service development and deployment phase, client 21 can send the remote access address and identifier of service 221 to server 31. Server 31 includes a registry (not shown in the diagram). The registry records the association between the identifier of service 221 and the remote access address of service 221. Thus, if the operation of service 121 requires calling service 221, client 11 can generate a query request based on the identifier of service 221 and send the query request to server 31. Server 31 can query the remote access address corresponding to the identifier of service 221 from the association based on the query request, and then return the remote access address of service 221 to client 11 so that service 221 can be called.

[0085] S204: Call the second service based on the remote call address of the second service.

[0086] After obtaining the remote call address of the second service, the second service can be called based on the remote call address in order to continue running the first service.

[0087] Alternatively, the second service can be invoked using either memory address passing or value passing.

[0088] Implementation Method 1: Invoking the second service by passing memory addresses.

[0089] If the second service is invoked via memory address passing, the first service can call the second service based on the remote call address, and pass the address of the parameters provided by the first service to the second service as input parameters. The second service can obtain the input parameters based on the address and run accordingly. During the execution of the second service, the value of the input parameters can be modified.

[0090] It should be noted that the above-described method of "invoking the second service via memory address passing" requires cross-process memory address space sharing. A detailed explanation of this will be provided below and will not be repeated here.

[0091] Implementation method 2: Invoke the second service by passing by value.

[0092] If the second service is invoked via pass-by-value, the first service can run the second service based on the remote call address and send the values ​​of the input parameters of the second service to the first service. During the execution of the second service, the variable corresponding to the input parameter can be created in the local process, and the corresponding memory space can be created for that variable. The data stored in the memory space can be determined based on the obtained value. Furthermore, the second service can return this value to the first service as a return value. For a more detailed explanation of pass-by-value, please refer to the following text.

[0093] For data transfer, in the value-passing implementation, parameter values ​​can be serialized and deserialized. Specifically, when providing the input parameter values ​​required by the second service, the first service can serialize the return value of the input parameter of the second service and pass the serialized value to the second service. The second service can deserialize the acquired data and assign the deserialized value to the input parameter. Similarly, if the first service needs to obtain the return value of the second service, the second service can serialize the return value and pass it to the first service. The first service can receive the serialized return value, deserialize it, and obtain the return value of the second service. The first service can then assign this return value to the corresponding parameter and continue running.

[0094] In this way, service calls are implemented by passing parameter values. Compared to calling services by passing memory addresses, services do not need to access the memory space of another service based on memory addresses, overcoming the semantic inconsistency problem and providing a foundation for using the same method for intra-process and cross-process calls. As a result, developers do not need to worry about the specific implementation details of the services, improving development efficiency.

[0095] For a detailed explanation of pass-by-value and semantic inconsistencies, please refer to the following text, which will not be repeated here.

[0096] As can be seen, during the operation of the first service, if it is found that the first service needs to call the second service, it can first be determined whether the local process corresponding to the first service includes the second service. The local process corresponding to the first service refers to the process to which the first service belongs, that is, the local process includes the first service. If the local process includes the second service, then the first service can call the second service in the local process using a same-process call method. If the local process does not include the second service, then the first service can obtain the remote call address of the second service and call the second service based on the remote call address. In other words, whether to use a same-process call or a cross-process call method to call the second service is determined during the operation of the first service, not during the development of the first service. Therefore, when developing the first service, it is not necessary to concern oneself with whether the first service and the second service belong to the same process at runtime. In this way, developers do not need to know the specific implementation and deployment location of the service, simplifying the development process of the first service. For the second service, since the first service does not need to distinguish between same-process and cross-process call methods, it is not necessary to develop different versions of the second service for different call methods. Thus, the amount of code to be developed is reduced, and the development difficulty is lowered.

[0097] Furthermore, when the second service needs to be called, the first service first checks whether the local process includes the second service. If not, it then uses the remote call address of the second service to make a cross-process call. In this way, regardless of whether the second service runs in the local process or another process, the first service can complete the call to the second service. This ensures the normal operation of the first service.

[0098] The previous section introduced the need for different calling methods for cross-process and intra-process calls in distributed architectures, and some implementation methods to solve this problem. The following section explains the reasons why different calling methods are needed for cross-process and intra-process calls in distributed architectures from a theoretical perspective.

[0099] When making a service call, if the calling service requires a parameter from the called service, semantic inconsistencies may arise. Specifically, most services currently use memory address passing to pass parameters. Memory address passing means that one service passes the memory address (or memory address reference) of a parameter to another service, allowing the other service to access the memory address to obtain the parameter's value and modify the data stored at that memory address.

[0100] For example, if service X includes parameter x1, and parameter x1 is the input parameter of service Y when service X calls service Y, then service X can pass the memory address (or memory address reference) of parameter x1 to service Y. Service Y can then access the memory address of parameter x1 based on the memory address (or memory address reference) and obtain the value of the input parameter by reading the data stored at that memory address. Furthermore, service Y can also modify the data stored at the memory address of parameter x1 during its execution, thus modifying parameter x1.

[0101] Specifically, the code for service Y can include write operation code for parameter x1. This write operation code is used to write data to the memory address of parameter x1. During the execution of service X, service Y can be run, and the memory address or memory address reference of parameter x1 can be passed to service Y. Service Y can access the memory address corresponding to parameter x1 based on the memory address or memory address reference, thereby obtaining the initial value of parameter x1. Through the write operation code, service Y can assign a new value to parameter x1 at the memory address it resides in.

[0102] However, the process described above is only applicable when services X and Y are in the same process. Specifically, since services within the same process can share memory addresses, service Y can access the data stored in the memory address space corresponding to its own process. This allows it to obtain the initial value of parameter x1 and adjust its value by writing code. Because service Y can write a new value for parameter x1 into the memory address space corresponding to parameter x1 in service X's memory address space, service X can obtain the new value of parameter x1 from its memory address space.

[0103] However, if services X and Y belong to different processes, and these processes do not share memory addresses, then after obtaining the memory address of parameter x1, service Y cannot access the memory space of other processes. Therefore, it cannot retrieve the value of parameter x1 based on its memory address, nor can it write a new value for parameter x1 into the memory address. Consequently, service Y can only perform calculations based on the default value of parameter x1 (e.g., 0) and cannot pass a new value for parameter x1 to service X.

[0104] As can be seen, if services X and Y belong to the same process, service Y can obtain the initial value of parameter x1 and modify its value, and service X can continue running based on the modified parameter x1. If services X and Y belong to different processes, service Y cannot obtain the initial value of parameter x1, nor can it modify its value, and service X cannot run based on the new value of parameter x1. Because it runs based on different values, service X will produce different output results. As can be seen from the above, if memory address passing is used to obtain parameters from other services, the output of intra-process calls and cross-process calls may differ, resulting in semantic inconsistency. Therefore, to overcome the semantic inconsistency between intra-process and cross-process calls, it is necessary to distinguish between intra-process and cross-process calls through different versions of the code.

[0105] To address this issue, this application provides at least two implementation methods.

[0106] Implementation Method 1: Achieve cross-process memory address space sharing.

[0107] In the first implementation, cross-process memory address space sharing can be achieved. That is, when setting up the program's execution framework, the ability to share memory address space across processes can be configured. Thus, due to this configured shared memory address space capability, services within one process can not only read data stored in the memory of other processes but also modify data stored in memory. Therefore, if the second service does not belong to the local process corresponding to the first service, the first service can pass the memory address or memory address reference of the input parameters to the second service. The second service can determine the input parameters based on the memory address or memory address reference and can also execute write operation code to write data to the memory address provided by the first service.

[0108] As can be seen, by configuring the ability to share memory address space across processes for services, the semantic inconsistency between intra-process and cross-process calls is overcome. Calling the same service using both intra-process and cross-process methods yields the same result. This ensures that different calling methods produce the same result, eliminating the need to configure different versions of the service for different calling methods.

[0109] Implementation Method 2: Implement service calls based on value passing.

[0110] In the second possible implementation, service calls can be implemented using pass-by-value instead of pass-by-memory-address. Pass-by-value means that one service passes parameters to another service based on their values. Since service calls are based on parameter values, services do not need to provide memory addresses to other services or access their memory space, thus eliminating the difference between intra-process and cross-process calls.

[0111] In other words, if the operation of the first service requires calling the second service, the first service can send the value of the input parameter to the second service, instead of the second service retrieving the value of the input parameter based on its memory address. The second service can allocate memory space for the input parameter from the memory space of the process to which it belongs, and write the value into that memory space. Since this memory space belongs to the process to which the second service belongs, the second service can access or modify the data stored in that memory space. Similarly, if the second service needs to modify the value of a parameter in the first service (e.g., an input parameter of the second service), the second service can return that parameter to the first service via a return value. The first service can then assign values ​​to its parameters based on the return value of the second service. Optionally, if the second service does not return a value, it can be assumed that the second service returned an "invalid (NULL)" value to the first service.

[0112] Let's continue with the example from before.

[0113] When service X calls service Y, it can send the value of parameter x1 to service Y. Service Y can create parameter y1, allocate memory space for parameter y1 within its own memory space, and store the initial value of parameter x1 obtained from service X into the memory space, thus assigning a value to parameter y1. Service Y can modify parameter y1 during runtime. If service X needs service Y to calculate the value of parameter x1, service Y can return the value of parameter y1 as its return value. Service X can then assign the return value of service Y back to parameter x1, completing the call to service Y.

[0114] During value passing, the service can serialize and deserialize the parameter values. That is, the first service can serialize the input parameter value for the second service and send the serialized value to the second service. After receiving the value sent by the first service, the second service can deserialize it to obtain the input parameter value.

[0115] In the above process, the assignment and adjustment of parameters in the first service are implemented by the first service itself, and the second service does not access the data stored in the memory address of the first service. Regardless of whether the second service belongs to the same process as the first service, it will not affect the value of the parameters read by the first service.

[0116] In this way, the first service can run directly based on the returned value, regardless of whether the first and second services belong to the same process, and the second service does not need to access the memory address space of the first service. Thus, by using return value passing instead of memory address passing for service calls, the semantic inconsistency problem caused by memory address passing is solved. This ensures that different calling methods yield the same results, eliminating the need to set up different versions of the service for different calling methods.

[0117] It is understood that the two implementation methods described above are merely examples. In some other possible implementations, other means can be used to overcome the semantic inconsistency between intra-process and cross-process calls.

[0118] The service invocation process has been described above. In the implementation methods described above, the first and second services were pre-developed and deployed. The following section uses the first service as an example to introduce some implementation methods for service development and deployment. Service development refers to developing the code corresponding to the service. Service deployment refers to deploying the developed code to a specific device.

[0119] First, combine Figure 1 This section introduces application scenarios for service development and deployment. Figure 1 In the implementation shown, services 121 and 122 are deployed on device 10, and service 221 is deployed on device 20.

[0120] Optionally, service 121 can be developed and deployed by a user (e.g., user A) on device 10. Service 221 can be developed and deployed by a user on device 20. Specifically, when developing service 121, the user can input the code for service 121 on client 11. After completing the code input, the user can trigger the controls provided by client 11 to compile the code, thereby deploying service 121 locally (i.e., device 10). When developing service 221, the user can input the code for service 221 on client 21. After completing the code input, the user can trigger the controls provided by client 21 to compile the code, thereby deploying service 221 locally (i.e., device 20).

[0121] In the above implementation, the service is developed and deployed locally. In some other possible implementations, the service can also be deployed remotely. Remote service deployment refers to developing the service code on one device and deploying the service to another device.

[0122] For example, service 122 could be developed by a user on device 20 and deployed to device 10. Specifically, when developing service 122, the user can input the code for service 122 on client 21. After completing the code development, the user can deploy service 122 to device 10. Optionally, client 21 can compile and package the code for service 122, and send the packaged code to device 10, thereby completing the remote deployment of service 122.

[0123] In real-world applications, a program may include numerous services, each with different requirements and developed by different developers. If the services are closely interrelated, such as requiring different calling methods, developers need to have a good understanding of the other services. This increases the demands on developers and reduces development efficiency.

[0124] Therefore, in this embodiment, the dependencies between services can be reduced during service development. Specifically, as described above, service calls can be implemented via pass-by-value, so that developers do not need to understand the internal implementation and deployment of the called service. Optionally, in some other possible implementations, the service call interface can be unified, thereby reducing development difficulty. The following section combines... Figure 3 This section details some specific implementation methods for service development and service deployment.

[0125] See Figure 3 , Figure 3 This is a schematic flowchart illustrating a service development and deployment method provided in an embodiment of this application. This method can be applied to... Figure 1 The application scenario shown can also be applied to other applicable application scenarios. If this method is applied to... Figure 1 Given the application scenario shown, this method can be executed by client 11.

[0126] Specifically, Figure 3 The service invocation methods shown may specifically include:

[0127] S301: Obtain the interface description information of the first service.

[0128] When developing the first service, developers can begin by entering the interface description information for that service. Specifically, the client can display an input control to the user, where developers can enter the interface description information for the first service.

[0129] The interface description information of the first service is used to describe the relevant information involved in calling the first service. That is, the interface description information describes what information other services need when calling the first service. Optionally, the interface description information of the first service may include interface identification information, input parameter information, and other information. The interface identification information is information related to the interface used to call the first service, such as the interface name corresponding to the first service. The input information is the information about the parameters that need to be entered into the first service when calling it, and the output information is the information about the parameters output by the first service when calling it.

[0130] Currently, there are several mainstream programming languages, such as Python, C++, and Java. In the software development method provided in this embodiment, to unify services developed using different programming languages, a unified language description interface description information can be set. That is, when developing the first service, the developers of the first service can write the interface description information and code for the first service using different programming languages. Optionally, a unified description language can be pre-defined. When developers input the interface description information, the client can display the rules of that description language to the developers, so that the developers can write the interface description information according to the rules of the description language.

[0131] Alternatively, in some implementations, the interface description information can also be written in natural language. That is, developers can describe the requirements for the interface of the first service in natural language. After obtaining the interface description information, Natural Language Processing (NLP) techniques can be used to perform semantic analysis on the interface description information to determine the relevant information for calling the interface of the first service. Specifically, the client can call a Large Language Model (LLN) with NLP capabilities to perform semantic analysis on the interface description information.

[0132] S302: Generate interface call code based on the interface description information.

[0133] After obtaining the interface description information, the client can generate interface call code based on the interface description information, so that developers can continue to develop the first service based on the interface call code. The interface call code is the part of the first service's code related to calling the interface, generated based on the interface description information.

[0134] In other words, the client can automatically generate the interface call code used to call the first service based on the interface description information input by the user. Because the interface call code is automatically generated, the calling format for services is standardized, ensuring the consistency of service interfaces.

[0135] Optionally, the client can generate multiple API call codes. These different API call codes can correspond to different programming languages. In other words, multiple versions of API call codes can be generated for various programming languages ​​based on the API description information. This way, regardless of the programming language used by the developers to develop the first service, the client can select the corresponding API call code as the API-related part of the first service's code. This ensures compatibility with different programming languages.

[0136] S303: Logic code for obtaining the first service.

[0137] In this embodiment, the code corresponding to the first service includes interface call code and logic code. Interface call code refers to the code associated with calling the first service. Logic code refers to the code used to implement the functionality of the first service. Optionally, the code of the first service other than the interface call code can be referred to as the logic code of the first service.

[0138] After obtaining the API call code, the client can retrieve the logic code for the first service. This logic code is provided by the developers of the first service. Optionally, the client can display an input control. Developers can enter the logic code for the first service into the input control. Alternatively, the client can include an import control, which allows developers to trigger an import operation to import the edited logic code.

[0139] As mentioned earlier, the client can generate interface call code for multiple programming languages. To facilitate the development of the first service, the client can display multiple language selection controls. Each language selection control corresponds to a programming language, indicating the programming language supported by the client. Developers can select one or more language selection controls and trigger an operation. The selected language selection control can be called the target language selection control. When a user triggers an operation on the target language selection control, it means that the user needs to select the programming language corresponding to the target language selection control for development. That is, the programming language of the logic code entered by the user matches the programming language corresponding to the target language selection control. Alternatively, the programming language used by the developer can also be determined by the file extension of the code file corresponding to the logic code.

[0140] As discussed earlier, in some possible implementations, service calls can be made using pass-by-value instead of pass-by-memory address. In these implementations, code suggestions can be provided to developers to prevent them from using pass-by-memory address methods for service calls.

[0141] Specifically, during the code input process, the entered logic code can be scanned to determine whether it contains statements used for passing memory addresses, such as cross-service parameter access statements. Cross-service parameter access statements are used to reference parameters from services other than the first service. If statements used for passing memory addresses, such as reference statements, are detected, the client can display error messages to the user. For example, a pop-up window may indicate a vulnerability in the user's entered code, or the aforementioned statements used for passing memory addresses may be marked with underscores, highlights, or other methods.

[0142] For example, suppose a programming language uses the symbol "&" to represent the passing of memory addresses. For instance, the code "int&x" represents referencing the value of parameter x from another process. If a user writes the logic code for a first service using this programming language, the client can scan the logic code for the "&" symbol. If it exists, the client can assume that the logic code includes statements for passing memory addresses, thus prompting the developer to modify the entered logic code. In this embodiment, the symbol "&" can be considered a statement used to implement memory address passing. This way, even if the developer accidentally enters statements for passing memory addresses, it can be detected immediately, avoiding semantic inconsistencies.

[0143] Optionally, considering that other services may call the first service, to avoid semantic inconsistencies when the first service is called, it can be determined whether the first service includes write operation code that writes data to the memory address space of other services. If the first service includes write operation code that writes data to the memory address space of other services, the client can report an error to prompt the developer to modify the entered code.

[0144] S304: Based on the logic code and interface call code, obtain the code corresponding to the first service.

[0145] After obtaining the API call code and logic code for the first service, the client can integrate the logic code and API call code to obtain the code corresponding to the first service. Specifically, the client can fill the logic code into the API call code to obtain the complete code corresponding to the first service.

[0146] If the platform supports multiple programming languages, the client can first determine the target API call code, and then obtain the code corresponding to the first service based on the target API call code and the logic code. The target API call code refers to the API call code whose programming language matches the logic code. For example, in the implementation method described earlier, the target API call code can be determined based on a target language selection control. Alternatively, the client can analyze the syntax of the logic code to determine the corresponding programming language, and then determine the target API call code. In this way, the client can generate API call code for multiple programming languages ​​and select the matching API call code based on the actual situation of the logic code. Thus, the development platform can support development in multiple programming languages.

[0147] In the code corresponding to the first service, the API call code is automatically generated based on the API description information. Since the API description information is independent of the programming language of the logic code, it's clear that the part of the code related to API calls is automatically generated, while the parts unrelated to API calls are written by the developers. In other words, the developers of the first service are responsible for writing the parts of the code unrelated to API calls and do not need to understand the specific implementation of the API call code. The API call code is the part of the first service's code that relates to other services. This reduces the need for developers to have knowledge of other services, lowers the development threshold, and improves development efficiency.

[0148] After obtaining the code corresponding to the first service, the first service can be deployed based on the code. If local deployment of the first service is required, it can be packaged and stored. If remote deployment of the first service is required, the corresponding software package can be sent to a remote device.

[0149] As discussed earlier, in some possible implementations, service calls can be made using pass-by-value instead of pass-by-memory address. Accordingly, before deploying the first service, the code can be scanned to determine if it contains code that uses pass-by-memory address. If so, deployment can be rejected. If not, deployment can proceed. This way, even if a developer accidentally enters statements that implement pass-by-memory address, it can be detected immediately, avoiding semantic inconsistencies.

[0150] Specifically, it can be determined whether the code corresponding to the first service contains cross-memory variable access statements. If the code does not contain cross-memory variable access statements, it means that the first service does not access other services via memory address passing, and the first service can be deployed. If the code corresponding to the first service contains cross-memory variable access statements, then when deploying the first service, it may access variables in other services using cross-memory variable access statements. In this case, if the accessed service and the first service belong to different processes, semantic inconsistencies may occur. Therefore, the deployment of the first service can be rejected, and a prompt message can be generated to remind developers to adjust the code of the first service. Thus, by scanning the code, semantic inconsistency issues can be avoided.

[0151] In addition, this application also provides a service invocation device, such as Figure 4 As shown, the service invocation device 400 includes:

[0152] The judgment module 410 is used to determine whether the second service is included in the local process in response to the call to the second service during the operation of the first service, wherein the first service is a service in the local process.

[0153] The local invocation module 420 is used to invoke the second service in the local process if the local process includes the second service;

[0154] The remote call module 430 is used to obtain the remote call address of the second service if the local process does not include the second service, and to call the second service based on the remote call address of the second service.

[0155] The judgment module 410, the local call module 420, and the remote call module 430 can all be implemented in software or in hardware. For example, the implementation of the judgment module 410 will be described below. Similarly, the implementation of the local call module 420 and the remote call module 430 can refer to the implementation of the judgment module 410.

[0156] As an example of a software functional unit, a module can include code running on a computing instance. A computing instance can include at least one of a physical host (computing device), a virtual machine, or a container. Furthermore, the aforementioned computing instance can be one or more. For example, a module can 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 can be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code can be distributed within the same availability zone (AZ) or in different AZs, each AZ comprising one or more geographically proximate data centers. Typically, a region can include multiple AZs.

[0157] 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.

[0158] As an example of a hardware functional unit, the decision module 410 may include at least one computing device, such as a server. Alternatively, the decision module 410 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.

[0159] The multiple computing devices included in the judgment module 410 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the judgment module 410 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the judgment module can be distributed in 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.

[0160] It should be noted that, in other embodiments, the judgment module 410 can be used to execute any step in the service invocation method, the local invocation module 420 can be used to execute any step in the service invocation method, and the remote invocation module 430 can be used to execute any step in the service invocation method. The steps implemented by the judgment module 410, the local invocation module 420, and the remote invocation module 430 can be specified as needed. By implementing different steps in the service invocation method through the judgment module 410, the local invocation module 420, and the remote invocation module 430, all functions of the service invocation device can be realized.

[0161] This application also provides a computing device 100. For example... Figure 5 As shown, the computing device 100 includes a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other via the bus 102. The computing device 100 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 100.

[0162] Bus 102 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 5 The bus 102 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 102 may include a path for transmitting information between various components of the computing device 100 (e.g., memory 106, processor 104, communication interface 108).

[0163] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0164] Memory 106 may include volatile memory, such as random access memory (RAM). Processor 104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0165] The memory 106 stores executable program code, which the processor 104 executes to implement the functions of the aforementioned judgment module, local call module, and remote call module, thereby realizing the service call method. In other words, the memory 106 stores instructions for executing the service call method.

[0166] Alternatively, the memory 106 may store executable code, which the processor 104 executes to implement the aforementioned service invocation devices, thereby implementing the service invocation method. That is, the memory 106 stores instructions for executing the service invocation method.

[0167] The communication interface 108 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 100 and other devices or communication networks.

[0168] 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.

[0169] like Figure 6 As shown, the computing device cluster includes at least one computing device 100. The memory 106 of one or more computing devices 100 in the computing device cluster may store the same instructions for executing service invocation methods.

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

[0171] It should be noted that the memory 106 in different computing devices 100 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 memory 106 of different computing devices 100 can implement the functions of one or more modules among the judgment module, the local invocation module, and the remote invocation module.

[0172] 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 7 One possible implementation is shown. For example... Figure 7 As shown, the two computing devices 100A and 100B are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device. In this possible implementation, the memory 106 in computing device 100A stores instructions for executing the functions of the judgment module 410. Meanwhile, the memory 106 in computing device 100B stores instructions for executing the functions of the local call module 420 and the remote call module 430.

[0173] It should be understood that Figure 7 The functions of the computing device 100A shown can also be performed by multiple computing devices 100. Similarly, the functions of the computing device 100B can also be performed by multiple computing devices 100.

[0174] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 6 and Figure 7 The connection method of the computing device cluster. The difference is that the memory 106 of one or more computing devices 100 in the computing device cluster can store the same instructions for executing service call methods.

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

[0176] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute a service invocation method.

[0177] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center that includes one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a service invocation method.

[0178] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A service invocation method, characterized in that, The method includes: In response to a call to the second service during the operation of the first service, it is determined whether the second service is included in the local process, wherein the first service is a service in the local process; If the local process includes the second service, then the second service in the local process is invoked; If the local process does not include the second service, obtain the remote call address of the second service, and call the second service based on the remote call address of the second service.

2. The method according to claim 1, characterized in that, The process of obtaining the remote call address of the second service includes: Based on the identifier of the second service, find the remote call address of the second service from the registry center; The registry center records the association between the identifier of the second service and the remote call address of the second service. This association is recorded in the registry center after the second service is loaded.

3. The method according to claim 1 or 2, characterized in that, The method of invoking the second service based on the remote call address of the second service includes: The second service is run according to the remote call address of the second service; during the operation of the second service, the input parameters are not modified, and the input parameters are the parameters passed to the second service when the first service calls the second service.

4. The method according to claim 3, characterized in that, The code for the second service does not include write operation code, which is used to perform write operations on the memory space of the first service during operation.

5. The method according to any one of claims 1 to 4, characterized in that, The first service was deployed using the following method: Obtain the code corresponding to the first service; Determine whether the code corresponding to the first service includes a cross-service parameter access statement, wherein the cross-service parameter access statement is used to access parameters outside the first service; Since the code corresponding to the first service does not include the cross-service parameter access statement, the first service is deployed as a plugin based on the code corresponding to the first service.

6. The method according to claim 5, characterized in that, The code corresponding to the first service is obtained in the following way: Obtain the interface description information of the first service, which is used to describe the relevant information involved in calling the first service; Based on the interface description information, multiple interface call codes are generated, and the multiple call interfaces correspond to multiple programming languages; Retrieve the logic code corresponding to the first service; Based on the logic code and the target interface call code, the code corresponding to the first service is obtained. The target interface call code is the interface call code whose programming language matches the logic code among the plurality of interface call codes.

7. The method according to claim 6, characterized in that, Before obtaining the code corresponding to the first service, the method further includes: Display the plurality of language selection controls, each of which corresponds to one of the plurality of programming languages; In response to an operation triggered by a target language selection control among the plurality of language selection controls, the target interface call code is determined, wherein the programming language corresponding to the target language selection control is consistent with the programming language corresponding to the target interface call code.

8. A service invocation device, characterized in that, The device includes: The judgment module is used to determine whether the second service is included in the local process in response to the call to the second service during the operation of the first service, wherein the first service is a service in the local process. A local invocation module is used to invoke the second service in the local process if the local process includes the second service; The remote call module is used to obtain the remote call address of the second service if the local process does not include the second service, and to call the second service based on the remote call address of the second service.

9. The apparatus according to claim 8, characterized in that, The remote call module is specifically used to find the remote call address of the second service from the registry center based on the identifier of the second service; wherein, the registry center records the association between the identifier of the second service and the remote call address of the second service, and the association is recorded in the registry center after the second service is loaded.

10. The apparatus according to claim 8 or 9, characterized in that, The remote call module is specifically used to run the second service according to the remote call address of the second service; during the operation of the second service, the input parameters are not modified, and the input parameters are the parameters passed to the second service when the first service calls the second service.

11. The apparatus according to claim 10, characterized in that, The code for the second service does not include write operation code, which is used to perform write operations on the memory space of the first service during operation.

12. The apparatus according to any one of claims 8 to 11, characterized in that, The device also includes a service deployment module; The service deployment module is used to obtain the code corresponding to the first service; determine whether the code corresponding to the first service includes a cross-service parameter access statement, wherein the cross-service parameter access statement is used to access parameters other than the first service; Since the code corresponding to the first service does not include the cross-service parameter access statement, the first service is deployed as a plugin based on the code corresponding to the first service.

13. The apparatus according to claim 12, characterized in that, The device also includes a code acquisition module; The code acquisition module is used to acquire the interface description information of the first service, which describes the relevant information involved in calling the first service. Based on the interface description information, generate multiple interface call codes, where the multiple call interfaces correspond to multiple programming languages; obtain the logic code corresponding to the first service; Based on the logic code and the target interface call code, the code corresponding to the first service is obtained. The target interface call code is the interface call code whose programming language matches the logic code among the plurality of interface call codes.

14. The apparatus according to claim 13, characterized in that, The code acquisition module is also used to display the plurality of language selection controls, each of which corresponds to one of the plurality of programming languages; in response to an operation triggered by a target language selection control among the plurality of language selection controls, the module determines the target interface call code, wherein the programming language corresponding to the target language selection control is consistent with the programming language corresponding to the target interface call code.

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

16. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, each computing device including a processor and memory: The memory is used to store instructions; The processor is configured to, according to the instructions, cause the computing device cluster to perform the operational steps of the method according to any one of claims 1 to 7.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computing device, cause the computing device to perform the operational steps of the method as described in any one of claims 1 to 7.

18. A computer program product comprising instructions that, when run on a computing device, cause the computing device to perform the operational steps of the method as described in any one of claims 1 to 7.

Images