Distributed service calling method and device, readable storage medium and terminal equipment

Abstract

The application belongs to the technical field of plug-in management, and particularly relates to a distributed service calling method and device, a computer readable storage medium and a terminal device. The method comprises the following steps: determining a target service to be called by a first plug-in; wherein the first plug-in is any plug-in in a distributed service system; obtaining a service address list corresponding to the target service; wherein the service address list comprises service addresses of each second plug-in, and the second plug-in is a plug-in providing the target service in the distributed service system; selecting an optimal service address from the service address list based on a preset load balancing strategy; wherein the load balancing strategy is a strategy for balancing loads within a process and outside the process; and if the second plug-in corresponding to the optimal service address is within the process, the second plug-in corresponding to the optimal service address is called by using a memory object calling mode to provide the target service for the first plug-in, thereby effectively reducing protocol overhead and improving service calling efficiency.

Description

Technical Field

[0001] This application belongs to the field of plug-in management technology, and in particular relates to a distributed service invocation method, apparatus, computer-readable storage medium and terminal device. Background Technology

[0002] In the process of application development, in order to facilitate functional expansion, an application framework that supports plug-in development can be used to encapsulate specific services in the form of plug-ins. When the service needs to be used, only the corresponding plug-in needs to be called.

[0003] In existing technologies, each service operates as an independent process, and plugins often use Remote Procedure Call (RPC) to call services, which generates significant Transmission Control Protocol (TCP) overhead, resulting in low efficiency of service calls. Summary of the Invention

[0004] In view of this, embodiments of this application provide a distributed service invocation method, apparatus, computer-readable storage medium, and terminal device to solve the problem of low efficiency in existing service invocation methods.

[0005] A first aspect of this application provides a distributed service invocation method, which may include:

[0006] Determine the target service to be invoked by the first plugin; wherein, the first plugin is any plugin in a preset distributed service system;

[0007] Obtain a list of service addresses corresponding to the target service; wherein, the list of service addresses includes the service addresses of each second plugin, and the second plugin is a plugin that provides the target service in the distributed service system;

[0008] The optimal service address is selected from the service address list based on a preset load balancing strategy; wherein, the load balancing strategy is a strategy for load balancing within and outside the process.

[0009] If the second plugin corresponding to the optimal service address is in the process, then the second plugin corresponding to the optimal service address is invoked using a memory object call to provide the target service to the first plugin.

[0010] In one specific implementation of the first aspect, the step of selecting the optimal service address from the service address list according to a preset load balancing strategy may include:

[0011] Determine the service weight of each service address in the service address list;

[0012] Based on the load balancing strategy, the optimal service address is selected from the list of service addresses according to the service weight.

[0013] In one specific implementation of the first aspect, determining the service weight of each service address in the service address list may include:

[0014] Determine the static weight of each service address in the service address list;

[0015] Determine the dynamic weight of each service address in the service address list;

[0016] The service weight of each service address in the service address list is determined based on the static weight and the dynamic weight.

[0017] In one specific implementation of the first aspect, determining the static weight of each service address in the service address list may include:

[0018] Obtain the number of hardware resources corresponding to each service address in the service address list;

[0019] The static weight of each service address in the service address list is determined based on the number of hardware resources; wherein the static weight is positively correlated with the number of hardware resources.

[0020] In one specific implementation of the first aspect, determining the dynamic weight of each service address in the service address list may include:

[0021] Obtain the service latency and service success rate corresponding to each service address in the service address list;

[0022] The dynamic weight of each service address in the service address list is determined based on the service latency and the service success rate; wherein the dynamic weight is negatively correlated with the service latency and positively correlated with the service success rate.

[0023] In one specific implementation of the first aspect, after selecting the optimal service address from the service address list based on a preset load balancing strategy, the method may further include:

[0024] Obtain the first port corresponding to the optimal service address;

[0025] Obtain the local machine address and the second port corresponding to the local machine address;

