zhaohai666 opened a new issue, #427: URL: https://github.com/apache/rocketmq-dashboard/issues/427
# \[studio\]\[Feature\]\[RIP\-1\]\[Track1\] ARCH\-01 \& BASE\-01 Design Specification ## 1\. Overview This feature implements the two foundational core modules of RocketMQ Studio RIP\-1 Track1: **ARCH\-01 SPI Framework** and **BASE\-01 Baseline Migration**\. It establishes the new 3\-tier control\-plane architecture for RocketMQ Dashboard, unifies heterogeneous cluster access logic, and completes a full technology stack upgrade while retaining all original v2\.1\.0 baseline capabilities\. This work serves as the mandatory underlying foundation for all subsequent RIP\-1 modules \(metadata management, ACL adaptation, observability, client diagnosis\) and lays the architecture baseline for RIP\-3 AI\-native interaction capabilities\. ## 2\. ARCH\-01 SPI Framework Design ### 2\.1 Design Purpose The original dashboard relies on hard\-coded version judgments and fixed SDK calling logic, which cannot adapt to RocketMQ 4\.x Broker architecture, 5\.x Proxy architecture, and cloud managed clusters simultaneously\. The SPI framework solves version fragmentation, multi\-protocol differences, and cloud vendor differentiation, realizing **capability\-driven dynamic adaptation**\. ### 2\.2 Core SPI Abstraction Three orthogonal core interfaces are defined under the `org.apache.rocketmq.dashboard.architecture` package to decouple cluster topology, data query, and command execution: - **ClusterProvider**: Responsible for cluster registration, health check, connection initialization, adapting NameServer direct connection and Proxy endpoint connection modes\. - **MetadataProvider**: Unified metadata data source contract, covering all dashboard query capabilities such as clusters, topics, consumer groups, broker status, and message traces\. - **AdminClient**: Unified operation execution layer, encapsulating Remoting\-based `DefaultMQAdminExt` and gRPC\-based Proxy admin SDK\. ### 2\.3 Multi\-Environment Provider Implementation The framework provides out\-of\-the\-box implementation providers for mainstream deployment modes: - V4 series providers: Adapt traditional Broker\-centric 4\.x clusters based on Remoting protocol - V5 Proxy series providers: Adapt 5\.x cloud\-native Proxy clusters based on gRPC protocol - Abstract cloud provider: Factory\-mode extension for Alibaba Cloud, AWS and other managed RocketMQ services ### 2\.4 Cluster Capability Negotiation Model A runtime `ClusterCapability` model is introduced as the front\-end and back\-end interaction contract\. The backend dynamically detects cluster features, including namespace isolation, LiteTopic, Pop consumption, gRPC, ACL 2\.0 and other capability flags\. The front\-end uses React Context global state to perceive cluster capabilities and realizes **conditional rendering of functions**, completely replacing traditional hard\-coded version judgment logic\. ### 2\.5 Frontend Capability\-Aware Component System A set of capability\-driven wrapper components is implemented for core business pages: - Capability\-aware Topic management: Automatically display or hide namespace and LiteTopic functions according to cluster capabilities - Capability\-aware ACL management: Automatically switch ACL1\.0 simple mode and ACL2\.0 role\-based fine\-grained permission mode ### 2\.6 Architecture Switch Configuration Support four running modes through unified configuration: `v4`, `v5-proxy`, `cloud`, `auto`\. The framework automatically loads the corresponding provider implementation to achieve zero\-intrusion switching of cluster architecture modes\. ## 3\. BASE\-01 Baseline Migration Design ### 3\.1 Migration Goals Completely upgrade the legacy dashboard technical stack, reconstruct the front\-end and back\-end architecture in a layered and modular manner, and ensure **full baseline capability equivalence** with the original version, without any functional degradation\. ### 3\.2 Backend Architecture Reconstruction Split the original monolithic code into domain\-driven modular structure, adopt **Controller\-Service\-Repository** layered design, and unify data access through repository interface abstraction instead of direct MQ SDK calls\. Introduce memory stub repository to support local mock development, laying the foundation for subsequent persistent expansion\. Add **compatible alias controller** to ensure smooth transition of old and new APIs, adopting the strangler fig incremental migration mode\. ### 3\.3 Frontend Full Stack Upgrade Complete front\-end technology stack iteration: - Build tool: CRA \-\> Vite6 - Runtime: React17 \-\> React18 - UI component: AntD4 \-\> AntD5 \+ TailwindCSS - State management: scattered Redux \-\> centralized Zustand Reorganize page modules according to business domain, unify API service encapsulation, and support global mock development mode\. ### 3\.4 Engineering \& Deployment Upgrade Complete container transformation, support Docker multi\-stage build and Docker Compose one\-click deployment of the full RocketMQ 5\.x development stack, including NameServer, Broker, Proxy and Dashboard integrated environment\. ## 4\. Incremental Delivery Boundary \(Current PR Scope\) This delivery only focuses on the underlying architecture foundation, **excluding all subsequent feature iterations**: ✅ Included: - Complete SPI three\-layer interface definition and multi\-architecture provider implementation - Cluster capability detection and front\-end dynamic adaptation framework - Full stack baseline migration and architectural reconstruction - Compatibility guarantee of all original dashboard basic management capabilities ❌ Not included \(delivered in subsequent independent PRs\): - Namespace, LiteTopic and other advanced metadata features - ACL2\.0 full adaptation and audit log capability - Monitoring metrics, client diagnosis and business enhancement functions - LLM, MCP, AI dialogue and all RIP\-3 related capabilities ## 5\. Architecture Value - **Unified heterogeneous cluster management**: Solve the historical problem of incompatible adaptation of RocketMQ 4\.x/5\.x/cloud clusters - **Eliminate hard\-coded version branches**: Realize true capability\-driven UI and logic adaptation - **Standardize engineering architecture**: Lay a unified modular foundation for all subsequent Studio new features - **Support long\-term iteration**: SPI pluggable design facilitates subsequent new architecture and new vendor extension ## 6\. Compatibility \& Risk Control - All original functions are fully compatible, no business degradation - Dual\-frontend coexistence \+ compatible alias API ensures smooth migration - Configurable architecture mode supports rolling switch and rollback - Pure underlying architecture refactoring, no impact on upper\-layer business logic > （注：部分内容可能由 AI 生成） -- 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]
