自 2021 年发布以来，Nacos 2.0 在社区的支持下已走过近三年，期间取得了诸多成就。在高性能与易扩展性方面，Nacos 2.0 取得了显著进展，同时在易用性和安全性上也不断提升。想了解更多详细信息，欢迎阅读我们之前发布的回顾文章：《Star 3w+，向更安全、更泛化、更云原生的 Nacos3.0 演进》。

近期，我们欣喜地宣布 Nacos 3.0 的第一个版本 Nacos 3.0-ALPHA 已经发布。Nacos 3.0 的目标是在 2.0 的基础上，进一步优化安全性、易用性和标准化。同时，我们将引入更多功能，帮助用户在分布式协调、AI 大模型、云原生等多种场景中更好地使用 Nacos，以提升其广泛适应性。

1. Nacos 3.0 Alpha 主要更新亮点

在 Nacos 3.0-ALPHA 的发布中，我们将重心放在了提升安全性和标准化上，这一部分内容将 Nacos 3.0 的后续更新的基础。

1.1 API 分类更为精细化

在 Nacos 3.0 之前，API 主要分为两大类：面向客户端和应用程序的 OpenAPI，以及供运维人员管理使用的 AdminAPI。这种分类方式在实际使用场景中存在一定的矛盾，比如用于引擎间数据同步的 API 和控制台上进行数据检索的 API，导致这部分 API 无法合理地对外开放和描述。同时，由于不同 API 对安全认证需求的差异，粗略将 API 分为两类也难以满足安全认证的多样化要求。

为了解决这些问题，Nacos 3.0 对 API 进行了更精细化的分类，具体包括：提供给客户端和应用程序的 OpenAPI、供运维人员和管理平面使用的 AdminAPI、用于控制台 UI 的 ConsoleAPI，以及引擎节点之间的 InnerAPI。这种新分类方式不仅针对不同使用场景提供了多维度的数据访问 API，同时也为不同类型的 API 实施相应的安全认证机制奠定了基础。

例如，客户端和应用程序往往更关心特定服务和配置，因此 OpenAPI 仅提供有限范围（如单个配置）的数据访问。而控制台则需要展示所有相关的数据，因此 ConsoleAPI 提供了更广泛的 list 范围 API。这种灵活的设计使得 Nacos 能够更好地满足不同用户和场景的需求。

1.2 按 API 类型默认启用安全认证

在 Nacos 3.0 之前，所有 API 都采用统一的安全认证方式，这对于 InnerAPI 和 AdminAPI 等主要用于内部调用的 API 来说并不适合。此外，由于所有 API 的安全认证采用同一个开关，导致在客户端和应用程序完成身份设置之前无法开启安全认证，从而带来了更高的安全风险。

为了解决这些问题，Nacos 3.0 将根据不同 API 类型默认采用不同的安全认证策略：对于 InnerAPI 和 AdminAPI，将默认启用 ServerIdentity 进行身份验证；对于 ConsoleAPI，将默认启用用户名和密码的身份及权限校验；而对于客户端和应用程序使用的 OpenAPI，则默认与 Nacos 2.0 保持一致，即默认不开启安全认证，需要用户自行查找并启用。这样做不仅提升了 Nacos 集群的数据安全性，还增加了用户在可信环境中的易用性，以及在升级启用安全认证过渡期间的稳定性。

1.3 优化默认命名空间

在 Nacos 中，命名空间 ID 是命名空间的唯一标识符。然而，许多用户在使用默认命名空间 public 时，错误地将名称“public”作为 ID 配置到应用程序中，这导致了一些问题。同时，其他正常使用此命名空间的用户对默认命名空间 public 的 ID 为空字符串''感到困惑。这种困惑源于服务发现模块可以使用 public 作为命名空间 ID 并将其视为默认处理方式，而在配置管理模块中却并非如此。简而言之，默认命名空间 ID 的处理方式存在不一致性。

此外，自 1.2.0 版本起，auth 插件依赖于命名空间 ID，而这种处理差异也引发了默认命名空间的权限问题。在适应默认命名空间''方面，数据源插件也遇到了一些困难。相关问题已在以下 ISSUE 中被讨论：#3525^[1]、#8774^[^2]、#9773^[^3]、#9783^[^4]等。

