Device and method for service calling

Abstract

The invention provides a device and a method for service calling. The device comprises a user login module, an access interface and a service calling request processing module, the user login module is used for user login and acquiring configuration information of a target service provided by the first background service system; the access interface is used for receiving a service calling request with a predetermined format sent by a user through a second background service system, the service calling request is used for calling a target service, and the predetermined format is used for the access interface to identify the service calling request; the service calling request processing module is used for calling a target service according to the service calling request and the configuration information to obtain response data of the target service; and the service calling request processing module also sends response data to the second background service system. According to the device, technical unification of service calling for the first background service systems can be realized, the efficiency of determining the service calling for the first background service systems is improved, and the development cost of an enterprise is saved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a device and method for service invocation. Background Art

[0002] Currently, in addition to providing its own services to the front-end application, the back-end service system sometimes needs to call a target service (which may be called a service call) provided by an external back-end service system to provide the target service to the front-end application.

[0003] However, since different backend service systems use different technologies, different backend service systems have different ways of making service calls. When an enterprise determines the service call plans for multiple backend service systems, it needs to determine the corresponding service call plans for each backend service system based on the technology used by each backend service system, which reduces the enterprise's development efficiency and increases the enterprise's development costs. For example, both backend service system A and backend service system B need to call the target service of external backend service system C. The enterprise needs to separately formulate a set of plans for backend service system A to call the target service of external backend service system C, and a set of plans for backend service system B to call the target service of external backend service system C. Summary of the invention

[0004] The present application provides a device and method for service calling, which realizes the technical unification of service calling schemes for multiple first background service systems, improves the efficiency of determining the service calling scheme for the first background service system, and saves the development cost of the enterprise.

[0005] In a first aspect, a device for service invocation is provided, comprising a user login module, an access interface and a service invocation request processing module;

[0006] The user login module is used for user login and obtaining configuration information of the target service provided by the first background service system;

[0007] The access interface is used to receive a service call request in a predetermined format sent by a user through the second background service system, the service call request is used to call a target service, and the predetermined format is used for the access interface to identify the service call request;

[0008] The service call request processing module is used to call the target service according to the service call request and configuration information to obtain the response data of the target service;

[0009] The service call request processing module is also used to send response data to the second background service system.

[0010] In a feasible design, a subscription interface is also included;

[0011] The subscription interface is used to receive a subscription request sent by a user through the second background service system, the subscription request includes a subscription event for a target service and an identifier of the second background service system, and the subscription event includes receiving response data;

[0012] The service call request processing module is also used to send response data to the second background service system, including:

[0013] The service call request processing module is also used to monitor whether the subscription event occurs;

[0014] If a subscription event occurs, the service call request processing module is further configured to send response data to the second background service system according to an identifier of the second background service system.

[0015] In a feasible design, the device adopts a distributed system architecture, which includes multiple microservices, and the user login module, access interface, and service call request processing module are deployed in multiple microservices.

[0016] In a feasible design, it also includes a configuration information storage module;

[0017] The configuration information storage module is used to store the configuration information obtained by the user login module.

[0018] In a feasible design, before calling the target service according to the service call request and the configuration information, the service call request processing module is also used to create a target proxy service submodule matching the target service according to the configuration information;

[0019] The service call request processing module is also used to update the proxy service mapping table according to the target proxy service submodule, and the proxy service mapping table is used to associate at least one proxy service submodule and the identification of at least one proxy service submodule.

[0020] In a feasible design, the service call request processing module is used to call the target service according to the service call request and configuration information, including:

[0021] The service call request processing module is also used to determine the identifier of the target proxy service submodule from the proxy service mapping table according to the service call request;

[0022] The service call request processing module is also used to trigger the target proxy service submodule to perform the following processing according to the identifier of the target proxy service submodule and the proxy service mapping table:

[0023] The target proxy service submodule obtains configuration information from the configuration information storage module according to the service call request;

[0024] The target proxy service submodule calls the target service according to the service call request and configuration information.

[0025] In a feasible design, the configuration information includes one or more of the following information:

[0026] The address of the target interface corresponding to the target service, the type of the target interface, the name of the target interface, the identifier of the target service, the format of the parameters of the target interface, and the parsing rules corresponding to the target service.