[0026] Based on the optimal service address, the local address, the first port, and the second port, it is determined whether the second plugin corresponding to the optimal service address is in the process.

[0027] In one specific implementation of the first aspect, determining whether the second plugin corresponding to the optimal service address is in a process based on the optimal service address, the local address, the first port, and the second port includes:

[0028] If the optimal service address is the same as the local address, and the first port and the second port are the same, then it is determined that the second plugin corresponding to the optimal service address is in the process.

[0029] If the optimal service address and the local address are inconsistent, or the first port and the second port are inconsistent, then the second plugin corresponding to the optimal service address is determined to be outside the process.

[0030] A second aspect of the embodiments of this application provides a distributed service invocation apparatus, which may include:

[0031] The target service determination module is used to determine the target service to be invoked by the first plugin; wherein, the first plugin is any plugin in a preset distributed service system;

[0032] The service address list acquisition module is used to acquire a service address list corresponding to the target service; wherein, the service address list includes the service addresses of each second plugin, and the second plugin is a plugin that provides the target service in the distributed service system;

[0033] The service address selection module is used to select the optimal service address from the service address list based on a preset load balancing strategy; wherein, the load balancing strategy is a strategy for load balancing within and outside the process.

[0034] The in-process service invocation module is used to invoke the second plugin corresponding to the optimal service address to provide the target service to the first plugin if the second plugin corresponding to the optimal service address is in the process, using a memory object invocation method.

[0035] In one specific implementation of the second aspect, the service address selection module may include:

[0036] The service weight determination submodule is used to determine the service weight of each service address in the service address list;

[0037] The load balancing submodule is used to select the optimal service address from the service address list based on the load balancing strategy and the service weight.

[0038] In one specific implementation of the second aspect, the service weight determination submodule may include:

[0039] A static weight determination unit is used to determine the static weight of each service address in the service address list;

[0040] A dynamic weight determination unit is used to determine the dynamic weight of each service address in the service address list;

[0041] The service weight determination unit is used to determine the service weight of each service address in the service address list based on the static weight and the dynamic weight.

[0042] In one specific implementation of the second aspect, the static weight determination unit may be specifically used to: obtain the number of hardware resources corresponding to each service address in the service address list; determine the static weight of each service address in the service address list based on the number of hardware resources; wherein the static weight is positively correlated with the number of hardware resources.

[0043] In one specific implementation of the second aspect, the dynamic weight determination unit may be specifically used to: obtain the service latency time and service success rate corresponding to each service address in the service address list; determine the dynamic weight of each service address in the service address list based on the service latency time and the service success rate; wherein the dynamic weight is negatively correlated with the service latency time and positively correlated with the service success rate.

[0044] In one specific implementation of the second aspect, the distributed service invocation device may further include:

[0045] The information acquisition module is used to acquire the first port corresponding to the optimal service address; and to acquire the local address and the second port corresponding to the local address.

[0046] The process determination module is used to determine whether the second plugin corresponding to the optimal service address is in a process based on the optimal service address, the local address, the first port, and the second port.

[0047] In one specific implementation of the second aspect, the process determination module can be specifically used to: if the optimal service address is consistent with the local address, and the first port is consistent with the second port, then determine that the second plugin corresponding to the optimal service address is in the process; if the optimal service address is inconsistent with the local address, or the first port is inconsistent with the second port, then determine that the second plugin corresponding to the optimal service address is outside the process.

[0048] A third aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the above-described distributed service invocation methods.

[0049] A fourth aspect of this application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above-described distributed service invocation methods.

[0050] The fifth aspect of this application provides a computer program product that, when run on a terminal device, causes the terminal device to execute the steps of any of the above-described distributed service invocation methods.

