Service calling method, apparatus, device, and storage medium

Abstract

Embodiments of the application disclose a service calling method and device, equipment and a storage medium, and belong to the technical field of computers. The method comprises: a first device identifying a first input instruction to obtain a first instruction identification result; generating a service calling request based on the first instruction identification result, the service calling request being used to request a second device to call a target service to perform a target action; and sending the service calling request to the second device, so that the second device deploys the target service based on a target service installation package and calls the target service to perform the target action, the target service installation package being obtained from a server. According to the scheme provided in the embodiments of the application, even if the second device does not have an instruction identification function, service calling based on instructions can be realized, and the second device can realize dynamic deployment of the target service based on the service calling request, thereby avoiding memory occupation caused by pre-deployment of a large number of services.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, and particularly relate to a service calling method and device, equipment and storage medium. BACKGROUND

[0002] Instruction control is a technology of recognizing and analyzing user instructions, and controlling a device to perform corresponding operations according to the recognition and analysis results. Common instruction control includes gesture control and voice control, etc.

[0003] In the related art, a computer device needs to have an instruction recognition function, and needs to be pre-deployed with a corresponding service, before the instruction control function can be realized. For example, when a vehicle terminal has voice recognition and is deployed with a video playing function, the vehicle terminal can play a video according to a voice instruction issued by a user. SUMMARY

[0004] Embodiments of the present application provide a service calling method, device, equipment and storage medium. The technical solution is as follows:

[0005] In one aspect, the present application provides a service calling method, which is executed by a first device, and the method comprises:

[0006] recognizing a first input instruction to obtain a first instruction recognition result;

[0007] generating a service calling request based on the first instruction recognition result, the service calling request being used to request a second device to call a target service to perform a target action;

[0008] sending the service calling request to the second device, so that the second device deploys the target service based on a target service installation package and calls the target service to perform the target action, the target service installation package being obtained from a server.

[0009] In another aspect, the present application provides a service calling method, which is executed by a second device, and the method comprises:

[0010] receiving a service calling request sent by a first device, the service calling request being used to request to call a target service to perform a target action, the service calling request being generated by the first device based on a first instruction recognition result of a first input instruction;

[0011] obtaining a target service installation package of the target service from a server based on the service calling request;

[0012] deploying the target service based on the target service installation package;

[0013] calling the target service to perform the target action.

[0014] In an aspect, the present application provides a service calling method, and the method comprises the following steps:

[0015] An instruction recognition module is configured to recognize the first input instruction to obtain a first instruction recognition result;

[0016] A request generation module is configured to generate a service calling request based on the first instruction recognition result, wherein the service calling request is used to request a second device to call a target service to perform a target action;

[0017] A request sending module is configured to send the service calling request to the second device, so that the second device deploys the target service based on a target service installation package and calls the target service to perform the target action, wherein the target service installation package is obtained from a server.

[0018] In an aspect, the present application provides a service calling device, and the device comprises:

[0019] A request receiving module is configured to receive a service calling request sent by a first device, wherein the service calling request is used to request to call a target service to perform a target action, and the service calling request is generated by the first device based on a first instruction recognition result of a first input instruction;

[0020] An installation package obtaining module is configured to obtain a target service installation package of the target service from a server based on the service calling request;

[0021] A service deployment module is configured to deploy the target service based on the target service installation package;

[0022] An execution module is configured to call the target service to perform the target action.

[0023] In an aspect, the present application provides a computer device, which comprises a processor and a memory; the memory stores at least one instruction, and the at least one instruction is used to be executed by the processor to implement the service calling method in the above aspect.

[0024] In an aspect, the present application provides a computer readable storage medium, which stores at least one program code; the program code is loaded and executed by a processor to implement the service calling method in the above aspect.

[0025] In another aspect, an embodiment of the present application provides a computer program product or computer program, which comprises computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the computer device to perform the service calling method provided in various optional implementations of the above aspect.

[0026] In an embodiment of the present application, a first device with instruction recognition function recognizes an input instruction, and sends a service calling request to a second device based on the instruction recognition result, instructing the second device to call a target service to perform a target action, so that the second device can obtain a target service installation package from a server and deploy the target service based on the service calling request, thereby calling the target service to perform the target action. By using the scheme provided in the embodiment of the present application, even if the second device does not have instruction recognition function, the service calling based on the instruction can be realized, and the second device can realize dynamic deployment of the target service based on the service calling request, thereby avoiding memory occupation caused by pre-deployment of a large number of services. BRIEF DESCRIPTION OF DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort.

[0028] Figure 1 FIG. 1 shows a system architecture diagram of a service calling system provided by an exemplary embodiment of the present application;

[0029] Figure 2 FIG. 2 shows a flowchart of a service calling method provided by an exemplary embodiment of the present application;

[0030] Figure 3 FIG. 3 is an implementation schematic diagram of a service calling method according to an exemplary embodiment of the present application;

[0031] Figure 4 FIG. 4 is an implementation schematic diagram of a service definition and installation package uploading process according to an exemplary embodiment of the present application;

[0032] Figure 5 FIG. 5 shows a flowchart of a service calling method provided by another exemplary embodiment of the present application;

[0033] Figure 6 FIG. 6 is a flowchart of a text analysis process according to an exemplary embodiment of the present application;

[0034] Figure 7is an implementation schematic diagram of a service dynamic deployment process shown in an example embodiment of the present application;

[0035] Figure 8 is an implementation schematic diagram of a service update process shown in an example embodiment of the present application;

[0036] Figure 9 is a flow chart of a service uninstallation process shown in an example embodiment of the present application;

[0037] Figure 10 is an implementation schematic diagram of a service uninstallation process shown in an example embodiment of the present application;

[0038] Figure 11 shows a structural block diagram of a service calling apparatus provided in an embodiment of the present application;

[0039] Figure 12 shows a structural block diagram of a service calling apparatus provided in another embodiment of the present application;

[0040] Figure 13 shows a structural block diagram of a computer device provided in an example embodiment of the present application. DETAILED DESCRIPTION

[0041] For the purpose, technical solutions and advantages of the present application to be clearer, the embodiments of the present application will be described in further detail below with reference to the drawings.

[0042] For the purpose, technical solutions and advantages of the present application to be clearer, the embodiments of the present application will be described in further detail below with reference to the drawings.

[0043] Service: the smallest unit for realizing a specific task. For example, a screenshot service is used to realize a device screenshot function, a video playing service is used to play a video, and so on. When a service is called, a device can call a locally deployed service or a service deployed on another device (i.e., cross-end calling). For example, a first device can call a local video playing service to play a video or call a video playing service of a second device to realize video playing on the second device.