[0027] In a feasible design, the service call request processing module is used to call the target service according to the service call request and configuration information, including:

[0028] The service call request processing module is used to determine the configuration information corresponding to the target service from the configuration information storage module according to the service call request;

[0029] The service call request processing module is used to determine the proxy service call request according to the configuration information and the service call request;

[0030] The service call request processing module is used to send a proxy service call request to the first background service system according to the configuration information, so as to call the target service of the first background service system.

[0031] In a feasible design, when the configuration information includes the parsing rule corresponding to the target service, the service call request processing module is further used to send response data to the second background service system, including:

[0032] The service call request processing module is also used to parse the response data according to the parsing rules;

[0033] The service call request processing module is also used to send the response data in the target format to the second background service system according to the target format specified by the parsing rule.

[0034] In a second aspect, a method for service invocation is provided, the method comprising:

[0035] Obtaining configuration information of a target service provided by the first background service system;

[0036] Receiving a service call request in a predetermined format sent by a user through a second background service system, where the service call request is used to call a target service;

[0037] Call the target service according to the service call request and configuration information to obtain the response data of the target service;

[0038] Send response data to the second background service system.

[0039] In the current service call scheme, developers need to determine the service call request based on the technology used by the first backend service system, as well as the specific scheme for the second backend service system to transmit the service call request to the first backend service system. If there are multiple first backend service systems, developers need to formulate corresponding service call schemes based on the technologies used by each first backend service system.

[0040] In the above example of the present application, after the developer logs in to the device through the user login module, the configuration information of the target service provided by the first background service system is stored in the device in advance through the device, and the developer can also import the configuration information of the target service provided by the first background service system into the device in advance. When the developer needs to call the target service later, he only needs to determine the service call request according to the predetermined format and send it to the device through the second background service system. The device calls the target service according to the service call request and the configuration information to obtain the response data of the target service. Then forward the response data to the second background service system, and the service call of the second background service system to the first background service system can be realized. And for the developer, the developer only needs to determine the service call request that the access interface of the device can identify according to the predetermined format, and then wait for the response data forwarded by the receiving device, without determining the service call scheme according to the technology adopted by the first background service system. Therefore, if there are multiple first background service systems, the developer does not need to formulate corresponding service call schemes according to the technology adopted by each first background service system, but only needs to determine the service call request corresponding to each first background service system according to the predetermined format according to the service called by each first background service system. Therefore, the above-mentioned device provided in the present application can achieve technical unification of service calling schemes for multiple first background service systems, and improve the efficiency of determining the service calling scheme for the first background service system, saving the development cost of the enterprise. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solution of the present application, the drawings required for use in the embodiments are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0042] Figure 1 This is a schematic diagram of a system architecture for service invocation provided by an exemplary embodiment of the present application;

[0043] Figure 2 is a schematic diagram of a device structure for service invocation provided by an exemplary embodiment of the present application;

[0044] Figure 3is a schematic flow chart of a method for service invocation provided by an exemplary embodiment of the present application;

[0045] Figure 4 This is another schematic diagram of a device structure for service invocation provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0046] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be interpreted as limiting the present application. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0047] It will be understood by those skilled in the art that, unless expressly stated, the singular forms "one", "said", and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. It should be understood that when we refer to an element as being "connected" or "coupled" to another element, it may be directly connected or coupled to the other element, or there may be an intermediate element. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein includes all or any unit and all combinations of one or more associated listed items.

[0048] In order to improve the efficiency of determining the service call solution of the background service system and save the development cost of the enterprise, the present application provides a system architecture 100 for service call, such as Figure 1 shown.

[0049] The system architecture 100 includes a first background service system 110, a device for service invocation 120, and a second background service system 130. The second background service system 130 sends a service invocation request having a predetermined format to the device for service invocation 120, and the service invocation request is used to invoke a target service provided by the first background service system 110. The predetermined format is used for the interface of the device 120 to identify the service invocation request. The device for service invocation 120 forwards the service invocation request to the first background service system 110. The first background service system 110 sends response data to the device for service invocation 120 according to the service invocation request. The device for service invocation 120 forwards the response data to the second background service system 130.