[0051] The beneficial effects of this application embodiment compared with the prior art are as follows: This application embodiment determines the target service to be invoked by the first plugin; wherein, the first plugin is any plugin in a preset distributed service system; obtains a service address list corresponding to the target service; wherein, the service address list includes the service addresses of various second plugins, the second plugins being plugins that provide the target service in the distributed service system; selects the optimal service address from the service address list based on a preset load balancing strategy; wherein, the load balancing strategy is a strategy for load balancing within and outside the process; if the second plugin corresponding to the optimal service address is within the process, then the second plugin corresponding to the optimal service address is invoked using a memory object call to provide the target service to the first plugin. Through this application embodiment, the optimal plugin can be selected from plugins providing the same service within and outside the process based on a load balancing strategy. If the selected plugin is within the process, the service call is no longer performed using RPC, but using a memory object call, thereby effectively reducing TCP protocol overhead and improving service call efficiency. Attached Figure Description

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

[0053] Figure 1 This is a schematic diagram of the application framework supporting plug-in development used in the embodiments of this application;

[0054] Figure 2This is a flowchart of one embodiment of a distributed service invocation method in this application.

[0055] Figure 3 A flowchart illustrating the process of determining the service weight of each service address in the service address list;

[0056] Figure 4 This is a diagram illustrating plugin invocation within a process.

[0057] Figure 5 This is a diagram illustrating plugin calls made outside of a process.

[0058] Figure 6 A diagram illustrating plugin calls across hosts;

[0059] Figure 7 This is a structural diagram of one embodiment of a distributed service invocation device according to the present application.

[0060] Figure 8 This is a schematic block diagram of a terminal device in an embodiment of this application. Detailed Implementation

[0061] To make the inventive objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0062] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0063] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0064] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0065] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0066] Furthermore, in the description of this application, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0067] During application development, to facilitate feature expansion, an application framework that supports plug-in development can be used to encapsulate specific services as plug-ins. When a service is needed, the corresponding plug-in can be called.

[0068] Figure 1 The diagram illustrates the application framework supporting plug-in development used in this embodiment. As shown, the application can include important components such as a host and plugins. The host is the backbone of the application, used to implement its core functions, while plugins are its extensions, used to implement its extended functions. The host can reference object instances of plugins, and plugins can call each other.

[0069] The host can perform plugin management operations such as installation, uninstallation, and querying. Plugins can be installed during compilation and runtime, and their resources can be destroyed when they are uninstalled. The host can also perform client management operations such as creation, destruction, and querying of third-party service clients and database clients. The host can also perform log management, exception handling, and monitoring operations.

[0070] When the application starts, the host container can be initialized first, and the host components can be loaded into the host container. Then, the plugin container can be initialized, with the host container as the parent container and the plugin container as the child container, and the plugin components can be loaded into the plugin container. After the plugin loading is completed, the plugin can be registered with the host's plugin manager so that the host can manage it.

[0071] Plugins are organized as services, with each plugin providing a corresponding service. When a plugin is loaded, the host can initiate service registration with the registry center, registering the service corresponding to the plugin with the registry center. The address of the service is the address of the host.

[0072] This application provides a distributed service system in which multiple applications can be deployed, and the various plugins within the same application reside within the same process. When making a service call, two scenarios exist: one where the called plugin is within the process, and another where the called plugin is outside the process.

[0073] In this embodiment, the host can select the optimal plugin from plugins that provide the same service both in-process and out-of-process based on a load balancing strategy. If the selected plugin is in-process, the service call will no longer be made using RPC, but using memory object calls, which can effectively reduce TCP protocol overhead and improve service call efficiency.

[0074] Please see Figure 2 One embodiment of a distributed service invocation method in this application may include:

[0075] Step S201: Determine the target service to be invoked by the first plugin.

[0076] The first plugin can be any plugin in the pre-defined distributed service system. During the use of the first plugin, if other services (denoted as the target service) are needed, a service call request can be sent to the host of the first plugin. The service call request can include the service name of the target service to be called. Upon receiving the service call request, the host can determine the target service to be called by the first plugin based on the service name in the request.

