HTTP2-based RPC and Actor integrated assembly and method

Abstract

The invention provides an RPC and Actor integrated assembly and method based on HTTP2. The RPC and Actor integrated assembly comprises an RPC management module, an Actor system module, an interface management module, a transmission module and an execution module, wherein the interface management module, the transmission module and the execution module are sequentially combined in series. The RPC management module and the Actor system module respectively register interface definition and create Actor or newly-added RPC interface service to the interface management module; the interface management module is used for newly adding and deleting interface definitions; the transmission module realizes network data exchange, data coding and decoding and flow control between services; and the execution module comprises a plurality of working threads and circularly and continuously executes various types of tasks. According to the invention, integration of two network communication normal forms of RPC and Actor is realized; the two systems can be selected for network communication according to design requirements, and two sets of systems and frames do not need to be maintained; the HTTP2 protocol is adopted, so that network communication has high performance, low delay and backpressure control; and efficient utilization of system resources is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software system design, and more specifically, to an integrated component method of RPC and Actor based on HTTP2. Background Art

[0002] The Remote Procedure Call (RPC) model is a technology that allows a program to call another program in a different address space. HTTP2 is an application layer transport protocol widely used in the Web field. At the same time, because HTTP2 has functions such as multiplexing, flow control, and header compression, it is used as the preferred data transmission protocol solution by a large number of mainstream RPC frameworks. For example, Google's gRPC and Alibaba's Dubbo. These RPC frameworks, with the support of the HTTP2 protocol, can not only support the common 'request-response' communication method, but also support streaming communication methods, including client streaming, server streaming, and bidirectional streaming.

[0003] The Actor model is a concurrent computing model. The core concept of Actor is to regard computing as a series of message passing and processing. Each "role" (Actor) that receives and processes messages is an independent computing unit. The Actor model has been widely used in distributed systems, parallel computing, and concurrent programming. Common frameworks and languages based on the Actor model are Akka and Erlang.

[0004] In the current design of microservice systems, the RPC model is the most commonly used communication solution between microservices; while in building complex, highly concurrent, highly elastic, and highly available distributed systems, the Actor model is the optimal solution.

[0005] However, the framework technologies used in the current RPC model and Actor model are often incompatible with each other. If an application system needs both the RPC model and the Actor model at the same time, then two network communication models, two thread models, and two serialization systems need to be maintained, increasing the complexity of the system and occupying system resources. For example, gRPC-java is based on the network communication framework Netty and serialization is based on Protobuf; while Akka is based on the network communication framework Aeron, with the thread model Dispatcher and an independent serialization scheme. Although Akka provides API-level compatibility with gRPC, the underlying network and thread models are still independent of each other and cannot achieve the optimal utilization of system resources. Summary of the Invention

[0006] In view of this, the purpose of the present invention is to develop an integration method for two network communication paradigms, namely the RPC model and the Actor model, and propose an integration method for RPC and Actor based on HTTP2, which can arbitrarily use the two frameworks of the RPC model and the Actor model for network communication according to design requirements, without the need to maintain two sets of systems and frameworks simultaneously, achieving low resource occupancy, and at the same time ensuring high scalability, maintainability, usability and high performance of the system.

[0007] The present invention provides an integration component for RPC and Actor based on HTTP2, including: an RPC management module, an Actor system module, and an interface management module, a transmission module, and an execution module that are sequentially connected in series; the RPC management module and the Actor system module are respectively connected to the interface management module to register interface definitions, create Actors or add new RPC interface services to the interface management module;

[0008] The interface management module is used for adding and deleting interface definitions;

[0009] Specifically, each interface definition contains a route (i.e., the mapping relationship between the HTTP2 request path and the RPC interface or Actor), a serializer and other communication parameter information. Each time a new RPC interface is added or a new Actor is created, a corresponding interface definition will be added to the interface management module. When creating an Actor, a sticky id will also be configured in the parameter information of the interface definition to implement the sticky queue selection strategy of the dispatcher;

[0010] The transmission module is the unified access point for network communication within the system, and is used to implement multiple functions such as network data exchange, data encoding and decoding, and traffic control between services;

[0011] The execution module contains multiple working threads that continuously execute various types of tasks in a loop. The task types include: RPC tasks, Actor message processing tasks, timed tasks, and user-defined asynchronous execution tasks.

[0012] The execution module is essentially a thread pool. Different from an ordinary thread pool, the execution module can require specific threads to execute specified tasks according to task types and requirements, and provides targeted performance optimization for both the processing of network communication messages and the processing of local asynchronous tasks.

[0013] Further, the transmission module includes: an HTTP2 controller, a routing controller, a serializer, and a write queue; the routing controller is downstream of the HTTP2 controller, and the serializer is downstream of the routing controller; the routing controller interacts with the HTTP2 controller, the serializer interacts with the routing controller, and the write queue is connected to the serializer.

[0014] Specifically, the HTTP2 controller is used to implement the format conversion between HTTP2 protocol data frames and system internal messages. At the sending end, the frame codec encodes the messages from within the system into HTTP2 data frames; at the receiving end, the frame codec decodes the data frames and passes them to the downstream; and the HTTP2 controller abstracts the TCP connection into an HTTP2 protocol data stream. Multiple data streams can multiplex the same TCP connection, and the multiplexing controller can provide flow control functions. While implementing backpressure control, the blocking of a certain data stream does not affect the data transmission of other data streams;

