A method, device, equipment and storage medium for calling interfaces between multiple applications

Abstract

The present application discloses a method, device, equipment and storage medium for calling interfaces between multiple applications, and relates to the field of computer technology, including: generating a call request packet for calling a target service provider interface through a service consumer, and passing the call request packet to a relay application based on a pre-registered service consumer dynamic agent and a corresponding first processor; transmitting the received call request packet to the target application through the relay application; calling the target service provider interface based on the target interface identifier in the call request packet through the target application, and returning the return parameter after the call to the relay application; using the relay application to pass the return parameter after the call to the service consumer to complete the call to the target service provider interface. It can be seen that the present application can realize cross-application calls between interfaces without adjusting the network policies between application systems, and can save complex network policy configuration or major adjustments to the application architecture for business applications.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method, device, equipment and storage medium for calling interfaces between multiple applications. Background Art

[0002] Microservices are widely used in various application systems today. Currently, the most commonly used remote call frameworks include Dubbo (open source distributed service framework), Spring Cloud, HSF and other microservice frameworks. The basic architecture consists of service providers, service consumers and registration centers. The three must be in the same network that can be connected, so that service consumers can call the interfaces registered and provided by service providers. Today's application architectures often have complex call relationships. Especially under complex network conditions, the communication between applications is still limited by the isolation of network conditions, and it is impossible to make effective cross-network or cross-application calls, and it is even more impossible to accurately select the best call path. One of the existing implementation solutions is proxy, which configures proxy ports between the same applications, but for example, the HSF remote framework interface in Alibaba Cloud cannot be accessed through the proxy. Therefore, the solution has certain limitations. The second is to configure Mesh network for traffic forwarding, etc. The disadvantage is that additional network ports must be added to communicate, and additional complex network policy deployment is required, which undoubtedly increases the complexity and risk of the application network. Moreover, in large systems, when most applications need to configure network relationships, developers or deployers must be familiar with the network relationships between applications before they can correctly configure the network relationships in each application, which will increase the difficulty of deployment in the early stages of application deployment. Therefore, if a visual network relationship diagram can be introduced, it will greatly reduce the difficulty of configuration. Summary of the invention

[0003] In view of this, the purpose of the present invention is to provide a method, device, equipment and storage medium for calling interfaces between multiple applications, which can solve the problem of cross-application service calling, realize cross-application calling between interfaces without adjusting the network policy between application systems, and save complex network policy configuration or major adjustment of application architecture for business applications. The specific scheme is as follows:

[0004] In a first aspect, the present application provides a method for calling an interface between multiple applications, comprising:

[0005] Generate a call request packet for calling a target service provider interface through a service consumer, and transmit the call request packet to a relay application based on a pre-registered service consumer dynamic proxy and a corresponding first processor;

[0006] transmitting the received call request packet to the target application through the relay application;

[0007] Calling the target service provider interface through the target application based on the target interface identifier in the call request packet, and returning the return parameters after the call to the relay application;

[0008] The relay application is used to pass the post-call return parameter to the service consumer to complete the call to the target service provider interface.

[0009] Optionally, before the service consumer generates a call request packet for calling the target service provider interface, the process further includes:

[0010] The service providers respectively create interface identifiers of the service providers based on the application names, group names, version numbers and interface names of their respective applications, thereby obtaining corresponding interface identifier libraries;

[0011] Correspondingly, the generating of a call request packet for calling the target service provider interface by the service consumer includes:

[0012] Generate a target interface identifier of the target service provider interface by the service consumer based on the application name, group name, method name, and version number of the target application;

[0013] The target interface identifier is matched with the interface identifier library by the service consumer, and when there is an interface identifier matching the target interface identifier in the interface identifier library, a call request packet for calling the target service provider interface is generated based on the target interface identifier.

[0014] Optionally, the pre-registered service consumer dynamic proxy and the corresponding first processor transmit the call request packet to the relay application, including:

[0015] Based on the pre-registered service consumer dynamic proxy, the routing processor is used to serialize the request parameters in the call request packet to obtain a corresponding serialized call request packet;

[0016] Querying a dynamic call path between the service consumer and the service provider based on the target interface identifier;

