Open KomachiSion opened 3 months ago
支持支持
https://github.com/alibaba/nacos/issues/12218
后面参与课题的同学可以多考虑一下上面这个issue的问题。并随时关注这个issue中的结论。
根据历史版本和多数使用场景的行为,发现绝大多数情况和场景下,都是endpoint优先, 仅在配置中心的parsing=false
时优先,且分析应该目前没有parsing=false
且同时配置endpoint和serverAddr的诉求。
因此最终预期,统一成endpoint优先:
ALIBABA_ALIWARE_ENDPOINT_URL
-> 其次是 用户传入的endpoing
或-Dendpoint
-> 最后是传入的serverAddr
和-DserverAddr
.endpoing
或-Dendpoint
-> 传入的serverAddr
和-DserverAddr
.后续做课题的同学,尽量保持现有的寻址逻辑和优先级顺序, 但是建议能够对ConfigService所对应的ServerListManager的优先级顺序进行调整, 不强制,仅作为加分项。
最终影响是否被采纳和合入的还是 重构的准确性
、代码质量
以及对更多寻址能力的可拓展能力
。
《天池大赛 - 用通义灵码,人人都是开源贡献者》活动已进入尾声,进入评分阶段。参赛PR基本满足ISSUE要求的条件,达到了可以合并的要求,经过社区导师和专家的评审,针对参赛PR进行评价如下:
PR提交者基本都采用了将服务地址管理ServerListManager和服务地址提供ServerListProvider拆分的方案进行最终开发,在大体方案上接近的情况下,评审主要针对功能的完整度、代码的可读性、面向失败的情况处理等因素进行打分。
--- #12274
该参赛者为第一个提交的PR,从提交历史来看,也是首个提交Provider和Manager拆分的参赛者
PR较好的设计和实现
PR设计和实现上的问题
1.1.1.1,2.2.2.2
和2.2.2.2,1.1.1.1
可能被识别为不同的数据。评分: 完成度16+可读性12+创新分15=43
--- #12366
该参赛者提供的内容最为丰富,但很多修改超出了本ISSUE所要求的范围,因此暂时要求移除,等待后续再贡献社区。
PR较好的设计和实现
1.1.1.1,2.2.2.2
和2.2.2.2,1.1.1.1
会被统一排序,认为是同样的地址。PR设计和实现上的问题
Only for AddressServerListProvider
,不像定义的接口。评分:完成度17+可读性11+创新分13=41
--- #12432
PR较好的设计和实现
PR设计和实现上的问题
1.1.1.1,2.2.2.2
和2.2.2.2,1.1.1.1
可能被识别为不同的数据。评分:完成度13+可读性10+创新分10=33
虽然大家都采用了服务地址管理ServerListManager和服务地址提供ServerListProvider拆分的方案, 但是大家在具体的实现和接口抽象上各有千秋,同时大家对于SPI加载时的异常处理和构造方法中的异常处理都没有进行考虑; 同时,大家对于需要异步线程来更新的地址服务器模式的处理方式也不相同,有的是通过实现的接口来判断是否需要、有的是下沉到实现内部自行管理、也有不论是否需要,都创建固定线程池来定期处理的,其实三种方案都没有问题,但是从合理性来看,方案二应该最为准确合理(ServerListManager管理ServerList的生命周期,ServerListProvider只负责提供地址),因此第二个PR的完成度最高; 从代码的可读性来看,第一个PR的代码读起来歧义最小,基本通读下来不会造成太大的误解,改动也比较小,只是有一些命名上还可以再进行优化,第二个PR也很出色,但是相对第一个略微差一些,第三个PR的则不够内聚,导致了外层使用区域的代码改动,相对来说最不理想; 因为最终大家都选择了服务地址管理ServerListManager和服务地址提供ServerListProvider拆分的方案,因此给予第一个提交PR且直接采用了该设计方案的第一个PR更多的创新分。
非常感谢大佬指出的问题,第一次参与开源项目PR让我认识到自身还有很多思考量不足,后续会继续学习,争取能为社区贡献。
感谢大佬,在这个过程中学习到很多,辛苦啦
感谢大佬点评,在此过程中学习到了不少知识,非常感谢
天池大赛 - 用通义灵码,人人都是开源贡献者
今年的天池大赛中将举办一个特殊的比赛,你可以借助通义灵码的检索增强能力对开源代码进行智能发现代码优化方向,输出 PR 或者根据开源社区诉求,开发新功能,提交专属 PR。更多赛事介绍请查看大赛详情。
Nacos社区作为被邀请的开源项目,将会选择一个社区任务作为比赛的课题,提供给参赛选手进行攻克,考虑到通义灵码的能力,最后社区选择的课题为:
利用通义灵码,帮助Nacos Client统一寻址模块的代码,并提供自定义拓展能力
。利用通义灵码,帮助Nacos Client统一寻址模块的代码,并提供自定义拓展能力。
该课题衍生自课题ISSUE#8310通过插件方式统一注册中心和配置中心的寻址模块。
虽然在之前的活动中已经尝试对该课题进行解决和处理,但当时的目标不仅需要统一客户端中注册中心和配置中心的寻址模块,还需要将客户端和服务端的寻址模块一起进行统一,且需要以插件的形式实现。随着项目的开发进展以及实践的反馈中,社区发现客户端和服务端的寻址模块在诸多方面有着不同,比如在对一致性的要求、在可用性的要求上。 因此社区的主线分支并没有采纳这种方案。
不过,虽然客户端和服务端之间的寻址模块诉求不同, 但是客户端中注册中心和配置中心的寻址诉求确实相同的,而目前客户端中注册中心和配置中心的寻址模块功能高度重合却又代码独立,这导致有时同一个问题需要在两个地方同时修复,容易造成遗漏,同时对于代码简洁性和复用度上都有较大欠缺。如ISSUE#9824 所提出的问题。
因此社区希望,选手通过通义灵码的代码解释及上下文对比的能力,对注册中心和配置中心的寻址模块的代码进行比对,将其公共部分的逻辑抽象出来,单独作为共用的寻址模块,同时设计一个可拓展的API,以提供用户能够添加更多类型的寻址方式。
赛事面向对象
成果要求
获胜条件
提出的方案最终被社区采纳,且提出的PR被社区所合并,目前活动规则仅一人的方案和PR会被最终采纳。
活动时间
2024年6月20日-2024年8月22日