[0015] The routing controller is used to implement the routing control from the message object to the RPC interface or Actor. The routing controller parses the path information in the HTTP2 request header, finds the corresponding serializer and RPC interface or Actor object for the request through the internal routing table, and sends this information to the downstream. The routing controller will monitor the changes in the routing information in the routing registration module in real time and update the local routing table.

[0016] The serializer is used at the sending end to serialize the message objects from RPC calls and Actors into binary data and pass them to the HTTP2 controller for further encoding into data frames; at the receiving end, it is used to deserialize the binary data decoded by the HTTP2 controller into message objects, and send the message objects and other information parsed by the routing controller to the downstream together;

[0017] The write queue is used for data sending. It adopts the ring array data structure of Disruptor. The messages of the external thread are first written into the write queue for caching, and then the IO thread of the transmission module pulls the data from the write queue, sends it to the serializer to be converted into binary format data, and then it is encapsulated into a frame by the HTTP2 controller.

[0018] Further, the execution module includes: a dispatcher, an event queue, a timer, and an executor; the dispatcher is connected to the serializer of the upstream transmission module; the event queue is downstream of the dispatcher, the executor is downstream of the event queue, and the executor is connected to the event queue; the event queue includes: an SPSC queue and an MPSC queue; the dispatcher is connected to the SPSC queue, and the timer is connected to the MPSC queue.

[0019] Specifically, each IO thread of the upstream transmission module corresponds to a dispatcher, and each dispatcher corresponds to multiple downstream event queues. When a new HTTP2 data stream is created, the dispatcher will select an event queue to bind to the data stream, and then all messages of the data stream will be written into this event queue. The dispatching strategies for the dispatcher to select event queues include: round-robin, random, load balancing, and sticky strategy. The load balancing strategy means that the dispatcher will monitor the production and consumption rates of the event queues and select one of the event queues with the highest rate. The sticky strategy means that when the HTTP2 data stream is created, the dispatcher will select a specified event queue according to the sticky id configured in the interface definition. The sticky strategy can ensure that multiple HTTP2 data streams can be processed by the same downstream worker threads. Because to ensure the thread safety inside each Actor, all messages passed to a specified Actor need to be scheduled to a single thread for processing, so the sticky strategy is necessary in the Actor model design.

[0020] The event queue is used to implement the asynchronous transmission of messages. The event queue adopts the Disruptor circular array data structure and can be divided into two types: single-producer single-consumer (SPSC) queue and multi-producer multi-consumer (MPSC) queue. The SPSC queue is used to connect the IO threads of the upstream transmission module and the worker threads of the downstream executor. The SPSC queue requires that each queue can only correspond to one producer IO thread and one consumer worker thread, which can ensure as few multi-threaded operations as possible and maximize the computing efficiency. The MPSC queue is used for message passing within the system, supports any thread to send messages to this queue, and is processed by a single executor worker thread. The message passing between local Actors is all implemented through the MPSC queue.

[0021] The calculation method for the number of event queues in a system is as follows: Assume that there are n IO threads in the transmission module and m worker threads in the executor in the system. Then the total number of SPSC queues is n * m, the number of downstream SPSC queues corresponding to each IO thread is m, and the number of upstream SPSC queues corresponding to each execution thread is n; the total number of MPSC queues is m, and the number of upstream MPSC queues corresponding to each execution thread is 1.

[0022] In RPC and the Actor model, there are often some processing of timed tasks, such as timeout detection, timed heartbeat, etc., which are all scheduled through timers. The timer adopts the time wheel data structure. When the timed task reaches the execution time point, the timer will send the task to the specified MPSC queue, and finally the task will be executed by the specified executor thread.

[0023] The actuator contains multiple execution threads internally. Each execution thread continuously consumes the upstream event queue and processes the consumed messages. The actuator itself is stateless. For RPC-type messages, the actuator will execute the user-defined code logic based on the RPC interface information parsed by the routing controller and the incoming messages. For Actor-type messages, the actuator will execute the user-defined Actor execution logic based on the Actor information parsed by the routing controller.

[0024] Furthermore, the RPC management module includes: an RPC service terminal sub-module and an RPC client sub-module; the RPC service terminal sub-module interacts with the RPC client sub-module.

[0025] Specifically, on the server side, the RPC service terminal sub-module registers the interface definition with the interface management module according to the server execution logic of the RPC interface defined by the user, and then can provide the RPC service of this RPC interface externally; on the client side, a data stream of an external RPC server can be created through the RPC client sub-module, and an RPC call can be executed.

[0026] Furthermore, the Actor system module includes: a lifecycle manager, a flow health manager, and a serialization registry; the lifecycle manager is connected to the interface management module; the flow health manager is connected to the transport module; the serialization registry is connected to the lifecycle manager.

[0027] Specifically, the lifecycle manager is used to implement the lifecycle management of local Actors. When an Actor is created, the routing, serialization information, sticky id and other interface definition information of the Actor are registered with the interface management module. When the Actor is destroyed, the corresponding interface definition is deleted from the interface management module.

