Protocol conversion method and device and readable storage medium

Abstract

The invention relates to a protocol conversion method and device and a readable storage medium, and the method comprises the steps: responding to a received first protocol request from a client, and converting the first protocol request into a standardized event; based on the standardized event, converting the first protocol request into a second protocol request, and outputting the second protocol request to a target server; wherein the protocol formats of the first protocol request and the second protocol request are different; and receiving an original response message fed back by the target server for the second protocol request, converting the original response message into a target response message matched with the protocol format of the first protocol request, and transmitting the target response message to the client. Through conversion of standardized events, the expansion difficulty of the protocol conversion system can be effectively reduced.

Description

Technical Field

[0001] The present application relates to the field of computer communication technology, and in particular to a protocol conversion method, device and readable storage medium. Background Art

[0002] In traditional distributed systems, there is a need to convert between the two communication protocols RESTful (Representational State Transfer) and JSON-RPC (JSON Remote Procedure Call). However, traditional RESTful and JSON-RPC protocol conversion solutions mostly rely on complex middleware conversion or manual conversion. As the system load increases, traditional protocol conversion systems are difficult to expand accordingly. Summary of the invention

[0003] Based on this, it is necessary to provide a protocol conversion method, device and readable storage medium that can effectively reduce the difficulty of expanding the protocol conversion system in response to the above technical problems.

[0004] In a first aspect, the present application provides a protocol conversion method, the method comprising:

[0005] In response to receiving a first protocol request from a client, converting the first protocol request into a standardized event;

[0006] Based on the standardized event, convert the first protocol request into a second protocol request, and output the second protocol request to the target server; wherein the first protocol request and the second protocol request have different protocol formats;

[0007] An original response message fed back by the target server for the second protocol request is received, the original response message is converted into a target response message having a protocol format matching the first protocol request, and then transmitted to the client.

[0008] In one of the embodiments, the first protocol request is a RESTful request, and the second protocol request is a JSON-RPC request; or, the first protocol request is a JSON-RPC request, and the second protocol request is a RESTful request.

[0009] In one embodiment, before converting the first protocol request into the second protocol request based on the standardized event, the method includes:

[0010] Through the event bus, the standardized event is transmitted to the corresponding protocol conversion processor according to the event type and event content of the standardized event.

[0011] In one embodiment, converting the first protocol request into the second protocol request includes:

[0012] The protocol conversion processor uses corresponding conversion logic according to the event type to convert the first protocol request into the second protocol request.

[0013] In one embodiment, the method further comprises:

[0014] Monitor the flow of the event stream to which the standardized event belongs and the working status parameters of the protocol conversion processor to obtain monitoring results; the working status parameters include load and delay indicators for protocol conversion;

[0015] Based on the monitoring results, determine whether to trigger an alarm.

[0016] In one embodiment, the method further comprises:

[0017] Dynamically adjust the priority of event flows based on business needs.

[0018] In one embodiment, in response to receiving a first protocol request from a client, converting the first protocol request into a standardized event includes:

[0019] The interface layer extracts key information of the first protocol request and encapsulates the key information into a standardized event object.

[0020] In one embodiment, converting the original response message into a target response message in a protocol format matching the first protocol request includes:

[0021] The protocol conversion processor converts the original response message into an original response event in a protocol format matching the second protocol request;

[0022] The original response event is transmitted to the interface layer through the event bus, and the interface layer converts the original response event into a target response message in a protocol format matching the first protocol request.

[0023] In a second aspect, the present application also provides a protocol conversion device, the device comprising:

[0024] A standardized event conversion module, configured to convert the first protocol request into a standardized event in response to receiving the first protocol request from the client;

[0025] A protocol request conversion and output module, used to convert a first protocol request into a second protocol request based on a standardized event, and output the second protocol request to a target server; wherein the first protocol request and the second protocol request have different protocol formats;

[0026] The response message conversion and transmission module is used to receive the response message fed back by the target server in response to the second protocol request, convert the response message into a response message in a protocol format matching the first protocol request, and then transmit it to the client.

[0027] In a third aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of any one of the methods in the first aspect when the computer program is executed by a processor.

