Hello, Community. It's time to discuss about the structure of control panel now. In recent project repo, control-panel with five modules:
shardingsphere-control-panel ├── shardingsphere-cluster │ ├── shardingsphere-cluster-configuration │ ├── shardingsphere-cluster-facade │ ├── shardingsphere-cluster-heartbeat │ ├── shardingsphere-cluster-state ├── shardingsphere-control-panel-spi ├── shardingsphere-metrics │ ├── shardingsphere-metrics-configuration │ ├── shardingsphere-metrics-facade │ ├── shardingsphere-metrics-prometheus │ ├── shardingsphere-metrics-spi ├── shardingsphere-opentracing ├── shardingsphere-orchestration │ ├── shardingsphere-orchestration-core │ │ ├── shardingsphere-orchestration-core-common │ │ ├── shardingsphere-orchestration-core-config │ │ ├── shardingsphere-orchestration-core-facade │ │ ├── shardingsphere-orchestration-core-metadata │ │ ├── shardingsphere-orchestration-core-registry │ │ ├── shardingsphere-orchestration-core-schema │ ├── shardingsphere-orchestration-repository │ │ ├── shardingsphere-orchestration-repository-api │ │ ├── shardingsphere-orchestration-repository-provider And obviously there are some details need to clearify here: · control-panel is a logic component, not an entity · orchestration is not clear for config and registry center, governance is more accurate · cluster and heartbeat modules shoule be a part of governance module · opentracing is an implementation of tracing, and metrics/tracing are parts of observability So we will refactor control-panel to two first level module of ShardingSphere: shardingsphere-observability ├── shardingsphere-observability-spi ├── shardingsphere-observability-metrics │ ├── shardingsphere-observability-metrics-configuration │ ├── shardingsphere-observability-metrics-facade │ ├── shardingsphere-observability-metrics-prometheus │ ├── shardingsphere-observability-metrics-spi ├── shardingsphere-observability-tracing │ ├──shardingsphere-observability-opentracing shardingsphere-governance ├── shardingsphere-governance-spi ├── shardingsphere-governance-core │ ├── shardingsphere-governance-core-common │ ├── shardingsphere-governance-core-config │ ├── shardingsphere-governance-core-facade │ ├── shardingsphere-governance-core-metadata │ ├── shardingsphere-governance-core-registry │ ├── shardingsphere-governance-core-schema ├── shardingsphere-governance-repository │ ├── shardingsphere-governance-repository-api │ ├── shardingsphere-governance-repository-provider ├── shardingsphere-governance-cluster │ ├── shardingsphere-governance-cluster-configuration │ ├── shardingsphere-governance-cluster-facade │ ├── shardingsphere-governance-cluster-heartbeat │ ├── shardingsphere-governance-cluster-state And after this refactoring, we should uniform Callback/EventBus mechanism, and ensure to use SPI/Facade to integration with other module. Task list: · Consider about structure of Orchestration&Control-Panel projectshttps://github.com/apache/shardingsphere/issues/6653 · Consider about merge Callback and OrchestrationEventBushttps://github.com/apache/shardingsphere/issues/6585 · Consider about redesign metrics configurationhttps://github.com/apache/shardingsphere/issues/6577 · Consider about merge OrchestrationFacade and ControlPanelFacadehttps://github.com/apache/shardingsphere/issues/6572 · Use SPI to introduce ClusterConfiguration in OrchestrationShardingSphereDataSourcehttps://github.com/apache/shardingsphere/issues/6547 · Should use SPI to introduce metrics in SingletonFacadeEngine.buildMetrics which calling on FrontendChannelInboundHandlerhttps://github.com/apache/shardingsphere/issues/7013
