CN116866431A - Cross-service request processing method and device and multi-service system - Google Patents

Cross-service request processing method and device and multi-service system Download PDF

Info

Publication number
CN116866431A
CN116866431A CN202310814952.6A CN202310814952A CN116866431A CN 116866431 A CN116866431 A CN 116866431A CN 202310814952 A CN202310814952 A CN 202310814952A CN 116866431 A CN116866431 A CN 116866431A
Authority
CN
China
Prior art keywords
service
request
rpc
original
response result
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
Application number
CN202310814952.6A
Other languages
Chinese (zh)
Inventor
李斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kangjian Information Technology Shenzhen Co Ltd
Original Assignee
Kangjian Information Technology Shenzhen Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Kangjian Information Technology Shenzhen Co Ltd filed Critical Kangjian Information Technology Shenzhen Co Ltd
Priority to CN202310814952.6A priority Critical patent/CN116866431A/en
Publication of CN116866431A publication Critical patent/CN116866431A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The application relates to the technical field of computers and the digital medical field, and discloses a cross-service request processing method and device and a multi-service system, wherein the method is applied to a bridging agent and comprises the following steps: receiving an original request of an application side of a first service; performing RPC protocol conversion on the original request to obtain an RPC request of a second service, and sending the RPC request to the second service to perform the request; and receiving an original response result of the production side of the second service, converting the original response result into an RPC response result, and returning to the application side of the first service. The service application side of each technical stack in the application does not need to make any adjustment, the bridging agent carries out bidirectional adaptation, does not change any programming style, does not increase the learning cost in technology, reduces the subsequent maintenance cost of codes, and reduces the cost and risk of technology iteration and upgrading.

Description