[0028] The above-mentioned protocol conversion method, device and readable storage medium convert the first protocol request from the client into a standardized event, then based on the standardized event, convert the first protocol request into a second protocol request and output it to the target server, receive the original response message fed back by the target server for the second protocol request, and then convert the original response message into a target response message of a protocol format matching the first protocol request, and then transmit it to the client. This application can effectively reduce the difficulty of expanding the protocol conversion system through the conversion of standardized events. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0030] Figure 1 An application environment diagram of a protocol conversion method in an embodiment;

[0031] Figure 2 A schematic diagram of a protocol conversion method in one embodiment;

[0032] Figure 3 A schematic diagram of a process for monitoring standardized events in one embodiment;

[0033] Figure 4 A schematic diagram of a process of converting and obtaining a target response message in one embodiment;

[0034] Figure 5 A timing diagram of the operation of a RESTful and JSON-RPC protocol conversion architecture in one embodiment;

[0035] Figure 6 is a structural block diagram of a protocol conversion device in one embodiment;

[0036] Figure 7 is a diagram showing the internal structure of a computer device of a client in one embodiment;

[0037] Figure 8 The figure is a diagram showing the internal structure of a computer device of a target server in one embodiment. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0039] In modern distributed systems, RESTful and JSON-RPC are two common communication protocols, each with its own advantages and applicable scenarios.

[0040] Among them, RESTful is an application layer protocol based on HTTP (Hypertext Transfer Protocol). It uses standard HTTP methods (such as GET, POST, PUT, DELETE, etc.) to process resources and can transmit data through concise URLs and standard HTTP status codes. It can be understood that RESTful is widely used in Web service and API (Application Programming Interface) design due to its simplicity, easy understanding and use.

[0041] JSON-RPC is a lightweight remote procedure call protocol, commonly used for communication between servers. JSON-RPC uses the JSON (JavaScript Object Notation) format to encode requests and responses, allowing clients to call remote server functions through a specified method name and parameters and receive response results. Since JSON-RPC does not rely on the HTTP protocol, it is widely used in some scenarios with high performance requirements or cross-protocol operations.

[0042] In practical applications, there is a need to convert between JSON-RPC and RESTful protocols to facilitate seamless integration between different systems. For example, a system using RESTful and another system using JSON-RPC need to communicate with each other. At this time, protocol conversion between JSON-RPC and RESTful is required to meet system compatibility requirements; for example, when migrating existing RESTful services to JSON-RPC, or vice versa, dual protocols need to be supported during the transition period to meet the needs of upgrading existing services.

[0043] However, traditional JSON-RPC and RESTful protocol conversion solutions mostly rely on complex middleware or manual conversion.

[0044] For example, traditional middleware solutions use middleware (such as API gateways) to implement protocol conversion. The middleware deployed on a server receives requests from clients, analyzes the protocol type of the request, and then performs the corresponding conversion operation. For example, when receiving a RESTful request, the middleware parses the URL (uniform resource locator), HTTP method, and request parameters, converts them into JSON-RPC format, and sends the converted request to the backend service. The returned response is then converted back to RESTful format by the middleware and returned to the client. However, this traditional middleware solution increases the complexity of the system, especially in large distributed systems, where performance bottlenecks may be introduced. In addition, its conversion logic needs to be updated frequently, with high maintenance costs, and the middleware may become a single point of failure, resulting in the reliability of the entire system relying on the stability of the middleware.

[0045] The other manual conversion method requires client / server modification, which is to directly perform protocol conversion on the client or server. For example, it is necessary to implement the conversion logic from RESTful to JSON-RPC on the client, or provide two interfaces, RESTful and JSON-RPC, on the server, and then the client calls the interface according to the needs. This manual conversion method may cause version compatibility issues, thus affecting the update and maintenance of the client. In addition, the server needs to maintain two sets of interfaces at the same time, which increases the development and maintenance costs, and may also bring the risk of system operation with inconsistent interfaces. These traditional protocol conversion methods not only increase the complexity of the protocol conversion system, but may also introduce performance bottlenecks and even security risks.

