A method, apparatus, device, and medium for cross-protocol interaction between services.

Abstract

This application relates to the field of data processing technology, specifically to a method, apparatus, device, and medium for cross-protocol interaction between services, used to solve the problem that existing cross-protocol service communication schemes cannot achieve direct communication interaction between services. The method includes: starting two ports to listen for a first protocol request message and a second protocol request message respectively; when a second protocol request message is received, determining whether the service in the second protocol request message is related to a first service or to the second service; if the service in the second protocol request message is related to the first service, then using a first preset protocol message converter to convert the second protocol request message into a first protocol message; and calling the first service to process the first protocol message. Based on the above method, direct communication between services across programming languages ​​and communication protocols can be achieved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method, apparatus, device, and medium for cross-protocol interaction between services. Background Technology

[0002] Inter-service communication refers to the process of communication between multiple independently running services in a distributed system or microservice architecture. These services may need to share data and collaborate to complete more complex business processes. Service interaction can utilize various protocols, such as HTTP / HTTPS (Hypertext Transfer Protocol), RPC (Remote Procedure Call), MQ (Message Queue), and event-driven architecture. Generally, services should use a unified communication protocol for interaction.

[0003] However, in real-world business scenarios, there may be situations where two services use different protocols or even different programming languages. For example, one service might use the standard HTTP protocol, similar to a typical web service, while another service might use a custom TCP (Transmission Control Protocol) for message communication. Due to differences in communication protocols and programming languages, these two services cannot directly communicate and interact.

[0004] Existing inter-service communication solutions generally require both service parties to use a unified message protocol for interaction. This necessitates both parties first defining unified interfaces and objects, then writing and generating corresponding interaction files according to their respective programming language syntax, and finally using the same protocol as the other party for interaction. However, these solutions do not adequately support direct interaction between two existing services using different protocols, requiring extensive adaptation and modification of the original services, resulting in a significant waste of time and resources. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for cross-protocol interaction between services, which solves the problem that existing cross-protocol service communication schemes cannot achieve direct communication and interaction between services.

[0006] In a first aspect, this application provides a method for cross-protocol interaction between services, the method comprising:

[0007] Start two ports to listen for the first protocol request message and the second protocol request message respectively;

[0008] When the second protocol request message is received, it is determined whether the service in the second protocol request message is related to the first service or the second service. The first service uses the first protocol for communication, and the second service uses the second protocol for communication.

[0009] If the service in the second protocol request message is related to the first service, then the second protocol request message is converted into a first protocol message using a first preset protocol message converter;

[0010] The first service is invoked to process the first protocol message.

[0011] In a service process on the server side, two different ports are started to listen for the first protocol request message and the second protocol request message respectively. A custom protocol message converter is used to realize the mutual conversion between the two different protocol messages. It supports the direct processing of requests using different protocols after conversion or outbound calls to other servers for processing, realizing communication and interaction between cross-protocol services.

[0012] In one possible embodiment, starting two ports to listen for a first protocol request message and a second protocol request message respectively includes: creating a first thread to receive and process the first protocol request message, and starting a first port to listen for the first thread, wherein the first thread is used to call the first service; creating a second thread to receive and process the second protocol request message, and starting a second port to listen for the second thread, wherein the second thread is used to call the second service, and the first thread and the second thread belong to the same process.

[0013] In one possible embodiment, the step of creating a second thread to receive and process the second protocol request message and starting a second port to listen to the second thread includes: creating a connection establishment loop thread and a selector corresponding to the connection establishment loop thread; creating an event loop processing thread group and binding the event loop processing thread group to the selector; and starting the second port to listen to the connection establishment loop thread.

[0014] By adopting I / O multiplexing mode to receive and process the second protocol request, the concurrent processing capability is improved.

[0015] In one possible embodiment, the format of the second protocol request message is as follows: the first four bytes of the second protocol request message are the message body length, the fifth and sixth bytes are the request type, and the seventh byte and all subsequent bytes are the request body.