[0044] Unlike a conventional service that needs to be deployed in advance (if not deployed, the corresponding function cannot be realized), the service involved in the embodiments of the present application supports dynamic deployment. When a service calling request is received, if a corresponding service is deployed locally, the service is called directly; if the corresponding service is not deployed locally, a service installation package can be acquired dynamically, and service deployment is completed based on the service installation package. In addition, unlike a conventional service that needs to be installed or uninstalled manually, the service in the embodiments of the present application supports automatic uninstallation, simplifying the operation process of service installation and uninstallation.

[0045] In some embodiments, the services can include static services and dynamic services, where the static services refer to services provided by the host application and need to be pre-installed in the device, and the dynamic services refer to services supporting dynamic deployment and can be dynamically deployed in the device during the invocation process. Optionally, a service installation package of the dynamic service is stored in a server, and the device can download the service installation package from the server.

[0046] Figure 1 A system structure diagram of a service invocation system provided by an example embodiment of the present application is shown, which includes a first device 110, a second device 120 and a server 130.

[0047] The first device 110 is an electronic device with an instruction recognition function. The instruction recognition function can be a voice recognition function, a gesture recognition function, a text recognition function, etc. The electronic device can be a smart phone, a tablet computer, a wearable device, a personal computer, a vehicle terminal, etc., and the present embodiment does not limit this.