[0046] The above solutions have the following limitations: (1) Performance bottleneck: Although traditional middleware solutions are powerful, they can easily become the performance bottleneck of the protocol conversion system, especially in high-concurrency scenarios, where the system protocol conversion overhead is particularly significant; (2) Increased complexity: Introducing middleware or modifying existing systems will increase the complexity of the system, leading to maintenance difficulties; (3) Lack of flexibility: Most existing protocol conversion solutions are hard-coded protocol conversion methods, lacking flexible support for complex business logic, such as dynamic parameter mapping, conditional conversion, etc.; (4) Security risks: Traditional middleware solutions and manual conversion and modification solutions may introduce new attack surfaces to the system, increasing the security risks of the protocol conversion system.

[0047] In order to solve the above problems, the present application proposes an efficient and reliable protocol conversion method. The protocol conversion method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown. Among them, the client 102 communicates with the target server 106 through the protocol conversion system 104. Exemplarily, the protocol conversion system 104 may include components such as an interface layer 108, an event bus 110, a protocol conversion processor 112, a monitoring management module 114, and the above components may be connected through a network. Among them, the client 102 can be implemented using a terminal. Exemplarily, the terminal may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices and portable wearable devices. The Internet of Things devices may be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. Portable wearable devices may be smart watches, smart bracelets, head-mounted devices, etc. The head-mounted devices may be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The target server 106 may be an independent physical server, a server cluster or a distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services. Exemplarily, the interface layer 108 and the protocol conversion processor 112 of the protocol conversion system 104 can be deployed on the device of the target server 106, and the event bus 110 and the monitoring and management module 114 can be deployed on an independent server. Through the deployment method of the above-mentioned system components, it can be achieved that even if an abnormality occurs in the server where the event bus 110 is located, as long as the node of the target server 106 is still working normally, the protocol conversion work can still be performed normally by relying only on the interface layer 108 and the protocol conversion processor 112, which effectively improves the availability of the protocol conversion system architecture. It should be understood that the above-mentioned component deployment method is only one of the deployment methods. In addition to the above-mentioned deployment method, other component deployment methods are also included. For example, the interface layer 108 and the protocol conversion processor 112 can also be deployed on multiple independent servers connected to the target server 106 respectively. The specific component deployment method can be flexibly selected according to business needs and application costs, and this application does not specifically limit it.

[0048] In an exemplary embodiment, Figure 2 As shown, a protocol conversion method is provided, which is applied to Figure 1 The protocol conversion system 104 in FIG. 1 is used as an example to illustrate the method, which includes the following steps 202 to 206. Among them:

[0049] Step 202: In response to receiving a first protocol request from a client, convert the first protocol request into a standardized event.

[0050] The first protocol request may be a request message in a set protocol format sent from a client to a target server. It is understandable that the first protocol request may include key request information, which may be used for the conversion of standardized event objects (standardized events) to facilitate subsequent processing. The event content of the standardized event may include the protocol format type of the first protocol request, the target resource to be extracted, the method name of the request call, and the request parameters, etc. Exemplarily, the above event content may be encapsulated in a preset format.

[0051] Specifically, after receiving the first protocol request sent by the client, the interface layer of the protocol conversion system may convert the first protocol request into a standardized event.

[0052] Furthermore, before responding to the step of receiving the first protocol request from the client, the method of this embodiment may further include: identifying a protocol type of the request sent by the client.

[0053] Optionally, the method of this embodiment may further include: performing security verification on the request sent by the client to prevent malicious requests from entering.

[0054] Step 204: based on the standardized event, convert the first protocol request into a second protocol request, and output the second protocol request to the target server; wherein the first protocol request and the second protocol request have different protocol formats.

[0055] It is understandable that the standardized event may include the request key information of the first protocol request, and the above request key information is converted into the protocol format of the second protocol request, so that the conversion of different protocol type requests from the first protocol request to the second protocol request can be realized through the standardized event. The target server may include one or more independent servers capable of processing different types of requests, and the target server can receive and process the second protocol request.

[0056] Specifically, the first protocol request from the client can be converted into a second protocol request that can be processed by the target server through the generated standardized event, and the second protocol request can be pushed to the corresponding target server.

[0057] Exemplarily, when a standardized event is obtained by converting a RESTful protocol request, the conversion from RESTful to JSON-RPC can convert the URL, HTTP method, and request parameters in the standardized event (this is a RESTful event) into the JSON-RPC format; or, when a standardized event is obtained by converting a JSON-RPC protocol request, the conversion from JSON-RPC to RESTful can convert the request call method name and request parameters in the standardized event (this is a JSON-RPC event) into the RESTful format.

[0058] For further explanation, illustratively, taking the standardized event converted from the RESTful protocol request as an example, the standardized event can be {type:"RESTful", resource:" / user",method:"GET", params: {id:123}}. Optionally, the server may also include a protocol conversion processor for converting the standardized event into a second protocol request. Specifically, the protocol conversion processor can convert the above-mentioned standardized event into a JSON-RPC request (second protocol request), and the converted JSON-RPC request can be {"jsonrpc": "2.0", "method": "getUser", "params": {"id": 123}, "id": 1}.

[0059] Step 206: Receive the original response message fed back by the target server in response to the second protocol request, convert the original response message into a target response message in a protocol format matching the first protocol request, and transmit the target response message to the client.

[0060] The target server may process the request message in the protocol format matching the second protocol request, and return the original response message in the protocol format matching the second protocol request. It is understandable that, to match the first protocol request sent by the client, the target response message received by the client must match the protocol format of the first protocol request.

[0061] Specifically, after receiving the original response message fed back by the target server for the second protocol request, the original response message of the target server can be converted into a target response message matching the protocol format of the first protocol request and returned to the client that issued the first protocol request.

[0062] This application can naturally support the expansion of the protocol conversion system by building an event-driven protocol conversion architecture. As the load increases, this application can easily expand the protocol conversion architecture without making large-scale changes to the existing system.

[0063] In one of the embodiments, the first protocol request is a RESTful request, and the second protocol request is a JSON-RPC request; or, the first protocol request is a JSON-RPC request, and the second protocol request is a RESTful request.

[0064] Among them, the RESTful request may include a request message using the RESTful protocol, and the JSON-RPC request may include a request message using the JSON-RPC protocol.

[0065] It is understandable that the RESTful protocol is based on the HTTP protocol, which is easy to integrate into the existing Web architecture and is relatively simple and easy to use in actual application scenarios. In addition, the RESTful protocol also includes a resource-oriented design concept, which naturally supports resource management in distributed systems and can provide a rich error handling mechanism for application systems through HTTP status codes.

[0066] The JSON-RPC protocol has a more compact message format, which is particularly suitable for resource-constrained systems or high-frequency call scenarios. In addition, the JSON-RPC protocol also supports batch processing of requests, which can effectively reduce the delay caused by multiple requests. It should be noted that as an RPC protocol, JSON-RPC also simplifies the process of remote function calls in application scenarios, allowing developers to use it without having to consider the underlying communication details.

[0067] Specifically, after receiving the first protocol request sent by the client, the interface layer of the protocol conversion system can convert the first protocol request into a standardized event.

[0068] In one embodiment, before converting the first protocol request into the second protocol request based on the standardized event, the method includes:

[0069] Through the event bus, the standardized event is transmitted to the corresponding protocol conversion processor according to the event type and event content of the standardized event.

[0070] Among them, the event bus is a communication channel for transmitting events between system components, and can be used to route standardized events to appropriate protocol conversion processors according to the event type and event content of the standardized events to convert between the first protocol request and the second protocol request. Furthermore, the event bus can also realize the function of an event queue, which is used to queue the received events and support priority management to cope with high-concurrency application scenarios. Furthermore, the event bus can also ensure reliability to provide the system with an event mechanism for message persistence and repeated message delivery to ensure that events are not lost. Optionally, this embodiment can implement the event bus through a message queue, a relational database, or the like.

[0071] Specifically, the standardized event generated based on the first protocol request can be transmitted to the protocol conversion processor with corresponding event processing logic through the event bus according to the event type and event content.

[0072] In one embodiment, converting the first protocol request into the second protocol request includes:

[0073] The protocol conversion processor uses corresponding conversion logic according to the event type to convert the first protocol request into the second protocol request.