[0017] The corresponding target communication protocol is called according to the protocol mode configured between applications and based on the dynamic calling path, and the serialized calling request packet is transferred to the relay application based on the target communication protocol.

[0018] Optionally, calling the target service provider interface based on the target interface identifier in the call request packet through the target application, and returning the return parameter after the call to the relay application, includes:

[0019] Deserialize the request parameters in the serialized call request packet by using the routing processor through the target application to obtain a corresponding deserialized call request packet;

[0020] Determining the target service provider interface according to the deserialized call request packet by the target application, calling the target service provider interface based on the method corresponding to the method name in the target interface identifier to obtain corresponding return parameters after the call;

[0021] The return parameters after the call are serialized by the routing processor, and the serialized return parameters are returned to the relay application.

[0022] Optionally, the using the relay application to pass the post-call return parameter to the service consumer includes:

[0023] Deserialize the serialized return parameter using the routing processor to obtain a first target return parameter;

[0024] The first target return parameter is directly delivered to the service consumer using the relay application.

[0025] Optionally, the using the relay application to pass the post-call return parameter to the service consumer includes:

[0026] Deserialize the serialized return parameter using the routing processor to obtain a first target return parameter;

[0027] The first target return parameter is processed accordingly using the relay application and a second processor associated with the service consumer dynamic agent to obtain a second target return parameter, and the second target return parameter is passed to the service consumer.

[0028] Optionally, the method further includes:

[0029] If an exception occurs during the calling process, the execution of related operations using the first processor and the post-processor included in the second processor is terminated, and the execution of related operations using the final processor included in the two processors continues.

[0030] In a second aspect, the present application provides a device for calling an interface between multiple applications, including:

[0031] A request packet delivery module, used to generate a call request packet for calling a target service provider interface through a service consumer, and deliver the call request packet to a relay application based on a pre-registered service consumer dynamic proxy and a corresponding first processor;

[0032] A request packet transmission module, used for transmitting the received call request packet to the target application through the relay application;

[0033] A parameter return module, used to call the target service provider interface through the target application based on the target interface identifier in the call request packet, and return the return parameters after the call to the relay application;

[0034] The parameter transfer module is used to transfer the return parameters after the call to the service consumer by using the relay application to complete the call to the target service provider interface.

[0035] In a third aspect, the present application provides an electronic device, including:

[0036] Memory, used to store computer programs;

[0037] The processor is used to execute the computer program to implement the aforementioned method for calling the interface between multiple applications.

[0038] In a fourth aspect, the present application provides a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the aforementioned method for calling an interface between multiple applications.

[0039] As can be seen from the above, when the present application makes an interface call between multiple applications, a call request packet for calling the target service provider interface is first generated by the service consumer, and the call request packet is passed to the relay application based on the pre-registered service consumer dynamic proxy and the corresponding first processor; the received call request packet is transmitted to the target application by the relay application; the target application calls the target service provider interface based on the target interface identifier in the call request packet, and returns the return parameter after the call to the relay application; the return parameter after the call is passed to the service consumer by the relay application to complete the call to the target service provider interface. It can be seen that the present application forms an application call network diagram, provides dynamic proxy generation for the service consumer for the interface, completes the call of the service provider interface, and realizes cross-application calls between interfaces without adjusting the network policy between application systems, which can save complex network policy configuration or major adjustments to the application architecture for business applications. For complex networks, the high reliability is especially exerted when complex application deployment architectures are used. The call link between an application and other applications will no longer be fixed and single, but dynamic and multi-path. It solves the problem of dynamic interface calls between multiple applications. It does not rely on a specified network request protocol. Users can adapt according to the communication protocol requirements of their own applications. The business relationship between applications can be effectively expanded before, during, and after the interface is executed to meet the needs of different businesses. The adjacent application connectivity data is initialized and configured, and can also be configured in the database configuration table. With the front-end display solution, the complete routing network topology map of the application can be fully displayed, so that users can observe the connectivity time, call path, and shortest path between applications based on the visualization of the page. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0041] Figure 1 A flowchart of a method for calling an interface between multiple applications provided by this application;