[0048] In some embodiments, with the voice recognition function, the first device 110 can convert an input voice into voice text through a voice recognition module 111, and analyze the voice text through a text analysis module 112 to obtain a voice recognition result (used to represent the user's intention).

[0049] Further, when the voice recognition result indicates that a service of an external device is invoked to make the external device perform a specific action, the first device 110 determines the external device (i.e. the second device 120 in the figure) to be invoked through a device selection module 113, and generates a service invocation request based on the voice recognition result, so as to send the service invocation request to the external device. The number of external devices is at least one.

[0050] The second device 120 is an electronic device supporting dynamic deployment of services. The electronic device can be a smart phone, a tablet computer, a wearable device, a personal computer, a vehicle terminal, etc., and the present embodiment does not limit this.

[0051] In some embodiments, the second device 120 is provided with a service agent 121, when receiving the service call request sent by the first device 110 through the service agent 121, first querying whether the first service indicated by the service call request is deployed locally through the service management module 122. The service lifecycle management module 123 is used to manage the lifecycle of each service in the device, if the target service is deployed, the service lifecycle management module 123 controls the service execution module 125 to call the target service to perform a specific action. If the target service is not deployed, the service management module 122 downloads the service installation package corresponding to the target service from the server 130 and stores it locally; the service installation module 124 deploys the target service according to the service installation package under the control of the service lifecycle management module 123. In addition to being responsible for controlling service installation and execution, the service lifecycle management module 123 also controls the service uninstallation module 126 to uninstall the deployed service according to the policy, to avoid deploying too many services on the device.

[0052] The server 130 is a server, a service cluster composed of several servers, or a cloud computing center. According to the function to be implemented, the server 130 includes a service definition management module 131, a service installation package management module 132, a subscription management module 133, a device management module 134, and a service gateway 135.

[0053] The service gateway 135 is an entrance for external devices to interact with the server, and is used to dynamically route the accessed traffic to the designated management module.

[0054] The service definition management module 131 is used to manage the service definition information of the services developed by the developers, and associate the service definition information to the corresponding service installation package, so as to subsequently obtain the corresponding service installation package based on the service definition information.

[0055] The service installation package management module 132 is used to manage the service installation package of the service developed by the developer, and store the service installation package in the file warehouse.

[0056] The subscription management module 123 is used to manage the subscription relationship between the device and the service, so as to subsequently control the device to update the service based on the subscription relationship.

[0057] The device management module 134 is used to manage the binding relationship between the account and the device, and the device state of each device, and provides the device selection basis for the device selection module 113 on the side of the first device 110.

[0058] It should be noted that the above embodiments only explain the basic framework of the service call system, and the system can also include other computer devices (such as developer devices) or servers implementing other functions, and the present embodiment does not constitute a limitation in this regard.

[0059] Reference is made to Figure 2 which shows a flowchart of a service calling method provided by an example embodiment of the present application. The example embodiment of the present application applies the method to Figure 1 The service calling system shown in the figure is taken as an example for illustration. The method comprises the following steps.

[0060] In step 201, the first device identifies the first input instruction to obtain a first instruction identification result.

[0061] Optionally, the first input instruction can be a voice instruction, a gesture instruction or a text instruction, etc. The example embodiment of the present application does not limit the form of the input instruction.

[0062] In some embodiments, the first device has a voice collection function. When the first input voice is collected by a voice collection device such as a microphone, the first device performs voice recognition on the first input voice to obtain a first voice recognition result, which is used to represent the voice control intent. As for the process of voice recognition, in a possible implementation, the first device first converts the input voice into voice text, and then parses the voice text to determine the parameters required for generating the service calling request as the voice recognition result.

[0063] In other embodiments, the first device has an image collection function. When the first gesture is collected by an image collection device such as a camera, the first device performs gesture recognition on the first gesture to obtain a first gesture recognition result based on the mapping relationship between the gesture and the control instruction, which is used to represent the control intent represented by the gesture.

[0064] In still other embodiments, the first device has a text input function. When the first input text input by the user is obtained by a text input component, the first device performs recognition on the first input text to obtain a first text recognition result, which is used to represent the control intent of the input text.

[0065] Optionally, the first instruction identification result contains the parameters required for generating the service calling request.

[0066] In step 202, the first device generates a service calling request based on the first instruction identification result.

[0067] The service calling request is used to request the second device to call the target service to perform the target action.

[0068] In a possible implementation, the service calling request can be a service calling url, and the example embodiment of the present application does not limit the specific form of the service calling request.

[0069] Illustratively, as Figure 3As shown, the smartphone 31 generates a service invocation request based on the voice recognition result of "play xxx video on the car machine", and the service invocation request is used to request the car machine to invoke the video playing service to play the xxx video.

[0070] In step 203, the first device sends a service invocation request to the second device.

[0071] In a possible implementation, after determining the second device to be invoked, the first device acquires the device address of the second device, and then sends the service invocation request to the second device based on the device address.

[0072] In some embodiments, when the number of second devices is at least two, the first device sends a service invocation request to each second device, where different second devices correspond to different service invocation requests (there are differences in some parameters in the requests, but they are all used to invoke the same service to perform the same action).

[0073] As shown, Figure 3 As shown, the smartphone 31 sends a service invocation request to the car machine 32.

[0074] In step 204, the second device receives the service invocation request sent by the first device.

[0075] In a possible implementation, the second device receives the service invocation request through a service agent.

[0076] In some embodiments, the second device checks the service invocation request, and further responds to the service invocation request after passing the check. The check manner includes request integrity check, invocation requester check, parameter compliance check, etc., which are not limited in the embodiments of the present application.

[0077] Optionally, after receiving the service invocation request, the second device automatically determines whether to accept the request, or determines whether to accept the request based on a user indication. If the request is accepted, step 205 is performed; if the request is not accepted, the process ends (a rejection invocation notification can be sent to the first device).

[0078] In step 205, the second device acquires a target service installation package of a target service from a server based on the service invocation request.

[0079] In a possible implementation, the second device detects whether the target service indicated by the service invocation request is deployed. If the target service is deployed, the service is invoked; if the target service is not deployed, dynamic deployment of the target service is needed first.

[0080] In the dynamic deployment of the target service, the second device first acquires the target server installation package of the target service from the server. The server is provided with a file warehouse containing service installation packages of dynamic services supporting dynamic deployment and realizing different functions.

[0081] As to the source of the service in the server, in a possible implementation, the service is developed by a developer and uploaded to the server.

[0082] As shown in Figure 4 , the developer uploads the service installation package to the server 130 by calling the upload interface of the service installation package management module 132 through the service gateway 135 of the server 130. The service installation package successfully uploaded is saved in the file warehouse in association with a unique installation package identifier, and the service installation package management module 132 feeds back the installation package identifier to the developer.

[0083] Further, the developer associates the service definition information of the service to the installation package identifier, and then saves the service definition information in the server 130 by calling the upload interface of the service definition management module 131 through the service gateway 135.

[0084] In a possible implementation, the second device sends an installation package acquisition request to the server, and the service gateway of the server receives the request, routes the request to the service installation package management module, and acquires the target service installation package from the file warehouse, so as to feed back the target service installation package to the second device.

[0085] Illustratively, as shown in Figure 3 , when the video playing service is not deployed, the car machine 32 downloads the video playing service installation package from the server 33.

[0086] Step 206: The second device deploys the target service based on the target service installation package.

[0087] In a possible implementation, the second device checks the acquired target service installation package, and deploys the target service based on the target service installation package after passing the check.

[0088] Step 207: The second device calls the target service to execute the target action.

[0089] Further, the second device determines the target action indicated by the service calling request, so as to call the target service to execute the target action.

[0090] Illustratively, as shown in Figure 3 , the car machine 32 determines that the target action is “playing xxx video”, so as to call the video playing service to play the xxx video.

[0091] From Figure 3As can be obviously seen from the embodiments, the smart phone with the voice recognition function can be used as the dispatch center to realize the voice calling of the services in the car machine in the case that the car machine does not have the voice control function; in the case that the car machine has the voice control function, the influence of the car machine on other services caused by the frequent voice recognition of the car machine can be avoided (the performance of the car machine is generally lower than that of the smart phone, and the car machine needs to call the important services related to the driving of the vehicle in real time). In addition, the car machine can dynamically deploy the services in the case that the service calling request is received, and the content occupation caused by the pre-deployment of the services (especially some services with low use frequency) can be avoided.

[0092] To sum up, in the embodiments of the present application, the first device with the instruction recognition function recognizes the input instruction, and sends a service calling request to the second device based on the instruction recognition result, instructs the second device to call the target service to perform the target action, so that the second device can obtain the target service installation package from the server based on the service calling request and deploy the target service, thereby calling the target service to perform the target action. By using the scheme provided in the embodiments of the present application, even if the second device does not have the instruction recognition function, the instruction-based service calling can be realized, and the second device can realize the dynamic deployment of the target service based on the service calling request, thereby avoiding the memory occupation caused by the pre-deployment of a large number of services.

[0093] For reference Figure 5 which shows a flowchart of a service calling method provided by another exemplary embodiment of the present application. The embodiment of the present application applies the method to Figure 1 The service calling system shown is taken as an example for illustration. The method comprises the following steps.

[0094] In step 501, the first device recognizes the first input instruction to obtain a first instruction recognition result.

[0095] Optionally, the first instruction recognition result comprises a target device name of a required calling device, a target service name of a required calling target service, and a target action name of a target action.

[0096] In a possible implementation manner, as shown in Figure 6 , the text analysis pre-configuration is first performed in the first device, so that the text analysis is performed based on the pre-configuration content in the application process.

[0097] The content configured in the text analysis pre-configuration process comprises an intent dictionary, an intent slot, an intent corpus, and an intent reply.

[0098] The intent dictionary includes key-value pairs in which the main word is the key and a list of synonyms is the value. For example, three intent dictionaries are configured. The key of the intent dictionary 1 is the device name, and the value is a list of synonyms of the device name (for example, the key is car machine, and the value is car terminal, car computer, etc.). The key of the intent dictionary 2 is the service name of the required calling service, and the value is a list of synonyms of the service name (for example, the key is video playing service, and the value is opening, playing, etc.). The key of the intent dictionary 3 is the action name of the required action, and the value is a list of synonyms corresponding to the action name.

[0099] The intent slot is a pre-configured placeholder variable, which corresponds to an intent dictionary. For example, three intent slots are configured. The variable of the intent slot 1 is var1, which corresponds to the intent dictionary 1. The variable of the intent slot 2 is var2, which corresponds to the intent dictionary 2. The variable of the intent slot 3 is var3, which corresponds to the intent dictionary 3.

[0100] The intent corpus is generally a mood prefix + a main word or synonym in the intent dictionary + a mood suffix or a grammatical variant thereof, which can support regular and irregular corpora. For example, a regular corpus and multiple irregular corpora are configured:

[0101] Regular corpus (regular matching):

[0102] (Please | Please help me | Help me |...) (car machine | car machine | car machine | car | car | car) (play | open |...) (XXX video) (OK | Can you | Yes | Can you |...)?

[0103] Irregular corpus:

[0104] Open XXX video on the car machine.

[0105] Open XXX video on the car machine.

[0106] Open XXX video on the car machine.

[0107] The intent reply is an operation performed when the output text matches the intent corpus. In this embodiment, it refers to obtaining target device address information and assembling a service calling request with the variable value of the intent slot, and initiating a call.

[0108] Optionally, when performing text analysis, the first device matches the voice text with the above-mentioned intent corpus and obtains the parameter value on the intent slot obtained by successful matching.

[0109] In an illustrative example, when the voice text is "play xxx video on the car machine", the matched parameter values are var1 = "car machine", var2 = "video playing service", and var3 = "playing xxx video".

[0110] In step 502, the first device obtains device addresses of at least one candidate device from the server based on the target device name contained in the first instruction recognition result, the candidate device meeting the target device name.

[0111] In the case where the target device name is contained in the first instruction recognition result, there can be multiple candidate devices meeting the target device name. In order to facilitate subsequent determination of the target device, the first device obtains device addresses of at least one candidate device from the server.

[0112] Optionally, the device address can be an address of a service agent in each candidate device, such as a gateway address of the service agent.

[0113] Optionally, the candidate device is a device meeting the target device name and having an association relationship with the first device. The association relationship can include at least one of the following: logging into the same user account, being located in the same device group, or having a friend relationship, and the like, which is not limited in the embodiments of the present application.

[0114] In a possible implementation, the device management module of the server stores device addresses of each device under a user account (reported by each device at regular intervals). The device selection module of the first device obtains device addresses of each candidate device meeting the target device name under the current user account by calling the device management module of the server.

[0115] For example, when the target device name is "car machine", and the current user account includes tablet computer 1, smart television 1, car machine 1, car machine 2, and car machine 3, the server determines car machine 1, car machine 2, and car machine 3 as candidate devices, and sends device addresses of car machine 1, car machine 2, and car machine 3 to the smart phone.

[0116] In step 503, the first device determines the second device from the at least one candidate device.

[0117] In order to ensure correct device service scheduling, the first device needs to determine the second device from the at least one candidate device. The first device can automatically determine the second device, or determine the second device based on user indication (i.e., manual determination).

[0118] In a possible implementation, the second device is determined from the at least one candidate device based on a target selection strategy.

[0119] Optionally, the target selection strategy includes at least one of the following: a distance-based selection strategy (e.g., determining the candidate device closest to the first device as the second device), a priority-based selection strategy (e.g., determining the candidate device with the highest priority as the second device based on a pre-set device priority), and a state-based selection strategy (e.g., determining the candidate device currently in use as the second device).

[0120] For example, the server periodically obtains the device status of each device and sends the device status along with the device address back to the first device. The first device then identifies the candidate device that is in use as the target device.

[0121] In another possible implementation, the second device displays a list of candidate devices, which contains device identifiers of at least one candidate device, thereby determining the second device based on a selection operation of a device identifier in the list of candidate devices.

[0122] To further improve the accuracy of the identified second device, the first device provides a list of candidate devices for the user to select from, and identifies at least one candidate device selected by the user as the target device.

[0123] Of course, in addition to the two methods of determining the second device mentioned above, the first device can also use other schemes (such as a combination of automatic and manual methods) to determine the second device, and this application embodiment does not limit this.

[0124] Step 504: The first device generates a service call request based on the device address of the second device, the target service name and the target action name contained in the first instruction identification result.

[0125] Furthermore, the first device generates corresponding service call requests for each identified second device.

[0126] In one possible implementation, the first device combines the device address, the target service name, and the target action as parameters to form a service call link.

[0127] Based on the examples in the steps above, the smartphone generates a service call request based on "vehicle system 1 address", "video playback service", and "play xxx video".

[0128] Step 505: The first device sends a service call request to the second device.

[0129] Furthermore, the first device sends a service call request to the second device based on the device address of the second device.

[0130] Step 506: The second device receives the service call request sent by the first device.

[0131] At step 507, the second device obtains the target service definition information of the target service from the server based on the target service name contained in the service invocation request, where the server stores a correspondence between service definition information and service installation package.

[0132] In order to determine whether dynamic deployment of the service is needed, the second device obtains the target service name contained in the service invocation request, and then obtains the target service definition information of the target service from the server based on the target service name.

[0133] In a possible implementation, the service management module of the second device invokes the service definition management module of the server via the service gateway of the server to obtain the target service definition information of the target service.

[0134] Illustratively, as shown in Figure 7 the service management module 122 of the second device 120 invokes the service definition management module 131 of the server 130 via the service gateway 135 to obtain the target service definition information.

[0135] At step 508, in a case where it is determined based on the target service definition information that the target service installation package does not exist locally, the second device obtains the target service installation package from the server based on the target service definition information.

[0136] In a possible implementation, the service definition information of a service is associated with the installation package identifier of a service installation package. After the second device obtains the target service definition information, the second device detects whether the target service installation package exists in the local storage based on the target installation package identifier associated with the target service definition information. If the target service installation package exists, the second device determines that dynamic deployment is not needed; if the target service installation package does not exist, the second device further obtains the target service installation package from the server based on the target service definition information.

[0137] Optionally, the second device invokes the service installation package management module of the server via the service gateway of the server to obtain the target service installation package.

[0138] Illustratively, as shown in Figure 7 the service management module 122 of the second device 120 invokes the service installation package management module 132 of the server 130 via the service gateway 135 to obtain the target service installation package.

[0139] At step 509, the second device deploys the target service based on the target service installation package.

[0140] At step 510, the second device invokes the target service to perform a target action.

[0141] The implementation of steps 509-510 can refer to steps 206-207, and the embodiments of the present application will not be described here.

[0142] As shown in Figure 7 After obtaining the target service installation package, the service lifecycle management module 123 calls the service installation module 124 to deploy the target service, and then calls the service execution module 125 to execute the target action indicated by the request.

[0143] In step 511, the second device sends a subscription message to the server, and the server is configured to maintain the subscription relationship between the second device and the target service based on the subscription message.

[0144] In some possible scenarios, the developer may update the developed service. In order to ensure the availability and timeliness of the service deployed on the device side, the server maintains the subscription relationship between each device and the service, so that the related device is notified in time to update the service based on the subscription relationship when the service is updated. Therefore, after obtaining the target installation package, the second device sends a subscription message to the server, indicating the server to update the service subscription information of the second device, that is, adding the target service in the service subscription information of the second device.

[0145] As shown in Figure 7 After obtaining the target service installation package, the second device 120 sends a subscription message to the service gateway 135, and the service gateway 135 calls the subscription management module 133 to update the subscription relationship of the second device.

[0146] Of course, in other possible embodiments, the server can also automatically update the subscription relationship between the device and the service after providing the service installation package, and the embodiments do not constitute a limitation in this regard.

[0147] In step 512, the second device receives the service update message sent by the server, and the service update message is pushed by the server based on the subscription relationship in the case of target service installation package update.

[0148] When the service is updated, the server pushes the service update message to each device that subscribes to the service based on the subscription relationship between the device and the service. Optionally, the service update message contains the service name.

[0149] In one illustrative example, the subscription relationship maintained in the server is shown in Table 1.

[0150] Table 1

[0151] Service Device Video playing service Car machine 1, smart TV 1 Screen capturing service Car machine 1, smart phone 1, tablet computer 1, smart watch Screen projection service Car machine 2, smart TV 1, tablet computer 1

[0152] When the video playing service is updated, the server pushes the service update message to the car machine 1 and the smart TV 1 respectively based on the subscription relationship shown in Table 1.

[0153] As shown in Figure 8 illustrated, the developer uploads the updated service definition information to the server 130 by calling the upload interface of the service definition management module 131 through the service gateway 135, and uploads the updated service installation package to the server 130 by calling the upload interface of the service installation package management module 131 through the service gateway 135. After completing the service definition information and service installation package update, the subscription management module 133 of the server 130 sends the service update message to the service agent 121 of the second device 120 through the service gateway 135.

[0154] In step 513, the second device acquires the updated target service installation package from the server based on the service update message.

[0155] Further, the second device acquires the updated target service installation package from the server based on the service name in the service update message, and downloads the originally deployed target service and deletes the originally stored target service installation package.

[0156] As shown in Figure 8 illustrated, the service management module 122 of the second device 120 acquires the updated service installation package from the server 120 and stores it in the local storage.

[0157] Optionally, the second device can further redeploy the target service based on the updated target service installation package, or perform service deployment in real time when a subsequent service call request is received, which is not limited in the embodiment.

[0158] In the embodiment, the first device acquires the service definition information and determines whether the local storage has the service installation package based on the service definition information, so as to avoid repeated downloading and waste of traffic in the case of storing the service installation package.

[0159] In addition, in the embodiment, the server maintains the subscription relationship between the device and the service, and pushes the service update message to the related device based on the subscription relationship in the case of service update, so as to ensure the availability and timeliness of the service deployed on the device side.

[0160] In order to avoid that the service occupies the memory for a long time, the second device can automatically uninstall the service according to the strategy, or the user can control the second device to uninstall the service through the instruction. As Figure 9 illustrated, a flowchart of a service uninstallation process is shown.

[0161] Step 901, the first device identifies the second input instruction to obtain a second instruction identification result.

[0162] Optionally, the second input instruction can be a voice instruction, a gesture instruction, or a text instruction, etc. The form of the input instruction is not limited in the embodiments of the present application.

[0163] In a possible implementation, when the input instruction is identified and the control intention represented by the instruction identification result is to delete the deployed service, the first device obtains the second instruction identification result, wherein the second instruction identification result contains parameters required for generating the service uninstall request.

[0164] Optionally, the second instruction identification result contains the device name of the service to be uninstalled and the service name of the service to be uninstalled.

[0165] The specific manner in which the first device performs instruction identification can refer to the above embodiments, which will not be repeated here.

[0166] In an illustrative example, the smartphone performs voice recognition on "delete the video playing service on the car machine" to obtain a voice recognition result containing the device name "car machine" and the service name "video playing service".

[0167] Step 902, the first device generates a service uninstall request based on the second instruction identification result, and the service uninstall request is used to request the second device to uninstall the target service.

[0168] In the case where the second instruction identification result contains the device name, there can be multiple candidate devices that meet the device name. In order to ensure the accuracy of subsequent service uninstallation, the first device needs to determine the target device that actually needs to download the service from the candidate devices.

[0169] In a possible implementation, the present step can include the following steps:

[0170] 1. Based on the target device name and the target service name contained in the second instruction identification result, obtain the device address of at least one candidate device from the server, the candidate device meets the target device name and deploys the target service.

[0171] In order to facilitate subsequent determination of the target device, the first device obtains the device address of at least one candidate device from the server. Optionally, the device address can be the address of the service agent in each candidate device, such as the gateway address of the service agent.

[0172] Optionally, the candidate device is a device that matches the target device name, is associated with the first device, and has the target service deployed on it. This association may include at least one of the following: logging into the same user account, being in the same device group, or having a friend relationship, etc., but this embodiment does not limit this.

[0173] In one possible implementation, the server's device management module stores the device addresses of each device under the user account (reported periodically by each device), and the subscription management module stores the subscription relationship between the service and the device. The device selection module of the first device obtains the device addresses of each candidate device under the current user account that matches the target device name and has the target service deployed by calling the server's device management module and subscription management module.

[0174] For example, if the target device is named "vehicle infotainment system", and the current user account includes tablet 1, smart TV 1, vehicle infotainment system 1, vehicle infotainment system 2, and vehicle infotainment system 3, and stores the subscription relationship between vehicle infotainment system 1 and video playback service, the server will identify vehicle infotainment system 1 as a candidate device and send the device address of vehicle infotainment system 1 to the smartphone.

[0175] 2. Determine the second device from at least one candidate device.

[0176] To ensure correct service unloading, the first device needs to determine the second device from at least one candidate device. The first device can determine the second device automatically, or it can determine the second device based on user instructions (i.e., manually).

[0177] In one possible implementation, the second device determines the second device from at least one candidate device based on a target selection strategy.

[0178] Optionally, the target selection strategy includes at least one of the following: a distance-based selection strategy (e.g., determining the candidate device closest to the first device as the second device), a priority-based selection strategy (e.g., determining the candidate device with the highest priority as the second device based on a pre-set device priority), and a state-based selection strategy (e.g., determining the candidate device currently in use as the second device).

[0179] For example, the server periodically obtains the device status of each device and sends the device status along with the device address back to the first device. The first device then identifies the candidate device that is in use as the target device.

[0180] In another possible implementation, the second device displays a list of candidate devices, which contains device identifiers of at least one candidate device, thereby determining the second device based on a selection operation of a device identifier in the list of candidate devices.

[0181] To further improve the accuracy of the determined second device, the first device provides a list of candidate devices for the user to select, and determines at least one candidate device selected by the user as the target device.

[0182] Of course, in addition to the above two ways of determining the second device, the first device can also determine the second device by other schemes (such as a combination of automatic and manual schemes), and the embodiments of the present application do not limit this.

[0183] 3. Based on the device address of the second device and the target service name, a service offloading request is generated.

[0184] Further, the first device generates a corresponding service offloading request for each determined second device.

[0185] In a possible implementation, the first device combines the device address and the target service name as parameters to form a service offloading link.

[0186] In combination with the examples in the above steps, the smartphone generates a service offloading request based on the "car machine 1 address" and the "video playback service".

[0187] Step 903, the first device sends a service offloading request to the second device.

[0188] In a possible implementation, the first device sends a service offloading request to the second device based on the device address of the second device.

[0189] Step 904, the second device receives the service offloading request sent by the first device.

[0190] In a possible implementation, the second device receives the service offloading request through a service agent.

[0191] In some embodiments, the second device checks the service offloading request and further responds to the service offloading request after passing the check. The check method includes request integrity check, offloading request party check, and parameter compliance check, etc., and the embodiments of the present application do not limit this.

[0192] Optionally, after receiving the service offloading request, the second device automatically determines whether to accept the request, or determines whether to accept the request based on user indication. If the request is accepted, step 905 is executed; if the request is not accepted, the process is ended (a rejection offloading notification can be sent to the first device).

[0193] Step 905, the second device offloads the target service based on the service offloading request.

[0194] To ensure the accuracy of service uninstallation, in a possible implementation, the second device first acquires target service definition information of the target service from the server based on the target service name contained in the service uninstallation request, thereby uninstalling the target service based on the target service definition information and deleting the locally stored target service installation package.

[0195] In addition, to avoid that the second device can still receive service update messages after service uninstallation, in a possible implementation, the second device sends a subscription cancellation message to the server to instruct the server to update the subscription relationship in the case that the target service is uninstalled (whether by instruction control or automatic uninstallation), and correspondingly, the server is configured to delete the subscription relationship between the second device and the target service based on the subscription cancellation message.

[0196] Optionally, the subscription cancellation message contains the device identifier of the second device and the target service name of the target service.

[0197] Illustratively, as shown in Figure 10 After the second device 120 receives the service uninstallation request through the service agent 121, the service management module 122 acquires target service definition information corresponding to the target service name by calling the service definition management module 131 through the service gateway 135, and then calls the service uninstallation module 126 to uninstall the target service and delete the target service installation package by the service lifecycle management module 123. After completing the service uninstallation, the second device 120 further sends a subscription cancellation message to the server 130 so that the subscription management module 133 of the server 130 deletes the subscription relationship between the target service and the second device.

[0198] In this embodiment, the user can instruct the second device to perform service uninstallation by inputting an instruction, without manually uninstalling the service, thereby simplifying the service uninstallation process and avoiding that too many services deployed in the second device affect the running performance of the device.

[0199] In another possible implementation, the second device uninstalls the target service in the case that an automatic uninstallation condition is met, wherein the automatic uninstallation condition includes at least one of the following: the number of invocations of the target service reaches a number threshold, the target service is not invoked within a target time length, and the deployment time length of the target service reaches a time length threshold.

[0200] Optionally, the automatic uninstallation condition is set in the service lifecycle management module and is customizable.

[0201] For example, when the number of invocations of the target service reaches 2, the service lifecycle management module in the second device automatically invokes the service uninstall module to uninstall the target service; when the target service is not invoked within 2 hours, the service lifecycle management module in the second device automatically invokes the service uninstall module to uninstall the target service; when the deployment duration of the target service reaches 24 hours, the service lifecycle management module in the second device automatically invokes the service uninstall module to uninstall the target service.

[0202] In the above embodiment, the interactive process is taken as an example for illustrative description, wherein the steps with the first device as the execution subject can be implemented as a service invocation method on the first device side, the steps with the second device as the execution subject can be implemented as a service invocation method on the second device side, and the steps with the server as the execution subject can be implemented as a service invocation method on the server side. Details are not described herein again.

[0203] The following is a device embodiment of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0204] Please refer to Figure 11 which shows a structural block diagram of a service invocation device provided by an embodiment of the present application. The device can include:

[0205] An instruction recognition module 1101 is configured to recognize a first input instruction to obtain a first instruction recognition result.

[0206] A request generation module 1102 is configured to generate a service invocation request based on the first instruction recognition result, wherein the service invocation request is used to request a second device to invoke a target service to perform a target action.

[0207] A request sending module 1103 is configured to send the service invocation request to the second device, so that the second device deploys the target service based on a target service installation package and invokes the target service to perform the target action, wherein the target service installation package is obtained from a server.

[0208] Optionally, the request generation module 1102 is configured to:

[0209] obtain device addresses of at least one candidate device from the server based on a target device name contained in the first instruction recognition result, wherein the candidate device meets the target device name.

[0210] determine the second device from the at least one candidate device.

[0211] generate the service invocation request based on the device address of the second device, the target service name and the target action name contained in the first instruction recognition result;

[0212] The request sending module 1103 is configured to:

[0213] send the service invocation request to the second device based on the device address of the second device.

[0214] Optionally, in the process of determining the second device from the at least one candidate device, the request generation module 1102 is configured to:

[0215] determine the second device from the at least one candidate device based on a target selection strategy;

[0216] or,

[0217] display a candidate device list containing device identifiers of the at least one candidate device, and determine the second device based on a selection operation on the device identifiers in the candidate device list.