Cross-service request processing method and device and multi-service system
Technical Field
The application relates to the technical field of computers and the digital medical field, in particular to a cross-service request processing method and device and a multi-service system.
Background
For an enterprise, a unified service technology stack is generally selected, but with the development of enterprise business, there is a need to incorporate other service technology stacks, for example, with the development of online medical treatment in the medical field, the functions involved in a business system of a hospital are more and more extensive, including online consultation, patient data management, medical instrument data management, medicine data management and the like; therefore, the business system of the hospital often needs to introduce different technical stacks to construct the business system.
In the prior art, dual registration or dual consumption is generally simply and directly adopted, a service application side simultaneously introduces multiple sets of service technology stacks to respectively perform RPC call according to respective modes, and RPC interaction can be rapidly opened, but in this way, a plurality of problems are brought, such as high technical complexity, difficult subsequent maintenance and the like, so that the learning cost and maintenance cost are increased, the influence of technical iteration and upgrading is also increased, and the cost and risk are also increased.
Disclosure of Invention
Aiming at the situation, the embodiment of the application provides a cross-service request processing method and device and a multi-service system, so as to overcome the defect that the latter part overcomes the defects in the prior art.
In a first aspect, an embodiment of the present application provides a cross-service request processing method, where the method is applied to a bridging agent, where the bridging agent has performed service registration on at least two services formed based on different micro-service technology stacks, and the method includes:
receiving an original request of an application side of a first service;
performing RPC protocol conversion on the original request to obtain an RPC request of a second service, and sending the RPC request to the second service to perform the request;
and receiving an original response result of the production side of the second service, converting the original response result into an RPC response result, and returning to the application side of the first service.
In a second aspect, an embodiment of the present application further provides a cross-service request processing apparatus, where the apparatus includes:
a request receiving unit, configured to receive an original request of an application side of a first service;
the request conversion unit is used for carrying out RPC protocol conversion on the original request to obtain an RPC request of a second service, and sending the RPC request to the second service to carry out the request;
and the result conversion unit is used for receiving the original response result of the production side of the second service, converting the original response result into an RPC response result and returning the RPC response result to the application side of the first service.
In a third aspect, an embodiment of the present application further provides a multi-service system, where the system includes at least two services formed based on different micro-service technology stacks, and a bridge proxy is further added to the system, where the bridge proxy is connected to each service separately, and the bridge proxy is deployed with the above-mentioned cross-service request processing device.
In a fourth aspect, an embodiment of the present application further provides an electronic device, including: a processor; and a memory arranged to store computer executable instructions that, when executed, cause the processor to perform the above-described cross-service request processing method.
In a fifth aspect, embodiments of the present application also provide a computer-readable storage medium storing one or more programs that, when executed by an electronic device that includes a plurality of application programs, cause the electronic device to perform the above-described cross-service request processing method.
The method adopted by the embodiment of the application at least has the following beneficial effects:
the application adds bridging agent between services formed by different micro-service technical stacks, when two services process the request, the request sending end is marked as a first service, the service processing the request is marked as a second service, before the request is processed, the bridging agent registers and pulls service information to the registration center of different micro-service technical stacks. When the first service sends a request, the first service does not directly send the request to the second service, but sends the request to an additionally arranged bridging agent, the bridging agent carries out RPC protocol conversion on the original request sent by the first service to obtain an RPC request of the second service, then sends the RPC request to a production side of the second service to carry out the request, the production side of the second service processes the RPC request to obtain a response result, the response result is recorded as an original response result, the second service returns the obtained original response result to the bridging agent, and the bridging agent converts the original response result to an RPC response result which can be identified by the first service and returns the RPC response result to an application side of the first service, so that the processing of the request in different technical stacks is realized. The application adds an intermediate bridging proxy node which is used as a producer (provider) of different micro-service technical stacks and also is used as a consumer (consumer) to carry out RPC protocol conversion on the original request, and then sends the request to a real producer, and the original response result returned by the producer is converted into a result which can be identified by one end sending the request, thereby realizing the processing of a request on different technical stacks. The service application side of each technical stack in the application does not need to make any adjustment, the bridging agent carries out bidirectional adaptation, does not change any programming style, does not increase the learning cost in technology, reduces the subsequent maintenance cost of codes, and reduces the cost and risk of technology iteration and upgrading.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:
FIG. 1 illustrates a schematic diagram of a multi-service system according to one embodiment of the application;
FIG. 2 shows a flow diagram of a cross-service request processing method according to one embodiment of the application;
FIG. 3 illustrates an abstract structural diagram of a bridging agent, according to one embodiment of the application;
FIG. 4 illustrates a business logic architecture diagram of a bridging agent in accordance with one embodiment of the present application;
FIG. 5 shows a schematic diagram of a cross-service request processing apparatus according to one embodiment of the application;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.
It often appears that a business system of an enterprise needs to introduce different technical stacks, for example, in the medical field, with the development of online medical treatment, the functions related to the business system of a hospital are more and more extensive, including online inquiry, patient data management, medical instrument data management, medicine data management and the like; therefore, the business system of the hospital often needs to introduce different technical stacks to construct the business system.
In the prior art, simple dual registration or dual consumption is generally adopted for a multi-technology stack, namely, a plurality of sets of micro-service technology stacks are simultaneously introduced at a service application side, and the multi-technology stack respectively performs RPC call according to respective modes, so that RPC interaction can be rapidly conducted, but the technical complexity, the code maintenance difficulty, the iteration upgrading cost and the like are extremely increased.
In this regard, the present application provides a cross-service request processing method, which is used for processing requests between services formed by different micro-service technology stacks, and the method may be implemented by a multi-service system, fig. 1 shows a schematic structural diagram of the multi-service system according to an embodiment of the present application, and as can be seen from fig. 1, the multi-service system 100 includes: at least two services based on different technology stacks are respectively denoted as a first service 110 and a second service 120, specifically, each service includes an application side and a production side, the first service 110 includes a first application side 111 and a first production side 112, the second service 120 includes a second application side 121 and a second production side 122, unlike the prior art, in the present application, a bridging agent 130 is added in the multi-service system 100, the bridging agent 130 is respectively connected to the first service 110 and the second service 120 in a communication manner, specifically, the bridging agent 130 is respectively connected to the first application side 111, the first production side 112, the second application side 121 and the second production side 122.
The cross-service request processing method of the present application may be implemented by the multi-service system shown in fig. 1, but the request processing method of the present application is not limited to the multi-service system shown in fig. 1, and any architecture or system capable of implementing the cross-service request processing method of the present application may be used.
Fig. 2 is a flow chart of a cross-service request processing method according to an embodiment of the present application, where the cross-service request processing method of the present application is applicable to the bridging agent, and the method of the present application at least includes steps S210 to S230:
step S210: an original request of an application side of a first service is received.
The main idea of the present application is to add an intermediate bridging proxy node, which is used as a producer (provider) of different micro-service technology stacks and also as a consumer (consumer), after performing RPC protocol conversion on the original request, sends the original request to the real producer, and converts the original response result returned by the producer into a result identifiable at the end sending the request, thereby realizing the processing of a request in different technology stacks.
In the present embodiment, a service that makes a request is referred to as a first service, and a service that processes a request is referred to as a second service. When a request is processed, the service that sent the request is Consumer, and the service that processed the request is Provier. In this embodiment, the description will be given taking an example in which the first service transmits a request to the second service, and therefore, the first service is a Consumer and the second service is a provider.
Bridging agent 130 registers with the registry or pulls service information as a Consumer within each micro-service technology stack hierarchy.
When the first application side 111 of the first service 110 makes a request to the second service 120, the issued request is denoted as an original request, which is not directly sent to the production side 122 of the second service 120, but to the bridging proxy (RPC Bridge) 130.
In some embodiments of the application, bridging agent 130 may provide access to different micro-service frameworks to reduce docking costs. FIG. 3 shows an abstract structural diagram of a bridge agent, and as can be seen in FIG. 3, bridge agent 130 mainly includes a plurality of technology stack ports (Endpoint) 131 and a protocol translation module 132, according to one embodiment of the application.
The plurality of technology stack ports 131, such as ports including web ports, or dubbo ports, or other micro-service technology stacks, primarily function to receive original requests issued by services.
In some embodiments of the present application, in the foregoing method, the receiving an original request of an application side of a first service includes: determining a technology stack type of the first service; determining a target technical stack port corresponding to the original request according to the determined technical stack type; and receiving an original request sent by the application side of the first service through the target technology stack port.
For example, the first service is constructed based on a Spring framework, after receiving an original request of the first service, the bridging agent 130 identifies the first service or the technical stack type of the request, and if it is determined that the technical stack type is the Spring framework, the original request is routed to the web port for receiving.
For another example, the first service is constructed based on the dubbo framework, after receiving the original request of the first service, the bridging agent 130 identifies the first service or the technical stack type of the request, and if it is determined that the technical stack type is the dubbo framework, the original request is routed to the dubbo port for receiving.
In addition, the bridging agent of the present application also supports other micro-service technology stacks, provides corresponding ports, and receives requests, which are not listed one by one.
Step S220: and performing RPC protocol conversion on the original request to obtain an RPC request of the second service, and sending the RPC request to the second service to perform the request.
The bridge agent 130 converts the original request into an RPC request of the second service according to a preset RPC protocol, and directly requests the second production side 122 (Provider side) of the second service 120 as a Consumer.
Referring to fig. 3 again, as can be seen from fig. 3, the Bridge agent is logically divided into four logic layers, where the aforementioned plurality of technology stack ports 131 are located at the uppermost layer of the Bridge agent, which may also be referred to as an ingress layer, and in this layer, the Bridge agent further includes a plurality of technology stacks SDKs, which may include an original SDK (Native SDK in the figure) provided by the Bridge agent RPC Bridge by default, and an SDK (openfeign SDK in the figure) provided by the openfeign to simplify the docking difficulty on the consumer side and reduce the development cost.
The second, third and fourth layers of rain and fog logic of the bridging agent form a protocol conversion module 132, and the protocol conversion module 132 mainly comprises from top to bottom: an Assembly Layer (Assembly Layer), a Filter Layer (Filter Layer), and an execution Layer (execution Layer);
in some embodiments of the present application, in the above method, the performing RPC protocol conversion on the original request to obtain an RPC request of the second service includes: constructing a corresponding request execution object for the original request based on the assembly layer; processing the request execution object based on the filter layer, the processing including at least one of current limiting, fusing, and demoting; converting the processed request execution object into a request command object as an RPC request of the second service based on the execution layer, wherein the request command object at least comprises: the bridging agent invokes execution logic of the production side of the second service as the application side.
When the original request sent by the first application side 111 of the first service 110 reaches one of the technology stack ports 131 of the bridging agent 130, the original request is transferred to the protocol conversion module 132 by the technology stack port 131, and then the original request of the first service is converted into an RPC request identifiable and processed by the second service through an Assembly Layer, a Filter Layer and an execution Layer of the protocol conversion module 132.
Specifically, the Assembly Layer mainly includes an Actator sub-module and a Render sub-module, the Actator sub-module may be constructed by related algorithms such as an Actator function, the Actator sub-module is mainly responsible for separately creating an Actator object for each request, and the Render sub-module is mainly used for processing the result returned by the second service.
After the original requests arrive at the Assembly Layer, a request execution object (an Actator object) is independently created for each original request by the Assembly submodule and the Render submodule, and the Actator object can call the execution logic of the lower Layer.
The obtained actioner object is transferred to a Filter Layer, and the Filter Layer has the main functions of performing current limiting, fusing, degradation and other treatments on the actioner object, and can flexibly and dynamically add and expand to realize new functions.
Then, the method goes to an execution Layer, and the execution Layer converts the execution Layer into a corresponding request command object (RemoteCommand object) through a transducer submodule according to the description parameters in the actor object, wherein the romitecommand object at least comprises execution logic for calling a provider by taking an RPC Bridge node as a consumer. Finally, the RomteCommand object is taken as the RPC request for the second service 120.
After converting to the RPC request, the bridging agent 130 may call the SDK of the corresponding technology stack and send it to the second production side 122 of the second service 120 to request the second production side 122 to process the RPC request.
Specifically, in some embodiments of the present application, the sending the RPC request to the second service for a request includes: determining a target technical stack SDK corresponding to the RPC request according to the technical stack type of the second service; and calling the target technology stack SDK and sending the RPC request to the production side of the second service.
For example, the second service is constructed based on the dubbo framework, after converting the original request into the RPC request, if the target technology stack SDK corresponding to the RPC request is determined to be the dubbo SDK, the bridge agent 130 invokes the dubbo SDK in the multiple technology stack SDKs, and sends the RPC request to the second production side 122 of the second service 120.
For another example, the second service is constructed based on a Spring framework, and after converting the original request into the RPC request, if the target technology stack SDK corresponding to the RPC request is Spring Clound SDK, the bridging agent 130 invokes Spring Clound SDK of the multiple technology stacks SDKs to send the RPC request to the second production side 122 of the second service 120.
The second production side 122 of the second service 120 parses the RPC request after receiving the RPC request, and processes the RPC request to obtain a processing result, where in the present application, the result is recorded as an original response result, and the second production side 122 of the second service 120 should return the original response result to the first service 110, and the original response result is not directly recognized by the first service 110, so that the second production side 122 needs to be converted, and returns the original response result to the bridging agent 130 for conversion.
Step S230: and receiving an original response result of the production side of the second service, converting the original response result into an RPC response result, and returning to the application side of the first service.
The bridging agent 130 receives the original response result of the second production side 122 of the second service 120, specifically, in some embodiments of the present application, the receiving the original response result of the production side of the second service includes: determining a target technical stack SDK corresponding to the original response result according to the technical stack type of the second service; and calling the target technology stack SDK, and receiving the original response result returned by the production side of the second service.
For example, the second service is constructed based on the dubbo framework, and then the dubbo SDKs in the plurality of technology stacks SDKs are called, and the original response result of the second production side 122 of the second service 120 is received.
For another example, the second service is constructed based on the Spring framework, and Spring Clound SDK in the multiple technology stacks SDKs are called to receive the original response result of the second production side 122 of the second service 120.
The bridging agent 130, upon receiving the original response result, converts it into an RPC result recognizable by the first service 110, and returns to the first application side 111 of the first service 110.
Specifically, in some embodiments of the present application, the converting the original response result into an RPC response result, and returning the RPC response result to the application side of the first service includes: converting the original response result into a corresponding result template object based on the assembly layer; and returning the result template object to the application side of the first service as an RPC response result.
After the bridging agent 130 receives the original response result through the multi-technology stack SDK, the original response result enters a Render sub-module of the Assembly Layer, and the Render sub-module processes the original response result and converts the processed response result into a result template object (Render object), where the result template object may be considered as a result that can be directly identified by the first service 110, that is, the result template object is returned to the first application side 111 of the first service 110 as an RPC response result, so far, the processing of a cross-service request is completed.
As can be seen from the method shown in fig. 2, the bridging agent is added between services formed by different micro-service technical stacks, when two services process a request, the request sending end is marked as a first service, the service processing the request is marked as a second service, and before the request is processed, the bridging agent registers and pulls service information to the registration centers of different micro-service technical stacks. When the first service sends a request, the first service does not directly send the request to the second service, but sends the request to an additionally arranged bridging agent, the bridging agent carries out RPC protocol conversion on the original request sent by the first service to obtain an RPC request of the second service, then sends the RPC request to a production side of the second service to carry out the request, the production side of the second service processes the RPC request to obtain a response result, the response result is recorded as an original response result, the second service returns the obtained original response result to the bridging agent, and the bridging agent converts the original response result to an RPC response result which can be identified by the first service and returns the RPC response result to an application side of the first service, so that the processing of the request in different technical stacks is realized. The application adds an intermediate bridging proxy node which is used as a producer (provider) of different micro-service technical stacks and also is used as a consumer (consumer) to carry out RPC protocol conversion on the original request, and then sends the request to a real producer, and the original response result returned by the producer is converted into a result which can be identified by one end sending the request, thereby realizing the processing of a request on different technical stacks. The service application side of each technical stack in the application does not need to make any adjustment, the bridging agent carries out bidirectional adaptation, does not change any programming style, does not increase the learning cost in technology, reduces the subsequent maintenance cost of codes, and reduces the cost and risk of technology iteration and upgrading.
In the multi-service system, any one service may be used as a service that issues a request, i.e., a Consumer application side, or may be used as an opposite Provider. That is, in the above embodiment, when the second service 120 makes a request to the first service 110, the flow is the same as the process that the first service 110 makes a request to the second service 120, and will not be described again.
Referring to fig. 4, fig. 4 is a flow chart illustrating a cross-service request processing method according to another embodiment of the present application, and as can be seen from fig. 4, for any two services, one of the services is a Consumer application side, the other is an opposite terminal Provider, and the Consumer application side initiates an RPC request of a cross-technology stack, and the RPC request is sent to a bridging agent through a technology stack port of a bridging agent service, and is sent to the opposite terminal Provider after being converted, the opposite terminal Provider returns a response result to the bridging agent, and the bridging agent converts the response result to the RPC result and returns to the Consumer application side.
In some embodiments of the present application, a Spring framework and a Dubbo framework are selected as the bottom layer architecture of the micro service to form different upper layer services, please refer to fig. 4, and as can be seen from fig. 4, in this embodiment, the first service is constructed based on the Spring framework, including Spring Clound Consumer, spring Clound Provider, and eureka, and similarly, the second service is constructed based on the Dubbo framework, which includes: dubbo Consumer, dubbo Provider, and zookeeper, which are consistent with the prior art, unlike the prior art, a bridging proxy service, denoted RPC Bridge Server, is added between the first service and the second service, and the bridging proxy service RPC Bridge Server includes a plurality of technology stack ports, such as Web endpoint, dubbo endpoint, etc., and further includes an RPC protocol conversion module RPC protocol Transformer, where the role of eureka and zookeeper is consistent in the first service and the second service, which can be simply understood as a module that actually processes requests.
Taking the example that the first service requests the second service, spring Clound Consumer sends the original request to the bridging proxy service RPC Bridge Server through the Web endpoint provided by the bridging proxy service, the RPC request is converted into the RPC request supported by the Dubbo framework by the RPC protocol conversion module RPC protocol Transformer, then the RPC request is sent to the Dubbo Provider, the Dubbo Provider sends the RPC request to the zookeeper for processing, the zookeeper returns a response result to the bridging proxy service RPC Bridge Server, and the bridging proxy service RPC Bridge Server returns the response result to Spring Clound Consumer after converting the response result.
Similarly, the Dubbo Consumer sends the original request to the bridge proxy RPC Bridge Server through the Dubbo endpoint provided by the bridge proxy, after being converted into an RPC request supported by the Spring framework by the RPC protocol conversion module RPC protocol Transformer, the RPC request is sent to Spring Clound Provider, sent to eureka by Spring Clound Provider for processing, and the response result is returned to the bridge proxy RPC Bridge Server by the eureka, and after being converted by the bridge proxy RPC Bridge Server, the response result is returned to the Dubbo Consumer.
Fig. 5 shows a schematic structural diagram of a cross-service request processing apparatus according to an embodiment of the present application, and as can be seen from fig. 5, the cross-service request processing apparatus 500 includes:
a request receiving unit 510, configured to receive an original request of an application side of a first service;
the request conversion unit 520 is configured to perform RPC protocol conversion on the original request to obtain an RPC request of a second service, and send the RPC request to the second service to perform a request;
and a result conversion unit 530, configured to receive an original response result of the production side of the second service, convert the original response result into an RPC response result, and return the RPC response result to the application side of the first service.
In some embodiments of the present application, in the foregoing apparatus, the bridging agent includes at least: a plurality of technology stack ports; a request receiving unit 510, configured to determine a technology stack type of the first service; determining a target technical stack port corresponding to the original request according to the determined technical stack type; and receiving an original request sent by the application side of the first service through the target technology stack port.
In some embodiments of the present application, in the foregoing apparatus, the bridging agent includes at least: a plurality of technology stacks SDKs; a request conversion unit 520, configured to determine, according to the technology stack type of the second service, a target technology stack SDK corresponding to the RPC request; invoking the target technology stack SDK and sending the RPC request to the production side of the second service; a result conversion unit 530, configured to determine, according to the technology stack type of the second service, a target technology stack SDK corresponding to the original response result; and calling the target technology stack SDK, and receiving the original response result returned by the production side of the second service.
In some embodiments of the present application, in the above apparatus, the protocol conversion module further includes: an assembly layer, a filter layer, and an execution layer; a request conversion unit 520, configured to construct a corresponding request execution object for the original request based on the assembly layer; processing the request execution object based on the filter layer, the processing including at least one of current limiting, fusing, and demoting; converting the processed request execution object into a request command object as an RPC request of the second service based on the execution layer, wherein the request command object at least comprises: the bridging agent invokes execution logic of the production side of the second service as the application side.
In some embodiments of the present application, in the above apparatus, a result converting unit 530 is configured to convert the original response result into a corresponding result template object based on the assembly layer; and returning the result template object to the application side of the first service as an RPC response result.
In some embodiments of the application, in the above apparatus, the micro service technology stack is selected from a Spring framework, and a Dubbo framework.
It should be noted that the above-mentioned cross-service request processing device may implement the foregoing cross-system request processing method one by one, which is not described herein in detail.
Fig. 6 is a schematic structural view of an electronic device according to an embodiment of the present application. Referring to fig. 6, at the hardware level, the electronic device includes a processor, and optionally an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory (non-volatile Memory), such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, network interface, and memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture ) bus, a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one bi-directional arrow is shown in FIG. 6, but not only one bus or type of bus.
And the memory is used for storing programs. In particular, the program may include program code including computer-operating instructions. The memory may include memory and non-volatile storage and provide instructions and data to the processor.
The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs, forming the cross-service request processing apparatus 500 at the logic level. And the processor is used for executing the program stored in the memory and particularly used for executing the method.
The method performed by the cross-service request processing apparatus disclosed in the embodiment of fig. 5 of the present application may be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, each step of the above method may be implemented by an integrated logic circuit of hardware in a processor or an instruction in a software format. The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but also digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads configuration information in the memory and, in combination with its hardware, performs the steps of the above method.
The electronic device may also execute the method executed by the cross-service request processing apparatus in fig. 5, and implement the functions of the cross-service request processing apparatus in the embodiment shown in fig. 5, which is not described herein.
The embodiment of the present application also proposes a computer-readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by an electronic device comprising a plurality of application programs, enable the electronic device to perform a method performed by a cross-service request processing apparatus in the embodiment shown in fig. 5, and in particular to perform the aforementioned method.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include non-volatile memory in a computer-readable medium, random Access Memory (RAM) and/or non-volatile memory, etc., in a format such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both permanent and non-permanent, removable and non-removable media, may implement configuration information storage by any method or technology. The configuration information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store configuration information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other identical elements in a process, method, article or apparatus that comprises the element.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are to be included in the scope of the claims of the present application.