[0042] Figure 2 A schematic diagram of the system structure for a multi-application service cross-application call scenario provided for this application

[0043] Figure 3 A specific multi-application interface calling method flow chart provided for this application;

[0044] Figure 4This is a schematic diagram of the structure of a device for calling an interface between multiple applications disclosed in this application;

[0045] Figure 5 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0046] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0047] One of the existing implementation solutions is proxy, which configures proxy ports between the same applications, but for example, the HSF remote framework interface in Alibaba Cloud cannot be accessed through the proxy. Therefore, the solution has certain limitations. Secondly, by configuring the Mesh network for traffic forwarding, the disadvantage is that additional network ports must be added to communicate, and additional complex network policy deployment is required, which undoubtedly increases the complexity and risk of the application network. To solve the above problems, this application provides a method for calling interfaces between multiple applications, which can realize cross-application calls between interfaces without adjusting the network policies between application systems, and can save complex network policy configuration or major adjustments to the application architecture for business applications.

[0048] See also Figure 1 As shown, the embodiment of the present invention discloses a method for calling an interface between multiple applications, including:

[0049] Step S11: Generate a call request packet for calling a target service provider interface through a service consumer, and transmit the call request packet to a relay application based on a pre-registered service consumer dynamic proxy and a corresponding first processor.

[0050] In this embodiment, before the service consumer generates a call request packet for calling the target service provider interface, it also includes: each service provider creates an interface identifier of each service provider based on the application name, group name, version number and interface name of each application, and obtains a corresponding interface identifier library; accordingly, the call request packet generated by the service consumer for calling the target service provider interface includes: the service consumer generates a target interface identifier of the target service provider interface based on the application name, group name, method name and version number of the target application; the service consumer matches the target interface identifier with the interface identifier library, and when there is an interface identifier matching the target interface identifier in the interface identifier library, a call request packet for calling the target service provider interface is generated based on the target interface identifier. That is, the present application first performs dynamic proxy registration of the service provider interface, and hands the interface over to the remote cascade container for management, and forms a unique interface consisting of the application name, group name, version number and interface name. Register the service consumer interface. The service consumer determines the uniqueness of the consumer calling interface based on the target application name, group name, method name, and version number. After the cascade container registration management, the cascade container generates a dynamic proxy class that will assemble the consumer pre-processor, routing processor, post-processor, and final processor. The service consumer can perform additional special execution enhancements and enrich the extensions according to the processor execution stage. The service provider and service consumer of the application's relay proxy interface and implementation class perform the above interface dynamic proxy registration. The purpose is to provide it to the relay agent for cross-application calls. The application itself provides a calling path. When the consumer initiates a call to a target other than this application, it will be forwarded through the relay interface registered by this application. The relay interface only provides the proxy forwarding function and will not perform additional operations on the calling interface. The call request package generated by the service consumer for calling the target service provider interface includes the target interface identifier and request parameters.

[0051] In this embodiment, the call request packet is passed to the relay application based on the pre-registered service consumer dynamic proxy and the corresponding first processor. In this process, based on business needs, the pre-processor is first used to perform operations according to the proxy class at the time of registration. Consumers can perform specific operations such as logging and context transfer in the pre-processor. The routing processor is used to perform corresponding operations, and the routing processor is the core processing logic of the calling service. It can be understood that the use of the pre-processor is based on business needs. If operations such as logging and context transfer are not required for a certain business, the pre-processor is no longer used, but the routing processor is very important and is required in any business.

[0052] Step S12: transmitting the received call request packet to the target application through the relay application.

[0053] In this embodiment, the received call request packet is transmitted to the target application through the relay application. When the relay application receives the request, it will perform relay transmission and forward the received request to the next target application until the target application receives the request. The impact of the relay application on its application is not reduced. During this period, the relay application is only responsible for executing the call transmission logic, recording the call log, and responding to the call results of the relay class. The relay application does not need to couple any interfaces and implementation codes of the service provider and service consumer, and only acts as a pure relay application. That is, when relay transmission is performed, if the next transmission application of the current relay application is the target application, the received call request packet will be directly transmitted to the target application. That is, Figure 2 As shown, A relays B to call C interface across applications. If there are other applications between the current relay application and the target application, the received call request packet is forwarded to the next relay application until the target application receives the request.