[0016] A custom TCP protocol message format was used to solve the problem of packet splitting and reassembly that may occur during TCP transmission.

[0017] In one possible embodiment, the step of converting the second protocol request message into a first protocol message using a first preset protocol message converter includes: parsing the first four bytes of the second protocol request message to obtain the message body length of the second protocol request message; obtaining the request body of the second protocol request message based on the message body length; obfuscating and decrypting the request body and performing Bson deserialization to obtain a Bson object; converting the Bson object into a JSON object; and generating the first protocol message based on the JSON object.

[0018] In one possible embodiment, after the first service is invoked to process the first protocol message, the method further includes: determining whether the processing result of the first protocol message needs to be fed back to the external server or client that sent the second protocol request message; if the processing result needs to be fed back to the external server or client that sent the second protocol request message, then the processing result is converted into a second protocol message using a second preset protocol message converter; and the second protocol message is sent to the external server or client.

[0019] In one possible embodiment, the step of using a second preset protocol message converter to convert the processing result into a second protocol message includes: performing Bson compression and encoding on the processing result to obtain the request body corresponding to the processing result and the length of the request body; and assembling the text length, the request type of the processing result, and the request body to obtain the second protocol message.

[0020] Secondly, this application provides an apparatus for cross-protocol interaction between services, the apparatus comprising:

[0021] The listening module starts two ports to listen for the first protocol request message and the second protocol request message respectively;

[0022] The judgment module, upon receiving the second protocol request message, determines whether the service in the second protocol request message is related to the first service or the second service, wherein the first service uses the first protocol for communication and the second service uses the second protocol for communication.

[0023] The conversion module, if the service in the second protocol request message is related to the first service, uses a first preset protocol message converter to convert the second protocol request message into a first protocol message;

[0024] The processing module calls the first service to process the first protocol message.

[0025] In one possible embodiment, the listening module is specifically configured to: create a first thread for receiving and processing the first protocol request message, and start a first port to listen to the first thread, wherein the first thread is used to call the first service; create a second thread for receiving and processing the second protocol request message, and start a second port to listen to the second thread, wherein the second thread is used to call the second service, and the first thread and the second thread belong to the same process.

[0026] In one possible embodiment, the listening module is further configured to: create a connection establishment loop thread and a selector corresponding to the connection establishment loop thread; create an event loop processing thread group and bind the event loop processing thread group to the selector; and start the second port to listen to the connection establishment loop thread.

[0027] In one possible embodiment, the format of the second protocol request message is as follows: the first four bytes of the second protocol request message are the message body length, the fifth and sixth bytes are the request type, and the seventh byte and all subsequent bytes are the request body.

[0028] In one possible embodiment, the conversion module is specifically configured to: parse the first four bytes of the second protocol request message to obtain the message body length of the second protocol request message; obtain the request body of the second protocol request message based on the message body length; obfuscate and decrypt the request body and perform Bson deserialization to obtain a Bson object; convert the Bson object into a JSON object, and generate the first protocol message based on the JSON object.

[0029] In one possible embodiment, the device is further configured to: determine whether the processing result of the first protocol message needs to be fed back to the external server or client that sent the second protocol request message; if the processing result needs to be fed back to the external server or client that sent the second protocol request message, then use a second preset protocol message converter to convert the processing result into a second protocol message; and send the second protocol message to the external server or client.

[0030] In one possible embodiment, the apparatus is further configured to: compress and encode the processing result using Bson to obtain the request body corresponding to the processing result and the length of the request body; and assemble the text length, the request type of the processing result, and the request body to obtain the second protocol message.

[0031] Thirdly, this application provides an electronic device, comprising:

[0032] Memory, used to store program instructions;

[0033] A processor is configured to invoke program instructions stored in the memory and execute the steps of the method described in any one of the first aspects according to the obtained program instructions.

[0034] Fourthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in any one of the first aspects.

[0035] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects. Attached Figure Description

[0036] Figure 1 A flowchart illustrating a method for cross-protocol interaction between services provided in this application embodiment;