[0218] Optionally, the instruction recognition module 1101 is further configured to recognize a second input instruction to obtain a second instruction recognition result.

[0219] The request generation module 1102 is further configured to generate a service offloading request based on the second instruction recognition result, the service offloading request being used to request the second device to offload the target service.

[0220] The request sending module 1103 is further configured to send the service offloading request to the second device, so that the second device offloads the target service.

[0221] Optionally, in the process of generating the service offloading request based on the second instruction recognition result, the request generation module 1102 is configured to:

[0222] obtain device addresses of at least one candidate device from the server based on a target device name and a target service name contained in the second instruction recognition result, the candidate device meeting the target device name and being deployed with the target service;

[0223] determine the second device from the at least one candidate device;

[0224] generate the service offloading request based on the device address of the second device and the target service name;

[0225] The request sending module 1103 is configured to:

[0226] send the service offloading request to the second device based on the device address of the second device.

[0227] Please refer to Figure 12 which shows a structural block diagram of a service calling apparatus provided by another embodiment of the present application. The apparatus can include:

[0228] The request receiving module 1201 is configured to receive a service calling request sent by a first device, the service calling request being used to request calling a target service to perform a target action, and the service calling request being generated by the first device based on a first instruction recognition result of a first input instruction;

[0229] The installation package obtaining module 1202 is configured to obtain a target service installation package of the target service from a server based on the service calling request;