[0054] Step S13: calling the target service provider interface through the target application based on the target interface identifier in the call request packet, and returning the post-call return parameters to the relay application.

[0055] In this embodiment, when the target application receives the call request packet, it searches for the corresponding registered service interface in the cascade management container based on the target interface identifier in the call request packet, calls the target service provider interface according to the method corresponding to the method name in the target interface identifier, and returns the return parameters after the call to the relay application.

[0056] Step S14: using the relay application to pass the post-call return parameter to the service consumer to complete the call to the target service provider interface.

[0057] In this embodiment, after the call is completed, the corresponding parameters are serialized and returned to the upper layer application interface. The upper layer application interface can be a service consumer interface or a relay application interface. When the relay application receives the return parameter, it continues to pass it to the upper layer application until it returns to the service consumer. In the transmission process, the routing processor can be used to deserialize the serialized return parameter to obtain the first target return parameter; the relay application can be used to directly pass the first target return parameter to the service consumer. It can also be used to deserialize the serialized return parameter to obtain the first target return parameter; the relay application and the second processor related to the service consumer dynamic agent can be used to perform corresponding processing on the first target return parameter to obtain the second target return parameter, and the second target return parameter can be passed to the service consumer. For example, the routing processor obtains a specific result after deserialization, and then the routing processor completes the operation. Execute the post-processor logic, and the user can perform specific operations related to the business in the post-processor. The user can perform some necessary execution operations in the final processor, and respond to the service consumer with the result after the final processor completes the process. It should be noted that if an exception occurs during the call, the first processor and the post-processor included in the second processor will be terminated to perform related operations, and the final processor included in the second processor will continue to perform related operations. That is, in all the above steps, it is possible that the execution of the processor steps will be terminated due to an exception in the call, and only the final processor will perform the final processing when any exception occurs.

[0058] As can be seen from the above, when the present application makes an interface call between multiple applications, a call request packet for calling the target service provider interface is first generated by the service consumer, and the call request packet is passed to the relay application based on the pre-registered service consumer dynamic proxy and the corresponding first processor; the received call request packet is transmitted to the target application by the relay application; the target application calls the target service provider interface based on the target interface identifier in the call request packet, and returns the return parameter after the call to the relay application; the return parameter after the call is passed to the service consumer by the relay application to complete the call to the target service provider interface. It can be seen that the present application forms an application call network diagram, provides dynamic proxy generation for the service consumer for the interface, completes the call of the service provider interface, and realizes cross-application calls between interfaces without adjusting the network policy between application systems, which can save complex network policy configuration or major adjustments to the application architecture for business applications. For complex networks, the high reliability is especially exerted when complex application deployment architectures are used. The call link between an application and other applications will no longer be fixed and single, but dynamic and multi-path. It solves the problem of dynamic interface calls between multiple applications. It does not rely on a specified network request protocol. Users can adapt according to the communication protocol requirements of their own applications. The business relationship between applications can be effectively expanded before, during, and after the interface is executed to meet the needs of different businesses. The adjacent application connectivity data is initialized and configured, and can also be configured in the database configuration table. With the front-end display solution, the complete routing network topology map of the application can be fully displayed, so that users can observe the connectivity time, call path, and shortest path between applications based on the visualization of the page.

[0059] See also Figure 3 As shown, the embodiment of the present invention discloses a specific method for calling an interface between multiple applications, including:

[0060] Step S21: Based on the pre-registered service consumer dynamic proxy, the routing processor is used to serialize the request parameters in the call request packet to obtain a corresponding serialized call request packet.

[0061] In this embodiment, after the service consumer generates a call request package for calling the target service provider interface, the request parameters in the call request package are serialized using a routing processor based on a pre-registered service consumer dynamic proxy. The purpose is to ensure that there is no reliance on specific entity classes in the relay agent transmission, to achieve complete decoupling, and finally obtain the corresponding serialized call request package.

[0062] Step S22: query the dynamic call path between the service consumer and the service provider based on the target interface identifier.

