Gateway processing method, gateway, device and medium

Abstract

The present application provides a gateway processing method, gateway, device and medium. The method includes: receiving multiple concurrent requests from a client and generating corresponding multiple request events; based on the io_uring technology, storing the multiple request events at the tail of a circular request queue; and, based on the threads in the thread pool, processing the request event at the head of the queue in the current circular request queue and generating a corresponding completion event after the processing is completed and storing it at the tail of the circular completion queue; taking out the completion event at the head of the queue in the circular completion queue. In the scheme of the present application, there is no need to create and destroy a large number of execution threads, thereby effectively reducing resource consumption, and it can be well applied to scenarios with high concurrent requests.

Description

Technical Field

[0001] The present application relates to communication technology, and in particular to a gateway processing method, a gateway, a device and a medium. Background Art

[0002] With the development of mobile Internet and communication technology, the number of Internet users has increased. In the face of the surge in user access, the gateway needs to perform corresponding processing. A current gateway processing solution includes that the gateway responds to the received request and creates a corresponding thread for each request, and the thread calls the upstream service to perform processing. If no result is returned by the upstream service, the current thread is suspended until the upstream service returns the result, and then the thread is awakened to continue processing.

[0003] Based on the above gateway processing solution, when the gateway handles high-concurrency requests, due to the large number of threads, it needs to frequently create and destroy threads, which results in huge resources. Summary of the invention

[0004] The present application provides a gateway processing method, a gateway, a device and a medium to solve the problem of excessive resource consumption in current gateway processing solutions.

[0005] On the one hand, the present application provides a gateway processing method, comprising: receiving multiple concurrent requests from a client, and generating corresponding multiple request events;

[0006] Based on the io_uring technology, the multiple request events are stored at the tail of the circular request queue; and based on the threads in the thread pool, the request event at the head of the queue in the current circular request queue is processed and after the processing is completed, a corresponding completion event is generated and stored at the tail of the circular completion queue;

[0007] The completion event at the head of the queue in the circular completion queue is taken out.

[0008] In one example, the gateway includes multiple main threads, and the main threads correspond to the client; the receiving multiple concurrent requests from the client and generating corresponding multiple request events include:

[0009] According to the port of the client, multiple concurrent requests of the client are routed to the corresponding main thread, so that the main thread generates corresponding request events based on the received requests.

[0010] In one example, the thread pool includes an internal thread pool and an upstream thread pool; the processing of the request event at the head of the queue in the current circular request queue based on the threads in the thread pool includes:

[0011] Based on the internal thread pool, performing protocol conversion on the request event at the head of the queue in the current ring request queue, and sending the data after protocol conversion to the upstream thread pool;

[0012] Based on the upstream thread pool, data is interacted with the upstream service corresponding to the request event according to the data converted by the protocol, so as to execute the processing of the request event.

[0013] In one example, after the processing is completed, generating a corresponding completion event and storing it at the tail of the circular completion queue includes:

[0014] Based on the upstream thread pool, the return data of the request event sent by the upstream service is sent to the internal thread pool;

[0015] Based on the internal thread pool, performing protocol conversion on the return data sent by the upstream thread pool to generate a completion event corresponding to the request event;

[0016] The generated completion event is stored at the tail of the circular completion queue.

[0017] In one example, the gateway is an enterprise service bus gateway.

[0018] On the other hand, the present application provides a gateway, including: a main thread module, configured to receive multiple concurrent requests from a client and generate corresponding multiple request events;

[0019] The main thread module is further used to store the multiple request events at the tail of the ring request queue based on the io_uring technology;

[0020] A thread pool module is used to process the request event at the head of the queue in the current circular request queue based on the threads in the thread pool and generate a corresponding completion event after the processing is completed and store it in the tail of the circular completion queue;

[0021] The main thread module is also used to take out the completion event at the head of the queue in the circular completion queue.

[0022] In one example, the gateway includes a plurality of main threads, and the main threads correspond to the client;

[0023] The main thread module is specifically used to route multiple concurrent requests of the client to the corresponding main thread according to the port of the client, so that the main thread generates corresponding request events based on the received requests.

[0024] In one example, the thread pool includes an internal thread pool and an upstream thread pool;

[0025] The thread pool module is specifically used to perform protocol conversion on the request event at the head of the queue in the current ring request queue based on the internal thread pool, and send the data after protocol conversion to the upstream thread pool;

[0026] The thread pool module is specifically used to perform data interaction with the upstream service corresponding to the request event based on the upstream thread pool and according to the data converted by the protocol, so as to execute the processing of the request event.

[0027] In one example, the thread pool module is further specifically used to send the return data of the request event sent by the upstream service to the internal thread pool based on the upstream thread pool;

[0028] The thread pool module is further configured to perform protocol conversion on the return data sent by the upstream thread pool based on the internal thread pool, and generate a completion event corresponding to the request event;

[0029] The thread pool module is further specifically used to store the generated completion event at the tail of the circular completion queue.

[0030] In one example, the gateway is an enterprise service bus gateway.

[0031] In yet another aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0032] The memory stores computer-executable instructions;

[0033] The processor executes the computer-executable instructions stored in the memory to implement the above-mentioned method.

[0034] On the other hand, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method as described above.

[0035] The gateway processing method, gateway, device and medium provided by the present application include generating multiple request events for multiple concurrent requests, storing the request events in a ring request queue based on io_uring technology, and generating corresponding completion events for completed request events, storing them in a ring completion queue and taking the request events out of the ring request queue to implement thread allocation and management operations. In the scheme of the present application, there is no need to create and destroy a large number of execution threads, thereby effectively reducing resource consumption, and it can be well applied to scenarios with high concurrent requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0037] Figure 1 A schematic diagram of an application scenario provided for an embodiment of the present application;

[0038] Figure 2 A schematic diagram of a flow chart of a gateway processing method is provided for the first embodiment of the present application;

[0039] Figure 3 This is a schematic diagram of the working principle of the IO_uring model;

[0040] Figure 4 It is a schematic diagram of the architecture of a blocking (BIO) communication;

[0041] Figure 5 A flowchart of a gateway processing method is provided for the second embodiment of the present application;

[0042] Figure 6 A flowchart of a gateway processing method provided in Embodiment 3 of the present application;

[0043] Figure 7 This is an example diagram of the architecture of a gateway model;

[0044] Figure 8 A schematic diagram of the structure of a gateway is provided for the fourth embodiment of the present application;

[0045] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0046] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0047] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0048] It should be noted that the brief description of terms in this application is only for the convenience of understanding the embodiments described below, and is not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their common and usual meanings.

[0049] Figure 1 A schematic diagram of an application scenario provided in an embodiment of the present application, combined with Figure 1 As shown in the figure, the application scenario of the gateway processing solution is illustrated. Figure 1 As shown, it includes: client 1, server 2 and upstream service 3. Among them, server 2 includes: network card, CPU, memory and gateway.

[0050] Combined with the above scenario example: Client 1 initiates a request to Server 2, and the initiated request reaches the network card of Server 2. In actual applications, the communication between the client and the server can adopt a variety of communication methods, such as wired or wireless communication. Among them, the type of request includes but is not limited to Transmission Control Protocol (TCP) layer data or L7 layer data, such as Hyper Text Transfer Protocol (Http), Message Queue (MQ), Remote Procedure Call (RPC).

[0051] After receiving the request, the network card can write the data in the request into the memory through the transmission of the computer hardware circuit, for example, write it to a certain address in the memory. After the writing is completed, the network card sends an interrupt signal to the CPU's operating system, and the operating system is informed that a new request has arrived, and then processes the request through the interrupt program. Specifically, the gateway monitors multiple request connection data based on the io_uring technology for multiple concurrent requests. The relevant threads in the Enterprise Service Bus (ESB) gateway will package the connection data to generate multiple request events and store the request events in the ring request queue. The corresponding thread executes the request event, and the gateway then packages the completed request event into a completion event, stores the corresponding completion event in the ring completion queue, and then takes the completion event out of the ring request queue to implement thread allocation and management operations, effectively saving resources.

[0052] The technical solutions of the present application and the technical solutions of the present application are described in detail with specific embodiments below. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. In the description of the present application, unless otherwise clearly specified and limited, each term should be understood in a broad sense in the art. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0053] Embodiment 1

[0054] Figure 2 A flow chart of a gateway processing method is provided for the first embodiment of the present application, such as Figure 2 As shown, the gateway processing method includes:

[0055] Step 101: receiving multiple concurrent requests from a client and generating corresponding multiple request events;

[0056] Step 102: Based on the io_uring technology, the multiple request events are stored at the tail of the circular request queue; and based on the threads in the thread pool, the request event at the head of the queue in the current circular request queue is processed and after the processing is completed, a corresponding completion event is generated and stored at the tail of the circular completion queue;

[0057] Step 103: Take out the completion event at the head of the queue in the circular completion queue.

[0058] In actual applications, as the number of Internet users increases, high concurrent requests usually occur. The high concurrent request scenario in this solution refers to the situation where the gateway encounters a large number of operation requests in a short period of time. Among them, multiple concurrent requests refer to multiple requests received in the high concurrent request scenario. Among them, the client, also known as the user end, refers to the program that corresponds to the server and provides local services to customers, such as application software.

[0059] In practical applications, the execution subject of the gateway processing method can be a gateway. There are many ways to implement the gateway. For example, it can be implemented through a computer program, such as application software, etc.; or it can be implemented as a medium storing relevant computer programs, such as a USB flash drive, a cloud disk, etc.; or it can be implemented through a physical device integrated or installed with relevant computer programs, such as a chip, etc.

[0060] Among them, IO_uring can be used as a Linux kernel interface and belongs to asynchronous input / output (IO) technology. In this embodiment, IO_uring technology is used to provide a circular request and completion queue, which can be shared between the kernel and user space to avoid copying. In one example, the gateway can monitor multiple file descriptors (FileDescriptor, fd for short), and once a certain fd is ready (generally read-ready or write-ready), it can notify the kernel to perform corresponding operations.

[0061] Take an example based on a real scenario: Figure 3 As shown, Figure 3 This is a schematic diagram of the working principle of the IO_uring model, in which a gateway is used as an example as the executor of this embodiment. In an example, the gateway first creates a listening interface and receives access to the port (also called a request). In combination with actual application examples, the gateway can listen to Socket connections. Specifically, Socket is an intermediate software abstraction layer for communication between the application layer and the TCP / IP protocol family. It is a set of interfaces. In the design pattern, Socket can be regarded as a facade pattern, which hides the complex TCP / IP protocol family behind the Socket interface. For users, a set of simple interfaces is all, allowing Socket to organize data to comply with the specified protocol.

[0062] After receiving the request, the gateway will package the request into a request event, store it at the end of the circular request queue, and notify the kernel. In an example, the enter() method can be called to notify the kernel. As an example, the code of the above process is as follows:

[0063] "sqe = wraperSqe (data, opcode); / / Package request event

[0064] sq.submit(sq); / / Store at the end of the request queue

[0065] enter(); / / Notify the kernel".

[0066] After receiving the notification, the kernel will process the request event at the head of the request queue. In practical applications, the request event can be processed according to its type, including but not limited to read or write. After the processing is completed, the gateway will take the request event out of the ring request queue, encapsulate the completion result of the request event into a completion event, and store it at the end of the ring completion queue. As an example, the code of the above process is as follows:

[0067] "sqe = sq.poll(); / / Get the request event

[0068] cqe=deal(sqe); / / Process

[0069] cq.submit(cqe); / / Submit to the end of the completion queue".

[0070] Optionally, each request event corresponds to a completion event. The gateway can obtain the result of the request processing by taking the completion event from the circular completion queue.

[0071] In practical applications, the IO_uring model can be initialized first. In an example, the IO_uring model consists of four data structures, including: request queue (sq), request event (sqe), completion queue (cq) and completion event (cqe). Among them, the request queue and completion queue are both ring buffer queues. As an example, the code of the above data structure is as follows:

[0072]

[0073]

[0074] It can be understood that when high concurrent requests occur, based on the solution of this embodiment, the gateway does not need to perform management processing such as thread creation and destruction for each request, thereby effectively reducing resource consumption. In addition, in one technology, such as Figure 4 As shown, it is a schematic diagram of the architecture of a blocking (Base Input Output, BIO for short) communication. In the figure, the receiving thread (Acceptor) is responsible for establishing a connection with the client (client). A thread (Thread) is started for each new request received, and each request corresponds to a response. The client will wait until the request is responded to. If no response is received, the gateway will suspend the current thread until the upstream service (UPStream) returns a response information message, and then the thread can be awakened before it can continue processing. Compared with this technology, in the solution of this embodiment, the gateway does not need to wait for the processing status of the existing request event for a new request, so it can avoid blocking and improve the efficiency and reliability of gateway processing.

[0075] Optionally, the solution of this embodiment can be applied to an ESB gateway. Accordingly, in one example, the gateway is an enterprise service bus gateway. It should be noted that the enterprise service bus is an integrated container and can also be used as a centralized service bus. Through the enterprise service bus, integrated business processing, monitoring of message flow between systems, and management of business services for interaction between systems can be achieved. The main technical scenario of the enterprise service bus is integration, the core concepts are services and messages, and the main working methods are protocol adaptation and intermediary processing. Based on the working scenarios of the above-mentioned enterprise service bus, it can be understood that since the enterprise service bus is oriented to the integration scenario, the number of users is larger, and the volume and frequency of high concurrent request scenarios require a more energy-efficient gateway processing solution than gateways in other scenarios. Therefore, in the solution of this embodiment, since there is no need to create and destroy threads and blocking can be avoided, it can be well applied to the enterprise service bus gateway to achieve the effect of efficient energy saving.

[0076] The gateway processing method provided in this embodiment includes generating multiple request events for multiple concurrent requests, storing the request events in a ring request queue based on the io_uring technology, and generating corresponding completion events for completed request events, storing them in a ring completion queue, and taking the request events out of the ring request queue to implement thread allocation and management operations. In this embodiment, there is no need to create and destroy a large number of execution threads, thereby effectively reducing resource consumption, and it can be well applied to scenarios with high concurrent requests.

[0077] Embodiment 2

[0078] Figure 5 A flow chart of a gateway processing method is provided for the second embodiment of the present application. This embodiment takes the gateway as an example of the execution subject. Accordingly, based on the first embodiment, the gateway includes multiple main threads, and the main threads correspond to the client; accordingly, Figure 5 As shown, step 101 may specifically include:

[0079] Step 201: Routing multiple concurrent requests of the client to the corresponding main thread according to the port of the client, so that the main thread generates corresponding request events based on the received requests.

[0080] In this embodiment, multiple main threads (Main-Reactor) are provided. In one example, the main thread can be responsible for initializing io_uring, processing IO events with the client (client), for example, after receiving a request and packaging it as a request event, the request event is stored in a circular request queue based on the io_uring technology, and the completed event is obtained from the circular completion queue based on the io_uring technology, and the processing continues. Compared with the usual case, a thread is assigned to a client connection. In this embodiment, a main thread specifically used for I / O interaction with the client is set. After performing I / O operations in an event-triggered manner, other threads are assigned. These other threads are specifically used to perform event processing, such as non-interactive events such as encoding and decoding and business logic operations. In this way, for different links of gateway processing, a special thread is set to achieve different processing, such as the decoupling of interaction and calculation processing, which can save the waiting time of a single thread and improve the utilization efficiency of the thread. In one example, the thread pool technology can also be used to reduce the frequent creation and destruction overhead of threads to further reduce overhead and save resources.

[0081] Specifically, the main thread can route to the corresponding main thread to process the connection request according to the port of the Socket connection establishment party. Optionally, hash routing can be used for routing. When the gateway receives data, such as when the upstream service returns data to the gateway, and when the data sender sends data to the gateway, the event type faced by the main thread at this time is a read event; when the gateway sends data, such as when the gateway sends data to the upstream service, and when the gateway returns data to the data sender, the event type faced by the main thread at this time is a write event.

[0082] In this embodiment, the Multiple-Main Multiple-Reactor has multiple main threads (Main-Reactor) for processing the establishment of connections. When a large number of short connection requests and disconnections occur, it will not be limited by the situation where a large number of connections time out and cannot be established due to the slow processing of a single thread. Therefore, the Multiple-Main Multiple-Reactor not only has the ability to read and write a large number of connections, but can also handle a large number of connection requests and disconnections.

[0083] In the gateway processing method provided in this embodiment, according to the port of the client, the concurrent request is routed to the corresponding main thread among the multiple main threads, and the main thread generates a corresponding request event based on the received request to perform subsequent processing. The scheme of this embodiment sets the main thread responsible for executing the interactive operation with the client to achieve the decoupling of the processing of different links, and further reduces the waiting time of a single thread by setting multiple main threads, thereby further improving the processing efficiency.

[0084] Embodiment 3

[0085] Figure 6 A flow chart of a gateway processing method provided in Embodiment 3 of the present application is provided. Based on Embodiment 2, the thread pool includes an internal thread pool and an upstream thread pool; accordingly, Figure 6 As shown, in step 102, based on the threads in the thread pool, processing is performed on the request event at the head of the queue in the current circular request queue, which may specifically include:

[0086] Step 301: Based on the internal thread pool, perform protocol conversion on the request event at the head of the queue in the current ring request queue, and send the protocol converted data to the upstream thread pool;

[0087] Step 302: Based on the upstream thread pool, data is exchanged with the upstream service corresponding to the request event according to the data converted by the protocol to execute processing of the request event.

[0088] In practical applications, the upstream service refers to the receiving end of data; the thread pool refers to a collection of threads.

[0089] To facilitate understanding, we will use the model architecture as an example: Figure 7 As shown in the figure, it is an example diagram of the architecture of a gateway model. Figure 7 As shown, the model adopts the Multiple-Main Multiple-Reactor architecture, which includes: main thread, internal thread pool and upstream thread pool. Among them, the main thread and upstream thread pool are interactive I / O threads, and the internal thread pool is the Handler processing thread.

[0090] Main thread: Also called Main-Reactor, it is responsible for establishing connections. For example, when the upstream service returns data to the gateway, or the client sends data to the gateway, the main thread is responsible for handling the interaction of read events; when the gateway sends data to the upstream service, or the gateway returns data to the client, the main thread is responsible for handling the interaction of write events.

[0091] Internal thread pool: also called Sub-Reactor Thread Pool, responsible for processing the logic inside the gateway. After the logic passes, the internal thread pool will submit the data after protocol conversion to the upstream thread pool.

[0092] Upstream thread pool: also known as upstream sub-Reactor Thread Pool, responsible for data interaction with the upstream service (Upstream Server), including connection establishment, sending and reading.

[0093] Optionally, the upstream thread pool in the solution of this embodiment is an abstracted separate thread pool that interacts with the upstream service and is specifically responsible for establishing, sending and reading the service connection between the gateway and the upstream service.

[0094] In one example, after the processing in step 101 is completed, generating a corresponding completion event and storing it at the tail of the circular completion queue may specifically include:

[0095] Based on the upstream thread pool, the return data of the request event sent by the upstream service is sent to the internal thread pool;

[0096] Based on the internal thread pool, performing protocol conversion on the return data sent by the upstream thread pool to generate a completion event corresponding to the request event;

[0097] The generated completion event is stored at the tail of the circular completion queue.

[0098] Combined with the scenario example: the upstream service will return data to the client, such as a response message, after executing the corresponding processing based on the request event of the gateway. Specifically, the upstream service sends the data that needs to be returned to the client to the upstream thread pool, and correspondingly, the upstream thread pool sends the return data sent by the upstream service to the internal thread pool; the internal thread pool performs protocol conversion on the return data, generates a completion event corresponding to the request event, and stores the generated completion event at the tail of the circular completion queue.

[0099] In this example, the upstream server is responsible for IO interaction with the upstream thread pool. When data needs to be sent to the upstream service, the gateway establishes a connection with the upstream server through the upstream thread pool. When the data passes some checks and protocol conversion and can be sent to the upstream service, the upstream thread pool sends the data to the upstream service. At the same time, the upstream thread pool is also responsible for receiving the data returned by the upstream service, and then sending it to the internal thread pool for corresponding processing. In this mode, IO asynchronous reading and writing will not affect the internal logic processing, and the performance and stability are greatly improved.

[0100] The model in this embodiment is different from the conventional thread model. The model of the above architecture is provided with multiple main threads for processing the establishment of connections. When a large number of short connection requests and disconnections occur, it will not be limited by the situation that a large number of connections cannot be established due to timeouts caused by slow single-thread processing. Therefore, it has a large number of read and write capabilities and can also handle a large number of connection requests and disconnection requests. In addition, since the gateway not only needs to establish a large number of connections with the client, but also needs to connect to a large number of upstream services. In view of this situation, the above model abstracts a separate upstream thread pool responsible for connecting and interacting with upstream services, thereby further improving the gateway processing efficiency.

[0101] The gateway processing method provided in this embodiment is designed to use two thread pools, the internal thread pool and the upstream thread pool, to process the connection requests with the client and the upstream server respectively. In this mode, the work of different thread modules is more specialized, and the interactive I / O asynchronous reading and writing will not affect the business logic processing, the coupling degree is lower, the performance and stability are greatly improved, and the number of concurrent connections supported can reach millions.

[0102] Embodiment 4

[0103] Figure 8 A schematic diagram of the structure of a gateway is provided for the fourth embodiment of the present application, such as Figure 8 As shown, the gateway includes:

[0104] The main thread module 81 is used to receive multiple concurrent requests from the client and generate corresponding multiple request events;

[0105] The main thread module 81 is further used to store the multiple request events at the tail of the ring request queue based on the io_uring technology;

[0106] The thread pool module 82 is used to process the request event at the head of the queue in the current circular request queue based on the threads in the thread pool and generate a corresponding completion event after the processing is completed and store it in the tail of the circular completion queue;

[0107] The main thread module 81 is also used to take out the completion event at the head of the queue in the circular completion queue.

[0108] In actual applications, as the number of Internet users increases, high concurrent requests usually occur. The high concurrent request scenario in this solution refers to the situation where the gateway encounters a large number of operation requests in a short period of time. Among them, multiple concurrent requests refer to multiple requests received in the high concurrent request scenario. Among them, the client, also known as the user end, refers to the program that corresponds to the server and provides local services to customers, such as application software.

[0109] In actual applications, there are many ways to implement the gateway. For example, it can be implemented through a computer program, such as application software, etc.; or it can be implemented as a medium storing relevant computer programs, such as a USB flash drive, a cloud disk, etc.; or it can be implemented through a physical device integrated or installed with relevant computer programs, such as a gateway, a chip, etc.

[0110] Among them, IO_uring can be used as a Linux kernel interface and belongs to asynchronous IO technology. In this embodiment, IO_uring technology is used to provide a circular request and completion queue, which can be shared between the kernel and user space to avoid copying. In one example, the gateway can monitor multiple fds (File Descriptors), and once a certain fd is ready (generally read-ready or write-ready), it can notify the kernel to perform corresponding operations.

[0111] After receiving the request, the gateway will package the request into a request event, then store it at the end of the circular request queue, and notify the kernel. In one example, the enter() method can be called to notify the kernel. After receiving the notification, the kernel will process the request event at the head of the request queue. In practical applications, the request event can be processed according to its type, including but not limited to read or write. After the processing is completed, the gateway will take the request event out of the circular request queue, and encapsulate the completion result of the request event into a completion event, and store it at the end of the circular completion queue.

[0112] Optionally, each request event corresponds to a completion event. The gateway can obtain the result of the request processing by taking the completion event from the circular completion queue.

[0113] In practical applications, the IO_uring model can be initialized first. In an example, the IO_uring model consists of four data structures, including: request queue (sq), request event (sqe), completion queue (cq) and completion event (cqe). Among them, the request queue and the completion queue are both ring buffer queues.

[0114] It can be understood that when high concurrent requests occur, based on the solution of this embodiment, the gateway does not need to perform management processing such as thread creation and destruction for each request, thereby effectively reducing resource consumption. In the solution of this embodiment, the gateway does not need to wait for the processing status of existing request events for new requests, so blocking can be avoided and the efficiency and reliability of gateway processing can be improved.

[0115] Optionally, the solution of this embodiment can be applied to an ESB gateway. Accordingly, in one example, the gateway is an enterprise service bus gateway. It should be noted that the enterprise service bus is an integrated container and can also be used as a centralized service bus. Based on the working scenarios of the above-mentioned enterprise service bus, it can be understood that since the enterprise service bus is oriented to the integration scenario, the number of users is larger, and the volume and frequency of high-concurrency request scenarios require a more energy-efficient gateway processing solution than gateways in other scenarios. Therefore, in the solution of this embodiment, since there is no need to create and destroy threads and blocking can be avoided, it can be well applied to the enterprise service bus gateway to achieve efficient energy saving effects.

[0116] In one example, the gateway includes multiple main threads, which correspond to the client; accordingly, the main thread module 81 is specifically used to route multiple concurrent requests of the client to the corresponding main thread according to the client's port, so that the main thread generates corresponding request events based on the received requests.

[0117] In this example, multiple main threads (Main-Reactor) are provided. In one example, the main thread can be responsible for initializing io_uring, processing IO events with the client (client), for example, after receiving a request and packaging it as a request event, the request event is stored in a circular request queue based on the io_uring technology, and the completed event is obtained from the circular completion queue based on the io_uring technology, and the processing continues. Compared with the usual case, a thread is assigned to a client connection. In this embodiment, a main thread specifically used for I / O interaction with the client is set, and after performing I / O operations in an event-triggered manner, other threads are assigned, and these other threads are specifically used to perform event processing, such as non-interactive events such as encoding and decoding and business logic operations. In this way, for different links of gateway processing, a special thread is set to achieve different processing, such as the decoupling of interaction and calculation processing, which can save the waiting time of a single thread and improve the utilization efficiency of the thread. In one example, the thread pool technology can also be used to reduce the frequent creation and destruction overhead of threads, so as to further reduce overhead and save resources.

[0118] Specifically, the main thread can route to the corresponding main thread to process the connection request according to the port of the Socket connection establishment party. Optionally, hash routing can be used for routing. When the gateway receives data, such as when the upstream service returns data to the gateway, and when the data sender sends data to the gateway, the event type faced by the main thread at this time is a read event; when the gateway sends data, such as when the gateway sends data to the upstream service, and when the gateway returns data to the data sender, the event type faced by the main thread at this time is a write event.

[0119] In this example, there are multiple main threads for processing the establishment of connections. When a large number of short connection requests and disconnections occur, it will not be limited by the situation where a large number of connections time out and cannot be established due to the slow processing of a single thread. Therefore, it not only has the ability to read and write a large number of connections, but also can handle requests and disconnections for a large number of connections. In this example, according to the client's port, the concurrent request is routed to the corresponding main thread in the multiple main threads, and the main thread generates a corresponding request event based on the received request to perform subsequent processing. The scheme of this embodiment sets the main thread responsible for executing the interactive operation with the client, realizes the decoupling of processing in different links, and further reduces the waiting time of a single thread by setting multiple main threads, further improving the processing efficiency.

[0120] In another example, the thread pool includes an internal thread pool and an upstream thread pool; accordingly, the thread pool module 82 is specifically used to perform protocol conversion on the request event at the head of the queue in the current circular request queue based on the internal thread pool, and send the protocol-converted data to the upstream thread pool; the thread pool module 82 is also specifically used to perform data interaction with the upstream service corresponding to the request event based on the upstream thread pool according to the protocol-converted data to perform processing on the request event. In practical applications, the upstream service refers to the receiving end of the data; the thread pool refers to a collection of threads.

[0121] Optionally, the upstream thread pool in the solution of this embodiment is an abstracted separate thread pool that interacts with the upstream service and is specifically responsible for establishing, sending and reading the service connection between the gateway and the upstream service.

[0122] In one example, the thread pool module 82 is specifically used to send the return data of the request event sent by the upstream service to the internal thread pool based on the upstream thread pool; the thread pool module 82 is specifically used to perform protocol conversion on the return data sent by the upstream thread pool based on the internal thread pool, and generate a completion event corresponding to the request event; the thread pool module 82 is specifically used to store the generated completion event at the tail of the circular completion queue.

[0123] Combined with the scenario example: the upstream service will return data to the client, such as a response message, after executing the corresponding processing based on the request event of the gateway. Specifically, the upstream service sends the data that needs to be returned to the client to the upstream thread pool, and correspondingly, the upstream thread pool sends the return data sent by the upstream service to the internal thread pool; the internal thread pool performs protocol conversion on the return data, generates a completion event corresponding to the request event, and stores the generated completion event at the tail of the circular completion queue.

[0124] In this example, the upstream server is responsible for IO interaction with the upstream thread pool. When data needs to be sent to the upstream service, the gateway establishes a connection with the upstream server through the upstream thread pool. When the data passes some checks and protocol conversion and can be sent to the upstream service, the upstream thread pool sends the data to the upstream service. At the same time, the upstream thread pool is also responsible for receiving the data returned by the upstream service, and then sending it to the internal thread pool for corresponding processing. In this mode, IO asynchronous reading and writing will not affect the internal logic processing, and the performance and stability are greatly improved.

[0125] The model in this example is different from the conventional thread model. The model of the above architecture is set with multiple main threads to handle the establishment of connections. When a large number of short connection requests and disconnections occur, it will not be limited by the situation where a large number of connections time out and cannot be established due to slow single-thread processing. Therefore, it has a large number of read and write capabilities and can also handle a large number of connection requests and disconnection requests. In addition, since the gateway not only needs to establish a large number of connections with the client, but also needs to connect with a large number of upstream services. In response to this situation, the above model abstracts a separate upstream thread pool to be responsible for connecting and interacting with upstream services, thereby further improving the gateway processing efficiency.

[0126] This example designs two thread pools, the internal thread pool and the upstream thread pool, to handle connection requests with the client and the upstream server respectively. In this mode, the work of different thread modules is more specialized, and the interactive I / O asynchronous reading and writing will not affect the business logic processing, the coupling degree is lower, the performance and stability are greatly improved, and the number of concurrent connections supported can reach millions.