Claims (10)

1. A method of cross-service request processing, the method being applied to a bridging agent that has registered for services with at least two services formed based on different micro-service technology stacks, the method comprising:
receiving an original request of an application side of a first service;
performing RPC protocol conversion on the original request to obtain an RPC request of a second service, and sending the RPC request to the second service to perform the request;
and receiving an original response result of the production side of the second service, converting the original response result into an RPC response result, and returning to the application side of the first service.
2. The method according to claim 1, wherein the bridging agent comprises at least: a plurality of technology stack ports;
the receiving the original request of the application side of the first service includes:
determining a technology stack type of the first service;
determining a target technical stack port corresponding to the original request according to the determined technical stack type;
and receiving an original request sent by the application side of the first service through the target technology stack port.
3. The method according to claim 1, wherein the bridging agent comprises at least: a plurality of technology stacks SDKs;
the sending the RPC request to the second service for a request includes:
determining a target technical stack SDK corresponding to the RPC request according to the technical stack type of the second service;
invoking the target technology stack SDK and sending the RPC request to the production side of the second service;
the receiving the original response result of the production side of the second service comprises the following steps:
determining a target technical stack SDK corresponding to the original response result according to the technical stack type of the second service;
and calling the target technology stack SDK, and receiving the original response result returned by the production side of the second service.
4. The method of claim 3, wherein the protocol conversion module further comprises: an assembly layer, a filter layer, and an execution layer;
the performing the RPC protocol conversion on the original request to obtain an RPC request of the second service includes:
constructing a corresponding request execution object for the original request based on the assembly layer;
processing the request execution object based on the filter layer, the processing including at least one of current limiting, fusing, and demoting;
converting the processed request execution object into a request command object as an RPC request of the second service based on the execution layer, wherein the request command object at least comprises: the bridging agent invokes execution logic of the production side of the second service as the application side.
5. A method according to claim 3, wherein said converting the original response result into an RPC response result, returning to the application side of the first service, comprises:
converting the original response result into a corresponding result template object based on the assembly layer;
and returning the result template object to the application side of the first service as an RPC response result.
6. The method according to any of claims 1-5, wherein the microservice technology stack is selected from a Spring framework, and a Dubbo framework.
7. A cross-service request processing apparatus, the apparatus comprising:
a request receiving unit, configured to receive an original request of an application side of a first service;
the request conversion unit is used for carrying out RPC protocol conversion on the original request to obtain an RPC request of a second service, and sending the RPC request to the second service to carry out the request;
and the result conversion unit is used for receiving the original response result of the production side of the second service, converting the original response result into an RPC response result and returning the RPC response result to the application side of the first service.
8. A multi-service system, characterized in that the system comprises at least two services formed based on different micro-service technology stacks, a bridging agent is additionally arranged in the system, the bridging agent is respectively connected with each service, and the bridging agent is provided with the cross-service request processing device in claim 7.
9. An electronic device, comprising:
a processor; and
a memory arranged to store computer executable instructions which, when executed, cause the processor to perform the method of any of claims 1 to 6.
10. A computer readable storage medium storing one or more programs, which when executed by an electronic device comprising a plurality of application programs, cause the electronic device to perform the method of any of claims 1-6.
CN202310814952.6A 2023-07-04 2023-07-04 Cross-service request processing method and device and multi-service system Pending CN116866431A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310814952.6A CN116866431A (en) 2023-07-04 2023-07-04 Cross-service request processing method and device and multi-service system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310814952.6A CN116866431A (en) 2023-07-04 2023-07-04 Cross-service request processing method and device and multi-service system