[0063] In this embodiment, according to the target application identifier, the dynamic call path from the service consumer to the service provider is queried. The call path between applications is calculated by an effective shortest path algorithm. When there are multiple paths in the actual application call path, the optimal shortest path is prioritized for relay call, which can effectively avoid the efficiency problems caused by random calls. It can also avoid the existence of a certain path in the fixed call path that is blocked and affects the interface call. The relay application routing can always adjust the optimal path according to the current application network situation in time for interface call. For complex networks, complex application deployment architectures are particularly effective in terms of high reliability. The call link between an application and other applications will no longer be fixed and single, but dynamic and multi-path. In the routing network, there are multiple connected paths. Even if a path fails, dynamic routing can instantly detect and calculate the latest routing line to ensure the high reliability of calls between applications. It only needs to maintain the relationship between the application network once to meet the dynamic routing requirements between all applications. It should be pointed out that multi-path high availability is achieved between applications, and the shortest path algorithm is the Dijkstra algorithm.

[0064] Step S23: calling the corresponding target communication protocol according to the protocol mode configured between applications and based on the dynamic calling path, and delivering the serialized calling request packet to the relay application based on the target communication protocol.

[0065] In this embodiment, the protocol call is performed according to the protocol mode configured between applications, and the serialized call request packet is passed to the relay application based on the target communication protocol, wherein the implemented protocol can be implemented by different protocols, such as Http, dubbo, Netty, etc. The call relationship between applications can be adapted and expanded by specific services. The present invention does not rely on a specific communication framework or protocol, and does not affect the original application communication protocol. In this way, the problem of dynamic interface calls between multiple applications is solved, and it does not rely on the specified network request protocol. Users can adapt according to the communication protocol requirements of their own applications. Whether it is Netty, dubbo, http and other mainstream protocols, they can be extended and adapted. The business relationship between applications can be effectively extended before, during and after the interface execution to meet the needs of different businesses.

[0066] Step S24: transmitting the received call request packet to the target application through the relay application.

[0067] Step S25: Deserialize the request parameters in the serialized call request packet using the routing processor through the target application to obtain a corresponding deserialized call request packet.

[0068] In this embodiment, when the target application receives a call request from a service consumer, it first uses the routing processor to deserialize the request parameters in the serialized call request packet to obtain a corresponding deserialized call request packet.

[0069] Step S26: Determine the target service provider interface through the target application according to the deserialized call request packet, and call the target service provider interface based on the method corresponding to the method name in the target interface identifier to obtain corresponding return parameters after the call.

[0070] In this embodiment, after obtaining the corresponding deserialized call request packet, the target application determines the target service provider interface according to the deserialized call request packet, that is, searches for the corresponding registered service interface from the cascade management container. Then, the target service provider interface is called based on the method corresponding to the method name in the target interface identifier to obtain the corresponding return parameters after the call.

[0071] Step S27: Serialize the return parameters after the call through the routing processor, and return the serialized return parameters to the relay application.

[0072] In this embodiment, after the call is completed, the corresponding parameters are serialized by the routing processor and then returned to the upper layer application interface, that is, the serialized return parameters are returned to the relay application.

[0073] Step S28: Use the relay application to pass the post-call return parameter to the service consumer to complete the call to the target service provider interface.

[0074] For the specific process of the above-mentioned step S24 and step S28, reference may be made to the corresponding contents disclosed in the above-mentioned embodiment, and will not be repeated here.

[0075] As can be seen from the above, when the present application makes an interface call, first, a unique identifier will be set for each application at the application level, and the application will configure the routing configuration that has a direct connection relationship with it during initialization. Then, the network routing information stored in this application will be exchanged with its adjacent applications. After data exchange between several applications, each application will have a complete routing relationship between all applications, thereby generating a complete application topology map. Each application will hold application topology map data with the same data structure, which is the basis for cross-application interface calls. There is no need to add additional policy ports, and functional expansion is performed on the basis of the original application. Compared with traditional remote service calls, dynamic calls to interfaces between multiple applications can realize scenarios where the same interface of different projects is called but the interface can realize different functions. In traditional remote service calls, the same interface, the same group, and the same version cannot exist at the same time. In the present invention, in addition to remote cross-application calls, independent registration and use of the same interface of multiple applications can also be realized. This application proposes a service remote call method based on application cascade, which solves the technical problem in the prior art that direct interface calls cannot be made across applications and networks. In the application cascade scenario, the interface parameters can be relayed between application networks based on the upper and lower network paths, and interface calls can be implemented in the target application. A network call link between applications is dynamically calculated to achieve multi-path high availability for interface calls. The network relationship is dynamically displayed, and the application link diagram between adjacent and other applications can be viewed through the interface data.

[0076] See also Figure 4 As shown, the embodiment of the present invention discloses a device for calling an interface between multiple applications, including:

[0077] A request packet delivery module 11, configured to generate a call request packet for calling a target service provider interface through a service consumer, and deliver the call request packet to a relay application based on a pre-registered service consumer dynamic proxy and a corresponding first processor;

[0078] A request packet transmission module 12, used for transmitting the received call request packet to the target application through the relay application;

[0079] A parameter return module 13, configured to call the target service provider interface through the target application based on the target interface identifier in the call request packet, and return the return parameters after the call to the relay application;

[0080] The parameter transfer module 14 is used to transfer the post-call return parameters to the service consumer by using the relay application to complete the call to the target service provider interface.

[0081] As can be seen from the above, when the present application makes an interface call between multiple applications, a call request packet for calling the target service provider interface is first generated by the service consumer, and the call request packet is passed to the relay application based on the pre-registered service consumer dynamic proxy and the corresponding first processor; the received call request packet is transmitted to the target application by the relay application; the target service provider interface is called by the target application based on the target interface identifier in the call request packet, and the return parameter after the call is returned to the relay application; the return parameter after the call is passed to the service consumer by the relay application to complete the call to the target service provider interface. It can be seen that the present application forms an application call network diagram, provides dynamic proxy generation for service consumers for interfaces, completes the call of service provider interfaces, and realizes cross-application calls between interfaces without adjusting the network policies between application systems, which can save complex network policy configuration or major adjustments to the application architecture for business applications. For complex networks, the high reliability is especially exerted when complex application deployment architectures are used. The call link between applications and other applications will no longer be fixed and single, but dynamic and multi-path. It solves the problem of dynamic interface calls between multiple applications. It does not rely on a specified network request protocol. Users can adapt according to the communication protocol requirements of their own applications. The business relationship between applications can be effectively expanded before, during, and after the interface is executed to meet the needs of different businesses. The adjacent application connectivity data is initialized and configured, and can also be configured in the database configuration table. With the front-end display solution, the complete routing network topology map of the application can be fully displayed, so that users can observe the connectivity time, call path, and shortest path between applications based on the visualization of the page.

[0082] In some specific embodiments, the request packet transmission module 11 further includes:

[0083] An interface identification library creation unit, used to create interface identifications of each service provider based on the application name, group name, version number and interface name of each application through each service provider, so as to obtain a corresponding interface identification library;

[0084] Correspondingly, the generating of a call request packet for calling the target service provider interface by the service consumer includes:

[0085] A target interface identifier generating unit, configured to generate a target interface identifier of the target service provider interface based on the application name, group name, method name and version number of the target application by the service consumer;

[0086] A request packet generating unit is used to match the target interface identifier with the interface identifier library through the service consumer, and when there is an interface identifier matching the target interface identifier in the interface identifier library, generate a call request packet for calling the target service provider interface based on the target interface identifier.

[0087] In some specific embodiments, the request packet transmission module 11 may include:

[0088] A serialization processing unit, configured to serialize the request parameters in the call request packet using a routing processor based on a pre-registered service consumer dynamic proxy to obtain a corresponding serialized call request packet;

[0089] A call path query unit, used to query the dynamic call path between the service consumer and the service provider based on the target interface identifier;

[0090] The request packet delivery unit is used to call the corresponding target communication protocol according to the protocol mode configured between applications and based on the dynamic call path, and deliver the serialized call request packet to the relay application based on the target communication protocol.

[0091] In some specific embodiments, the parameter returning module 13 may include:

