YoWuwuuuw opened a new issue, #7532: URL: https://github.com/apache/incubator-seata/issues/7532
### Check Ahead - [x] I have searched the [issues](https://github.com/seata/seata/issues) of this repository and believe that this is not a duplicate. - [x] I am willing to try to implement this feature myself. ### Why you need it? > base: https://summerofcode.withgoogle.com/programs/2025/projects/jI0IGDJg Seata's current registry mechanism only supports raw service registration based on IP and port, lacking support for service metadata. This limitation hinders the implementation of advanced routing and load balancing strategies. This project aims to **introduce metadata support into the registry system** , enabling Seata to recognize and manage metadata associated with service instances, thus supporting flexible routing and load balancing strategies such as weighted distribution and region-based routing. ### How it could be? #### Summary 1）Metadata registration and discovery This feature focuses on enhancing the `discovery` module by introducing a new RegistryService structure `ServiceInstance` that **supports metadata registration and discovery.** Currently, full-process metadata registration and discovery are **supported** for the **`namingserver` registry type**: ● `Server` → uploads metadata → `namingServer` ● `Client` → fetches metadata → `namingServer` 2）Metadata usage A simple **`WeightedRandomLoadbalance` strategy has been added** to demonstrate metadata-based decision making. Advanced weighted strategies will be supported in future enhancements. #### Architecture & Design 1）Metadata support - Introduced a generic abstraction `ServiceInstance` to replace the original `InetSocketAddress` - Encapsulates service address and metadata map - Supports metadata extension - Maintains backward compatibility with the original IP + Port model - Updated the RegistryService interface and usage in `seata-core`, `seata-server`, and `discovery `modules accordingly - ServiceInstance Interaction Diagram: ```mermaid sequenceDiagram participant Server participant RegistryService participant ServiceInstance Server->>ServiceInstance: Construct ServiceInstance(address, metadata) Server->>RegistryService: register(ServiceInstance) RegistryService-->>Server: Registration successful Server->>RegistryService: unregister(ServiceInstance) RegistryService-->>Server: Unregistration successful ``` 2）Enhancements to `namingserver` module The existing `NamingServerNode` and related classes in the `namingserver` module already support `Map<String, Object> metadata = new HashMap<>()`, enabling native support for metadata registration and discovery. Thus, metadata from the server can be incrementally added without changing the internal implementation of `namingserver`. Relevant enhancements are made in the `discovery-namingserver` module. ### Other related information #### Future Work - **Extend metadata support** to all currently supported registry implementations (excluding 'file' mode), such as `Nacos` and `Zookeeper` - Support **advanced load balancing strategies**, including performance-based strategies like response-time weighting and connection-count weighting - Support **metadata-based routing rules with logical composition capabilities** (e.g., AND, OR), enabling **multi-condition matching for complex business scenarios** - **Integrate with `Kubernetes-native` service registration and discovery mechanisms**, including full metadata capabilities #### Notes ● Why use `ServiceInstance` instead of `common.metadata.Instance`: The `Instance` class is mainly designed for internal server instance management and for interaction with the `namingserver`. It includes several namingserver-specific fields (such as `ClusterRole`, `Node.Endpoint`, etc.) and is tightly coupled with internal logic. `ServiceInstance` is introduced as a lightweight, decoupled abstraction focused solely on representing service nodes with address and metadata, making it more suitable for generic usage across modules. ● Server-side metadata loading: Server metadata configuration is natively supported, as seen at the following code locations: ``` src/main/java/org/apache/seata/server/instance/GeneralInstanceStrategy.java src/main/java/org/apache/seata/server/instance/RaftServerInstanceStrategy.java ``` -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