[0028] The flow health manager is used to ensure the continuous availability of the data stream between Actors across nodes. When the data stream is disconnected or an exception occurs, the flow health manager will attempt to recreate a new data stream to ensure timely communication between Actors.

[0029] The Actor model has higher requirements for message serialization capabilities compared to RPC. The message types passed between Actors are often dynamic. Therefore, a unified serialization registration center is needed to uniformly manage message types and serialization. When an Actor is created, the serialization registration center provides the Actor with a serializer of dynamic type and hands it over to the lifecycle manager for interface definition registration. In addition, the serializer generated by the serialization registration center can also support the serialization of Actors. Its essence is the serialization of interface definitions. For example, Actor1 of node a can send itself as the message content to Actor2 of node b. After Actor2 receives this message, it directly communicates with Actor1 for messages. The address of Actor1 is transparent to Actor2.

[0030] Further, the interface management module includes: an interface registration sub-module. The upstream of the interface registration sub-module is connected to the lifecycle manager and / or the RPC management module, and the downstream of the interface registration sub-module is connected to the routing controller.

[0031] Specifically, when an RPC interface is deleted or an Actor lifecycle ends, the corresponding interface information will also be deleted synchronously in the interface registration sub-module.

[0032] The present invention also provides an integration method of RPC and Actor based on HTTP2, which is applied to the integration component of RPC and Actor based on HTTP2 as described above, including: an RPC interface management method, an Actor management method, a network communication data receiving method, and a network communication data sending method. Among them, the RPC interface management method includes:

[0033] A1. The RPC service terminal sub-module registers the interface definition to the interface management module. The interface definition information is synchronized to the routing controller of the transmission module to create an interface, and the interface is completed and put online.

[0034] A2. The RPC service terminal sub-module applies to the interface management module to delete the interface definition information. Subsequently, the interface definition information in the routing controller is synchronously deleted, and the interface is deleted to complete the interface going offline.

[0035] A3. After the client and the server establish a connection, the client directly pulls the available interfaces from the server to obtain the client interfaces.

[0036] The Actor management method includes:

[0037] B1. Lifecycle Management: When the Actor system module creates an Actor, it first binds an interface definition to the Actor and registers the interface definition with the interface management module. The lifecycle manager listens for changes in the Actor's state in real time. When the Actor's lifecycle ends and it needs to be destroyed, the lifecycle manager triggers a cleanup task to delete the interface definition corresponding to the Actor from the interface management module.

[0038] B2. Implementing Local Communication between Actors: Suppose Actor1 sends a message to local Actor2. The data transfer process is as follows: Actor1 obtains the sticky id in the interface definition of Actor2 based on the interface definition information bound to Actor2, finds the execution thread and the MPSC queue corresponding to the execution module based on the sticky id, and sends the message and the interface definition bound to Actor2 to the MPSC queue. After the execution thread pulls the message from the MPSC queue, it executes according to the interface definition without caring whether the message comes from the network or locally.

[0039] The network communication data receiving method includes:

[0040] C1. Network data enters the HTTP2 controller in the transmission module for frame decoding, and the data frame is parsed into binary data.

[0041] Specifically, each TCP connection and the HTTP2 data stream established on this TCP connection are processed by a dedicated IO thread.

[0042] C2. The server receives the data of the HTTP2 request. After the HTTP2 data stream is established, the routing controller parses the request message header to obtain the interface definition information corresponding to the HTTP2 request, and hands the data stream to the downstream for processing. The client receives the data of the HTTP2 response. The routing controller directly obtains the interface definition information according to the request header information corresponding to the data stream of the HTTP2 response, and hands the data stream to the downstream for processing.

[0043] C3. The serializer deserializes the binary data into a message object, and sends the message object and the interface definition information to the dispatcher in the execution module.

[0044] C4. The dispatcher sends the message and the interface definition information to the SPSC queue according to the distribution strategy of the interface definition.

[0045] C5. The execution thread in the execution module pulls the message from the SPSC queue and executes the task according to the interface definition.

[0046] The network communication data sending method includes:

[0047] D1. The client sends a request and the server sends a response.

[0048] D2. The client or the server writes the message to be sent into the write queue of the transmission module. The IO thread of the transmission module pulls the message object data from the write queue and converts the message object data into binary format data through a serializer.

[0049] D3. The frame codec encapsulates the binary format data into a frame and sends the message to the external network.

[0050] Further, the content of registering the interface definition in the interface management module for the RPC interface management method and the Actor management method includes:

[0051] Routing: That is, the one-to-one mapping relationship between the HTTP2 request header and the receiving object.

[0052] Call type: including two types, RPC and Actor.

[0053] Receiving object: If it is the RPC call type, the receiving object is the RPC interface execution logic defined by the server user. If it is the Actor call type, the receiving object is the corresponding Actor.

[0054] Interface type: including four types, request-response, client stream, server stream, and bidirectional stream. If it is the RPC call type, all four types are supported. If it is the Actor call type, only the client stream type is supported.

[0055] Serializer: used to serialize and deserialize the message object used by this interface.