[0092] A deserialization processing unit, configured to perform deserialization processing on the request parameters in the serialized call request packet by using the routing processor through the target application to obtain a corresponding deserialized call request packet;

[0093] An interface calling unit, used to determine the target service provider interface according to the deserialized calling request packet through the target application, and call the target service provider interface based on the method corresponding to the method name in the target interface identifier to obtain corresponding return parameters after the call;

[0094] The parameter returning unit is used to serialize the return parameters after the call through the routing processor, and return the serialized return parameters to the relay application.

[0095] In some specific embodiments, the parameter transfer module 14 may include:

[0096] a first target return parameter acquisition unit, configured to use the routing processor to perform a deserialization operation on the serialized return parameter to obtain a first target return parameter;

[0097] A first return parameter delivery unit, configured to deliver the first target return parameter directly to the service consumer by using the relay application;

[0098] The second return parameter delivery unit is used to use the relay application and the second processor related to the service consumer dynamic agent to perform corresponding processing on the first target return parameter to obtain a second target return parameter, and deliver the second target return parameter to the service consumer.

[0099] In some specific embodiments, the device further comprises:

[0100] The processor utilizing unit is used to terminate the use of the first processor and the post-processor included in the second processor to perform related operations if an exception occurs during the calling process, and continue to use the final processor included in the two processors to perform related operations.

[0101] Furthermore, the present application also discloses an electronic device. Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram cannot be regarded as any limitation on the scope of use of the present application.

[0102] Figure 5 A schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the multi-application interface calling method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0103] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0104] In addition, the memory 22 as a carrier for resource storage may be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon may include an operating system 221, a computer program 222, etc., and the storage method may be temporary storage or permanent storage.

[0105] The operating system 221 is used to manage and control the hardware devices and computer programs 222 on the electronic device 20, and can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to complete the multi-application interface calling method executed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks.

[0106] Furthermore, the present application also discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the aforementioned disclosed method for calling an interface between multiple applications. The specific steps of the method can be referred to the corresponding contents disclosed in the aforementioned embodiment, and will not be repeated here.

[0107] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0108] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0109] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0110] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0111] The technical solution provided by the present application is introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for general technicians in this field, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for calling an interface between multiple applications, characterized in that: include: Generate a call request packet for calling a target service provider interface through a service consumer, and transmit the call request packet to a relay application based on a pre-registered service consumer dynamic proxy and a corresponding first processor; transmitting the received call request packet to the target application through the relay application; Calling the target service provider interface through the target application based on the target interface identifier in the call request packet, and returning the return parameters after the call to the relay application; Using the relay application to pass the return parameter after the call to the service consumer to complete the call to the target service provider interface; Before the service consumer generates a call request packet for calling the target service provider interface, the process further includes: The service providers respectively create interface identifiers of the service providers based on the application names, group names, version numbers and interface names of their respective applications, thereby obtaining corresponding interface identifier libraries; Correspondingly, the generating of a call request packet for calling the target service provider interface by the service consumer includes: Generate a target interface identifier of the target service provider interface by the service consumer based on the application name, group name, method name, and version number of the target application; The target interface identifier is matched with the interface identifier library by the service consumer, and when there is an interface identifier matching the target interface identifier in the interface identifier library, a call request packet for calling the target service provider interface is generated based on the target interface identifier; The method of transmitting the call request packet to the relay application based on the pre-registered service consumer dynamic proxy and the corresponding first processor includes: Based on the pre-registered service consumer dynamic proxy, the routing processor is used to serialize the request parameters in the call request packet to obtain a corresponding serialized call request packet; Based on the target interface identifier, query the dynamic call path between the service consumer and the service provider; wherein the dynamic call path is calculated by a shortest path algorithm; the shortest path algorithm is a Dijkstra algorithm; Calling a corresponding target communication protocol according to the protocol mode configured between applications and based on the dynamic call path, and delivering the serialized call request packet to the relay application based on the target communication protocol; The calling the target service provider interface based on the target interface identifier in the call request packet through the target application, and returning the return parameter after the call to the relay application, includes: Deserialize the request parameters in the serialized call request packet by using the routing processor through the target application to obtain a corresponding deserialized call request packet; Determining the target service provider interface according to the deserialized call request packet by the target application, calling the target service provider interface based on the method corresponding to the method name in the target interface identifier to obtain corresponding return parameters after the call; Serializing the return parameters after the call through the routing processor, and returning the serialized return parameters to the relay application; The using the relay application to transmit the post-call return parameter to the service consumer includes: Deserialize the serialized return parameter using the routing processor to obtain a first target return parameter; Delivering the first target return parameter directly to the service consumer using the relay application; The using the relay application to transmit the post-call return parameter to the service consumer includes: Deserialize the serialized return parameter using the routing processor to obtain a first target return parameter; The first target return parameter is processed accordingly using the relay application and a second processor associated with the service consumer dynamic agent to obtain a second target return parameter, and the second target return parameter is passed to the service consumer.