[0077] Step S202: Obtain the list of service addresses corresponding to the target service.

[0078] When a plugin is loaded, the host initiates service registration with the registry center, registering the service corresponding to the plugin. Therefore, after determining the target service to be invoked by the first plugin, the host can obtain a list of service addresses corresponding to the target service from the registry center. This list of service addresses may include the service addresses of various second plugins, which are the plugins that provide the target service in the distributed service system.

[0079] Step S203: Select the optimal service address from the service address list based on the preset load balancing strategy.

[0080] Specifically, the host can first determine the service weight of each service address in the service address list, and then select the optimal service address from the service address list based on the service weight according to the load balancing strategy.

[0081] In one specific implementation of this application's embodiments, the host can, as follows: Figure 3The process shown determines the service weight of each service address in the service address list:

[0082] Step S2031: Determine the static weight of each service address in the service address list.

[0083] Specifically, the host can first obtain the number of hardware resources corresponding to each service address in the service address list, and then determine the static weight of each service address in the service address list based on the number of hardware resources.

[0084] The number of hardware resources can be the number of CPU cores. It's easy to understand that the static weight is positively correlated with the number of hardware resources; that is, the larger the number of hardware resources corresponding to a service address, the larger the static weight of that service address, and vice versa.

[0085] In one specific implementation of this application, the number of hardware resources corresponding to a service address can be directly used as the static weight of that service address, i.e.: static weight = number of hardware resources. Specifically, if the number of hardware resources corresponding to each service address is the same, then the static weights are all the same, and in this case, the static weights can all be assigned a value of 1.

[0086] Step S2032: Determine the dynamic weight of each service address in the service address list.

[0087] Specifically, the host can first obtain the service latency and service success rate corresponding to each service address in the service address list, and then determine the dynamic weight of each service address in the service address list based on the service latency and service success rate.

[0088] The service success rate is the ratio of the number of successful service requests to the number of service requests, i.e., Service Success Rate = Number of Successful Service ÷ Number of Service Requests. Service latency is the time interval from sending a service request to receiving a service response, i.e., Service Latency = Time to Receive Service Response - Time to Send Service Request. On one hand, dynamic weight is negatively correlated with service latency; the smaller the service latency for a service address, the greater its dynamic weight, and vice versa. On the other hand, dynamic weight is positively correlated with service success rate; the higher the service success rate for a service address, the greater its dynamic weight, and vice versa.

[0089] In one specific implementation of this application, the dynamic weight can be calculated according to the following formula: Dynamic weight = (Minimum service delay time ÷ Service delay time) × (Service success rate ÷ Maximum service success rate), where the minimum service delay time is the minimum value of the service delay time corresponding to each service address, and the maximum service success rate is the maximum value of the service success rate corresponding to each service address.

[0090] Step S2033: Determine the service weight of each service address in the service address list based on the static weight and the dynamic weight.

[0091] On the one hand, service weight is positively correlated with static weight; that is, the higher the static weight of a service address, the higher its service weight, and vice versa. On the other hand, service weight is positively correlated with dynamic weight; that is, the higher the dynamic weight of a service address, the higher its service weight, and vice versa.

[0092] In one specific implementation of this application, the product of the static weight and the dynamic weight of the service address can be used as its service weight, that is: service weight = static weight × dynamic weight.

[0093] After determining the service weight of each service address in the service address list, the optimal service address can be selected from the service address list based on the load balancing strategy and the service weight.

[0094] In one specific implementation of this application, a random selection load balancing strategy can be adopted, that is, randomly selecting a service address from a list of service addresses as the optimal service address. Specifically, for any given service address, the probability of it being randomly selected is positively correlated with its service weight; that is, the higher the service weight of a service address, the higher the probability of it being randomly selected, and vice versa.