[0056] Sticky id; dispatcher distribution strategy; HTTP2 protocol parameters; connection timeout, heartbeat configuration parameters.

[0057] Among them, the sticky id is a parameter required for the Actor call type. The sticky id is used to ensure that the dispatcher of the execution module can deliver all the messages sent to the same Actor to the same thread for processing. For the RPC call type, this parameter is optional.

[0058] The dispatcher distribution strategy includes polling, random, load balancing, and sticky strategies.

[0059] The HTTP2 protocol parameters are used for optimizing the data transfer of the HTTP2 protocol.

[0060] Preferably, by adopting an event-driven asynchronous non-blocking model and using data structures such as circular arrays and time wheels, the resource occupancy can be further optimized.

[0061] The present invention also provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the steps of the integration method of RPC and Actor based on HTTP2 as described above are implemented.

[0062] The present invention also provides a computer device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of the integration method of RPC and Actor based on HTTP2 as described above are implemented.

[0063] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0064] The integration method of RPC and Actor based on HTTP2 provided by the present invention realizes the integration of two network communication paradigms, namely the RPC and Actor models; these two can be arbitrarily selected for network communication according to design needs. For example, RPC is used for data communication between the server and the client; the Actor model is used for data communication between clusters or large-scale nodes, without the need to maintain two sets of systems and frameworks; efficient and reliable network data communication is achieved; the industry-standard HTTP2 protocol is used for network communication, which can ensure reliable data transmission, connection multiplexing, and flow control; high performance, low latency, and backpressure control of network communication are realized; efficient utilization of system resources is achieved, and the RPC model and the Actor model can share the same network traffic inlet and outlet, which reduces the system resource occupancy while improving the system operation efficiency and can support data communication between large-scale nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] By reading the following detailed description of the preferred embodiments, various other advantages and benefits will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the present invention.

[0066] In the drawings:

[0067] Figure 1 is a schematic diagram of the component structure of the integration component of RPC and Actor based on HTTP2 according to an embodiment of the present invention;

[0068] Figure 2 is the internal execution logic and schematic diagram of the integration component and integration method of RPC and Actor based on HTTP2 according to an embodiment of the present invention;

[0069] Figure 3 is a usage example diagram under the RPC paradigm according to an embodiment of the present invention;

[0070] Figure 4It is a usage example diagram under the Actor paradigm of the embodiment of the present invention;

[0071] Figure 5 It is a schematic diagram of the composition of the computer device according to the embodiment of the present invention. Detailed implementation manners

[0072] Here, the exemplary embodiments will be described in detail, and the examples are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present disclosure. On the contrary, they are merely examples of devices and products consistent with some aspects of the present disclosure as detailed in the appended claims.

[0073] The terms used in the present disclosure are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure. The singular forms "a", "the", and "said" used in the present disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0074] It should be understood that although the terms first, second, third, etc. may be used in the present disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0075] The following further details the embodiments of the present invention.

[0076] The embodiment of the present invention provides an integrated component of RPC and Actor based on HTTP2, as Figure 1 shown, including: an RPC management module, an Actor system module, and an interface management module, a transmission module, and an execution module that are sequentially connected in series; the RPC management module and the Actor system module are respectively connected to the interface management module, register interface definitions to the interface management module, create Actors or add RPC interface services;

[0077] The interface management module is used for adding and deleting interface definitions;

[0078] For each newly added RPC interface or newly created Actor, a corresponding interface definition will be added to the interface management module. When creating an Actor, a sticky id will also be configured in the parameter information of the interface definition to implement the sticky queue selection strategy of the dispatcher;

[0079] The transmission module is the unified entrance and exit for network communication within the system, and is used to implement multiple functions such as network data exchange, data encoding and decoding, and traffic control between services;

[0080] The execution module includes multiple working threads that continuously execute various types of tasks in a loop. The task types include: RPC tasks, Actor message processing tasks, timed tasks, and user-defined asynchronous execution tasks.

[0081] The execution module can require specific threads to execute specified tasks according to the task type and requirements, and provides targeted performance optimizations for both the processing of network communication messages and local asynchronous task processing.

[0082] The transmission module includes: an HTTP2 controller, a routing controller, a serializer, and a write queue; the routing controller is downstream of the HTTP2 controller, and the serializer is downstream of the routing controller; the routing controller interacts with the HTTP2 controller, the serializer interacts with the routing controller, and the write queue is connected to the serializer.

[0083] The HTTP2 controller is used to implement the format conversion between HTTP2 protocol data frames and messages within the system. At the sending end, the frame codec encodes the messages from within the system into HTTP2 data frames; at the receiving end, the frame codec decodes the data frames and passes them to the downstream; and the HTTP2 controller abstracts the TCP connection into an HTTP2 protocol data stream. Multiple data streams can reuse the same TCP connection, and the multiplexing controller can provide traffic control functions. While implementing backpressure control, the blocking of a certain data stream does not affect the data transmission of other data streams;

[0084] The routing controller is used to implement the routing control from the message object to the RPC interface or Actor. The routing controller parses the path information in the HTTP2 request header, finds the serializer and the RPC interface or Actor object corresponding to the request through the internal routing table, and sends this information to the downstream. The routing controller will continuously monitor the changes in the routing information in the routing registration module and update the local routing table.