[0050] The present application completes the forwarding of the service call request of the second background service system 130 and the forwarding of the response data of the first background service system 110 by setting up a device 120 for service calling, so that the second background service system 130 completes the calling of the target service provided by the first background service system 110.

[0051] like Figure 2 and Figure 3 As shown, the present application provides a device for service invocation, including a user login module, an access interface, and a service invocation request processing module;

[0052] The user login module is used for user login and obtaining configuration information of the target service provided by the first background service system;

[0053] The access interface is used to receive a service call request in a predetermined format sent by a user through the second background service system, the service call request is used to call a target service, and the predetermined format is used for the access interface to identify the service call request;

[0054] The service call request processing module is used to call the target service according to the service call request and configuration information to obtain the response data of the target service;

[0055] The service call request processing module is also used to send response data to the second background service system.

[0056] Exemplarily, the user login module obtains the configuration information input by the user by displaying a login webpage to the user. The second backend service system obtains the login page through the network, and the user enters the configuration information after logging into the page through the second backend service system.

[0057] Exemplarily, the predetermined format is the format based on the content of the service call request, and the predetermined format is determined according to the access interface. For example, the predetermined format is: the identifier of the service call request is used as the header information, and the content of the service call request is used as the intermediate information. The intermediate information is determined according to the target service. The identifier of the service call request is used by the access interface to identify and determine whether to receive the request.

[0058] In the current service call scheme, developers need to determine the service call request based on the technology used by the first backend service system, as well as the specific scheme for the second backend service system to transmit the service call request to the first backend service system. If there are multiple first backend service systems, developers need to formulate corresponding service call schemes based on the technologies used by each first backend service system.

[0059] In the above example of the present application, after the developer logs in to the device through the user login module, the configuration information of the target service provided by the first background service system is stored in advance through the device, and the developer can also import the configuration information of the target service provided by the first background service system into the device in advance. When the developer needs to call the target service later, he only needs to determine the service call request according to the predetermined format and send it to the device through the second background service system. The device calls the target service according to the service call request and the configuration information to obtain the response data of the target service. Then forward the response data to the second background service system, and the service call of the second background service system to the first background service system can be realized. And for the developer, the developer only needs to determine the service call request that the access interface of the device can identify according to the predetermined format, and then wait for the response data forwarded by the receiving device, without determining the service call scheme according to the technology adopted by the first background service system. Therefore, if there are multiple first background service systems, the developer does not need to formulate the corresponding service call scheme according to the technology adopted by each first background service system, but only needs to determine the service call request corresponding to each first background service system according to the predetermined format according to the service called by each first background service system. Therefore, the above device provided by the present application can achieve technical unification of service call schemes for multiple first background service systems, and improve the efficiency of determining the service call scheme for the first background service system, saving the development cost of the enterprise. In a feasible design, the configuration information includes one or more of the following information:

[0060] The address of the target interface corresponding to the target service, the type of the target interface, the name of the target interface, the identifier of the target service, the format of the parameters of the target interface, and the parsing rules corresponding to the target service.

[0061] Wherein, the first background service system provides target service through the target interface.

[0062] Exemplarily, the identifier of the target service is the same as the name of the target interface.

[0063] In a feasible design, it also includes a configuration information storage module;

[0064] The configuration information storage module is used to store the configuration information obtained by the user login module.

[0065] Exemplarily, the configuration information storage module uses a redis cache database or a mysql database to store configuration information.

[0066] For example, the configuration information of the target service stored in the configuration information storage module is shown in the following Table 1:

[0067] Table 1

[0068]

[0069] As shown in Table 1, the serial number indicates the serial number of the configuration information stored in the configuration information storage module, the interface name and the identifier of the target service are both "check ticket", the address of the target interface "10.215.5.82:80 / ticketCheck" is the address of the target interface, the device forwards the service call request according to the address of the target interface, the type of the target interface "GET" is used by the device to create a proxy service for the target service to process the service call request, the format of the parameters of the target interface "body" is used to specify the format followed by the parameters of the target interface in the service call request, the parsing rule "JSON" indicates that the device parses the response data sent by the first background service system according to the "JSON" format, and the device sends the response data to the second background service system in the target format "JSON" according to the target format specified by the parsing rule.

[0070] In a feasible design, the service call request includes the name of the target interface and parameters of the target interface.

