silentchildh opened a new pull request, #4333: URL: https://github.com/apache/eventmesh/pull/4333
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 : - `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. ### 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 - Convert a task under the TCP protocol to a processor ### 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: dev-unsubscr...@eventmesh.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@eventmesh.apache.org For additional commands, e-mail: dev-h...@eventmesh.apache.org