为了解决默认命名空间 ID 的使用问题，Nacos 3.0 计划对默认命名空间的 ID 进行调整。根据社区讨论的 ISSUE#9846^[^5]，默认命名空间的 ID 将被修改为 public，与其名称相同。在访问 API 时，如果未传入命名空间 ID 或仍然传入空字符串''，Nacos 3.0 将自动将其匹配为 public 以进行后续处理，从而兼容旧客户端的访问请求。

需要注意的是，Nacos 3.0 Alpha 版本在数据存储的平滑迁移和适配方面尚未进行处理，因此进行直接升级会导致配置数据无法获取，并且目前无法实现平滑升级。不过，Nacos 3.0 的正式版本将会支持平滑升级。

1.4 支持先进的 xDS 协议

xDS（Extended Discovery Service）是一组由 Envoy proxy 团队提出的协议，广泛应用于服务网格中，旨在服务发现和配置管理，以支持现代微服务架构下的动态配置。随着服务网格概念的普及，xDS 协议逐渐获得了社区的认可。Nacos 作为微服务生态体系中的注册与配置中心，通过标准化协议来满足服务网格的功能需求，成为云原生化的核心要求之一。

在 Nacos 2.0 版本中，Nacos 通过 Istio 的 MCP 协议获取服务数据，并将其转换为 xDS 协议数据。然而，这一过程依赖于中间组件 Istio，这导致系统的复杂性和稳定性面临风险。而在 Nacos 3.0 版本中，Nacos 直接支持 xDS 协议中的 EDS、LDS、RDS 和 CDS 协议，显著降低了对 Istio 组件的依赖，提高了系统的易用性和稳定性。

2. Nacos 3.0 即将推出的新功能

基于 Nacos 3.0-Alpha 版本所提供的基础功能，在 Nacos3.0 正式版中计划进一步从架构上提升提升安全性和标准化能力。

2.1 全新 Admin API 的推出

在 Nacos 的早期版本中，AdminAPI 主要面向运维人员，专注于 Nacos 集群的维护操作。由于当时的设计场景多以人为本地调用为主，因此 AdminAPI 的定义较为随意，导致其安全性和标准化程度不足。这使得后续的控制台在复用 AdminAPI 时面临困难，同时也给希望开发自定义控制台或构建管理平台的开发者带来了挑战。

为了解决这些问题，Nacos 3.0 正式版将对 AdminAPI 进行全面的重新设计。我们将规范 API 的请求体、返回体和错误码等标准，提升整体的标准化水平。同时，默认启用并优化 AdminAPI 的身份验证，以增强安全性。此外，我们将提供 Maintainer-SDK，以便希望开发自定义管理程序的开发者方便使用。这些改进将为 Nacos 控制台与引擎的灵活拆分和部署奠定坚实基础。

2.2 控制台与引擎的灵活拆合部署

在之前的 Nacos 版本中，为了方便用户的部署和使用，控制台与引擎程序一直合并部署，且共用同一个端口。这种方式虽然增强了使用的便利性，但也带来了一些安全风险。此外，由于控制台和引擎在使用场景上存在差异，它们对于开放网络访问范围及安全认证需求的预期也不尽相同。基于此，Nacos 计划在新版本中对控制台和引擎的部署架构进行较大调整。

在 Nacos 3.0 中，控制台将独立在一个 Web 容器中运行，允许用户设定独立的访问端口。这一改变使得 Nacos 集群的运维人员能够更灵活地配置网络访问控制列表（ACL），例如，仅将控制台端口开放给办公网络。同时，配合控制台默认启用的安全认证，这将显著提高 Nacos 的安全性。此外，独立的 Web 容器还将与全新的 Admin API 相结合，实现控制台和引擎节点的灵活拆分部署，使得它们能够在不同节点上运行，进一步增强安全性。

2.3 引入分布式锁支持

Nacos 社区向用户征集了他们对 Nacos 3.0 的期望功能，其中支持分布式锁的需求是呼声最高的功能之一。分布式锁是一项在分布式应用中常用的功能，目前大多数实现依赖于 Zookeeper 或 Redis 等产品。许多用户已经将 Nacos 替换为 Zookeeper 来进行服务和配置管理，但由于 Nacos 尚未支持分布式锁，用户仍需额外运维 Zookeeper 集群，增加了系统的复杂性。

因此，Nacos 3.0 正式版本计划引入分布式锁的实验性功能，以满足部分用户对轻量级分布式锁的需求。这一功能的推出将帮助用户减少对额外系统的依赖，从而简化微服务应用架构，拓展 Nacos 的使用场景。

2.4 Spring Boot 3 和原生启动的支持

