天池大赛 - 用通义灵码，人人都是开源贡献者
今年的天池大赛中将举办一个特殊的比赛，你可以借助通义灵码的检索增强能力对开源代码进行智能发现代码优化方向，输出 PR 或者根据开源社区诉求，开发新功能，提交专属 PR。更多赛事介绍请查看 大赛详情 。
Nacos社区作为被邀请的开源项目，将会选择一个社区任务作为比赛的课题，提供给参赛选手进行攻克，考虑到通义灵码的能力，最后社区选择的课题为： 利用通义灵码，帮助Nacos Client统一寻址模块的代码，并提供自定义拓展能力 。
利用通义灵码，帮助Nacos Client统一寻址模块的代码，并提供自定义拓展能力。
该课题衍生自课题 ISSUE#8310 通过插件方式统一注册中心和配置中心的寻址模块。
虽然在之前的活动中已经尝试对该课题进行解决和处理，但当时的目标不仅需要统一客户端中注册中心和配置中心的寻址模块，还需要将客户端和服务端的寻址模块一起进行统一，且需要以插件的形式实现。随着项目的开发进展以及实践的反馈中，社区发现客户端和服务端的寻址模块在诸多方面有着不同，比如在对一致性的要求、在可用性的要求上。 因此社区的主线分支并没有采纳这种方案。
不过，虽然客户端和服务端之间的寻址模块诉求不同， 但是客户端中注册中心和配置中心的寻址诉求确实相同的，而目前客户端中注册中心和配置中心的寻址模块功能高度重合却又代码独立，这导致有时同一个问题需要在两个地方同时修复，容易造成遗漏，同时对于代码简洁性和复用度上都有较大欠缺。如 ISSUE#9824 所提出的问题。
因此社区希望，选手通过通义灵码的代码解释及上下文对比的能力，对注册中心和配置中心的寻址模块的代码进行比对，将其公共部分的逻辑抽象出来，单独作为共用的寻址模块，同时设计一个可拓展的API，以提供用户能够添加更多类型的寻址方式。
赛事面向对象
- 任何有意向参与的社区贡献者
成果要求
- 利用通义灵码的各项能力，快速理解和比对当前Nacos Client中，注册中心和配置中心的寻址模块的代码公共的逻辑部分。
- 将寻址模块公共逻辑抽象到寻址模块的公共代码中，并保留拓展能力，以保证当前Nacos Client中注册中心和配置中心的寻址能力和修改前保持一致。
- 对于具体的寻址能力实现，除了保留当前的从参数中指定和地址服务器获取的方式外，需要能够通过一定的方式（如SPI，初始化传入等）给予使用者自定义扩展的能力
获胜条件
提出的方案最终被社区采纳，且提出的PR被社区所合并，目前活动规则仅一人的方案和PR会被最终采纳。
活动时间
2024年6月20日-2024年8月22日
3条答案
按热度按时间q3aa05251#
支持支持
q5iwbnjs2#
#12218
后面参与课题的同学可以多考虑一下上面这个issue的问题。并随时关注这个issue中的结论。
w51jfk4q3#
根据历史版本和多数使用场景的行为，发现绝大多数情况和场景下，都是endpoint优先， 仅在配置中心的
parsing=false时优先，且分析应该目前没有parsing=false且同时配置endpoint和serverAddr的诉求。因此最终预期，统一成endpoint优先：
ALIBABA_ALIWARE_ENDPOINT_URL-> 其次是 用户传入的endpoing或-Dendpoint-> 最后是传入的serverAddr和-DserverAddr.endpoing或-Dendpoint-> 传入的serverAddr和-DserverAddr.后续做课题的同学，尽量保持现有的寻址逻辑和优先级顺序， 但是建议能够对ConfigService所对应的ServerListManager的优先级顺序进行调整， 不强制，仅作为加分项。
最终影响是否被采纳和合入的还是
重构的准确性、代码质量以及对更多寻址能力的可拓展能力。