Nacos 2.0 的架构主要聚焦对性能和可扩展性进行优化和提升。
对于性能升级，Nacos 2.0 通过将通信模型从 HTTP 升级至 gRPC，从短连接模型升级到长连接模型，使得 Nacos 的通信吞吐量中极大提升；同时配合数据存储和数据结构模型的升级，进一步减少核心操作所涉及的步骤和链路，最终实现性能的 10 倍提升。
关于可扩展性升级，Nacos 2.0 通过将一些具有个性化需求的通用能力进行抽象，进行插件化改造的方式，允许 Nacos 用户和运维人员能够开发自定义插件，适配个人或企业的个性化需求。
虽然 Nacos 2.0 在性能和可扩展性实现了一些突破，但仍然还存在一些挑战。
其中一个主要的挑战就是 Nacos 的安全风险。比如：Nacos 2.0 中所有的 HTTP API 均使用 8848 端口， 这其中及包含了 1.X 客户端使用的 API，也包含了运维人员以及控制台的 API。不同类型的 API， 对于权限的需求其实是不同的，对于网络访问的连通性要求也是不同的。使用单端口并且使用唯一的鉴权开关，导致了网络的访问控制，以及鉴权控制都不是很灵活。许多用户为了方便使用，将此端口暴露在办公网甚至公网环境，同时未开启鉴权，这就造成了安全风险。
另一个问题就是默认命名空间的使用，Nacos 最初的版本中定义了命名空间作为数据资源的强隔离属性，不同命名空间之间的服务和配置不能互相发现和获取；但在最初版本中因为历史原因，注册中心和配置中心对于默认命名空间的处理方式有一定的不统一，这导致了许多用户在使用默认命名空间时经常配置错误或者出现疑惑；并且在 Nacos 2.0 提供各种插件能力之后，许多插件实现时需要额外工作进行适配，严重阻碍了插件的开发以及插件的稳定性。
随着 AI 时代来临，AI Agent 应用的部署形态在之前云原生可弹性可伸缩的基础上，要求更加轻量，更加弹性，例如 FC 场景；在这种要求下，我们需要考虑 Nacos 之前的服务发现和配置管理的能力是否还能承载 AI Agent 的应用的部署。同时，随着越来越多的 AI Agent 的应用贯穿业务全线，Nacos 能否帮助更好地管理 AI Agent 的应用，是 Nacos 在当前的挑战，同时也是新的机遇。
为了应对这些挑战以及机遇，Nacos 3.0 架构也做了对应的升级。目标是在 AI 时代成为更安全的 Registry。设计理念也由之前的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台升级为一个易于构建 AI Agent 应用的动态服务发现、配置管理和 AI 智能体管理平台。