[0085] The serializer is used at the sending end to serialize message objects from RPC calls and Actors into binary data and pass them to the HTTP2 controller for further encoding into data frames; at the receiving end, it is used to deserialize the binary data decoded by the HTTP2 controller into message objects, and send the message objects and other information parsed by the routing controller to the downstream together;

[0086] The write queue is used for data sending. It adopts the circular array data structure of Disruptor. Messages from external threads are first written into the write queue for caching, and then the IO threads of the transmission module pull data from the write queue, send it to the serializer to be converted into binary format data, and then it is encapsulated into frames by the HTTP2 controller.

[0087] The execution module includes: a dispatcher, an event queue, a timer, and an executor; the dispatcher is connected to the serializer of the upstream transmission module; the event queue is downstream of the dispatcher, the executor is downstream of the event queue, and the executor is connected to the event queue; the event queue includes: an SPSC queue and an MPSC queue; the dispatcher is connected to the SPSC queue, and the timer is connected to the MPSC queue.

[0088] Each IO thread of the upstream transmission module corresponds to a dispatcher, and each dispatcher corresponds to multiple downstream event queues. When a new HTTP2 data stream is created, the dispatcher will select an event queue to bind to the data stream, and then all messages of the data stream are written into this event queue; the dispatching strategies for the dispatcher to select event queues include: round-robin, random, load balancing, and sticky strategies; the load balancing strategy means that the dispatcher will monitor the production and consumption rates of the event queues and select one of the event queues with the highest rate; the sticky strategy means that when the HTTP2 data stream is created, the dispatcher will select a specified event queue according to the sticky id configured in the interface definition. The sticky strategy can ensure that multiple HTTP2 data streams can be processed by the same downstream working threads. Because to ensure the thread safety inside each Actor, all messages passed to a specified Actor must be scheduled to a unique thread for processing, so the sticky strategy is necessary in the Actor model design.

[0089] The event queue is used to achieve asynchronous message passing. The event queue adopts the Disruptor ring array data structure and can be divided into two types: single-producer single-consumer (SPSC) queue and multi-producer multi-consumer (MPSC) queue. The SPSC queue is used to connect the IO thread of the upstream transmission module and the working thread of the downstream executor. The SPSC queue requires that each queue can only correspond to one producer IO thread and one consumer working thread, which can ensure as few multi-threaded operations as possible and maximize the computing efficiency. The MPSC queue is used for message passing within the system. It can support any thread to send messages to this queue and be processed by a single executor working thread. The message passing between local Actors is all implemented through the MPSC queue.

[0090] The calculation method of the number of event queues in a system is as follows: Suppose there are n IO threads in the transmission module and m working threads in the executor in the system. Then the total number of SPSC queues is n * m, the number of downstream SPSC queues corresponding to each IO thread is m, and the number of upstream SPSC queues corresponding to each execution thread is n; the total number of MPSC queues is m, and the number of upstream MPSC queues corresponding to each execution thread is 1.

[0091] In the RPC and Actor models, there are often some processing of timed tasks, such as timeout detection, timed heartbeat, etc. These are all scheduled by the timer. The timer adopts the time wheel data structure. When the timed task reaches the execution time point, the timer will send the task to the specified MPSC queue, and finally the task will be executed by the specified executor thread.

[0092] The executor contains multiple execution threads internally. Each execution thread will continuously consume the upstream event queue and process the consumed messages. The executor itself is stateless. For RPC-type messages, the executor will execute the user-defined code logic according to the RPC interface information parsed by the routing controller and the sent messages. For Actor-type messages, the executor will execute the user-defined Actor execution logic according to the Actor information parsed by the routing controller.

[0093] The RPC management module includes: an RPC service terminal sub-module and an RPC client sub-module; the RPC service terminal sub-module interacts with the RPC client sub-module.

[0094] On the server side, the RPC service terminal sub-module registers the interface definition to the interface management module according to the server execution logic of the RPC interface defined by the user, and then can provide the RPC service of this RPC interface externally; on the client side, a data stream of the external RPC server can be created through the RPC client sub-module and an RPC call can be executed.

[0095] The Actor system module includes: a lifecycle manager, a stream health manager, and a serialization registry; the lifecycle manager is connected to the interface management module; the stream health manager is connected to the transmission module; the serialization registry is connected to the lifecycle manager.

[0096] The lifecycle manager is used to implement the lifecycle management of local Actors. When an Actor is created, the routing and serialization information of the Actor, as well as interface definition information such as sticky ids, are registered with the interface management module. When an Actor is destroyed, the corresponding interface definitions are deleted from the interface management module.

[0097] The stream health manager is used to ensure the continuous availability of the data stream between Actors across nodes. When the data stream is disconnected or an exception occurs, the stream health manager will attempt to recreate a new data stream to ensure timely communication between Actors.

