CN117201571A - Cross-service calling method and device, electronic equipment and storage medium - Google Patents
Cross-service calling method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN117201571A CN117201571A CN202310671966.7A CN202310671966A CN117201571A CN 117201571 A CN117201571 A CN 117201571A CN 202310671966 A CN202310671966 A CN 202310671966A CN 117201571 A CN117201571 A CN 117201571A
- Authority
- CN
- China
- Prior art keywords
- service
- network transmission
- transmission protocol
- protocol
- target service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 53
- 230000005540 biological transmission Effects 0.000 claims abstract description 159
- 230000008569 process Effects 0.000 claims description 11
- 230000004044 response Effects 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 7
- 238000004891 communication Methods 0.000 description 13
- 238000012546 transfer Methods 0.000 description 13
- 238000010586 diagram Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 10
- 230000003993 interaction Effects 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000149 penetrating effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000004148 unit process Methods 0.000 description 1
Landscapes
- Computer And Data Communications (AREA)
Abstract
The application relates to the technical field of computers, in particular to a cross-service calling method, a device, electronic equipment and a storage medium, wherein the method comprises the following steps: acquiring a first call request of a current service, wherein the current service integrates a first ClientJar, the first call request comprises a target service, when a first network transmission protocol of the current service is inconsistent with a second network transmission protocol of the target service, intercepting the first network transmission protocol to a preset protocol processor by using the first ClientJar, converting the first network transmission protocol into the second network transmission protocol by the preset protocol processor, and then sending the first call request to the target service. Therefore, the problems that different micro services can not mutually interact and communicate due to different network protocols caused by service demands in a distributed system are solved, and the calling compatibility and expandability among the services in the platform are greatly improved.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a cross-service calling method, a device, an electronic device, and a storage medium.
Background
Under the circumstance that the current business is continuously expanded and services are continuously subdivided, the traditional single architecture cannot meet the increasingly changing architecture requirements, and the services are highly single and need to perform functional interaction in a certain way and based on a certain network transmission protocol.
Thus, in the current implementation of the technology, various remote service calling modes such as RPC (Remote Procedure Call ), HTTP (Hyper Text Transfer Protocol, hypertext transfer protocol), RMI (Remote Method Invocation, remote method call) and the like appear, and each calling mode has different characteristics. The currently mainstream remote call mode belongs to the RPC and HTTP protocol-based RestFul (Representational State Transfer ) style call mode. The inter-communication call is realized among a plurality of micro-services of one platform, only one call mode, RPC or RestFul style is often selected, and because the premise of the inter-service call is based on the same network transmission protocol, after the inter-service call mode is selected by one platform, the inter-service call is difficult to be carried out by using the call modes based on other protocols.
In the related art, as shown in fig. 1, fig. 1 is a schematic diagram of service-to-service call under a distributed system in the related art, and in a distributed architecture used by a current company, service-to-service call is performed between each micro service through a RestFul.
However, as platform vehicle data proliferates, the request amount greatly rises, if the call between services is still called by the RestFul, the transmission speed is slower than the RPC, the throughput is low, but the network protocol of all micro services is modified in the stabilized distributed platform so as to change the call mode, which is obviously not feasible; and not all micro services can call each other more frequently due to the surge of service demands, so that the calling mode of all services is not changed.
Disclosure of Invention
The application provides a cross-service calling method, a device, electronic equipment and a storage medium, which are used for solving the problem that different micro services can not mutually interact and communicate due to different network protocols caused by service demands in a distributed system, and the like, and greatly improving the calling compatibility and expandability among the services in a platform.
An embodiment of a first aspect of the present application provides a cross-service calling method, including the following steps:
acquiring a first call request of a current service, wherein the current service integrates a first ClientJar, and the first call request comprises a target service;
judging whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service; and
if the first network transmission protocol of the current service is inconsistent with the second network transmission protocol of the target service, intercepting the first network transmission protocol to a preset protocol processor by using the first ClientJar, converting the first network transmission protocol into the second network transmission protocol by the preset protocol processor, and then sending the first calling request to the target service.
Optionally, in some embodiments, after sending the first call request to the target service, further comprising: and receiving response data sent by the target service based on the first call request, wherein the receiving process is based on the second network transmission protocol.
Optionally, in some embodiments, the cross-service calling method further includes:
acquiring a second call request of the target service, wherein the second call request comprises the current service, and the target service integrates a second ClientJar;
judging whether the third network transmission protocol of the target service is consistent with the fourth network transmission protocol of the target service;
if the third network transmission protocol of the target service is inconsistent with the fourth network transmission protocol of the target service, intercepting the third network transmission protocol to the preset protocol processor by using the second ClientJar, converting the third network transmission protocol into the fourth network transmission protocol by the preset protocol processor, and then sending the second calling request to the current service.
Optionally, in some embodiments, after determining whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service, the method further includes: and if the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service, sending the first calling request to the target service.
An embodiment of a second aspect of the present application provides a cross-service invocation apparatus, including:
the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring a first call request of a current service, the current service integrates a first ClientJar, and the first call request comprises a target service;
a first judging module, configured to judge whether a first network transmission protocol of the current service is consistent with a second network transmission protocol of the target service; and
and the first calling module is used for intercepting the first network transmission protocol to a preset protocol processor by using the first ClientJar when the first network transmission protocol of the current service is inconsistent with the second network transmission protocol of the target service, converting the first network transmission protocol into the second network transmission protocol by the preset protocol processor, and then sending the first calling request to the target service.
Optionally, in some embodiments, after sending the first call request to the target service, the first call module further includes: and the receiving unit is used for receiving response data sent by the target service based on the first calling request, wherein the receiving process is based on the second network transmission protocol.
Optionally, in some embodiments, the cross-service calling device further includes:
a second obtaining module, configured to obtain a second call request of the target service, where the second call request includes the current service, and the target service integrates a second ClientJar;
the second judging module is used for judging whether the third network transmission protocol of the target service is consistent with the fourth network transmission protocol of the target service;
and the second calling module is used for intercepting the third network transmission protocol to the preset protocol processor by using the second ClientJar when the third network transmission protocol of the target service is inconsistent with the fourth network transmission protocol of the target service, converting the third network transmission protocol into the fourth network transmission protocol by the preset protocol processor, and then sending the second calling request to the current service.
Optionally, in some embodiments, after determining whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service, the first determining module further includes: and the sending unit is used for sending the first calling request to the target service when the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service.
An embodiment of a third aspect of the present application provides an electronic device, including: the system comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor executes the program to realize the cross-service calling method according to the embodiment.
An embodiment of a fourth aspect of the present application provides a computer-readable storage medium having stored thereon a computer program for execution by a processor for implementing a cross-service invocation method as described in the above embodiment.
Therefore, the application can intercept the request of remote service call by developing a ClientJar packet acting on the service and a protocol transfer station, and can convert the network transmission protocol by the protocol transfer station when the network transmission protocol of the current service is inconsistent with the network transmission protocol of the target service. Therefore, the application can utilize the protocol transfer station to convert the HTTP protocol into the RPC protocol, and further can call each other between the services of two different protocols, thereby solving the problem that different micro services can not mutually communicate due to different network protocols caused by service demands in a distributed system, and the like, and greatly improving the call compatibility and expandability between the services in the platform.
Additional aspects and advantages of the application will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the application.
Drawings
The foregoing and/or additional aspects and advantages of the application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a schematic diagram of an inter-service call under a distributed system in the related art;
FIG. 2 is a schematic diagram of a remote invocation philosophy in accordance with one embodiment of the present application;
FIG. 3 is a flow chart of a cross-service invocation method provided in accordance with an embodiment of the present application;
FIG. 4 is a schematic diagram of an inter-service call according to one embodiment of the application;
FIG. 5 is a schematic diagram of a cross-service invocation apparatus provided according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar elements or elements having like or similar functions throughout. The embodiments described below by referring to the drawings are illustrative and intended to explain the present application and should not be construed as limiting the application.
The following describes a cross-service calling method, a device, an electronic device and a storage medium according to an embodiment of the application with reference to the accompanying drawings. Aiming at the problem that in the distributed system, different micro services can not mutually communicate due to different network protocols caused by service demands, the application provides a cross-service calling method, in which a first calling request of a current service is acquired, wherein the current service integrates a first ClientJar, and the first calling request comprises a target service; judging whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service; if the first network transmission protocol of the current service is inconsistent with the second network transmission protocol of the target service, intercepting the first network transmission protocol to a preset protocol processor by using a first ClientJar, converting the first network transmission protocol into the second network transmission protocol by the preset protocol processor, and then sending a first calling request to the target service. Therefore, the problems that different micro services can not mutually interact and communicate due to different network protocols caused by service demands in a distributed system are solved, and the calling compatibility and expandability among the services in the platform are greatly improved.
Prior to describing the embodiments of the present application, a brief description of the related art to which the present application relates will be provided.
As can be appreciated by those skilled in the art, in the conventional single architecture, there is no communication between services, that is, there is little problem related to network protocols, but with the continuous development and expansion of services, the single architecture cannot be satisfied, services are more and more subdivided, and interactive communication between services is unavoidable.
Fig. 2 is a schematic diagram of a basic principle of remote invocation provided by the embodiment of the present application, as shown in fig. 2, in a distributed system, a service is split into several units with independent functions, and each unit processes one service, that is, a single service. With the continuous change and increase of service demands, the service units inevitably need to interact with each other to share data, that is, call each other between services. While the invocation of the service requires the support of the network protocol, the service must use the same network protocol.
In today's distributed systems, numerous micro-services must use a unified network protocol calling style, such as RPC or HTTP-based RestFul style calling style, because of the need to invoke interactions with each other.
Among other things, RPC occurs mainly to address interface calls between different systems in a distributed system. Previously, when a system with a small scale is made, a single architecture is used, and an application and a database are deployed on a server. With the gradual expansion of services, the services are gradually subdivided, and communication is required to be invoked among a plurality of services through remote distributed interfaces, namely different services are deployed on different servers, and remote invocation is required to be used when the services are mutually invoked. The basic flow is that the client requests service processing from the service provider through the network based on a certain transmission protocol, and then obtains the returned data. This way of invocation, for the client, the developer does not need to know the specific network transport protocol, as with the local service. The framework conceals the communication details through the local dynamic proxy, sequences the request through the component, executes the real service code from the network to the server, returns the result to the client, and deserializes the data to the process of calling the method.
RestFul is a design style and development mode of a network application program, is based on the HTTP protocol, and is the most popular Internet software architecture at present. In current software development, the Json format is more used to define data. The function is the same as RPC, and is used for calling the interface between the cross services, transmitting data, and realizing different protocols and different realization modes.
Because various calling modes have different advantages and disadvantages, for example, RPC calling has the advantages of high speed, high throughput and the like, restFul has the advantages of penetrating a firewall, carrying large data volume, being easy to observe, and the like, under the condition that service requirements continuously change and develop, each micro-service in a distributed system can dynamically meet the use of calling modes based on different protocols, so that the service is not limited to a single calling mode.
Therefore, in order to solve the above-mentioned problems, the present application develops a protocol conversion station for processing the HTTP protocol, converting it into the RPC protocol, and further making a call between services of two different protocols. The cross-service calling method provided by the application is described in detail below with reference to specific embodiments.
Specifically, fig. 3 is a schematic flow chart of a cross-service calling method according to an embodiment of the present application.
As shown in fig. 3, the cross-service invocation method includes the steps of:
in step S301, a first call request of a current service is acquired, wherein the current service integrates a first ClientJar, and the first call request includes a target service.
It should be noted that the cross-service calling method provided by the application can be applied to micro-services, namely, the application program is divided into a group of small services, and the services are mutually coordinated and matched to realize corresponding functions. In a distributed system, a plurality of application programs inevitably need to interact with each other, namely, cross-service call is performed, wherein the plurality of application programs respectively use different network transmission protocols.
In some distributed system, if a service of a certain application program needs to call a service of another application program to realize functions such as data sharing, the service is a requester, and the requester can send a call request to a target service, where the call request includes address information of the target service.
Specifically, the current service of the embodiment of the application integrates a ClientJar packet, and the Jar packet is mainly used for intercepting the service request of a requester. The ClientJar packet is relied upon to enter the required service between different network transport protocols. In addition, the application is not particularly limited to the naming of the jar packet, and a person skilled in the art can set the jar packet according to the requirement when writing the jar packet.
For example, fig. 4 is a schematic diagram of an inter-service call provided in an embodiment of the present application, as shown in fig. 4, in the system, there are two application programs, one application program uses HTTP protocol, including service 1, service 2, service 3 and service 4; another application uses the RPC protocol, including service 5, service 6, service 7, and service 8. If service 1 (HTTP protocol) invokes service 5 (RPC protocol), then the dependency package ClientJar is injected into service 1. Thus, service 1 intercepts its call request via the jar packet, and the call request contains address information of service 5.
In addition, the jar package provided by the application is suitable for each micro service in any platform, and the dependency is only injected into the corresponding service, so that the dependency is deleted when the use is not needed, and any function of the original service is not influenced, therefore, the cross-service calling method provided by the application has high compatibility and hot plug property.
In step S302, it is determined whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service.
The first network transmission protocol of the embodiment of the application is the current service, namely the transmission protocol of the requester, and the second network transmission protocol is the target service, namely the transmission protocol of the called party.
Optionally, in some embodiments, after determining whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service, further includes: and if the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service, sending a first calling request to the target service.
It will be appreciated that service invocation may take place in interaction between two different services within the same application, in which case it uses the same network transport protocol, which naturally may be direct interaction, i.e. no injection of ClientJar packets between the same protocol services is required; the service call can also occur between services of different application programs, namely cross-service call, and different application programs use different network transmission protocols.
In step S303, if the first network transmission protocol of the current service is inconsistent with the second network transmission protocol of the target service, the first network transmission protocol is intercepted to a preset protocol processor by using the first ClientJar, and after the first network transmission protocol is converted to the second network transmission protocol by the preset protocol processor, the first call request is sent to the target service.
The preset protocol processor is a protocol transfer station provided by the application and is used for receiving the request intercepted by the ClientJar packet, carrying out protocol conversion, and unifying different network transmission protocols, namely converting the transmission protocol of the current service (the requesting party) into the transmission protocol consistent with the transmission protocol of the target service (the calling party). For example, in the embodiment of the present application, the first network transmission protocol is an HTTP protocol, the second network transmission protocol is an RPC protocol, and the ClientJar packet intercepts the HTTP protocol into the protocol processor, performs a protocol conversion, and may convert the HTTP protocol into the RPC protocol.
Further, after the first network transmission protocol is converted into the second network transmission protocol by the protocol processor, the transmission protocols of the current service and the target service are consistent, so that the current service can send a call request to the target service, and a cross-service interaction function is realized.
Optionally, in some embodiments, after sending the first call request to the target service, further comprising: and receiving response data sent by the target service based on the first call request, wherein the receiving process is based on a second network transmission protocol.
The service that receives the call request performs the request processing, and returns response data through the original connection. That is, when the current service (requester) receives response data of the target service (caller), it is performed based on the converted network transmission protocol.
For example, in fig. 4, a service 1 based on the HTTP protocol sends a call request to a service 5 based on the RPC protocol, a client-dependent jar packet injected by the service 1 intercepts the HTTP protocol in the call request, and at this time, a written protocol processor converts the HTTP protocol into the RPC protocol, and further sends the call request of the service 1 to the service 5 using the RPC protocol, after the service 5 receives the call request of the service 1, processes the call request, and feeds back response data based on the call request to the service 1 through the RPC protocol.
Thus, in the distributed system of fig. 4, there are two kinds of network protocol microservices that can not be called each other, however, the protocol conversion can be performed by the protocol processor provided by the present application, so that the calling each other is realized.
Optionally, in some embodiments, the cross-service invocation method further comprises: acquiring a second call request of the target service, wherein the second call request comprises the current service, and the target service integrates a second ClientJar; judging whether the third network transmission protocol of the target service is consistent with the fourth network transmission protocol of the target service; if the third network transmission protocol of the target service is inconsistent with the fourth network transmission protocol of the target service, intercepting the third network transmission protocol to a preset protocol processor by using a second ClientJar, converting the third network transmission protocol into the fourth network transmission protocol by the preset protocol processor, and then sending a second calling request to the current service.
It will be appreciated that the service receiving the request also requires callback to the service sending the request, and that this process also requires injection of the dependency ClientJar package.
The second call request of the application is a callback request of a target service, and the target service is also injected with ClientJar dependency. The third network transmission protocol of the target service intercepted by the ClientJar packet is converted by a protocol converter, and the third network transmission protocol is converted into a fourth network transmission protocol, so that the transmission protocol of the current service is consistent with that of the target service.
For example, in fig. 4, when the service 5 calls back the requested service 1, the transmission protocol of the response data received by the service 1 is the RPC protocol, and the service 1 is based on the HTTP protocol, so when the service 5 sends the call request, the ClientJar needs to be integrated to intercept the call request of the service 5, and determine whether the transmission protocols of the service 5 and the service 1 are consistent, and further, after the RPC protocol of the service 5 is converted into the HTTP protocol by the protocol processor, the call back request of the service 5 is sent to the service 1 based on the HTTP protocol.
Therefore, in the distributed system, different micro services can design different network transmission protocols according to the actual data access quantity, so that different calling modes are selected to call each other between the micro services. In addition, the method is not affected by network protocols in the distributed system, that is, the cross-service calling method can customize different interaction strategies according to different transmission protocols among platform services, so that the method has expandability.
According to the cross-service calling method provided by the embodiment of the application, a ClientJar packet acting on the service and a protocol transfer station are developed, when the network transmission protocol of the current service is inconsistent with the network transmission protocol of the target service, a request for remotely calling the service is intercepted by the ClientJar packet, and the network transmission protocol is converted by the protocol transfer station. Therefore, the application can utilize the protocol transfer station to convert the HTTP protocol into the RPC protocol, and further can call each other between the services of two different protocols, thereby solving the problem that different micro services can not mutually communicate due to different network protocols caused by service demands in a distributed system, and the like, and greatly improving the call compatibility and expandability between the services in the platform.
Next, a cross-service calling device according to an embodiment of the present application will be described with reference to the accompanying drawings.
FIG. 5 is a block diagram of a cross-service invocation apparatus according to an embodiment of the present application.
As shown in fig. 5, the cross-service invocation apparatus 10 includes: the device comprises a first acquisition module 100, a first judgment module 200 and a first calling module 300.
The first obtaining module 100 is configured to obtain a first call request of a current service, where the current service integrates a first ClientJar, and the first call request includes a target service; a first judging module 200, configured to judge whether a first network transmission protocol of a current service is consistent with a second network transmission protocol of a target service; and a first invoking module 300, configured to intercept the first network transmission protocol to a preset protocol processor by using the first ClientJar when the first network transmission protocol of the current service is inconsistent with the second network transmission protocol of the target service, and send a first invoking request to the target service after converting the first network transmission protocol to the second network transmission protocol by the preset protocol processor.
Optionally, in some embodiments, after sending the first call request to the target service, the first call module 300 further includes: and a receiving unit.
The receiving unit is used for receiving response data sent by the target service based on the first calling request, wherein the receiving process is based on the second network transmission protocol.
Optionally, in some embodiments, the cross-service invocation apparatus 10 further comprises: the device comprises a second acquisition module, a second judgment module and a second calling module.
The second acquisition module is used for acquiring a second call request of the target service, wherein the second call request comprises the current service, and the target service integrates a second ClientJar; the second judging module is used for judging whether the third network transmission protocol of the target service is consistent with the fourth network transmission protocol of the target service; and the second calling module is used for intercepting the third network transmission protocol to a preset protocol processor by using the second ClientJar when the third network transmission protocol of the target service is inconsistent with the fourth network transmission protocol of the target service, converting the third network transmission protocol into the fourth network transmission protocol by the preset protocol processor, and then sending a second calling request to the current service.
Optionally, in some embodiments, after determining whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service, the first determining module 200 further includes: and a transmitting unit.
The sending unit is used for sending a first calling request to the target service when the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service.
It should be noted that the foregoing explanation of the cross-service invocation method embodiment is also applicable to the cross-service invocation apparatus of this embodiment, and will not be repeated herein.
According to the cross-service calling device provided by the embodiment of the application, a ClientJar packet acting on the service and a protocol transfer station are developed, when the network transmission protocol of the current service is inconsistent with the network transmission protocol of the target service, a request for remotely calling the service is intercepted by the ClientJar packet, and the network transmission protocol is converted by the protocol transfer station. Therefore, the application can utilize the protocol transfer station to convert the HTTP protocol into the RPC protocol, and further can call each other between the services of two different protocols, thereby solving the problem that different micro services can not mutually communicate due to different network protocols caused by service demands in a distributed system, and the like, and greatly improving the call compatibility and expandability between the services in the platform.
Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application. The electronic device may include:
a memory 601, a processor 602, and a computer program stored on the memory 601 and executable on the processor 602.
The processor 602 implements the cross-service invocation method provided in the above embodiments when executing a program.
Further, the electronic device further includes:
a communication interface 603 for communication between the memory 601 and the processor 602.
A memory 601 for storing a computer program executable on the processor 602.
The memory 601 may include a high-speed RAM (Random Access Memory ) memory, and may also include a nonvolatile memory, such as at least one disk memory.
If the memory 601, the processor 602, and the communication interface 603 are implemented independently, the communication interface 603, the memory 601, and the processor 602 may be connected to each other through a bus and perform communication with each other. The bus may be an ISA (Industry Standard Architecture ) bus, a PCI (Peripheral Component, external device interconnect) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one thick line is shown in fig. 6, but not only one bus or one type of bus.
Alternatively, in a specific implementation, if the memory 601, the processor 602, and the communication interface 603 are integrated on a chip, the memory 601, the processor 602, and the communication interface 603 may perform communication with each other through internal interfaces.
The processor 602 may be a CPU (Central Processing Unit ) or ASIC (Application Specific Integrated Circuit, application specific integrated circuit) or one or more integrated circuits configured to implement embodiments of the present application.
The embodiment of the application also provides a computer readable storage medium, on which a computer program is stored, which when executed by a processor implements the cross-service invocation method as above.
In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or N embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, "N" means at least two, for example, two, three, etc., unless specifically defined otherwise.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and additional implementations are included within the scope of the preferred embodiment of the present application in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order from that shown or discussed, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the embodiments of the present application.
It is to be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the N steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. As with the other embodiments, if implemented in hardware, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable gate arrays, field programmable gate arrays, and the like.
Those of ordinary skill in the art will appreciate that all or a portion of the steps carried out in the method of the above-described embodiments may be implemented by a program to instruct related hardware, where the program may be stored in a computer readable storage medium, and where the program, when executed, includes one or a combination of the steps of the method embodiments.
While embodiments of the present application have been shown and described above, it will be understood that the above embodiments are illustrative and not to be construed as limiting the application, and that variations, modifications, alternatives and variations may be made to the above embodiments by one of ordinary skill in the art within the scope of the application.
Claims (10)
1. A cross-service invocation method, comprising the steps of:
acquiring a first call request of a current service, wherein the current service integrates a first ClientJar, and the first call request comprises a target service;
judging whether the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service; and
if the first network transmission protocol of the current service is inconsistent with the second network transmission protocol of the target service, intercepting the first network transmission protocol to a preset protocol processor by using the first ClientJar, converting the first network transmission protocol into the second network transmission protocol by the preset protocol processor, and then sending the first calling request to the target service.
2. The method of claim 1, further comprising, after sending the first call request to the target service:
and receiving response data sent by the target service based on the first call request, wherein the receiving process is based on the second network transmission protocol.
3. The method as recited in claim 1, further comprising:
acquiring a second call request of the target service, wherein the second call request comprises the current service, and the target service integrates a second ClientJar;
judging whether the third network transmission protocol of the target service is consistent with the fourth network transmission protocol of the target service;
if the third network transmission protocol of the target service is inconsistent with the fourth network transmission protocol of the target service, intercepting the third network transmission protocol to the preset protocol processor by using the second ClientJar, converting the third network transmission protocol into the fourth network transmission protocol by the preset protocol processor, and then sending the second calling request to the current service.
4. The method of claim 1, further comprising, after determining whether the first network transport protocol of the current service is consistent with the second network transport protocol of the target service:
and if the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service, sending the first calling request to the target service.
5. A cross-service invocation apparatus, comprising:
the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring a first call request of a current service, the current service integrates a first ClientJar, and the first call request comprises a target service;
a first judging module, configured to judge whether a first network transmission protocol of the current service is consistent with a second network transmission protocol of the target service; and
and the first calling module is used for intercepting the first network transmission protocol to a preset protocol processor by using the first ClientJar when the first network transmission protocol of the current service is inconsistent with the second network transmission protocol of the target service, converting the first network transmission protocol into the second network transmission protocol by the preset protocol processor, and then sending the first calling request to the target service.
6. The apparatus of claim 5, wherein after sending the first call request to the target service, the first call module further comprises:
and the receiving unit is used for receiving response data sent by the target service based on the first calling request, wherein the receiving process is based on the second network transmission protocol.
7. The apparatus as recited in claim 5, further comprising:
a second obtaining module, configured to obtain a second call request of the target service, where the second call request includes the current service, and the target service integrates a second ClientJar;
the second judging module is used for judging whether the third network transmission protocol of the target service is consistent with the fourth network transmission protocol of the target service;
and the second calling module is used for intercepting the third network transmission protocol to the preset protocol processor by using the second ClientJar when the third network transmission protocol of the target service is inconsistent with the fourth network transmission protocol of the target service, converting the third network transmission protocol into the fourth network transmission protocol by the preset protocol processor, and then sending the second calling request to the current service.
8. The apparatus of claim 5, wherein the first determining module, after determining whether the first network transport protocol of the current service is consistent with the second network transport protocol of the target service, further comprises:
and the sending unit is used for sending the first calling request to the target service when the first network transmission protocol of the current service is consistent with the second network transmission protocol of the target service.
9. An electronic device, comprising: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor executing the program to implement the cross-service invocation method of any of claims 1-4.
10. A computer readable storage medium having stored thereon a computer program, the program being executable by a processor for implementing the cross-service invocation method of any of claims 1-4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310671966.7A CN117201571A (en) | 2023-06-06 | 2023-06-06 | Cross-service calling method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310671966.7A CN117201571A (en) | 2023-06-06 | 2023-06-06 | Cross-service calling method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117201571A true CN117201571A (en) | 2023-12-08 |
Family
ID=88998605
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310671966.7A Pending CN117201571A (en) | 2023-06-06 | 2023-06-06 | Cross-service calling method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117201571A (en) |
-
2023
- 2023-06-06 CN CN202310671966.7A patent/CN117201571A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100426307B1 (en) | Apparatus and method accessing data by using single object access protocol-extended markup language | |
| US7587447B2 (en) | Systems, methods and computer programs for implementing and accessing web services | |
| US6775700B2 (en) | System and method for common information model object manager proxy interface and management | |
| US20030009539A1 (en) | Distributed object middleware connection method | |
| EP1560117A1 (en) | System and method for publishing and accessing application apis on a generic terminal | |
| CN111917737B (en) | Cross-network RPC calling system and method | |
| AU2007227774A1 (en) | Estimation of initial dynamic rendering control data | |
| CN111818158B (en) | Gateway control method, device, electronic equipment and storage medium | |
| US20020046304A1 (en) | Dynamic class loading | |
| US7685603B2 (en) | Selecting client adapters | |
| Aijaz et al. | Enabling high performance mobile web services provisioning | |
| CN112256246A (en) | Micro-service integration framework for supporting cross-language calling in power system | |
| US11269611B2 (en) | Data interface processing method, device, server and medium | |
| CN111367685B (en) | Interface calling method and device, computer equipment and storage medium | |
| CN113726869A (en) | Communication method, gateway and electronic equipment | |
| CN100405760C (en) | Method and system for providing web services from a service environment with a gateway | |
| CN106357654B (en) | Remote procedure calling method, device and communication system | |
| CN108810000B (en) | Method and device for generating serialization and deserialization API | |
| CN115242565A (en) | System architecture, communication method and device for realizing DDS communication based on AUTOSAR | |
| CN117201571A (en) | Cross-service calling method and device, electronic equipment and storage medium | |
| CN113535419A (en) | Service arranging method and device | |
| CN109005163B (en) | HTTP dynamic request service calling method | |
| CN111352872A (en) | Execution engine, data processing method, apparatus, electronic device, and medium | |
| CN110557428B (en) | Script interpretation type service agent method and system based on Kubernetes | |
| CN114257576A (en) | RPC server implementation method based on support of multiple communication protocols |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |