Add multicast support to registery module

[YoWuwuuuw]

I have been learning about seata's registery module recently. Given my previous study of dubbo's registery module, I wonder if seata can also add support for multicast functions like dubbo does. For example, during local testing, multicast functions could be used directly for service discovery, eliminating the need to start any central nodes. This would greatly facilitate small-scale applications and local testing environments. If it's feasible, I'd like to try.

[slievrly]

The default registration type is file, which means direct connection and dynamic service discovery is not used. Generally this mode is used for local debugging. The configuration is as follows:

seata.registry.type=file
seata.tx-service-group=default_tx_group
seata.service.vgroup-mapping.default_tx_group=default
seata. service. grouplist. default = 127.0.0.1:8091

Are there any other usage scenarios for multicast, and what are its usage limitations?

[YoWuwuuuw]

I think the solution for service discovery based on multicast is a 'plus' of the file-based solution

Enhancement of multicast:

1. Simplified configuration: There is no need to manually write the address of server cluster or single instance into the configuration file, only the address of Multicast group can be specified uniformly
2. Dynamism and flexibility: The online and offline of TC instances can be automatically perceived by the Seata client, and the client can dynamically adjust the TC list to optimize its connection allocation with available TC instances (load balancing)
3. Automated testing: Multicast In the automated testing environment, TC instances can be dynamically started and stopped, Seata The client can automatically discover TC instances without modifying the configuration file

Shortcomings of multicast:

1. Reliability: It relies on the UDP protocol and needs to use a retry mechanism to mitigate packet loss, but it cannot fully guarantee message reliability.
2. Security: There is no encryption and authentication mechanism provided by the registration center
3. Network restrictions: can only be used within the LAN

Based on these characteristics, I think the implementation of multicast is more convenient and easy to use for local testing, distributed deployment, and small applications than file-based service discovery

[funky-eyes]

Seata already supports the file registration center type. You can directly fill in the corresponding service address of the Seata server, so I think the multicast mode is not very necessary.

[YoWuwuuuw]

okok, I understand. May I ask if there are any enhancements/pain points/bugs in the discovery module? I am interested in this module.