[0098] The Actor model has higher requirements for the ability to serialize messages compared to RPC. The message types passed between Actors are often dynamic, so a unified serialization registry is needed for unified management of message types and serialization. When an Actor is created, the serialization registry provides a dynamic-type serializer for the Actor and hands it over to the lifecycle manager for interface definition registration. In addition, the serializer generated by the serialization registry can also support the serialization of Actors, which is essentially the serialization of interface definitions. For example, Actor1 on node a can send itself as the message content to Actor2 on node b. After Actor2 receives this message, it can directly communicate with Actor1, and the address of Actor1 is transparent to Actor2.

[0099] The interface management module includes: an interface registration sub-module. The upstream of the interface registration sub-module is connected to the lifecycle manager and / or the RPC management module, and the downstream of the interface registration sub-module is connected to the routing controller.

[0100] The embodiment of the present invention also provides an integration method of RPC and Actor based on HTTP2, which is applied to the integration component of RPC and Actor based on HTTP2 as described above, including: an RPC interface management method, an Actor management method, a network communication data receiving method, and a network communication data sending method. Among them, the RPC interface management method includes:

[0101] A1. The RPC service terminal sub-module registers the interface definition with the interface management module. The interface definition information is synchronized to the routing controller of the transmission module, and an interface is created and the interface goes online.

[0102] A2. The RPC service terminal module applies to the interface management module to delete the interface definition information. Subsequently, the interface definition information in the routing controller is synchronously deleted, the interface is deleted, and the interface goes offline;

[0103] A3. After the client establishes a connection with the server, it directly pulls the available interfaces from the server to obtain the client interfaces;

[0104] The described Actor management method includes:

[0105] B1. Lifecycle management: When the Actor system module creates an Actor, it first binds an interface definition to the Actor and registers the interface definition with the interface management module; The lifecycle manager listens to the Actor status changes in real time. When the Actor needs to be destroyed at the end of its lifecycle, the lifecycle manager triggers a cleanup task to delete the interface definition corresponding to the Actor from the interface management module;

[0106] In this embodiment, the content of registering the interface definition to the interface definition in the interface management module in the described RPC interface management method and the described Actor management method includes:

[0107] Routing: That is, the one-to-one mapping relationship between the HTTP2 request header and the receiving object;

[0108] Call type: Includes two types, RPC and Actor;

[0109] Receiving object: If it is the RPC call type, the receiving object is the RPC interface execution logic defined by the server user. If it is the Actor call type, the receiving object is the corresponding Actor;

[0110] Interface type: Includes four types, request-response, client stream, server stream, and bidirectional stream; If it is the RPC call type, all four types are supported; If it is the Actor call type, only the client stream type is supported;

[0111] Serializer: Used to serialize and deserialize the message objects used by the interface;

[0112] Other parameters include: sticky id; dispatcher distribution strategy; HTTP2 protocol parameters; connection timeout, heartbeat configuration, etc.

[0113] Among them, the sticky id is a parameter required for the Actor call type. The sticky id is used to ensure that the dispatcher of the execution module can deliver all the messages sent to the same Actor to the same thread for processing; For the RPC call type, this parameter is optional;

[0114] The dispatcher distribution strategies include round-robin, random, load balancing, and sticky strategies;

[0115] The HTTP2 protocol parameters are used for optimizing data transfer in the HTTP2 protocol.

[0116] B2. Implement local communication between Actors: Suppose Actor1 sends a message to local Actor2. The data transfer process is as follows: Actor1 obtains the sticky id in the interface definition of Actor2 according to the interface definition information bound to Actor2, finds the execution thread and the MPSC queue corresponding to the execution module based on the sticky id, and sends the message and the interface definition bound to Actor2 to this MPSC queue; after the execution thread pulls this message from the MPSC queue, it executes according to the interface definition. There is no need to care whether this message comes from the network or locally.

[0117] The network communication data receiving method includes:

[0118] C1. Network data enters the HTTP2 controller of the transmission module for frame decoding, and the data frame is parsed into binary data;

[0119] C2. The server receives the data of the HTTP2 request. After the HTTP2 data stream is established, the routing controller parses the request message header, obtains the interface definition information corresponding to this HTTP2 request, and hands the data stream to the downstream for processing; the client receives the data of the HTTP2 response, and the routing controller directly obtains the interface definition information according to the request header information corresponding to the data stream of this HTTP2 response, and hands the data stream to the downstream for processing;

[0120] C3. The serializer deserializes the binary data into a message object, and sends the message object and the interface definition information to the dispatcher of the execution module;

[0121] C4. The dispatcher sends the message and the interface definition information to the SPSC queue according to the distribution strategy of the interface definition;

[0122] C5. The execution thread of the execution module pulls the message from the SPSC queue and executes the task according to the interface definition;

[0123] The network communication data sending method includes:

[0124] D1. The client sends a request and the server sends a response;

[0125] D2. The client or the server writes the message to be sent into the write queue of the transmission module. The IO thread of the transmission module pulls the message object data from the write queue and converts the message object data into binary format data through the serializer;

[0126] D3. The frame codec encapsulates the binary format data into frames and sends messages to the external network.

[0127] Figure 2 Shows the internal execution logic and principle of the integration component and integration method of RPC and Actor based on HTTP2 in this embodiment.

