silentchildh opened a new pull request, #4317: URL: https://github.com/apache/eventmesh/pull/4317
Fixes #549 ### Motivation - Unified TCP and HTTP code styles - Optimize code encapsulation and reduce coupling - More careful subcontracting and naming enhances readability #### boot Firstly, I divided the server into three layers: 1. The most basic layer is `AbstractRemotingServer` . It leverages Netty for the most basic communication server. 2. Then there are the protocol-layer servers that enable the runtime module to run simply, such as `AbstractTcpServer` and `AbstractHttpServer`. 3. Finally, there are `EventMeshXxxServer` that integrate multiple capabilities (typically a manager that assembles the capabilities to enhance the server) , such as `EventMeshTCPServer` and 'EventMeshHTTPServer`. In my opinion, the most important part of the runtime module is the "processor" . The main component of the second-tier server is the "processor" . That is, declare the "processor" required for registration in the Layer 2 server `AbstractXXXServer` to build the layer server. In layer 3 server, I prefer pluggable plug-in design. That is, in the process of extending the "processor" , if there is a function that requires other modules, add the manager of the corresponding function in this layer. The processor then retrieves the corresponding manager through the `EventMeshXxxServer` instance. For example : - To better manage event/message production and consumption in the runtime module, `ProducerManager` and `ConsumerManager` are provided. - `Registry` is provided for cluster deployment of eventmesh servers. - The rest of the modules, such as 'security' and 'metric' , can be inserted into the corresponding manager in the tier 3 server. #### core Here is my understanding of the refactored core package and what it takes to implement a server based on `EventMeshHTTPServer`. - Producer is used to upload messages from the client to the message storage. - Consumer is used to download messages from the message storage to the client. - The retry mechanism is needed to ensure the security and reliability of messages, whether they are uploaded or downloaded. - The server-side operation is based on the processor implementation. ### Modifications boot: - So I implemented TCP's second-tier server, `AbstractTcpServer` . I've used all of Netty's required handlers as `AbstracTcpServer` internal classes to better manage this tier of servers. - And registered "processor" in the third-tier server juts like `EventMeshHTTPServer` - I think the creation and use of threads is actually the basis for the server to run, so I put it on the second-tier server and used an interface `ThreadPoolGroup` to normalize it, the implementation classes of this interface can assemble the required thread pool. core: - During the refactoring I found that producer and consumer can actually be abstracted out and used by both TCP and HTTP. - Also related to HTTP are `SubcriptionManager` and `HttpClientGroupMapping`, which hold data locally on the `EventMeshHTTPServer` about the relationships between clients, producers, and subscription items, so I pulled it out and put it in the local package. - The original `ClientSessionGroupMapping` and `ClientGroupWrapper` classes in TCP record client, session, producer, consumer, and subscription project relationships locally. Now that I've decoupled it so that `ClientManager` focuses on the relationship between the client and the session, `SessionManager` uses `ProducerMap` to record the relationship between the producer and the session, and `ConsumerMap` to record the relationship between the consumer and the session, `SubscriptionMap` records the relationship of the subscription item to the session. ### Documentation - Does this pull request introduce a new feature? (yes / no) - If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented) - If a feature is not applicable for documentation, explain why? - If a feature is not documented yet in this PR, please create a followup issue for adding the documentation -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
