totalo
totalo
> > > 暂时还没有进行细节review，目前有一个问题可能需要考虑一下： > > > #12218 根据这个issue的信息， 目前配置中心和注册中心的ServerListManager 寻址的优先级顺序有一定的区别， 建议在设计时考虑进去。 > > > > > > ok. > > issue中已经有结论回复了， 可以考虑略微进行一下修改，并解决一下出现的冲突。 已经调整
> > > > > 暂时还没有进行细节review，目前有一个问题可能需要考虑一下： > > > > > > #12218 根据这个issue的信息， 目前配置中心和注册中心的ServerListManager 寻址的优先级顺序有一定的区别， 建议在设计时考虑进去。 > > > > > > > > > > > > >...
> 给予了一些review的评价： > > 1. 事件是否也统一抽象出去？ > > 2. 异步从地址服务器更新地址列表的逻辑是否也可以抽象出去复用？ > > 3. 梳理一下ServerListManager的构造器，去除一些不使用的，减少复杂度 > > 4. 是否遗漏了IS_USE_CLOUD_NAMESPACE_PARSING相关逻辑？ 好的，谢谢大佬，我这边详细看看考虑一下
@KomachiSion 大佬，我调整了一个版本，辛苦有空 review。主要的问题点如下： - load 是通过属性中添加类型与 provider 类型名称匹配，就使用这个配置，这种方式可行吗？ - IS_USE_CLOUD_NAMESPACE_PARSING 的逻辑原来就没有，这次需要加上吗?
> > @KomachiSion 大佬，我调整了一个版本，辛苦有空 review。主要的问题点如下： > > > > * load 是通过属性中添加类型与 provider 类型名称匹配，就使用这个配置，这种方式可行吗？ > > * IS_USE_CLOUD_NAMESPACE_PARSING 的逻辑原来就没有，这次需要加上吗? > > 关于问题1， 其实这么来思考： > > 1. 现有的地址服务器形式的和serverAddr参数形式的算不算是ServerListProvider的一种？如果算的话，为什么他们是在ServerListProvider之外的AddressServerListManager中实现；如果不算的话，那他们和ServerListProvider是什么关系？ > 2. 如果同时配置了ServerListProvider的type和endpoint或serverAddr，...
@KomachiSion 大佬，我又调整了一版。有时间辛苦 review，整体思路如下： - 抽出公共的寻址模块，默认分为 AddressServerListProvider 和 EndpointServerListProvider - 寻址模块的 SPI 通过order 进行降序排列，这样用户自定义实现的寻址可以通过定义 order 选择合适的位置
@KomachiSion 大佬，已经调整，辛苦 review
@KomachiSion 调整了一下，辛苦大佬再看看～
> 目前初步review似乎没有太大的问题了， 之后会在活动截止前对PR进行整体评判后决定是否合入。 > > > > 我先跑一下CI，请关注一下结果，避免后续需要合入时由于CI问题被阻塞。 好的，谢谢
@KomachiSion 大佬，其他的做了一个调整，但是这个不是很理解，"未对SPI的实现做异常处理，可能导致其中一个错误的SPI实现抛出异常影响到其他SPI的加载以及整个Client的初始化。", 这是指 init 的时候么？