[0128] Figure 3 This is a usage example under the RPC paradigm of this embodiment. The server registration interface is defined. The client can establish a connection with the server and support four types of RPC calls: request-response, client stream, server stream, and bidirectional stream. Under the RPC paradigm, the service is centralized, and the client needs to actively establish a connection with the server. The clients are isolated from each other. It is applicable to microservice development and common business development.

[0129] Figure 4 This is a usage example under the Actor paradigm of this embodiment. Each Actor node is equivalent to a server. The communication between Actor nodes is all client streams, that is, the Actor at the source end pushes data to the Actor at the target end in real time. Under the Actor paradigm, the service is decentralized, and Actor nodes can establish connections with each other and communicate with each other, which is applicable to cluster construction.

[0130] The embodiment of the present invention also provides a computer device. Figure 5 This is a schematic structural diagram of a computer device provided by the embodiment of the present invention; see the accompanying drawings Figure 5 As shown, the computer device includes: an input system 23, an output system 24, a memory 22, and a processor 21; the memory 22 is used to store one or more programs; when the one or more programs are executed by the one or more processors 21, the one or more processors 21 implement the integration method of RPC and Actor based on HTTP2 provided in the above embodiment; where the input system 23, the output system 24, the memory 22, and the processor 21 can be connected through a bus or other means. Figure 5 Taking the connection through the bus as an example.

[0131] The memory 22, as a computable device-readable and writable storage medium, can be used to store software programs and computer-executable programs, such as program instructions corresponding to the integration method of HTTP2-based RPC and Actor according to the embodiments of the present invention; the memory 22 may mainly include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the device, etc.; in addition, the memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage devices; in some instances, the memory 22 may further include a memory remotely set relative to the processor 21, and these remote memories can be connected to the device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0132] The input system 23 can be used to receive input digital or character information, and generate key signal inputs related to the user settings and function control of the device; the output system 24 may include display devices such as a display screen.

[0133] The processor 21 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory 22, that is, implements the above-mentioned integration method of HTTP2-based RPC and Actor.

[0134] The computer device provided above can be used to execute the integration method of HTTP2-based RPC and Actor provided in the above embodiments, and has corresponding functions and beneficial effects.

[0135] An embodiment of the present invention also provides a storage medium containing computer-executable instructions. When the computer-executable instructions are executed by a computer processor, they are used to execute the integration method of RPC and Actor based on HTTP2 provided in the above embodiment. The storage medium is any of various types of memory devices or storage devices, including: installation media, such as CD-ROMs, floppy disks, or tape systems; computer system memories or random access memories, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memories, such as flash memories, magnetic media (such as hard disks or optical storage); registers or other similar types of memory elements, etc.; the storage medium may also include other types of memories or combinations thereof; additionally, the storage medium may be located in a first computer system in which the program is executed, or may be located in a different second computer system that is connected to the first computer system through a network (such as the Internet); the second computer system may provide program instructions to the first computer for execution. The storage medium includes two or more storage media that may reside in different locations (e.g., in different computer systems connected through a network). The storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0136] Of course, for a storage medium containing computer-executable instructions provided in an embodiment of the present invention, the computer-executable instructions are not limited to the integration method of RPC and Actor based on HTTP2 described in the above embodiment, and may also execute related operations in the integration method of RPC and Actor based on HTTP2 provided in any embodiment of the present invention.

[0137] So far, the technical solution of the present invention has been described in combination with preferred embodiments. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to relevant technical features, and the technical solutions after these changes or substitutions will all fall within the protection scope of the present invention.

[0138] The above are only the preferred embodiments of the present invention and are not used to limit the present invention; for those skilled in the art, the present invention may have various changes and modifications. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. An integrated component of RPC and Actor based on HTTP2, characterized in that: include: RPC management module, Actor system module, and interface management module, transmission module, and execution module that are sequentially connected in series; the RPC management module and Actor system module are respectively connected to the interface management module, register interface definitions with the interface management module, create Actor or add RPC interface services; The interface management module is used to add and delete interface definitions; The transmission module is a unified entrance and exit for network communication within the system, and is used to implement multiple functions such as network data exchange, data encoding and decoding, and flow control between services; The execution module includes multiple working threads, which continuously execute various types of tasks in a loop. Task types include: RPC tasks, Actor message processing tasks, scheduled tasks, and user-defined asynchronous execution tasks.

2. The integrated component of RPC and Actor based on HTTP2 according to claim 1, characterized in that: The transmission module includes: an HTTP2 controller, a routing controller, a serializer, and a write queue; the routing controller is downstream of the HTTP2 controller, and the serializer is downstream of the routing controller; the routing controller interacts with the HTTP2 controller, the serializer interacts with the routing controller, and the write queue is connected to the serializer.

