You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@dubbo.apache.org by "Alex Stocks (Jira)" <ji...@apache.org> on 2026/03/29 10:50:00 UTC
[jira] [Commented] (DUBBO-150) Refactoring and Capability Enhancement of the Dubbo-Go Metadata Subsystem
[ https://issues.apache.org/jira/browse/DUBBO-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18069365#comment-18069365 ]
Alex Stocks commented on DUBBO-150:
-----------------------------------
[~solomax] our dubbo-go members thank you for your help.
> Refactoring and Capability Enhancement of the Dubbo-Go Metadata Subsystem
> -------------------------------------------------------------------------
>
> Key: DUBBO-150
> URL: https://issues.apache.org/jira/browse/DUBBO-150
> Project: Apache Dubbo
> Issue Type: Wish
> Reporter: Alex Stocks
> Priority: Major
> Labels: Dubbo, dubbo-go, gsoc, gsoc2026
> Original Estimate: 2,688h
> Remaining Estimate: 2,688h
>
> h2. Abstract
> Metadata is a core component in the Dubbo ecosystem, enabling service discovery, governance, and cross-language interoperability. While Dubbo Java and dubbo-go-3.0 provide a relatively complete and well-structured metadata subsystem, the current implementation in Dubbo-Go still lacks key capabilities and architectural clarity.
> This project aims to systematically refactor and enhance the Dubbo-Go metadata subsystem by introducing a standardized Identifier system, completing the MetadataReport abstraction, adding ServiceDefinition support, and improving reliability through unified retry mechanisms and optional local caching. The goal is to align Dubbo-Go with the mature design of Dubbo Java while maintaining Go idioms and backward compatibility.
> This work will significantly improve the consistency, extensibility, and production readiness of Dubbo-Go’s metadata infrastructure.
> ----
> h2. Detailed Description
> Metadata in Dubbo is responsible for managing application-level metadata, service-level metadata, service name mappings, service definitions, and runtime URLs. It forms the foundation for service registration, discovery, and governance.
> Although Dubbo-Go has partially implemented metadata-related capabilities, several critical gaps remain:
> * Lack of a unified *Identifier system*, leading to inconsistent key/path generation across metadata backends.
> * Incomplete *MetadataReport abstraction*, missing service definition storage, URL lifecycle management, and destruction operations.
> * Absence of *ServiceDefinition support*, preventing fine-grained service modeling.
> * Mixed responsibilities in {{metadata_service.go}}, resulting in unclear module boundaries and reduced maintainability.
> * Fragmented retry logic without centralized scheduling or observability.
> * No local metadata caching mechanism, affecting system resilience.
> * Incomplete *MetadataServiceExporter lifecycle abstraction*.
> These issues limit the maintainability, extensibility, and long-term evolution of the metadata subsystem.
> The core goal of this project is:
> {quote}*To systematically redesign and complete the Dubbo-Go metadata subsystem while preserving backward compatibility and aligning with the broader Dubbo ecosystem.*
> {quote}
> ----
> h2. Deliverables
> h3. Core Enhancements (Priority P0)
> * Implement a standardized *Identifier system*
> * Unified key/path generation for application, service, and subscriber metadata
> * Reusable across all metadata backends
> * Complete *MetadataReport abstraction*
> * Application metadata publish/get/remove
> * Provider/Consumer metadata storage
> * URL management (exported/subscribed)
> * Lifecycle destroy support
> * Introduce *ServiceDefinition model*
> * ServiceDefinition / MethodDefinition / TypeDefinition
> * JSON-based serialization (initial version)
> ----
> h3. Architecture and Reliability Improvements (Priority P1)
> * Refactor metadata service structure:
> * Split service / exporter / adapter / info modules
> * Improve testability and maintainability
> * Implement unified *retry and failure recovery mechanism*
> * Centralized scheduler
> * Configurable retry and backoff strategies
> * Failure tracking
> * Introduce optional *local metadata cache*
> * File-based cache for resilience
> * Graceful degradation when metadata center is unavailable
> * Enhance *MetadataServiceExporter lifecycle*
> * Export / Unexport / GetExportedURLs / IsExported
> ----
> h3. Supporting Work (Priority P2)
> * Unit and integration tests
> * Documentation and design spec
> * Migration and compatibility guidelines
> ----
> h2. Implementation Plan
> h3. Phase 1: Analysis and Design
> * Analyze current Dubbo-Go metadata implementation and identify gaps
> * Study Dubbo Java and dubbo-go-3.0 designs
> * Design Identifier abstraction and MetadataReport extension
> * Define ServiceDefinition model structure
> * Draft architecture refactoring plan
> ----
> h3. Phase 2: Core Capability Implementation (P0)
> * Implement Identifier system and integrate into metadata backends
> * Extend MetadataReport interface and core implementations
> * Implement ServiceDefinition model and serialization
> * Ensure backward compatibility
> ----
> h3. Phase 3: Architecture Refactoring and Reliability (P1)
> * Refactor {{metadata_service.go}} into modular structure:
> metadata/
> └── service/
> ├── interface.go
> ├── service.go
> ├── exporter.go
> ├── adapters.go
> └── service_info.go * Implement unified retry mechanism
> * Add local cache support
> * Enhance exporter lifecycle abstraction
> ----
> h3. Phase 4: Testing and Documentation (P2)
> * Add comprehensive unit tests and integration tests
> * Validate compatibility with existing metadata backends
> * Provide usage examples and documentation
> * Write design documentation for future contributors
> ----
> h2. Required Skills
> * Proficiency in Go programming and familiarity with concurrent system design
> * Understanding of distributed systems and service governance concepts
> * Familiarity with Dubbo architecture or similar RPC frameworks
> * Experience with metadata systems, service discovery, or configuration centers (e.g., Nacos, Zookeeper, Etcd)
> * Ability to read and understand Java code (for referencing Dubbo Java implementation)
> ----
> h2. Benefits to Apache Dubbo-go
> * Improved consistency across Dubbo language implementations (Java and Go)
> * Stronger extensibility for future metadata and governance features
> * Reduced maintenance cost through cleaner architecture
> * Improved system resilience via retry and caching mechanisms
> * Better support for cross-language interoperability
> * Lower barrier for contributors due to clearer abstractions
> ----
> h2. Conclusion
> This project provides a systematic redesign of the Dubbo-Go metadata subsystem, addressing both missing capabilities and architectural limitations. By aligning with the proven design of Dubbo Java while preserving Go idioms, it lays a solid foundation for future evolution in service governance, cross-language interoperability, and metadata-driven features.
> ----
> h2. Useful Links
> * [https://github.com/apache/dubbo-go]
> * [https://github.com/apache/dubbo-go/issues/3188]
>
> ----
> h2. Contact Information
> * Mentor Name: Xinfan Wu [[wuxinfan@apache.org|mailto:wuxinfan@apache.org]], Apache Dubbo Committer
--
This message was sent by Atlassian Jira
(v8.20.10#820010)