Run mvn spotless:applywith jdk17+ to fix code format

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 61.00%. Comparing base (192d433) to head (88905cf).

@@             Coverage Diff              @@
##                3.3   #15561      +/-   ##
============================================
- Coverage     61.00%   61.00%   -0.01%     
- Complexity    11495    11497       +2     
============================================
  Files          1909     1909              
  Lines         86777    86779       +2     
  Branches      13093    13093              
============================================
- Hits          52942    52941       -1     
- Misses        28416    28418       +2     
- Partials       5419     5420       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

if DubboServiceAddressURL#getServiceInterface has problems, why not add @Override method to it?

The content you expressed is a little difficult to understand, i try to explain it based on my own understanding.

NacosAggregateListener will aggregate all instances into each service.

NacosAggregateListener aggregates instances to service instances map which grouped by service name.

every instances in NacosAggregateListener will be related to the consumerURL URL of each service when build DubboServiceAddressURL from instance and DubboServiceAddressURL#getServiceInterface is realized as ## return consumerURL.getServiceInterface() ##

1. Every service instance that NacosAggregateListener aggregated is related to the consumerURL of the service.
2. Every DubboServiceAddressURL was built from the service instance.
3. DubboServiceAddressURL#getServiceInterface method took the result of consumerURL#getServiceInterface as it's return value.

every single service changed , the Subscriber will process all the service, and cache file store the all related service info. #15267

The subscriber will be notified with all service info even just one service instance status is changed, e.g.,
there are 3 services which names are A,B and C, let's say A has 100 instances, B has 200 instances, C has 300 instances, the subscribe will be notified with all A,B,C service instances info(100+200+300) even just one instance of service A or B or C changed.

so you want change the result of DubboServiceAddressURL#getServiceInterface to limit the notification scope of dubbo service instance changing event?

you'd better provide test comparison report to show the effectiveness of this PR.

so the notified instance will be very big ,and if we use local file cache , it will wirte all the content to file when every time notify method invoked.

in our test env, we have 1500+ service ,and 2200 + instance info. Dubbo-admin need 4G to save the URL info .it need more in pro env,the dubbo-admin start very slow.

in our test env, we have 1500+ service ,and 2200 + instance info. Dubbo-admin need 4G to save the URL info .it need more ,the dubbo-admin start very slow.

i see.

i doubt it's not only dubbo-admin that has this problem, getServiceInterface might need to get service interface from super when consumerURL.getParameter(SIDE_KEY) is PROVIDER_SIDE

if the issue only existed in nacos, maybe the simplest way is using zk as your register center because it's difficult to determine this pr might affect existed applications or not.
According to other member saying, more than one big issues occurred due to nacos getServiceInterface codes modification in the history. He prefer you get atomic object directly and deal it at dubbo-admin.

We have old services using old versions of dubbo (zk 3.4), springboot, and JDK, and some new services using higher versions of dubbo, Springboot, and JDK. So the solution we use is dual registration of zk and nacos, and all services will be registered with nacos. After all old services are upgraded, we can use the higher version of zk as a registration center, but this process will be longer.

You are right. Directly modifying the ServiceAddress URL will have a wide impact. This problem is mainly caused by the dubbo-admin scenario and nacos' compatibility with the old service format. Do we have plans to remove nacos' support for the old service format?

You are right. Directly modifying the ServiceAddress URL will have a wide impact. This problem is mainly caused by the dubbo-admin scenario and nacos' compatibility with the old service format. Do we have plans to remove nacos' support for the old service format?

i don't know. As for me, you might customize‌ these codes to meet your requirements. it's not easy to remove or modify any existed algorithm of community edition due to compatibility reason.

i doubt it's not only dubbo-admin that has this problem, getServiceInterface might need to get service interface from super when consumerURL.getParameter(SIDE_KEY) is PROVIDER_SIDE

This PR is limited to the admin protocol and will not affect other features.

What do you plan to do? In the dubbo-admin scenario, create a separate NacosAggregateListener object instance for each service?

In the dubbo-admin scenario, create a separate NacosAggregateListener object instance for each service?

As for me, it might be better to customerize your dubbo-admin. By now, there are no plan to modify Dubbo for this scenario.