[0074] The protocol conversion processor may select appropriate protocol conversion logic according to the event type and event content of the standardized event to convert a RESTful request into a JSON-RPC request, or vice versa. Exemplarily, the conversion process of the protocol conversion processor from RESTful to JSON-RPC may include: converting the URL, HTTP method and parameters in the RESTful event into the JSON-RPC format; the conversion process of the protocol conversion processor from JSON-RPC to RESTful may include: converting the method name and parameters in the JSON-RPC event into the RESTful format.

[0075] Specifically, after receiving a standardized event generated based on a first protocol request from the event bus, the standardized event is converted through the corresponding conversion logic of the protocol conversion processor to obtain a second protocol request, thereby realizing the function of converting a RESTful request into a JSON-RPC request.

[0076] For further explanation, for example, the protocol conversion processor receives a RESTful event from the event bus, and the RESTful event is {type: "RESTful", resource: " / user", method: "GET", params: {id: 123}}. The protocol conversion processor can convert the above RESTful event into a JSON-RPC request, and the corresponding request generated is {"jsonrpc": "2.0", "method": "getUser", "params":{"id":123},"id":1}, and push the converted request to the target server for further processing.

[0077] In one embodiment, if Figure 3 As shown, the method also includes:

[0078] Step S302, monitoring the flow of the event flow to which the standardized event belongs and the working state parameters of the protocol conversion processor to obtain monitoring results; the working state parameters include load and delay indicators for protocol conversion;

[0079] Step S304: determine whether to trigger an alarm based on the monitoring result.

[0080] It is understandable that if one or more clients can send multiple first protocol requests, multiple standardized events may appear in the protocol conversion system. The embodiment of the present application can manage the generated standardized events through the event stream, so that the flow of the event stream to which the standardized event belongs and the working state parameters of the protocol conversion processor can be monitored, thereby realizing event management of multiple standardized events and improving the efficiency and stability of system operation.

[0081] Specifically, the traffic of the event flow to which the standardized event belongs and the working status parameters of the protocol conversion processor can be monitored. If it is determined based on the monitoring results that the system is abnormal, an alarm is automatically triggered, and fault isolation and recovery operations are performed.

[0082] Optionally, the traffic of the event stream to which the standardized event belongs and the working status parameters of the protocol conversion processor can be monitored through the monitoring and management module deployed on an independent server. Specifically, through the monitoring and management module, the priority and processing strategy of each standardized event processing can be dynamically adjusted according to real-time data, so as to adapt to different business needs and make rapid responses and adjustments under peak load or other abnormal conditions.

[0083] Furthermore, the monitoring and management module can be used to configure the address of the target server, access credentials, and the request format that the target server can receive; and can also be used to detect whether the target server is online. Exemplarily, if it is detected that the target server is online, a message is sent to the event bus, so that the target server can subscribe to the first protocol request event in the event bus, and the corresponding request format that the target server can receive is recorded in the event bus.

[0084] In one embodiment, the method further comprises:

[0085] Dynamically adjust the priority of event flows based on business needs.

[0086] Among them, the priority of the event stream can represent the criticality of the request sent by the client.

[0087] Specifically, by dynamically adjusting the priority of the event stream, the priority of standardized events is dynamically adjusted according to business needs, thereby ensuring that key requests sent by the client can be processed first.

[0088] In one embodiment, in response to receiving a first protocol request from a client, converting the first protocol request into a standardized event includes:

[0089] The interface layer extracts key information of the first protocol request and encapsulates the key information into a standardized event object.

[0090] The interface layer can receive the first protocol request from the client and convert it into a standardized event. The key information of the first protocol request can include URL, protocol parameters, HTTP method, protocol method name, etc. These key information can be used to encapsulate into a standardized event object to facilitate subsequent processing.

[0091] Specifically, after receiving the first protocol request from the client, the interface layer may extract key information in the first protocol request to further encapsulate the key information into a standardized event object (standardized event).

[0092] For further explanation, illustratively, taking the first protocol request sent by the client as a RESTful request, the RESTful request may include "GET / user? Id=123". The interface layer may identify the request sent by the client. If the interface layer identifies that the request sent by the client is a RESTful request, the key request information in the RESTful request is extracted. Based on the key request information in the RESTful request, the interface layer generates a corresponding standardized event object such as {type:"RESTful",resource:" / user",method:"GET",params:{id:123}}.

