[Improvement]: Make Controller Depend on Stateless Services

[baiyangtx]

Search before asking

• I have searched in the issues and found no similar issues.

What would you like to be improved?

To support multi-node deployment of AMS REST services(as mentioned in issue #2810 ), we must refactor the Controller implementation and its dependent service layer to be stateless.

How should we improve?

Based on the previous discussion at #2997, the current services will be split into two types: stateless services and stateful services.

Firstly, these two types of services will adhere to the following standards:

1. All stateless service interfaces will have the suffix Manager such as CatalogManager or OptimizerManager.

2. Stateless services can provide more complex functionalities than direct database access, such as CatalogCache, etc., but they must assume that state changes will occur on other nodes. Therefore, stateless services need to pay attention to maintaining the consistency between in-memory objects and the database state.

3. Stateful service interfaces will have the suffix Service such as TableService or OptimizingService, and will share a common parent interface named StatefulService, which includes an initialize method and a dispose method. All methods of the stateful service interfaces must check the initialization state.

4. Stateless services will be initialized before the leader election, and stateful services will be initialized after the election, and will only be initialized on the master node.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Subtasks

I will break down the task into several subtasks to advance the goal in parallel.

1.Refactoring of the TableService Interface

• CatalogManager: The TableService interface will no longer inherit from CatalogService, and CatalogService will be modified to become a stateless CatalogManager.
• InternalTableManager: Interfaces related to TableMetadata management will be extracted into InternalTableManager, which will be used by IcebergRestCatalogServer.
• TableBlockerManager: Interfaces related to TableBlocker will be extracted into TableBlockerManager, which will be used by MixedFormat and Table Thrift API.
• MaintainedTableManager: Interfaces related to ServerTableIdentifier and TableRuntimeMeta will be extracted into MaintainedTableManager, which will be used by Process and Optimizing-related controllers.
• TableService: The remaining functionality of TableService will be retained, including the maintenance of TableRuntime and the implementation of the TableRuntimeHandler listener chain invocation.

2.Refactoring of the DefaultOptimizingService Interface

• Extract the implementation of OptimizerManager from DefaultOptimizingService and reimplement it as a stateless service.
• Refer to the design of TableConfig refresh and TableRuntimeHandler to implement the refresh and exploration of OptimizingGroupConfig(due to modifications may not take place on the master node).

3.Implement the forwarding of necessary requests to the master node.

Since some features can only be implemented on the Master (such as Kill Process), it is necessary to provide a mechanism to send requests to the master node.

• Obtain the master's service address based on service discovery, which requires writing the HTTP port to ZooKeeper as well.
• Forward requests to the master node using the HTTP client generated based on Swagger.

Code of Conduct

• I agree to follow this project's Code of Conduct