[0037] Figure 2 This is a schematic diagram of the structure of a web server provided in an embodiment of this application;

[0038] Figure 3 This application provides a schematic diagram of the structure of an RPC request processing server according to an embodiment of the present application.

[0039] Figure 4 A schematic diagram illustrating a custom TCP packet format provided in an embodiment of this application;

[0040] Figure 5 A schematic diagram of an apparatus for cross-protocol interaction between services provided in an embodiment of this application;

[0041] Figure 6 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0043] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0044] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0045] The acquisition, transmission, storage, and use of data in this application all comply with the requirements of relevant national laws and regulations.

[0046] To facilitate a better understanding of the technical solutions provided in the embodiments of this application by those skilled in the art, the following is a brief explanation of the relevant technical terms:

[0047] Socket communication is a concept in network programming that provides a method for establishing and maintaining connections between two computers on a network. The socket interface allows programmers to create and manage inter-process network communication endpoints, called sockets, which can be used to transmit data packets.

[0048] I / O multiplexing is a technique that manages multiple I / O operations simultaneously within a single process or thread. It allows a program to wait for multiple file descriptors (or sockets), and the system notifies the program when any descriptor is ready for reading or writing, without polling each descriptor individually. This approach can more efficiently utilize system resources and improve server concurrency performance.

[0049] Java NIO (Non-Blocking I / O) is a new feature introduced in Java 1.4, extending the standard Java IO API. In traditional Java IO, read and write operations are blocking, meaning that when a thread performs a read or write operation, it will be blocked if the data is not ready until it is. This can become a performance bottleneck when handling high-concurrency I / O operations. Java NIO provides concepts such as selectors, channels, and buffers, allowing programs to handle multiple connections simultaneously, thus improving system concurrency. It supports buffered, non-blocking I / O operations, allowing data to be read from and written to multiple streams simultaneously without creating a separate thread for each stream.

[0050] Before introducing a method for cross-protocol interaction between services provided in the embodiments of this application, the technical background of the embodiments of this application will be described in detail below for ease of understanding.

[0051] Currently, most business support platforms contain multiple servers using different communication protocols. For example, a business support platform might have multiple web microservices developed in Java that communicate via HTTP, as well as some RPC server and client software developed in C++ that communicate via TCP. Because these services use different communication protocols and have different message formats, inter-service communication is not possible.

[0052] Most existing cross-language, cross-protocol service communication solutions use message middleware or files for interaction, requiring extensive modifications and adaptations to existing services. They cannot achieve direct communication between services, consuming a significant amount of time and resources.

[0053] To address the aforementioned issues, this application provides a method for cross-protocol interaction between services. This method involves starting a port within a service process to listen for and process HTTP requests. Based on Socket communication, a thread is created within the original service to receive and process RPC requests, and a port is bound to receive related requests. This service simultaneously supports processing HTTP requests from browsers and web services, as well as requests from TCP server and client software, adapting to various external services and software. Through a custom protocol message converter, it supports the conversion between standard HTTP protocol messages and various custom TCP protocol messages. Furthermore, it supports directly processing converted requests using different communication protocols or calling other types of servers for processing and returning the processing results. This method achieves direct inter-service communication across programming languages ​​and communication protocols.

[0054] The solutions provided in this application are applicable to most cross-protocol communication scenarios between different services, and are not limited to the communication interaction between a web service using the HTTP protocol and an RPC service using the TCP protocol described above. The above communication scenarios are merely illustrative examples and not intended to limit the scope of this application. In specific implementation, the technical solutions provided in this application can be flexibly applied according to actual needs.

[0055] The method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings. See also: Figure 1 The diagram shown is a flowchart illustrating a method for cross-protocol interaction between services provided in this application embodiment. This method is applied to the server side, and the specific implementation process of the method is as follows:

[0056] Step 101: Start two ports to listen for the first protocol request message and the second protocol request message respectively;

[0057] In this embodiment of the application, the first protocol may be, but is not limited to, the HTTP protocol, and the second protocol may be, but is not limited to, the TCP protocol.

[0058] Specifically, within a service process, a first thread is created to receive and process a first protocol request message, and a first port is started to listen for the first thread. This first thread is used to call the first service. Simultaneously, a second thread is created to receive and process a second protocol request message, and a second port is started to listen for the second thread. This second thread is used to call the second service. The first service uses the first protocol for communication, and the second service uses the second protocol for communication. The first service and the second service can be internal services of the server applied by this method, or services provided by an external server.

[0059] The internal services of the server can include web services and RPC services. The specific construction process of this server is as follows:

[0060] First, build a typical web server application, using Tomcat as the built-in server, binding it to the first port to listen for and handle HTTP requests. The structure of the web server is as follows. Figure 2 As shown, the first service is provided based on this web server.

[0061] Then, a second thread is started in the web service, binding to a second port to listen for and process TCP request packets. Simultaneously, I / O multiplexing can be used, leveraging Java NIO's Selector and Channel functions to receive and process TCP request packets, significantly improving concurrency capabilities.

[0062] An RPC request processing server is created based on I / O multiplexing mode, and its structure is as follows: Figure 3 As shown, specifically, a connection establishment loop thread and its corresponding Selector are created to receive and process connection events (OP_ACCEPT) from clients or external servers. An event loop processing thread group is created to handle specific requests. This thread group is bound to the Selector. Specifically, whenever a new client establishes a connection, a new Channel is created and registered with the Selector for listening. Whenever I / O is ready on a Channel, the event loop processing thread triggers subsequent processing based on the bound Selector, handling the request and returning the result. A second port is started to listen for the connection establishment loop thread.

[0063] Based on I / O multiplexing technology, an asynchronous, non-blocking I / O model is used to build an RPC request processing server. Through an event-driven approach, the server can efficiently handle concurrent connections and a large number of requests.

[0064] By building a web service on one server and then creating an RPC service in a separate thread within that web service, the server can simultaneously handle HTTP requests from browsers and web services, as well as TCP requests from TCP services and client software, thus adapting to a variety of external services and software.

[0065] Step 102: When a second protocol request message is received, determine whether the service in the second protocol request message is related to the first service or the second service;

[0066] In this embodiment, when the second protocol request message is a TCP message, it can originate from an external client or a TCP server. When the second port detects the second protocol request message, it receives the message and determines whether the service in the message is related to the first service or the second service.

[0067] In one possible implementation, if the business in the second protocol request message is related to the second service, the internal RPC server is directly invoked for processing, or the second protocol request message is forwarded to other external RPC servers for processing.

[0068] In one possible implementation, if the service in the second protocol request message is related to the first service, then the following step 103 is performed.

[0069] Step 103: If the service in the second protocol request message is related to the first service, then the second protocol request message is converted into a first protocol message using the first preset protocol message converter;

[0070] In this embodiment of the application, the first preset protocol message converter is a custom message converter used to convert different protocol messages.

[0071] When converting a second protocol request message into a first protocol message using a first preset protocol message converter, it is necessary to obtain the complete request body of the second protocol request message. When the second protocol request message is a TCP message, due to the single transmission limitation of TCP messages, a single request may be sent in multiple parts. To ensure that the complete request is obtained before processing, multiple request messages need to be merged. Therefore, a message format is defined, such as... Figure 4 The image shows a custom TCP packet format. The first four bytes represent the packet length, the next two bytes (the fifth and sixth bytes) represent the request type, and the seventh byte and all subsequent bytes represent the request body. The request type is an internally defined type, such as 1-RPC request, 2-data subscription request, etc.

[0072] By defining a custom, unified TCP packet format standard, the problem of packet splitting and reassembly that may occur during TCP transmission can be resolved.

[0073] Specifically, the process of converting the second protocol request message into a first protocol message using the first preset protocol message converter is as follows:

[0074] Parse the first four bytes of the second protocol request message to obtain the complete message body length. Based on this message body length, continuously read data from the Socket stream to obtain the complete request body of the second protocol request message. After confirming that complete message data has been received, obfuscate and decrypt the message body and deserialize it using Bson, converting it into a Bson object. Then, by implementing BsonConvert, convert the Bson object into a JSON object, and generate the first protocol message, i.e., the HTTP message, based on the JSON object.

[0075] By using a custom protocol message converter, it supports the conversion between standard HTTP protocol messages and various custom TCP protocol messages, thereby enabling direct communication between services across programming languages ​​and communication protocols.

[0076] Step 104: Call the first service to process the first protocol message.

[0077] Specifically, after converting the second protocol request message into a first protocol message, the first service is invoked to process the first protocol message. The first service can be an internal service of the server applied by this method, i.e., an internally built web service, or a service provided by an external server.

[0078] Furthermore, after processing the first protocol message using the first service, it is determined whether the processing result of the first protocol message needs to be fed back to the external server or client that sent the second protocol request message. For example, if the request in the second protocol request message is a write request, then it is not necessary to feed back the processing result to the external server or client that sent the second protocol request message; if the request in the second protocol request message is a read request, then it is necessary to feed back the processing result to the external server or client that sent the second protocol request message. Whether or not a processing result needs to be fed back can be determined by parsing the request type in the second protocol request message. It is worth noting that the method for determining whether or not a processing result needs to be fed back is not limited to parsing the request type.

[0079] In one possible implementation, if the processing result needs to be fed back to the external server or client that sent the second protocol request message, the processing result is converted into a second protocol message using a second preset protocol message converter, and the second protocol message is sent to the external server or client.

[0080] Specifically, the process of converting the processing result into a second protocol message using a second preset protocol message converter is as follows:

[0081] The processing result is compressed and encoded using Bson to obtain the request body and its length. The length, the request type, and the request body are then assembled to obtain the second protocol message.

[0082] This application enables direct communication between services by starting a port within a service process to listen for and process HTTP requests. Based on Socket communication, a thread for receiving and processing RPC requests is created within the original service, and a port is bound to receive related requests. This service simultaneously supports processing HTTP requests from browsers and web services, as well as requests from TCP server and client software, adapting to various external services and software. Through a custom protocol message converter, it supports the conversion between standard HTTP protocol messages and various custom TCP protocol messages, and supports the direct processing of requests using different communication protocols after conversion, or outbound calls to other types of servers for processing and return of processing results, realizing direct communication between services across programming languages ​​and communication protocols.

[0083] Based on the same inventive concept, embodiments of this application provide a device for cross-protocol interaction between services. Please refer to... Figure 5 The device includes:

[0084] The listening module 501 starts two ports to listen for the first protocol request message and the second protocol request message respectively.

[0085] The judgment module 502, when receiving the second protocol request message, determines whether the service in the second protocol request message is related to the first service or the second service, wherein the first service uses the first protocol for communication and the second service uses the second protocol for communication;

[0086] The conversion module 503, if the service in the second protocol request message is related to the first service, uses a first preset protocol message converter to convert the second protocol request message into a first protocol message;

[0087] Processing module 504 calls the first service to process the first protocol message.

[0088] In one possible embodiment, the listening module 501 is specifically configured to: create a first thread for receiving and processing the first protocol request message, and start a first port to listen to the first thread, wherein the first thread is used to call the first service; create a second thread for receiving and processing the second protocol request message, and start a second port to listen to the second thread, wherein the second thread is used to call the second service, and the first thread and the second thread belong to the same process.

[0089] In one possible embodiment, the listening module 501 is further configured to: create a connection establishment loop thread and a selector corresponding to the connection establishment loop thread; create an event loop processing thread group and bind the event loop processing thread group to the selector; and start the second port to listen to the connection establishment loop thread.

[0090] In one possible embodiment, the format of the second protocol request message is as follows: the first four bytes of the second protocol request message are the message body length, the fifth and sixth bytes are the request type, and the seventh byte and all subsequent bytes are the request body.

[0091] In one possible embodiment, the conversion module 503 is specifically configured to: parse the first four bytes of the second protocol request message to obtain the message body length of the second protocol request message; obtain the request body of the second protocol request message according to the message body length; obfuscate and decrypt the request body and perform Bson deserialization to obtain a Bson object; convert the Bson object into a JSON object, and generate the first protocol message based on the JSON object.

[0092] In one possible embodiment, the device is further configured to: determine whether the processing result of the first protocol message needs to be fed back to the external server or client that sent the second protocol request message; if the processing result needs to be fed back to the external server or client that sent the second protocol request message, then use a second preset protocol message converter to convert the processing result into a second protocol message; and send the second protocol message to the external server or client.

[0093] In one possible embodiment, the apparatus is further configured to: compress and encode the processing result using Bson to obtain the request body corresponding to the processing result and the length of the request body; and assemble the text length, the request type of the processing result, and the request body to obtain the second protocol message.

[0094] Based on the same inventive concept, this application also provides an electronic device that can realize the function of the aforementioned device for cross-protocol interaction between services. (Refer to...) Figure 6 The electronic device includes:

[0095] At least one processor 601 and a memory 602 connected to at least one processor 601. In this embodiment, the specific connection medium between the processor 601 and the memory 602 is not limited. Figure 6 The example shown is the connection between processor 601 and memory 602 via bus 600. Bus 600 is... Figure 6 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The 600 bus can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 6 The term is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, the processor 601 can also be called a controller; there is no restriction on the name.

[0096] In this embodiment, memory 602 stores instructions executable by at least one processor 601. By executing the instructions stored in memory 602, at least one processor 601 can perform the inter-service cross-protocol interaction method described above. Processor 601 can implement... Figure 5 The functions of each module in the device shown.

[0097] The processor 601 is the control center of the device. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 602 and calling data stored in memory 602, the processor can perform various functions and process data, thereby monitoring the device as a whole.

[0098] In one possible design, processor 601 may include one or more processing units. Processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 601. In some embodiments, processor 601 and memory 602 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0099] Processor 601 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the inter-service cross-protocol interaction method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0100] Memory 602, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 602 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 602 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 602 may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0101] By designing and programming the processor 601, the code corresponding to the inter-service cross-protocol interaction method described in the foregoing embodiments can be embedded into the chip, thereby enabling the chip to execute the code during runtime. Figure 1The steps of the method for cross-protocol interaction between services in the illustrated embodiment are described below. How to design and program the processor 601 is a technique well-known to those skilled in the art and will not be elaborated upon here.

[0102] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium. The computer program product includes computer program code, which, when executed on a computer, causes the computer to perform any of the inter-service cross-protocol interaction methods discussed above. Since the principle by which the above-described computer-readable storage medium solves the problem is similar to that of the inter-service cross-protocol interaction method, the implementation of the above-described computer-readable storage medium can be found in the implementation of the method; repeated details will not be elaborated further.

[0103] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the inter-service cross-protocol interaction methods discussed above. Since the principle by which the above-described computer program product solves the problem is similar to that of the inter-service cross-protocol interaction method, the implementation of the above-described computer program product can refer to the implementation of the method, and repeated details will not be elaborated further.

[0104] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can 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, etc.) containing computer-usable program code.

[0105] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0106] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0107] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of user-operated steps to be executed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0108] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for cross-protocol interaction between services, characterized in that, The method is applied to the server side, and the method includes: Start two ports to listen for the first protocol request message and the second protocol request message respectively; When the second protocol request message is received, it is determined whether the service in the second protocol request message is related to the first service or the second service. The first service uses the first protocol for communication, and the second service uses the second protocol for communication. If the service in the second protocol request message is related to the first service, then a first preset protocol message converter is used to convert the second protocol request message into a first protocol message. The first preset protocol message converter is used to parse the first four bytes of the second protocol request message to obtain the message body length of the second protocol request message; based on the message body length, obtain the request body of the second protocol request message; obfuscate and decrypt the request body and perform Bson deserialization to obtain a Bson object; convert the Bson object into a JSON object, and generate the first protocol message based on the JSON object. The first service is invoked to process the first protocol message.