[0093] In one embodiment, if Figure 4 As shown, converting the original response message into a target response message in a protocol format matching the first protocol request includes:

[0094] Step S402, the protocol conversion processor converts the original response message into an original response event in a protocol format matching the second protocol request;

[0095] Step S404: The original response event is transmitted to the interface layer through the event bus, and the interface layer converts the original response event into a target response message in a protocol format matching the first protocol request.

[0096] It can be understood that the original response message is a response in a protocol format matching the second protocol request returned by the target server, and the original response message can be converted into an original response event in a protocol format matching the second protocol request by the protocol conversion processor. The event bus can be used to transmit the original response message to the interface layer, and the interface layer can convert the original response message in a protocol format matching the second protocol request into a target response message based on the protocol format of the first protocol request.

[0097] Specifically, the original response message returned by the target server for the second protocol request can be converted into an original response event through the protocol conversion processor, and then the original response event can be transmitted to the interface layer through the event bus. The interface layer converts the original response event into a target response message matching the protocol format of the first protocol request, so as to return the target response message to the client.

[0098] In some exemplary embodiments, the interface layer may also include a request access layer and a response processing layer; wherein the request access layer can be used to receive RESTful or JSON-RPC requests from the client and convert them into standardized events; the response processing layer can be used to receive response events from the target server and convert them into a response format recognizable by the client.

[0099] The response format recognizable by the client may match the protocol format of the first protocol request sent by the client. It should be understood that the response processing layer in the interface layer may also be used to generate an appropriate HTTP status code or JSON-RPC error code according to the status code of the request or the response content.

[0100] In an exemplary embodiment, in order to make the purpose, technical solution and advantages of the present application more clear, as shown in FIG. Figure 5 As shown, the present application is further described in detail by taking a client sending a RESTful request as an example. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0101] Among them, in this embodiment, the client, interface layer, event bus, protocol conversion processor, monitoring and management module and target server can be deployed on different independent servers respectively, wherein the target server is a JSON-RPC server that processes JSON-RPC requests. It can be understood that the above-mentioned component deployment method is another component deployment method. In addition to the above-mentioned embodiment, other component deployment methods can also be used.

[0102] See also Figure 5As shown in the timing diagram, in the architecture constructed in this embodiment, the target server is first configured on the monitoring and management module, including configuring the address of the target server, access credentials, and request events that the target server can process. If the monitoring and management module detects that the target server is online, a subscription message is sent to the event bus, so that the JSON-RPC server subscribes to the first protocol request event that it can process on the event bus, and records the corresponding request format that the target server can receive in the event bus. If the subscription is successful, the event bus can return a successful subscription message to the monitoring and management module.

[0103] In response to a RESTful request sent by the client, the request can be identified and received by the interface layer. After receiving the RESTful request, the interface layer can perform basic security verification on the request and convert the RESTful request into a standardized event (standardized event object) after the verification is completed.

[0104] The interface layer can push the generated standardized events to the event bus, and subscribe to the event ID corresponding to the standardized event on the event bus for the interface layer, so that when the subsequent event bus obtains the corresponding response event, it can push the response event to the corresponding interface layer based on the event ID, thereby improving the efficiency and accuracy of message push.

[0105] After receiving the standardized event, the event bus searches for the target server that has subscribed to the request event on the event bus, and learns the specific target server that has subscribed to the standardized event and the request protocol format that it can process. After the event bus completes the search and positioning of the target server, it can determine that the protocol conversion processor including the conversion logic between RESTful and JSON-RPC needs to be called later. The event bus pushes the standardized event and the address of the JSON-RPC server (target server) to the above-mentioned protocol conversion processor.

[0106] After receiving the standardized event and the address of the JSON-RPC server (target server), the protocol conversion processor converts the standardized event into a JSON-RPC request and pushes it to the JSON-RPC server corresponding to the address. The JSON-RPC server returns the corresponding JSON-RPC response message to the protocol conversion processor based on the content of the JSON-RPC request.

[0107] After receiving the JSON-RPC response message returned from the JSON-RPC server, the protocol conversion processor can convert it into a corresponding JSON-RPC response event, and push the converted JSON-RPC response event to the event bus.

