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