[0230] The service deploying module 1203 is configured to deploy the target service based on the target service installation package;

[0231] The executing module 1204 is configured to call the target service to perform the target action.

[0232] Optionally, the installation package obtaining module 1202 is configured to:

[0233] obtain target service definition information of the target service from the server based on a target service name contained in the service calling request;

[0234] obtain the target service installation package from the server based on the target service definition information in a case where it is determined based on the target service definition information that the target service installation package does not exist locally, the server storing a correspondence between service definition information and service installation packages.

[0235] Optionally, the apparatus further includes:

[0236] The message sending module is configured to send a subscription message to the server, the server being configured to maintain a subscription relationship between the second device and the target service based on the subscription message.

[0237] Optionally, the apparatus further includes:

[0238] The message receiving module is configured to receive a service update message sent by the server, the service update message being pushed by the server based on the subscription relationship in a case where the target service installation package is updated;

[0239] The updating module is configured to obtain an updated target service installation package from the server based on the service update message.

[0240] Optionally, the apparatus further comprises:

[0241] The message sending module is configured to send a subscription cancellation message to the server in a case where the target service is unloaded, and the server is configured to delete the subscription relationship based on the subscription cancellation message.

[0242] Optionally, the apparatus further comprises:

[0243] The request receiving module 1201 is further configured to receive a service uninstallation request sent by the first device, the service uninstallation request being used to request the second device to uninstall the target service, and the service uninstallation request being generated by the first device based on a second instruction recognition result of a second input instruction;