[0108] After receiving the JSON-RPC response event, the event bus searches for the interface layer that has subscribed to the event ID of the response event and pushes the JSON-RPC response event to the interface layer.

[0109] After receiving the JSON-RPC response event from the event bus, the interface layer converts the JSON-RPC response event into a RESTful response message and cancels the subscription to the response event. After converting to obtain the required RESTful response message, the interface layer returns the RESTful response message to the client.

[0110] It should be understood that the above embodiment is only an exemplary implementation of the present application. The components can also be deployed in other ways. The request sent by the client can also be a JSON-RPC request, and the target server can also be a RESTful server. The present application does not make specific limitations on this.

[0111] Based on the protocol conversion method of the present application, an event-driven architecture can be constructed. The event-driven architecture naturally supports expansion, and can also use standard interfaces to enable each component to be seamlessly integrated with existing microservices, API gateways or other application systems, making the architecture easily integrated into existing distributed systems. The event-driven architecture can be quickly deployed and expanded based on containerization technology (such as Docker, Kubernetes). As the system load increases, the event-driven architecture can easily add more protocol conversion processors or expand the capacity of the event bus to improve the load capacity of the event-driven architecture.

[0112] It should be noted that, since the event bus used in this application has the decoupling feature, the event-driven architecture does not require large-scale changes to the existing system when a new processor is added, effectively reducing the difficulty of system expansion.

[0113] Furthermore, the present application can support asynchronous processing by adopting an event bus. Therefore, in a high-concurrency application scenario, the protocol conversion system built on an event-driven architecture can still ensure that the requests sent by the client will not be lost, and can complete the processing even when the load is low, thereby improving the overall throughput of the system.

[0114] In addition, the above-mentioned components involved in this application have a modular design. For example, the request access layer, protocol conversion processor, response processing layer, etc. can be independently developed and maintained, which not only speeds up the development speed of the system, but also reduces the maintenance cost of the system. Therefore, when the system is upgraded or new functions need to be introduced, only the relevant module components can be updated without large-scale reconstruction of the entire system.

[0115] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0116] Based on the same inventive concept, the embodiment of the present application also provides a protocol conversion device for implementing the above-mentioned protocol conversion method. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above-mentioned method, so the specific limitations in the one or more protocol conversion device embodiments provided below can refer to the limitations on the protocol conversion method above, and will not be repeated here.

[0117] In an exemplary embodiment, Figure 6 As shown, a protocol conversion device 600 is provided, and the device 600 includes:

[0118] A standardized event conversion module 602, configured to convert the first protocol request into a standardized event in response to receiving the first protocol request from the client;

[0119] The protocol request conversion and output module 604 is used to convert the first protocol request into a second protocol request based on the standardized event, and output the second protocol request to the target server; wherein the first protocol request and the second protocol request have different protocol formats;

[0120] The response message conversion and transmission module 606 is used to receive the response message fed back by the target server in response to the second protocol request, convert the response message into a response message in a protocol format matching the first protocol request, and then transmit it to the client.

[0121] In one embodiment, the first protocol request is a RESTful request, and the second protocol request is a JSON-RPC request; or, the first protocol request is a JSON-RPC request, and the second protocol request is a RESTful request.

[0122] In one embodiment, the apparatus 600 further includes:

[0123] The event bus transmission module is used to transmit the standardized event to the corresponding protocol conversion processor through the event bus according to the event type and event content of the standardized event.

[0124] In one embodiment, the protocol request conversion and output module 604 is further configured to convert the first protocol request into the second protocol request by the protocol conversion processor using corresponding conversion logic according to the event type.

[0125] In one embodiment, the apparatus 600 further includes:

[0126] An event monitoring module is used to monitor the flow of the event stream to which the standardized event belongs and the working status parameters of the protocol conversion processor to obtain monitoring results; the working status parameters include load and delay indicators for protocol conversion;

[0127] The alarm module is used to determine whether to trigger an alarm based on the monitoring results.

[0128] In one embodiment, the apparatus 600 further includes:

[0129] The priority adjustment module is used to dynamically adjust the priority of the event stream according to business needs.