[0071] Exemplarily, the parameters of the target interface in the service call request are configurable.

[0072] Users can flexibly configure the parameters of the target interface as needed to obtain different response data.

[0073] For example, after the user configures the configuration information corresponding to the verification work order service of the first background service system on the device, the second background service system sends a service call request 1 to the device. Among them, the content of the service call request 1 is the parameters of the target interface, including "'Serial number' = '1'; 'Start time' = 'March 1st'; 'End time' = 'March 31st'". The format of the content of the service call request 1 is "body". The device obtains the configuration information shown in Table 1 from the configuration information storage module through the serial number of the service call request 1. Then, according to the interface address in the configuration information, the service call request is sent to the verification work order interface of the first background service system to call the verification work order service of the first background service system. The first background service system sends response data to the device through the verification work order interface, and the response data includes the work order information for March.

[0074] If the user needs to obtain the work order information of March and April, the user can reconfigure the content corresponding to the interface parameters of service call request 1 as needed to generate service call request 2, so as to obtain the work order information of March and April. The content of service call request 2 is the parameters of the target interface, including "'sequence number' = '1'; 'start time' = 'March 1'; 'end time' = 'April 30'". The format of the content of service call request 2 is "body".

[0075] It can be seen that the user only needs to input configuration information for the target service once on the device, and then change the service call request as needed, without having to configure the target service multiple times.

[0076] In a feasible design, the service call request processing module is used to call the target service according to the service call request and configuration information, including:

[0077] The service call request processing module is used to determine the configuration information corresponding to the target service from the configuration information storage module according to the service call request;

[0078] The service call request processing module is used to determine the proxy service call request according to the configuration information and the service call request;

[0079] The service call request processing module is used to send a proxy service call request to the first background service system according to the configuration information, so as to call the target service of the first background service system.

[0080] Exemplarily, the service call request processing module is used to implement the calling of the target service according to the service call request and the configuration information, including:

[0081] The service call request processing module determines the configuration information corresponding to the target service from the configuration information storage module according to the name of the target service in the service call request;

[0082] The service call request processing module determines the proxy service call request according to the type of the target interface and the format of the parameters of the target interface in the configuration information and the parameters of the target interface of the service call request;

[0083] The service call request processing module sends a proxy service call request to the first background service system according to the address of the target interface in the configuration information, so as to call the target service of the first background service system.

[0084] In the above example, the service call request processing module selects the configuration information corresponding to the target service from the configuration information storage module according to the service call request, and then re-determines the proxy service call request that can be recognized by the first background service system according to the configuration information and the service call request to realize the target service of the first background service system.

[0085] In a feasible design, when the configuration information includes the parsing rule corresponding to the target service, the service call request processing module is further used to send response data to the second background service system, including:

[0086] The service call request processing module is also used to parse the response data according to the parsing rules;

[0087] The service call request processing module is also used to send the response data in the target format to the second background service system according to the target format specified by the parsing rule.

[0088] In the above example, no matter what technology the first backend service system uses, or what format the response data sent by the target service provided by the first backend service system uses, the service call request processing module can parse the response data through the parsing rules corresponding to the target service, and send the response data to the second backend service system in the target format, so that the second backend service system can recognize the response data.

[0089] In a feasible design, the device further includes a subscription interface;

[0090] The subscription interface is used to receive a subscription request sent by a user through the second background service system, the subscription request includes a subscription event for a target service and an identifier of the second background service system, and the subscription event includes receiving response data;

[0091] The service call request processing module is also used to send response data to the second background service system, including:

[0092] The service call request processing module is also used to monitor whether the subscription event occurs;

[0093] If a subscription event occurs, the service call request processing module is further configured to send response data to the second background service system according to an identifier of the second background service system.

[0094] Currently, after the second background service system starts a service call to the first background service system, it can only wait for the response data until it receives the response data from the first background service system, and cannot perform other processing, resulting in idle computing resources.

[0095] In the above embodiment of the present application, after the second background service system sends a subscription request to the subscription interface, the subsequent tasks of the service call are performed only after receiving the response data that matches the subscription request. Therefore, before receiving the response data, the second background service system can process other tasks, and after receiving the response data, it processes the subsequent tasks according to the response data, thereby avoiding idle computing resources and improving the parallel processing capability of the second background service system. That is, the second background service system monitors whether the service call process changes by sending a subscription request to the subscription interface. If a change occurs, the task of the service call process will continue to be processed. If no change occurs, the service call process will be shelved to process the tasks of other processes. Changes in the service call process refer to whether a subscription event occurs, such as whether the response data corresponding to the subscription request is received.