[0244] The uninstallation module is configured to uninstall the target service based on the service uninstallation request.

[0245] Optionally, the uninstallation module is configured to:

[0246] obtain the target service definition information of the target service from the server based on a target service name contained in the service uninstallation request;

[0247] uninstall the target service based on the target service definition information, and delete the locally stored target service installation package.

[0248] Optionally, the uninstallation module is further configured to:

[0249] uninstall the target service in a case where an automatic uninstallation condition is met, the automatic uninstallation condition including at least one of the following: a number of times of calling the target service reaches a number threshold, the target service is not called within a target time length, and a deployment time length of the target service reaches a time length threshold.

[0250] Please refer to Figure 13 which shows a structural block diagram of a computer device provided by an example embodiment of the present application. The computer device 1700 can be implemented as the first device or the second device in the above-mentioned embodiments. The computer device 1700 can include one or more of the following components: a processor 1710 and a memory 1720.

[0251] The processor 1710 can include one or more processing cores. The processor 1710 connects various parts within the entire computer device 1700 by various interfaces and lines, and performs various functions and processes data of the computer device 1700 by running or executing instructions, programs, code sets or instruction sets stored in the memory 1720, and calling data stored in the memory 1720. Optionally, the processor 1710 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), a programmable logic array (PLA). The processor 1710 can integrate a combination of one or several of a central processing unit (CPU), a graphics processing unit (GPU), a neural-network processing unit (NPU), and a modem. Among them, the CPU is mainly used to process operating systems, user interfaces, and application programs; the GPU is used to render and draw the content to be displayed on the touch display screen; the NPU is used to implement artificial intelligence (AI) functions; and the modem is used to process wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 1710, but be implemented by a separate chip.

[0252] The memory 1720 can include a random access memory (RAM) and can also include a read-only memory (ROM). Optionally, the memory 1720 includes a non-transitory computer-readable storage medium. The memory 1720 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 1720 can include a program storage area and a data storage area, wherein the program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing each of the methods described below, etc.; and the data storage area can store data (such as audio data, a phone book) created according to the use of the computer device 1700, etc.

[0253] In some embodiments, when the computer device 1700 implements a first device, the computer device 1700 is further provided with a voice collection component, which can be a built-in microphone or an external microphone.

[0254] In addition, those skilled in the art can understand that the structure of the computer device 1700 shown in the above-described drawings does not constitute a limitation on the computer device, and the computer device can include more or fewer components than those shown in the drawings, or combine certain components, or different component arrangements. For example, the computer device 1700 further includes a display screen, a camera component, a speaker, a radio frequency circuit, an input unit, a sensor (such as an acceleration sensor, an angular velocity sensor, a light sensor, etc.), an audio circuit, a WiFi module, a power supply, a Bluetooth module, and the like, which are not described here.

[0255] The embodiments of the present application also provide a computer readable storage medium, which stores at least one program code, the program code is loaded and executed by a processor to implement the service calling method according to the above various embodiments.

[0256] The embodiments of the present application provide a computer program product or computer program, which includes computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to make the computer device execute the service calling method provided in various optional implementation manners of the above aspects.

[0257] It should be understood that "multiple" referred to herein refers to two or more. The "and / or" describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone. The character " / " generally represents that the associated objects before and after it are in an "or" relationship. In addition, the step numbers described herein only exemplarily show a possible execution order between steps, and in some other embodiments, the above steps can also be executed in a different order from the numbering order, such as simultaneously executing two steps with different numbers, or executing two steps with different numbers in an order opposite to the illustration, and the embodiments of the present application do not limit this.

[0258] The above only describes optional embodiments of the present application and does not limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A service invocation method, characterized by, The method is performed by a first device, and the method comprises: recognizing a first input instruction to obtain a first instruction recognition result; obtaining, from a server, a device address of at least one candidate device based on a target device name contained in the first instruction recognition result, the candidate device meeting the target device name; determining a second device from the at least one candidate device by the first device; generating a service call request based on the device address of the second device, a target service name and a target action name contained in the first instruction recognition result, the service call request being used to request the second device to call a target service to perform a target action, wherein a service is a minimum unit for implementing a specific task, and comprises a static service and a dynamic service, a service installation package of the dynamic service being stored in a server and supporting being downloaded from the server in a process of dynamic deployment; sending, to the second device, the service call request based on the device address of the second device, so that the second device deploys the target service based on a target service installation package and calls the target service to perform the target action, the target service installation package being obtained by the second device from the server based on target service definition information in a case that it is determined by the second device based on the target service definition information that the target service installation package does not exist locally, the server storing a correspondence between service definition information and service installation packages, and target service definition information of the target service being obtained by the second device from the server based on the target service name contained in the service call request; wherein the target service installation package is updated by the second device based on a service update message in a case that the service update message is received by the second device, the service update message being pushed by the server based on a subscription relationship in a case that the target service installation package is updated, the server being used to maintain a subscription relationship between the second device and the target service based on a subscription message, the subscription message being sent by the second device to the server; recognizing a second input instruction to obtain a second instruction recognition result; generating a service uninstall request based on the second instruction recognition result, the service uninstall request being used to request the second device to uninstall the target service; and sending, to the second device, the service uninstall request, so that the second device uninstalls the target service.

2. The method of claim 1, wherein, The determining of the second device from the at least one candidate device comprises: determining the second device from the at least one candidate device based on a target selection strategy; or, displaying a candidate device list containing device identifiers of the at least one candidate device in the candidate device list; and determining the second device based on a selection operation on the device identifiers in the candidate device list.