Spring 社区已经停止了 Spring Boot2 的支持，同时最新的 Spring Boot3 支持了 Java 原生启动的支持；考虑到 Spring Boot 3 要求将 JDK 升级至 17 及以上版本，这可能会导致许多用户在升级时遇到阻碍，因此 Nacos 2.X 版本依然基于 JDK 8 和 Spring Boot 2，并未升级至 Spring Boot 3。

然而，随着时间的推移，失去支持的 Spring Boot 2 将会产生越来越多的安全漏洞，这将间接降低Nacos的安全性。因此，Nacos 计划在 3.0 版本中对 JDK 和 Spring Boot 进行升级。这一升级不仅能确保遵循社区的支持，及时修复安全漏洞，而且还能利用 Java 原生启动来提升性能。

3. Nacos 3.X 发展蓝图

在 Nacos 3.0 的发展蓝图中，我们将继续致力于提升易用性与普适性，以满足用户日益增长的需求。

在引擎自身方面，新版本计划引入了服务与配置的模糊订阅功能，使用户能够更灵活地管理服务和配置，简化在网关应用中服务发现和配置订阅的操作流程。此外，我们计划支持 DNS 协议，以进一步拓展 Nacos 在支持较弱编程语言场景中的适用性。另外对于服务健康检查体系，我们将优化相关机制，通过将健康检查与服务类型解耦，提供更多关于服务可用性的判断依据，这将使微服务之间的流量调用更加灵活，同时确保系统的稳定运行。最后对于社区中已经比较成熟的插件，我们会将其纳入 Nacos 的主干仓库中进行维护，诸如 PostgreSQL 插件、AES 配置加密插件等，让这些插件在后续版本中随引擎一起发布、不需要再独立构建引入。

在生态建设方面，我们将通过 Nacos Controller 的快速迭代，实现 Kubernetes 服务与配置的同步管理，从而使云原生环境下的使用变得更加便捷。此外，我们将积极探索多语言生态与 AI 大模型的集成，通过支持多语言应用框架以及 Spring AI 和其他 AI 大模型开发框架的动态 prompt 发现和资源发现，为用户提供更加丰富的功能选择与应用场景，努力构建一个高效、灵活的分布式协调平台。

4. 关于 Nacos3.0 的一些投票和讨论

Nacos 是一个开放的社区，任何社区参与者和使用者都可以参与 Nacos 发展的讨论，提供自己的想法和建议。由于 Nacos3.0 的改动较大，因此社区也发起了一些投票和讨论，希望大家能够积极参与，帮助 Nacos 社区更好的进行规划。

4.1 1.X 正式 EoL（End of Life）

Nacos 2.X 版本经过了近 3 年的演进和沉淀，无论是从性能、稳定、安全的角度，都比 1.X 版本优秀太多；而且 1.X 版本实际上也已经进入了尾声维护阶段（仅修复严重 Bug 和安全漏洞）近 2 年，我们希望在 Nacos 3.0 正式发版之际，正式归档和 EoL Nacos 的 1.X 版本（不再进行更新）。希望征询社区的意见，大家可以到 ISSUE#12921^[6]中进行投票和讨论。

4.2 3.X 不再支持 1.X 的客户端

Nacos 的 2.X 版本兼容大多数 1.X 的客户端，这主要是考虑到业务应用升级客户端版本较为谨慎，时间周期较长；随着 Nacos 2.X 版本经过了近 3 年的演进和沉淀，主要的上游应用框架基本都升级到了 Nacos 2.X 的客户端，因此我们希望在 Nacos 3.0 或未来的某个 3.X 版本中，不再支持 1.X 的客户端，减少 Nacos 冗余代码。希望征询社区的意见，大家可以到 ISSUE#12922^[7]中进行投票和讨论。

4.3 spring boot3 + jdk 17 升级

正如前文所提及的，由于 spring boot2 已经彻底停止了维护，nacos3 升级到spring boot 3 势在必行，对应的 JDK 版本也必须升级到 17。而升级 JDK 版本可能是一个比较大的变动，部分使用者可能由于各种考量无法接受 JDK 版本的升级。因此我们希望通过社区投票，再决定 Nacos 3.0 是否升级到 JDK17，欢迎大家到 ISSUE#12923^[^8]中进行投票和讨论。

除了上述的 3 个投票，Nacos 社区还有更多关于 Nacos3.0 改动的讨论，也欢迎大家积极参与，比如：ISSUE#9129^[^9]、ISSUE#9846 等。