Publications (1)

Publication Number Publication Date
CN116866431A true CN116866431A (en) 2023-10-10

Family

ID=88229773

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310814952.6A Pending CN116866431A (en) 2023-07-04 2023-07-04 Cross-service request processing method and device and multi-service system

Country Status (1)

Country Link
CN (1) CN116866431A (en)

Similar Documents

Publication Publication Date Title
CN109002362B (en) Service method, device and system and electronic equipment
CN108600326B (en) Communication method, device and equipment
US10817284B2 (en) Melding of mediation flow service component architecture (SCA) components
US20170048359A1 (en) Method and device for transmitting a message in a vehicle
CN113141405B (en) Service access method, middleware system, electronic device, and storage medium
CN111818158B (en) Gateway control method, device, electronic equipment and storage medium
CN111461887A (en) Block chain consensus processing method and device and electronic equipment
WO2016107120A1 (en) Application programming interface calling method and device
US11269611B2 (en) Data interface processing method, device, server and medium
CN113612686A (en) Traffic scheduling method and device and electronic equipment
US11500690B2 (en) Dynamic load balancing in network centric process control systems
CN111597058B (en) Data stream processing method and system
CN114363233B (en) Packet routing method, device, electronic equipment and storage medium
CN112751935B (en) Request processing method and device, electronic equipment and storage medium
CN116866431A (en) Cross-service request processing method and device and multi-service system
CN112579212A (en) Cross-language calling method, calling party device and called party device
US11796975B2 (en) Network centric process control
CN114675821A (en) Service standardization system and method based on low codes
CN116881022A (en) Cross-service request processing method and device and multi-service system
CN111580998A (en) RPC calling method of multiple tenants in SaaS service mode
CN116074622B (en) Implementation method, device, equipment and medium for multi-protocol control USB camera
CN117041980B (en) Network element management method and device, storage medium and electronic equipment
CN113986955B (en) Service chain determining method and device, electronic equipment and medium
WO2024093731A1 (en) Automotive open system architecture, data processing method and on-board device
CN113014411B (en) Method, device and system for managing network device

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