[0096] In one possible design, Figure 4 As shown, the device adopts a distributed system architecture, which includes multiple microservices, and the user login module, access interface and service call request processing module are deployed in multiple microservices.

[0097] Exemplarily, a configuration information storage module may also be deployed in the microservice.

[0098] Specifically, the user login module, access interface, configuration information storage module and service call request processing module can be deployed in one microservice, or one or two of these modules can be deployed in one microservice. When a microservice deploys one or two of these modules, it needs to work with other microservices to implement the service call function. In the above example, when faced with a large number of users sending service call requests or subscription requests to the device, the distributed system architecture shares the pressure of large-scale service call requests or subscription requests through multiple microservices, enabling the device to efficiently process large-scale service call requests or subscription requests without causing input / output (IO) congestion.

[0099] Exemplarily, the first background service system can also support the simultaneous processing of multiple proxy service call requests for the target service, and the microservice also supports the simultaneous processing of multiple service call requests for the target service. In this case, the device can assign multiple service call requests to one microservice for processing, or evenly distribute the multiple service call requests to the multiple microservices by polling multiple microservices. This embodiment achieves the effect of multiple second background service systems calling the target service at the same time.

[0100] In a feasible design, before calling the target service according to the service call request and the configuration information, the service call request processing module is also used to create a target proxy service submodule matching the target service according to the configuration information, that is, the target proxy service submodule belongs to the service call request processing module;

[0101] The service call request processing module is also used to update the proxy service mapping table according to the target proxy service submodule, and the proxy service mapping table is used to associate at least one proxy service submodule and the identification of at least one proxy service submodule.

[0102] Specifically, the target proxy service submodule is added to the proxy service mapping table, and the identification of the target proxy service submodule is determined according to the order of the target proxy service submodule in the proxy service mapping table. At this time, the association relationship between the target proxy service submodule and the corresponding identification is established in the proxy service mapping table.

[0103] Exemplarily, the service call request processing module is further used to create a target proxy service submodule matching the target service according to the configuration information, including:

[0104] The service call request processing module is also used to create a target proxy service submodule matching the target service according to the interface type.

[0105] In the above example, the service call request processing module can create a target proxy service submodule for calling the target service according to the interface type corresponding to the target service. When the user configures services of multiple interface types on the device, the service call request processing module can create various proxy service submodules according to the interface type of each service (including the target service). Through various proxy service submodules, it is possible to process the calls of multiple services of different interface types.

[0106] Exemplarily, the service call request processing module is used to call the target service according to the service call request and configuration information, including:

[0107] The service call request processing module is also used to determine the identifier of the target proxy service submodule from the proxy service mapping table according to the service call request;

[0108] The service call request processing module is also used to trigger the target proxy service submodule to perform the following processing according to the identifier of the target proxy service submodule and the proxy service mapping table:

[0109] The target proxy service submodule obtains configuration information from the configuration information storage module according to the service call request;

[0110] The target proxy service submodule calls the target service according to the service call request and configuration information.

[0111] It should be understood that the proxy service mapping table can call the target proxy service submodule to work according to the identifier of the target proxy service submodule.

[0112] In the above example, the service call request processing module can create corresponding target proxy service submodules for different target services by creating target proxy service submodules according to configuration information, thereby realizing calling corresponding services through different target proxy service submodules according to multiple service call requests at the same time, thereby improving the parallel processing capability of the device.

[0113] Exemplarily, the service call request uses a format specified by the Hypertext Transfer Protocol, which is a Hypertext Transfer Protocol (HTTP) request.

[0114] The following example illustrates how the service call request processing module determines the identifier of the target proxy service submodule from the proxy service mapping table according to the service call request:

[0115] The service call request processing module first intercepts the received service call request, and then determines the identifier of the target proxy service submodule from the proxy service mapping table according to the service call request.

[0116] The following describes the main logic of the proxy service submodule for processing service call requests and response data:

[0117] (1) According to the service call request, the identifier of the proxy service submodule matching the target service is filtered out from the proxy service mapping table.

[0118] (2) Select the corresponding target proxy service submodule through the identification of the proxy service submodule.

[0119] (3) The target proxy service submodule pre-processes the service call request and then forwards the service call request to the first background service system. The pre-processing includes but is not limited to: verifying whether the service call request conforms to the predetermined format; verifying the user's authority, such as some business scenarios need to verify the user's authority before processing the user request; for service call requests related to log output, first check whether the relevant log is recorded in the database or file.

[0120] (4) Finally, the service call request is post-processed to obtain response data, and the response data is sent to the second background service system.

[0121] Exemplarily, the proxy service submodule obtains the configuration information corresponding to the target service in the configuration information storage module by calling the annotation interface service (RequestLine) method, where RequestLine is an annotation interface service method of spring cloud feign.

[0122] Among them, post-processing means that after the subscription interface receives the subscription request sent by the user through the second background service system, the service call request processing module uses the data flow model to process the response data to implement the following method: the service call request processing module monitors whether the subscription event occurs; if the subscription event occurs, the service call request processing module sends the response data to the second background service system. The data flow model includes the Flux data flow model or the Mono data flow model. Among them, the Flux data flow model is used to store multiple response data, and the Mono data flow model is used to store a single response data.

[0123] In combination with the above-mentioned device for service invocation, the present application also provides a method for service invocation, such as Figure 2 As shown, the method includes:

[0124] S210: Obtain configuration information of a target service provided by the first background service system.

[0125] S220, receiving a service calling request in a predetermined format sent by a user through a second background service system, where the service calling request is used to call a target service.

[0126] S230, calling the target service according to the service call request and the configuration information to obtain response data of the target service.

[0127] S240: Send response data to the second background service system.

[0128] In a feasible design, before receiving the service call request in a predetermined format sent by the user through the second background service system, the method further includes:

[0129] Receiving a subscription request sent by a user through the second background service system, the subscription request includes a subscription event for a target service and an identifier of the second background service system, the subscription event includes receiving response data;

[0130] Send response data to the second background service system, including:

[0131] Monitor whether the subscription event occurs;

[0132] If a subscription event occurs, response data is sent to the second background service system according to the identifier of the second background service system.

[0133] In one feasible design, the method is implemented using a distributed system architecture, where the method is deployed in multiple microservices.

[0134] In a feasible design, after obtaining the configuration information of the target service provided by the first background service system input by the user, the method further includes:

[0135] The configuration information is stored.

[0136] In a feasible design, the configuration information is stored in a configuration information storage module, and the target service is called according to the service call request and the configuration information, including:

[0137] According to the service call request, determine the configuration information corresponding to the target service from the configuration information storage module;

[0138] Determine the proxy service call request based on the configuration information and the service call request;

[0139] According to the configuration information, a proxy service calling request is sent to the first background service system to call the target service of the first background service system.

[0140] In a feasible design, the configuration information includes one or more of the following information:

[0141] The address of the target interface corresponding to the target service, the type of the target interface, the name of the target interface, the identifier of the target service, the format of the parameters of the target interface, and the parsing rules corresponding to the target service.

[0142] In a feasible design, when the configuration information includes the parsing rule corresponding to the target service, sending response data to the second background service system includes:

[0143] Parse the response data according to the parsing rules;

[0144] According to the target format specified by the parsing rule, the response data is sent to the second background service system in the target format.

[0145] In a feasible design, before calling the target service according to the service call request and the configuration information, the method further includes:

[0146] Create a target proxy service submodule that matches the target service according to the configuration information;

[0147] According to the target proxy service submodule, a proxy service mapping table is updated, where the proxy service mapping table is used to associate at least one proxy service submodule and an identifier of at least one proxy service submodule.

[0148] In a feasible design, the target service is called according to the service call request and configuration information, including:

[0149] According to the service call request, determine the identifier of the target proxy service submodule from the proxy service mapping table;

[0150] According to the identification of the target proxy service submodule and the proxy service mapping table, the target proxy service submodule is triggered to perform the following processing:

[0151] The target proxy service submodule obtains configuration information according to the service call request;

[0152] The target proxy service submodule calls the target service according to the service call request and configuration information.