2. The method as described in claim 1, characterized in that, The process of starting two ports to listen for the first protocol request message and the second protocol request message respectively includes: A first thread is created to receive and process the first protocol request message, and a first port is started to listen for the first thread, wherein the first thread is used to call the first service; A second thread is created to receive and process the second protocol request message, and a second port is started to listen for the second thread. The second thread is used to call the second service, and the first thread and the second thread belong to the same process.

3. The method as described in claim 2, characterized in that, The step of creating a second thread to receive and process the second protocol request message, and starting a second port to listen for the second thread, includes: Create a connection establishment loop thread, and a selector corresponding to the connection establishment loop thread; Create an event loop processing thread group and bind the event loop processing thread group to the selector; Start the second port to establish a loop thread to listen for the connection.

4. The method as described in claim 1, characterized in that, The format of the second protocol request message is as follows: The first four bytes of the second protocol request message represent the message body length, the fifth and sixth bytes represent the request type, and the seventh byte and all subsequent bytes represent the request body.

5. The method as described in claim 1, characterized in that, After invoking the first service to process the first protocol message, the process further includes: Determine whether the processing result of the first protocol message needs to be fed back to the external server or client that sent the second protocol request message; If the processing result needs to be fed back to the external server or client that sent the second protocol request message, then a second preset protocol message converter is used to convert the processing result into a second protocol message. The second preset protocol message converter is used to perform Bson compression and encoding on the processing result to obtain the request body corresponding to the processing result and the length of the request body. The length of the request body, the request type of the processing result, and the request body are assembled to obtain the second protocol message. The second protocol message is sent to the external server or client.

6. An apparatus for cross-protocol interaction between services, characterized in that, The device includes: The listening module starts two ports to listen for the first protocol request message and the second protocol request message respectively; The judgment module, upon receiving the second protocol request message, determines whether the service in the second protocol request message is related to the first service or the second service, wherein the first service uses the first protocol for communication and the second service uses the second protocol for communication. The conversion module, if the service in the second protocol request message is related to the first service, uses a first preset protocol message converter to convert the second protocol request message into a first protocol message. The first preset protocol message converter parses the first four bytes of the second protocol request message to obtain the message body length of the second protocol request message; obtains the request body of the second protocol request message based on the message body length; performs obfuscation decryption and Bson deserialization on the request body to obtain a Bson object; converts the Bson object into a JSON object; and generates the first protocol message based on the JSON object. The processing module calls the first service to process the first protocol message.

7. The apparatus as claimed in claim 6, characterized in that, The monitoring module is specifically used for: A first thread is created to receive and process the first protocol request message, and a first port is started to listen for the first thread, wherein the first thread is used to call the first service; A second thread is created to receive and process the second protocol request message, and a second port is started to listen for the second thread. The second thread is used to call the second service, and the first thread and the second thread belong to the same process.

8. The apparatus as claimed in claim 7, characterized in that, The monitoring module is also used for: Create a connection establishment loop thread, and a selector corresponding to the connection establishment loop thread; Create an event loop processing thread group and bind the event loop processing thread group to the selector; Start the second port to establish a loop thread to listen for the connection.

9. The apparatus as claimed in claim 6, characterized in that, The device is also used for: Determine whether the processing result of the first protocol message needs to be fed back to the external server or client that sent the second protocol request message; If the processing result needs to be fed back to the external server or client that sent the second protocol request message, then a second preset protocol message converter is used to convert the processing result into a second protocol message. The second preset protocol message converter is used to perform Bson compression and encoding on the processing result to obtain the request body corresponding to the processing result and the length of the request body. The length of the request body, the request type of the processing result, and the request body are assembled to obtain the second protocol message. The second protocol message is sent to the external server or client.

10. An electronic device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method according to any one of claims 1-5.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1-5.

12. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of claims 1-5.

Images