3. The RPC and Actor integrated component based on HTTP2 according to claim 2, characterized in that: The execution module includes: a distributor, an event queue, a timer, and an executor; the distributor is connected to the serializer of the upstream transmission module; the event queue is downstream of the distributor, the executor is downstream of the event queue, and the executor is connected to the event queue; the event queue includes: an SPSC queue and an MPSC queue; the distributor is connected to the SPSC queue, and the timer is connected to the MPSC queue; The distribution strategies of the event queue selected by the distributor include: polling, random, load balancing and stickiness strategy; the load balancing strategy means that the distributor will monitor the production and consumption rate of the event queue and select one of the event queues with the highest rate; the stickiness strategy means that when the HTTP2 data stream is created, the distributor will select a specified event queue according to the stickiness id configured in the interface definition; the stickiness strategy ensures that multiple HTTP2 data streams can be processed by the same downstream worker thread; The SPSC queue is used to connect the IO thread of the upstream transmission module and the working thread of the downstream executor. The SPSC queue requires that each queue can only correspond to one producer IO thread and one consumer working thread, which can ensure as few multi-threaded operations as possible and maximize computing efficiency; the MPSC queue is used for system-local message transmission and supports any thread to send messages to the queue.

4. The RPC and Actor integrated component based on HTTP2 according to claim 1, characterized in that: The RPC management module includes: an RPC service terminal module and an RPC client submodule; the RPC service terminal module interacts with the RPC client submodule.

5. The RPC and Actor integrated component based on HTTP2 according to claim 2, characterized in that: The Actor system module includes: a lifecycle manager, a stream health manager, and a serialization registration center; the lifecycle manager is connected to the interface management module; the stream health manager is connected to the transmission module; and the serialization registration center is connected to the lifecycle manager.

6. The RPC and Actor integrated component based on HTTP2 according to claim 5, characterized in that: The interface management module includes: an interface registration submodule, the upstream of the interface registration submodule is connected to the lifecycle manager and / or the RPC management module, and the downstream of the interface registration submodule is connected to the routing controller.

7. The RPC and Actor integration method based on HTTP2 is applied to the RPC and Actor integration component based on HTTP2 as described in any one of claims 1 to 6, characterized in that: include: RPC interface management method, Actor management method, network communication data receiving method, network communication data sending method, wherein the RPC interface management method includes: A1. The RPC service terminal module registers the interface definition to the interface management module. The interface definition information is synchronized to the routing controller of the transmission module, and the interface is created and launched. A2. The RPC service terminal module applies to the interface management module to delete the interface definition information, and then the interface definition information in the routing controller is deleted synchronously, the interface is deleted, and the interface is offline; A3. After the client establishes a connection with the server, it directly pulls the available interface from the server to obtain the client interface; The Actor management method includes: B1. Lifecycle management: When creating an Actor, the Actor system module first binds an interface definition to the Actor and registers the interface definition to the interface management module. The lifecycle manager monitors the state changes of the Actor in real time. When the Actor's lifecycle ends and needs to be destroyed, the lifecycle manager triggers a cleanup task and deletes the interface definition corresponding to the Actor from the interface management module. B2. Realize local communication between Actors: Assume that Actor1 sends a message to local Actor2. The data transmission process is as follows: Actor1 obtains the sticky id in the interface definition of Actor2 according to the interface definition information bound to Actor2, finds the execution thread and MPSC queue corresponding to the execution module based on the sticky id, and sends the message and the interface definition bound to Actor2 to the MPSC queue; after the execution thread pulls the message from the MPSC queue, it executes according to the interface definition; The network communication data receiving method comprises: C1. Network data enters the HTTP2 controller of the transmission module for frame decoding, and the data frame is parsed into binary data; C2. The server receives the data of the HTTP2 request. After the HTTP2 data stream is established, the routing controller parses the request message header, obtains the interface definition information corresponding to the HTTP2 request, and hands the data stream to the downstream for processing; the client receives the data of the HTTP2 response. The routing controller directly obtains the interface definition information according to the request header information corresponding to the data stream of the HTTP2 response, and hands the data stream to the downstream for processing; C3, the serializer deserializes the binary data into a message object, and sends the message object and interface definition information to the distributor of the execution module; C4, the distributor sends the message and interface definition information to the SPSC queue according to the distribution strategy defined by the interface; C5, the execution thread of the execution module pulls the message from the SPSC queue and executes the task according to the interface definition; The network communication data sending method comprises: D1. The client sends a request and the server sends a response; D2. The client or server writes the message to be sent into the write queue of the transmission module. The IO thread of the transmission module pulls the message object data from the write queue and converts the message object data into binary format data through the serializer; D3. The frame codec encapsulates the binary format data into frames and sends messages to the external network.

8. The method for integrating RPC and Actor based on HTTP2 according to claim 7, characterized in that: The content of the interface definition registered in the interface management module of the RPC interface management method and the Actor management method includes: Routing: a one-to-one mapping between HTTP2 request headers and receiving objects; Call type: including RPC and Actor; Receiving object: If it is an RPC call type, the receiving object is the RPC interface execution logic defined by the server user. If it is an Actor call type, the receiving object is the corresponding Actor. Interface type: including request-response, client stream, server stream, and bidirectional stream. If it is an RPC call type, all four types are supported. If it is an Actor call type, only the client stream type is supported. Serializer: used to serialize and deserialize the message objects used by this interface; Sticky ID; distributor distribution strategy; HTTP2 protocol parameters; connection timeout, heartbeat configuration parameters.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the HTTP2-based RPC and Actor integration method described in claim 7 or 8 are implemented.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the RPC and Actor integration method based on HTTP2 as described in claim 7 or 8 are implemented.

Images