[0127] The gateway provided in this embodiment generates multiple request events for multiple concurrent requests, and based on the io_uring technology, stores the request events in a ring request queue, and generates corresponding completion events for completed request events, stores them in a ring completion queue, and takes the request event out of the ring request queue to implement thread allocation and management operations. In this embodiment, there is no need to create and destroy a large number of execution threads, thereby effectively reducing resource consumption, and it can be well applied to scenarios with high concurrent requests.

[0128] Embodiment 5

[0129] Fig. 9 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown in FIG. Fig. 9 As shown, the electronic device includes:

[0130] The electronic device includes a processor 291 and a memory 292; it may also include a communication interface 293 and a bus 294. The processor 291, the memory 292, and the communication interface 293 may communicate with each other through the bus 294. The communication interface 293 may be used for information transmission. The processor 291 may call the logic instructions in the memory 294 to execute the method of the above embodiment.

[0131] In addition, the logic instructions in the above-mentioned memory 292 can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product.

[0132] The memory 292 is a computer-readable storage medium that can be used to store software programs and computer executable programs, such as program instructions / modules corresponding to the methods in the embodiments of the present application. The processor 291 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 292, that is, implementing the methods in the above method embodiments.

[0133] The memory 292 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 292 may include a high-speed random access memory and may also include a non-volatile memory.

[0134] An embodiment of the present application provides a non-temporary computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the method described in the above embodiment.

[0135] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0136] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A gateway processing method, characterized in that: include: Receive multiple concurrent requests from the client and generate corresponding multiple request events; Based on the io_uring technology, the multiple request events are stored at the tail of the circular request queue; and based on the threads in the thread pool, the request event at the head of the queue in the current circular request queue is processed and after the processing is completed, a corresponding completion event is generated and stored at the tail of the circular completion queue; Taking out the completion event at the head of the queue in the circular completion queue; The thread pool includes an internal thread pool and an upstream thread pool; The processing of the request event at the head of the queue in the current circular request queue based on the thread in the thread pool includes: Based on the internal thread pool, performing protocol conversion on the request event at the head of the queue in the current ring request queue, and sending the data after protocol conversion to the upstream thread pool; Based on the upstream thread pool, according to the data converted by the protocol, data is interacted with the upstream service corresponding to the request event to execute the processing of the request event; After the processing is completed, the corresponding completion event is generated and stored at the tail of the circular completion queue, including: Based on the upstream thread pool, the return data of the request event sent by the upstream service is sent to the internal thread pool; Based on the internal thread pool, performing protocol conversion on the return data sent by the upstream thread pool to generate a completion event corresponding to the request event; The generated completion event is stored at the tail of the circular completion queue.

2. The method according to claim 1, characterized in that The gateway includes a plurality of main threads, and the main threads correspond to the client; the receiving of a plurality of concurrent requests from the client and the generation of a plurality of corresponding request events include: According to the port of the client, multiple concurrent requests of the client are routed to the corresponding main thread, so that the main thread generates corresponding request events based on the received requests.

3. The method according to any one of claims 1 to 2, characterized in that: The gateway is an enterprise service bus gateway.

4. A gateway, characterized in that: include: The main thread module is used to receive multiple concurrent requests from the client and generate corresponding multiple request events; The main thread module is further used to store the multiple request events at the tail of the ring request queue based on the io_uring technology; A thread pool module, used for taking out the completion event at the head of the queue in the circular completion queue; The thread pool includes an internal thread pool and an upstream thread pool; The processing of the request event at the head of the queue in the current circular request queue based on the thread in the thread pool includes: Based on the internal thread pool, performing protocol conversion on the request event at the head of the queue in the current ring request queue, and sending the data after protocol conversion to the upstream thread pool; Based on the upstream thread pool, according to the data converted by the protocol, data is interacted with the upstream service corresponding to the request event to execute the processing of the request event; After the processing is completed, the corresponding completion event is generated and stored at the tail of the circular completion queue, including: Based on the upstream thread pool, the return data of the request event sent by the upstream service is sent to the internal thread pool; Based on the internal thread pool, performing protocol conversion on the return data sent by the upstream thread pool to generate a completion event corresponding to the request event; The main thread module is also used to take out the completion event at the head of the queue in the circular completion queue.

5. The gateway according to claim 4, characterized in that: The gateway includes a plurality of main threads, and the main threads correspond to the client; The main thread module is specifically used to route multiple concurrent requests of the client to the corresponding main thread according to the port of the client, so that the main thread generates corresponding request events based on the received requests.

6. The gateway according to any one of claims 4-5, characterized in that: The gateway is an enterprise service bus gateway.

7. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 3.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 3 when executed by a processor.

Images