2. The method for calling a multi-application interface according to claim 1, characterized in that: Also includes: If an exception occurs during the calling process, the execution of related operations using the first processor and the post-processor included in the second processor is terminated, and the execution of related operations using the final processor included in the two processors continues.

3. A device for calling an interface between multiple applications, characterized in that: include: A request packet delivery module, used to generate a call request packet for calling a target service provider interface through a service consumer, and deliver the call request packet to a relay application based on a pre-registered service consumer dynamic proxy and a corresponding first processor; A request packet transmission module, used for transmitting the received call request packet to the target application through the relay application; A parameter return module, used to call the target service provider interface through the target application based on the target interface identifier in the call request packet, and return the return parameters after the call to the relay application; A parameter transfer module, used to transfer the return parameters after the call to the service consumer by using the relay application, so as to complete the call to the target service provider interface; The request packet transmission module further includes: An interface identification library creation unit, used to create interface identifications of each service provider based on the application name, group name, version number and interface name of each application through each service provider, so as to obtain a corresponding interface identification library; Correspondingly, the generating of a call request packet for calling the target service provider interface by the service consumer includes: A target interface identifier generating unit, configured to generate a target interface identifier of the target service provider interface based on the application name, group name, method name and version number of the target application by the service consumer; a request packet generating unit, configured to match the target interface identifier with the interface identifier library through the service consumer, and generate a call request packet for calling the target service provider interface based on the target interface identifier when an interface identifier matching the target interface identifier exists in the interface identifier library; Wherein, the request packet transmission module includes: A serialization processing unit, configured to serialize the request parameters in the call request packet using a routing processor based on a pre-registered service consumer dynamic proxy to obtain a corresponding serialized call request packet; A call path query unit, used to query the dynamic call path between the service consumer and the service provider based on the target interface identifier; wherein the dynamic call path is calculated by a shortest path algorithm; the shortest path algorithm is a Dijkstra algorithm; A request packet delivery unit, configured to call a corresponding target communication protocol according to a protocol mode configured between applications and based on the dynamic call path, and deliver the serialized call request packet to a relay application based on the target communication protocol; The parameter return module includes: A deserialization processing unit, configured to perform deserialization processing on the request parameters in the serialized call request packet by using the routing processor through the target application to obtain a corresponding deserialized call request packet; An interface calling unit, used to determine the target service provider interface according to the deserialized calling request packet through the target application, and call the target service provider interface based on the method corresponding to the method name in the target interface identifier to obtain corresponding return parameters after the call; A parameter returning unit, configured to serialize the return parameters after the call through the routing processor, and return the serialized return parameters to the relay application; The parameter transfer module comprises: a first target return parameter acquisition unit, configured to use the routing processor to perform a deserialization operation on the serialized return parameter to obtain a first target return parameter; A first return parameter delivery unit, configured to deliver the first target return parameter directly to the service consumer by using the relay application; The second return parameter delivery unit is used to use the relay application and the second processor related to the service consumer dynamic agent to perform corresponding processing on the first target return parameter to obtain a second target return parameter, and deliver the second target return parameter to the service consumer.

4. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor is used to execute the computer program to implement the multi-application interface calling method as claimed in claim 1 or 2.

5. A computer-readable storage medium, characterized in that: Used to store a computer program, which, when executed by a processor, implements the multi-application interface calling method as claimed in claim 1 or 2.

Images