3. The method of claim 1, wherein, The generating of the service uninstall request based on the second instruction recognition result comprises: obtaining, from the server, a device address of at least one candidate device that meets the target device name and is deployed with the target service, based on the target device name and the target service name contained in the second instruction recognition result; determining the second device from the at least one candidate device; generating the service offloading request based on the device address of the second device and the target service name; the sending of the service offloading request to the second device comprises: sending the service offloading request to the second device based on the device address of the second device.

4. A service invocation method characterized by, The method is performed by a second device, and the method comprises: receiving a service invocation request sent by a first device, the service invocation request being used to request invoking a target service to perform a target action, the service invocation request being generated by the first device based on a device address of the second device, a target service name and a target action name contained in a first instruction recognition result of a first input instruction, the second device being determined by the first device from at least one candidate device, a device address of at least one candidate device being obtained by the first device from a server based on a target device name contained in the first instruction recognition result, the candidate device meeting the target device name, wherein a service is a minimum unit for implementing a specific task, and comprises a static service and a dynamic service, a service installation package of the dynamic service being stored in a server and supporting being downloaded from the server in a process of dynamic deployment; obtaining target service definition information of the target service from the server based on the target service name contained in the service invocation request; in a case where it is determined based on the target service definition information that a target service installation package does not exist locally, obtaining the target service installation package from the server based on the target service definition information, the server storing a correspondence between service definition information and service installation packages; deploying the target service based on the target service installation package; invoking the target service to perform the target action; receiving a service offloading request sent by the first device, the service offloading request being used to request the second device to offload the target service, the service offloading request being generated by the first device based on a second instruction recognition result of a second input instruction; offloading the target service based on the service offloading request; sending a subscription message to the server, the server being used to maintain a subscription relationship between the second device and the target service based on the subscription message; receiving a service update message sent by the server, the service update message being pushed by the server based on the subscription relationship in a case where the target service installation package is updated; obtaining an updated target service installation package from the server based on the service update message.

5. The method of claim 4, wherein, The method further comprises: in a case where the target service is offloaded, sending a subscription cancellation message to the server, the server being used to delete the subscription relationship based on the subscription cancellation message.

6. The method of claim 4, wherein, the offloading of the target service based on the service offloading request comprises: obtaining the target service definition information of the target service from the server based on a target service name contained in the service uninstall request; uninstalling the target service based on the target service definition information, and deleting the locally stored target service installation package.

7. The method of any one of claims 4 to 5, wherein, The method further includes: uninstalling the target service when an automatic uninstall condition is met, the automatic uninstall condition including at least one of the following: the number of invocations of the target service reaching a threshold number of invocations, the target service not being invoked within a target time period, and the deployment time period of the target service reaching a threshold time period.

8. A service invocation apparatus characterized by comprising: The apparatus includes: an instruction recognition module configured to recognize a first input instruction to obtain a first instruction recognition result; a request generation module configured to obtain a device address of at least one candidate device from a server based on a target device name contained in the first instruction recognition result, the candidate device meeting the target device name; determine a second device from the at least one candidate device; and generate a service invocation request based on the device address of the second device, a target service name and a target action name contained in the first instruction recognition result, the service invocation request being used to request the second device to invoke a target service to perform a target action, wherein a service is a minimum unit for implementing a specific task, and includes a static service and a dynamic service, a service installation package of the dynamic service being stored in a server and supporting being downloaded from the server in a dynamic deployment process; a request sending module configured to send the service invocation request to the second device based on the device address of the second device, so that the second device deploys the target service based on a target service installation package and invokes the target service to perform the target action, the target service installation package being obtained by the second device from the server based on target service definition information in a case where it is determined by the second device based on the target service definition information that the target service installation package does not exist locally, the server storing a correspondence between service definition information and service installation packages, and target service definition information of the target service being obtained by the second device from the server based on a target service name contained in the service invocation request; wherein the target service installation package is updated by the second device based on a service update message in a case where the service update message is received by the second device, the service update message being pushed by the server based on a subscription relationship in a case where the target service installation package is updated, the server being configured to maintain a subscription relationship between the second device and the target service based on a subscription message, the subscription message being sent by the second device to the server; The instruction recognition module is further configured to recognize a second input instruction to obtain a second instruction recognition result. The request generation module is further configured to generate a service uninstall request based on the second instruction recognition result, the service uninstall request being used to request the second device to uninstall the target service. The request sending module is further configured to send the service offloading request to the second device, so that the second device offloads the target service.

9. A service invocation apparatus characterized by comprising: The apparatus comprises: The request receiving module is configured to receive a service invocation request sent by a first device, the service invocation request being used to request to invoke a target service to perform a target action, the service invocation request being generated by the first device based on a device address of a second device, a target service name and a target action name contained in a first instruction recognition result of a first input instruction, the second device being determined by the first device from at least one candidate device, a device address of the at least one candidate device being obtained by the first device from a server based on a target device name contained in the first instruction recognition result, the candidate device meeting the target device name, wherein a service is a minimum unit for implementing a specific task, and includes static services and dynamic services, a service installation package of the dynamic service being stored in the server and supporting being downloaded from the server in a dynamic deployment process; The installation package obtaining module is configured to obtain target service definition information of the target service from the server based on the target service name contained in the service invocation request, and obtain the target service installation package from the server based on the target service definition information in a case where it is determined based on the target service definition information that the target service installation package does not exist locally. The service deployment module is configured to deploy the target service based on the target service installation package. The execution module is configured to invoke the target service to perform the target action. The request receiving module is further configured to receive a service offloading request sent by the first device, the service offloading request being used to request the second device to offload the target service, the service offloading request being generated by the first device based on a second instruction recognition result of a second input instruction. The offloading module is configured to offload the target service based on the service offloading request. The message sending module is configured to send a subscription message to the server, the server being configured to maintain a subscription relationship between the second device and the target service based on the subscription message. The message receiving module is configured to receive a service update message sent by the server, the service update message being pushed by the server based on the subscription relationship in a case where the target service installation package is updated. The update module is configured to obtain an updated target service installation package from the server based on the service update message.

10. A computer device, comprising: The computer device comprises a processor and a memory; the memory stores at least one instruction, the at least one instruction being used to be executed by the processor to implement the service invocation method according to any one of claims 1 to 3, or implement the service invocation method according to any one of claims 4 to 7.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores at least one program code, the program code is loaded and executed by the processor to implement the service calling method of any one of claims 1 to 3, or implement the service calling method of any one of claims 4 to 7.

12. A computer program product, characterised in that, The computer program product comprises computer instructions stored in a computer readable storage medium; the processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions, so that the computer device executes the service calling method of any one of claims 1 to 3, or implements the service calling method of any one of claims 4 to 7.

Images