[0095] In another specific implementation of this application embodiment, a round-robin load balancing strategy can be adopted, that is, service addresses are selected sequentially from the service address list as the optimal service address. Specifically, for any given service address, the number of times it is selected in the round-robin is positively correlated with its service weight; that is, the higher the service weight of a service address, the more times it is selected in the round-robin, and vice versa.

[0096] It should be noted that the above load balancing strategies are merely examples. In practical applications, other load balancing strategies can be adopted according to specific circumstances. This application does not impose any specific limitations on this.

[0097] After selecting the optimal service address, we can obtain the first port corresponding to the optimal service address, as well as the local address and the second port corresponding to the local address. Then, based on the optimal service address, the local address, the first port, and the second port, we can determine whether the second plugin corresponding to the optimal service address is in the process.

[0098] Specifically, if the optimal service address is the same as the local address, and the first port and the second port are the same, it means that the second plugin corresponding to the optimal service address is in the same process as the first plugin. At this time, step S204 can be executed.

[0099] Step S204: Use memory object invocation to call the second plugin corresponding to the optimal service address to provide the target service to the first plugin.

[0100] In this way, such as Figure 4 As shown, the host can directly call the object instance of the second plugin in the memory of the current process, thereby providing the target service to the first plugin.

[0101] If the optimal service address and the local address are inconsistent, or the first port and the second port are inconsistent, it means that the second plugin corresponding to the optimal service address is outside the process, that is, the second plugin and the first plugin are in different processes. At this time, the host can use RPC to call the second plugin corresponding to the optimal service address to provide the target service to the first plugin.

[0102] In this embodiment of the application, RPC calls may specifically include two scenarios.

[0103] In the first scenario, if the optimal service address and the local machine address are the same, but the first port and the second port are different, it indicates that the second plugin corresponding to the optimal service address and the first plugin are in different processes on the same host. In this case, if... Figure 5 As shown, the host of the first plugin (denoted as host A) can interact with the host of the second plugin (denoted as host B), and dispatch requests through host B, thereby calling the second plugin outside the process to provide the target service for the first plugin.

[0104] In the second scenario, if the optimal service address and the local machine address are inconsistent, it means that the second plugin corresponding to the optimal service address is not on the local machine. Figure 6As shown, the host of the first plugin (denoted as host A, and the host on which it is located is denoted as host 1) can interact with the host of the second plugin outside the local machine (denoted as host B, and the host on which it is located is denoted as host 2). The request is distributed through host B, thereby calling the second plugin across hosts to provide the target service for the first plugin.

[0105] In summary, this application embodiment determines the target service to be invoked by the first plugin; wherein the first plugin is any plugin in a preset distributed service system; obtains a list of service addresses corresponding to the target service; wherein the service address list includes the service addresses of various second plugins, and the second plugins are plugins that provide the target service in the distributed service system; selects the optimal service address from the service address list based on a preset load balancing strategy; wherein the load balancing strategy is a strategy for load balancing within and outside the process; if the second plugin corresponding to the optimal service address is within the process, then the second plugin corresponding to the optimal service address is invoked using a memory object call to provide the target service to the first plugin. Through this application embodiment, the optimal plugin can be selected from plugins providing the same service within and outside the process based on a load balancing strategy. If the selected plugin is within the process, the service call is no longer performed using RPC, but using a memory object call, thereby effectively reducing TCP protocol overhead and improving service call efficiency.

[0106] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0107] Corresponding to the distributed service invocation method described in the above embodiments, Figure 7 This illustration shows a structural diagram of an embodiment of a distributed service invocation device provided in this application.

[0108] In this embodiment, a distributed service invocation device may include:

[0109] The target service determination module 701 is used to determine the target service to be called by the first plugin; wherein, the first plugin is any plugin in a preset distributed service system;

[0110] The service address list acquisition module 702 is used to acquire a service address list corresponding to the target service; wherein, the service address list includes the service addresses of each second plugin, and the second plugin is a plugin that provides the target service in the distributed service system;

