[ISSUE #12189] refactor the server list manager code in the client module

[misakacoder]

What is the purpose of the change

#12189

Brief changelog

XX

Verifying this change

XXXX

Follow this checklist to help us incorporate your contribution quickly and easily:

• [ ] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• [ ] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
• [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• [ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
• [ ] Run mvn -B clean package apache-rat:check findbugs:findbugs -Dmaven.test.skip=true to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test to make sure integration-test pass.

本改动借助了通义灵码进行辅助编程

[KomachiSion]

已收到PR， 会尽快进行review，请时刻关注

[misakacoder]

方案中可以认可的点：

1. 用SPI进行扩展。
2. 将AddressServer和Properties独立作为两个拓展实现。
3. 将公共逻辑抽象到抽象类中

可能有问题的点：

1. SPI不需要自己实现，我理解jdk自带的足以支持
2. order的排序方式可以写入到AbstractServerListManager，作为方法提供，用注解+反射的方法可能没那么好。
3. 事件不需要修改名称， 旧的名称足以表达意思
4. 地址服务器的实现可能有逻辑遗漏，建议在梳理一下，做好注册和配置中心的区分（命名和调用逻辑上。

1. jdk自带的SPI会自动创建全部实现类的实例，因为我的初始化逻辑是写到构造方法里面的，所以我不想一次性全部实例化。当然像上面说的，采用init函数来手动初始化也行，我改下吧
2. 自定义排序我弄成方法，的确能不反射就不反射。
3. 这个我改回去，我是把之前的2个不同事件名称删除了重新建的，命名习惯不一样。
4. 我看过config和naming的ServerListManager逻辑，我理解的地址服务器就是简单的一个web服务，请求指定接口返回nacos服务列表，就如官网的图所示，所以像上面说的Header header = NamingHttpUtil.builderHeader();这个区别，我认为可能是不同的人写的导致的，因为就是请求一个接口，返回nacos服务器地址列表，config和naming不应该有区别才对噻。

[misakacoder]

@KomachiSion 幸苦空了看看我的回复和疑惑，我这边好调整调整

[KomachiSion]

方案中可以认可的点：

1. 用SPI进行扩展。
2. 将AddressServer和Properties独立作为两个拓展实现。
3. 将公共逻辑抽象到抽象类中

可能有问题的点：

1. SPI不需要自己实现，我理解jdk自带的足以支持
2. order的排序方式可以写入到AbstractServerListManager，作为方法提供，用注解+反射的方法可能没那么好。
3. 事件不需要修改名称， 旧的名称足以表达意思
4. 地址服务器的实现可能有逻辑遗漏，建议在梳理一下，做好注册和配置中心的区分（命名和调用逻辑上。

1. jdk自带的SPI会自动创建全部实现类的实例，因为我的初始化逻辑是写到构造方法里面的，所以我不想一次性全部实例化。当然像上面说的，采用init函数来手动初始化也行，我改下吧
2. 自定义排序我弄成方法，的确能不反射就不反射。
3. 这个我改回去，我是把之前的2个不同事件名称删除了重新建的，命名习惯不一样。
4. 我看过config和naming的ServerListManager逻辑，我理解的地址服务器就是简单的一个web服务，请求指定接口返回nacos服务列表，就如官网的图所示，所以像上面说的Header header = NamingHttpUtil.builderHeader();这个区别，我认为可能是不同的人写的导致的，因为就是请求一个接口，返回nacos服务器地址列表，config和naming不应该有区别才对噻。

第4点很重要，是用来区分注册中心和配置中心的情况， 如果是用同一个地址服务器，然后注册和配置中心是不同集群的时候，需要通过Header来区分是需要哪个。

[KomachiSion]

@KomachiSion 幸苦空了看看我的回复和疑惑，我这边好调整调整

辛苦再调整一下。

[KomachiSion]

@misakacoder any update？

[misakacoder]

@misakacoder any update？

不好意思，前几天有点忙，我调整了下，幸苦帮忙review下呢

[misakacoder]

@KomachiSion 大佬，我优化了一下，麻烦再review一下呢

[misakacoder]

@KomachiSion 已修改，麻烦再review下呢，另外NamingHttpClientProxy只有一个地址就不重试的逻辑我是优化成这样了。

[misakacoder]

目前初步review似乎没有太大的问题了， 之后会在活动截止前对PR进行整体评判后决定是否合入。

好的，感谢

[KomachiSion]

根据最后的评分结果， https://github.com/alibaba/nacos/pull/12274 会被合并入主干分支，

感谢参赛同学的贡献，该PR也有很多可取之处， 欢迎继续贡献此模块内容，将这部分内容优化的更好。