[0130] In one embodiment, the standardized event conversion module 602 is further configured to extract key information of the first protocol request from the interface layer, and encapsulate the key information into a standardized event object.

[0131] In one embodiment, the response message conversion and transmission module 606 is also used to convert the original response message into an original response event in a protocol format that matches the second protocol request by a protocol conversion processor; transmit the original response event to the interface layer through the event bus, and the interface layer converts the original response event into a target response message in a protocol format that matches the first protocol request.

[0132] Each module in the above-mentioned protocol conversion device can be implemented in whole or in part by software, hardware and a combination thereof. Each of the above-mentioned modules can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each of the above modules.

[0133] In an exemplary embodiment, a client is provided. For example, the client may be a computer device, and the computer device may be a terminal. The internal structure diagram thereof may be as shown in FIG. Figure 7As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NearField Communication, NFC) or other technologies. When the computer program is executed by the processor, a protocol conversion method is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0134] In an exemplary embodiment, a target server is provided. Exemplarily, the target server may be a computer device, and the computer device may be a server. The internal structure diagram thereof may be as shown in FIG. Figure 8 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device can be used to store second protocol request data and response message data corresponding to the target server, etc. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a protocol conversion method can be implemented.

[0135] Those skilled in the art will understand that Figure 7 and Figure 8The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0136] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the steps of the method described in any one of the above embodiments are implemented.

[0137] In an exemplary embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0138] In one embodiment, a computer program product is provided, including a computer program, which implements the steps of the method described in any one of the above embodiments when executed by a processor.

[0139] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0140] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0141] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A protocol conversion method, characterized in that: The method comprises: In response to receiving a first protocol request from a client, converting the first protocol request into a standardized event; Based on the standardized event, converting the first protocol request into a second protocol request, and outputting the second protocol request to a target server; wherein the first protocol request and the second protocol request have different protocol formats; An original response message fed back by the target server in response to the second protocol request is received, the original response message is converted into a target response message having a protocol format matching the first protocol request, and then transmitted to the client.

2. The method according to claim 1, characterized in that The first protocol request is a RESTful request, and the second protocol request is a JSON-RPC request; or, the first protocol request is a JSON-RPC request, and the second protocol request is a RESTful request.

3. The method according to claim 1, characterized in that Before the step of converting the first protocol request into a second protocol request based on the standardized event, the method includes: The standardized event is transmitted to the corresponding protocol conversion processor through the event bus according to the event type and event content of the standardized event.

4. The method according to claim 3, characterized in that The converting the first protocol request into a second protocol request comprises: The protocol conversion processor adopts corresponding conversion logic according to the event type to convert the first protocol request into the second protocol request.

5. The method according to claim 3, characterized in that: The method further comprises: Monitoring the flow of the event stream to which the standardized event belongs and the working state parameters of the protocol conversion processor to obtain monitoring results; the working state parameters include load and delay indicators for protocol conversion; Based on the monitoring result, determine whether to trigger an alarm.

6. The method according to claim 5, characterized in that The method further comprises: The priority of the event stream is dynamically adjusted according to business requirements.

7. The method according to any one of claims 1 to 6, characterized in that: In response to receiving a first protocol request from a client, converting the first protocol request into a standardized event comprises: The interface layer extracts key information of the first protocol request and encapsulates the key information into a standardized event object.

8. The method according to any one of claims 1 to 6, characterized in that: The converting the original response message into a target response message in a protocol format matching the first protocol request includes: The protocol conversion processor converts the original response message into an original response event in a protocol format matching the second protocol request; The original response event is transmitted to the interface layer through the event bus, and the interface layer converts the original response event into a target response message in a protocol format matching the first protocol request.

9. A protocol conversion device, characterized in that: The device comprises: A standardized event conversion module, configured to, in response to receiving a first protocol request from a client, convert the first protocol request into a standardized event; A protocol request conversion and output module, used to convert the first protocol request into a second protocol request based on the standardized event, and output the second protocol request to a target server; wherein the first protocol request and the second protocol request have different protocol formats; The response message conversion and transmission module is used to receive the original response message fed back by the target server in response to the second protocol request, convert the original response message into a target response message matching the protocol format of the first protocol request, and then transmit it to the client.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images