[0111] The service address selection module 703 is used to select the optimal service address from the service address list based on a preset load balancing strategy; wherein, the load balancing strategy is a strategy for load balancing within and outside the process.

[0112] The in-process service call module 704 is used to call the second plugin corresponding to the optimal service address to provide the target service to the first plugin by using a memory object call method if the second plugin corresponding to the optimal service address is in the process.

[0113] In one specific implementation of this application embodiment, the service address selection module may include:

[0114] The service weight determination submodule is used to determine the service weight of each service address in the service address list;

[0115] The load balancing submodule is used to select the optimal service address from the service address list based on the load balancing strategy and the service weight.

[0116] In one specific implementation of this application embodiment, the service weight determination submodule may include:

[0117] A static weight determination unit is used to determine the static weight of each service address in the service address list;

[0118] A dynamic weight determination unit is used to determine the dynamic weight of each service address in the service address list;

[0119] The service weight determination unit is used to determine the service weight of each service address in the service address list based on the static weight and the dynamic weight.

[0120] In one specific implementation of this application, the static weight determination unit may be specifically used to: obtain the number of hardware resources corresponding to each service address in the service address list; determine the static weight of each service address in the service address list based on the number of hardware resources; wherein the static weight is positively correlated with the number of hardware resources.

[0121] In one specific implementation of this application, the dynamic weight determination unit may be specifically used to: obtain the service latency time and service success rate corresponding to each service address in the service address list; determine the dynamic weight of each service address in the service address list based on the service latency time and the service success rate; wherein the dynamic weight is negatively correlated with the service latency time and positively correlated with the service success rate.

[0122] In one specific implementation of this application embodiment, the distributed service invocation device may further include:

[0123] The information acquisition module is used to acquire the first port corresponding to the optimal service address; and to acquire the local address and the second port corresponding to the local address.

[0124] The process determination module is used to determine whether the second plugin corresponding to the optimal service address is in a process based on the optimal service address, the local address, the first port, and the second port.

[0125] In one specific implementation of this application, the process determination module can be specifically used to: if the optimal service address is consistent with the local address, and the first port is consistent with the second port, then determine that the second plugin corresponding to the optimal service address is in the process; if the optimal service address is inconsistent with the local address, or the first port is inconsistent with the second port, then determine that the second plugin corresponding to the optimal service address is outside the process.

[0126] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0127] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0128] Figure 8 A schematic block diagram of a terminal device provided in an embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0129] like Figure 8 As shown, the terminal device 8 in this embodiment includes: a processor 80, a memory 81, and a computer program 82 stored in the memory 81 and executable on the processor 80. When the processor 80 executes the computer program 82, it implements the steps in the various distributed service invocation method embodiments described above, for example... Figure 2 Steps S201 to S204 are shown. Alternatively, when the processor 80 executes the computer program 82, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 7 The functions of modules 701 to 704 are shown.

[0130] For example, the computer program 82 may be divided into one or more modules / units, which are stored in the memory 81 and executed by the processor 80 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program 82 in the terminal device 8.

[0131] The terminal device 8 can be a desktop computer, laptop, handheld computer, or other computing device. Those skilled in the art will understand that... Figure 8 This is merely an example of terminal device 8 and does not constitute a limitation on terminal device 8. It may include more or fewer components than shown, or combine certain components, or different components. For example, terminal device 8 may also include input / output devices, network access devices, buses, etc.

[0132] The processor 80 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0133] The memory 81 can be an internal storage unit of the terminal device 8, such as a hard disk or memory of the terminal device 8. The memory 81 can also be an external storage device of the terminal device 8, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the terminal device 8. Furthermore, the memory 81 can include both internal and external storage units of the terminal device 8. The memory 81 is used to store the computer program and other programs and data required by the terminal device 8. The memory 81 can also be used to temporarily store data that has been output or will be output.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0135] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0136] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0137] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0138] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0139] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0140] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc. It should be noted that the content included in the computer-readable storage medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable storage medium does not include electrical carrier signals and telecommunication signals.