[0153] For other implementations and effects of the method, please refer to the description in the embodiment of the device for service invocation, which will not be repeated here.

[0154] The basic principles of the present application are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present application are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present application. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, not for limitation, and the above details do not limit the present application to being implemented by adopting the above specific details.

[0155] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.

[0156] The block diagrams of the devices, apparatuses, equipment, and systems involved in this application are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be appreciated by those skilled in the art, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, referring to "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The words "such as" used here refer to the phrase "such as but not limited to", and can be used interchangeably with them.

[0157] It should also be noted that in the apparatus, device and method of the present application, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present application.

[0158] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present application. Therefore, the present application is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0159] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present application to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

Claims

1. A device for service invocation, characterized in that: It includes user login module, access interface and service call request processing module; The user login module is used for user login and obtaining configuration information of the target service provided by the first background service system; The access interface is used to receive a service call request in a predetermined format sent by the user through the second background service system, the service call request is used to call the target service, and the predetermined format is used by the access interface to identify the service call request; The service call request processing module is used to call the target service according to the service call request and the configuration information to obtain the response data of the target service; The service call request processing module is also used to send the response data to the second background service system.

2. The device according to claim 1, characterized in that It also includes a subscription interface; The subscription interface is used to receive a subscription request sent by the user through the second background service system, the subscription request includes a subscription event for the target service and an identifier of the second background service system, and the subscription event includes receiving the response data; The service call request processing module is also used to send the response data to the second background service system, including: The service call request processing module is also used to monitor whether the subscription event occurs; If the subscription event occurs, the service call request processing module is further configured to send the response data to the second background service system according to an identifier of the second background service system.

3. The device according to claim 1 or 2, characterized in that: The device adopts a distributed system architecture, which includes multiple microservices, and the user login module, access interface, and service call request processing module are deployed in the multiple microservices.

4. The device according to claim 1 or 2, characterized in that: Also includes a configuration information storage module; The configuration information storage module is used to store the configuration information obtained by the user login module.

5. The device according to claim 4, characterized in that Before calling the target service according to the service call request and the configuration information, the service call request processing module is further used to create a target proxy service submodule matching the target service according to the configuration information; The service call request processing module is further used to update a proxy service mapping table according to the target proxy service submodule, wherein the proxy service mapping table is used to associate at least one proxy service submodule and an identifier of at least one proxy service submodule.

6. The device according to claim 5, characterized in that The service call request processing module is used to call the target service according to the service call request and the configuration information, including: The service call request processing module is further used to determine the identifier of the target proxy service submodule from the proxy service mapping table according to the service call request; The service call request processing module is further used to trigger the target proxy service submodule to perform the following processing according to the identifier of the target proxy service submodule and the proxy service mapping table: The target proxy service submodule obtains the configuration information from the configuration information storage module according to the service call request; The target proxy service submodule calls the target service according to the service call request and the configuration information.

7. The device according to claim 1 or 2, characterized in that: The configuration information includes one or more of the following information: The address of the target interface corresponding to the target service, the type of the target interface, the name of the target interface, the identifier of the target service, the format of the parameters of the target interface, and the parsing rule corresponding to the target service.

8. The device according to claim 4, characterized in that The service call request processing module is used to call the target service according to the service call request and the configuration information, including: The service call request processing module is used to determine the configuration information corresponding to the target service from the configuration information storage module according to the service call request; The service call request processing module is used to determine the proxy service call request according to the configuration information and the service call request; The service call request processing module is used to send the proxy service call request to the first background service system according to the configuration information, so as to call the target service of the first background service system.

9. The device according to claim 7, characterized in that In the case where the configuration information includes the parsing rule corresponding to the target service, the service call request processing module is further used to send the response data to the second background service system, including: The service call request processing module is also used to parse the response data according to the parsing rule; The service call request processing module is further used to send the response data to the second background service system in the target format according to the target format specified by the parsing rule.

10. A method for service invocation, characterized in that: The method comprises: Obtaining configuration information of a target service provided by the first background service system; receiving a service calling request in a predetermined format sent by the user through a second background service system, wherein the service calling request is used to call the target service; Calling the target service according to the service call request and the configuration information to obtain response data of the target service; The response data is sent to the second background service system.

Images