答复: [DISCUSSION][JAVA-CHASSIS] Refactor IpPort List in org.apache.servicecomb.serviceregistry.client.IpPortManager

[Liubao (A)]

Your explain is correct. I think is not a very critical problem, since 
CacheEndpoint carries instance information while microservice.yaml list do not 
have this. 

We do not merge the two list because they may not redundant in some situations, 
e.g. when you access service center after a firewall or use DNS, you cannot use 
the discovered address. Separate them can make the discovery logic more stable 
and predictable. 

Anyway, please feel free to submit PR's if you have better implementation for 
this. 

-----邮件原件-----
发件人: Ang Li [mailto:liang951...@qq.com] 
发送时间: 2020年1月22日 17:30
收件人: dev <dev@servicecomb.apache.org>
主题: [DISCUSSION][JAVA-CHASSIS] Refactor IpPort List in 
org.apache.servicecomb.serviceregistry.client.IpPortManager

Hi Team,&nbsp;


In&nbsp;org.apache.servicecomb.serviceregistry.client.IpPortManager, we used 
List<IpPort&gt; and List<CacheEndpoint&gt; to handle ipPort:
- List<IpPort&gt; is used to maintain default ip ports from microservice.yaml;
- List<CacheEndpoint&gt; is used to maintain CacheEndpoints from 
instanceManager.


I have following questions about that:
1. The only usage of CacheEndpoint here is to get IpPort; 2. CacheEndpoint list 
and IpPort list may have the same ip port which is redundant, and no any 
deduplication in code. Which will lead to the maxRetryTimes (size of 
List<IpPort&gt; add size of List<CacheEndpoint&gt;) exceed actual SC ip port 
count; 3. Two different lists with different data types is inconvenient to 
maintain.


Maybe it is better to maintain one ipPort list containing both of the above.