[0141] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A distributed service invocation method, characterized in that, include: Determine the target service to be invoked by the first plugin; wherein, the first plugin is any plugin in a preset distributed service system; Obtain a list of service addresses corresponding to the target service; wherein, the list of service addresses includes the service addresses of each second plugin, and the second plugin is a plugin that provides the target service in the distributed service system; The optimal service address is selected from the list of service addresses based on a preset load balancing strategy; wherein, the load balancing strategy is a strategy for load balancing within and outside the process; a plugin is an appendage of the application, used to implement the extended functions of the application; each plugin in the same application is in the same process; each plugin provides a corresponding service; If the second plugin corresponding to the optimal service address is in the process, then the second plugin corresponding to the optimal service address is invoked using a memory object call to provide the target service to the first plugin.

2. The distributed service invocation method according to claim 1, characterized in that, The step of selecting the optimal service address from the service address list according to the preset load balancing strategy includes: Determine the service weight of each service address in the service address list; Based on the load balancing strategy, the optimal service address is selected from the list of service addresses according to the service weight.

3. The distributed service invocation method according to claim 2, characterized in that, Determining the service weight of each service address in the service address list includes: Determine the static weight of each service address in the service address list; Determine the dynamic weight of each service address in the service address list; The service weight of each service address in the service address list is determined based on the static weight and the dynamic weight.

4. The distributed service invocation method according to claim 3, characterized in that, Determining the static weight of each service address in the service address list includes: Obtain the number of hardware resources corresponding to each service address in the service address list; The static weight of each service address in the service address list is determined based on the number of hardware resources; wherein the static weight is positively correlated with the number of hardware resources.

5. The distributed service invocation method according to claim 3, characterized in that, Determining the dynamic weight of each service address in the service address list includes: Obtain the service latency and service success rate corresponding to each service address in the service address list; The dynamic weight of each service address in the service address list is determined based on the service latency and the service success rate; wherein the dynamic weight is negatively correlated with the service latency and positively correlated with the service success rate.

6. The distributed service invocation method according to any one of claims 1 to 5, characterized in that, After selecting the optimal service address from the service address list based on a preset load balancing strategy, the process further includes: Obtain the first port corresponding to the optimal service address; Obtain the local machine address and the second port corresponding to the local machine address; Based on the optimal service address, the local address, the first port, and the second port, it is determined whether the second plugin corresponding to the optimal service address is in the process.

7. The distributed service invocation method according to claim 6, characterized in that, The step of determining whether the second plugin corresponding to the optimal service address is in a process based on the optimal service address, the local address, the first port, and the second port includes: If the optimal service address is the same as the local address, and the first port and the second port are the same, then it is determined that the second plugin corresponding to the optimal service address is in the process. If the optimal service address and the local address are inconsistent, or the first port and the second port are inconsistent, then the second plugin corresponding to the optimal service address is determined to be outside the process.

8. A distributed service invocation device, characterized in that, include: The target service determination module is used to determine the target service to be invoked by the first plugin; wherein, the first plugin is any plugin in a preset distributed service system; The service address list acquisition module is used to acquire a service address list corresponding to the target service; wherein, the service address list includes the service addresses of each second plugin, and the second plugin is a plugin that provides the target service in the distributed service system; The service address selection module is used to select the optimal service address from the service address list based on a preset load balancing strategy; wherein, the load balancing strategy is a strategy for load balancing within and outside the process; a plugin is an appendage of the application, used to implement the extended functions of the application; each plugin in the same application is in the same process; each plugin provides a corresponding service; The in-process service invocation module is used to invoke the second plugin corresponding to the optimal service address to provide the target service to the first plugin if the second plugin corresponding to the optimal service address is in the process, using a memory object invocation method.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the distributed service invocation method as described in any one of claims 1 to 7.

10. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the distributed service invocation method as described in any one of claims 1 to 7.

Images