大家好，我是R哥。
Nacos 3.0.0 前几天正式发布了，这是一个非常重大的版本，支持许多新功能。史诗级更新！强的离谱！！
Nacos 先扫个盲：
Nacos 一个用于构建云原生应用的动态服务发现、配置管理和服务管理平台，由阿里巴巴开源，致力于发现、配置和管理微服务。
说白了，Nacos 就是充当微服务中的的注册中心和配置中心。
Nacos 3.0.0 十大更新
1、依赖环境升级
大家都知道，Spring Boot 2.x 已经停止维护更新了，如果 Nacos 还继续使用 2.x 就可会产生越来越多的安全漏洞，这将间接降低 Nacos 的安全性。
所以，Nacos 3.0.0 正式对 Spring Boot 和 JDK 版本大刀阔斧，将 Spring Boot 升级到 3.4.1，并将 JDK 版本升级到 17，正式宣布了 JDK 8 的退役。
这一升级不仅能修复安全漏洞，提升 Nacos 的安全性，另外，Spring Boot 3.x 支持了 Java 原生启动，所以还能利用 Java 原生启动功能来提升性能。
2、API 分类更精细化
在 Nacos 3.0 版本之前，API 主要分为两大类：
- OpenAPI：主要面向客户端和应用程序；
- AdminAPI：主要提供给运维人员管理和使用的。
不过，在实际应用中，这种按照两大类划分 API 的方式问题不少。
比如，有些 API 无法被准确地开放和描述出来；再比如，不同 API 对安全认证的要求千差万别，简单粗暴地分成两类，根本无法覆盖各种复杂的安全需求。
所以，为了更好地解决这些问题，Nacos 3.0 对 API 做了更细致的划分，由以前的 2 大类分成了现在的 4 大类，如图所示：
Nacos 3.0.0 中的最新 API 分类：
- OpenAPI：主要面向客户端和应用程序；
- AdminAPI：主要提供给运维人员管理和使用的；
- ConsoleAPI：主要服务于控制台界面；
- InnerAPI：主要用于引擎节点之间内部通信。
这种灵活的设计，可以使 Nacos 能够更好地满足不同用户和场景的需求，不光让不同场景下的数据访问更清晰，还为后续针对不同 API 类型实施对应的安全认证打下了坚实基础。
另外，在 Nacos 3.0 版本中，Nacos 控制台 UI 使用了新的 v3 控制台 API 替换旧的 v1 API，并且默认禁用旧的 v1 API 使用的旧控制台 UI。
3、全新的 Admin API
AdminAPI 主要面向运维人员使用，专注于 Nacos 集群的维护操作。但 Nacos 早期设计的 AdminAPI 比较随意，设计场景也主要以本地调用为主，安全性和标准化程度都是个问题。
Nacos 3.0.0 对 AdminAPI 进行了重新设计：
这次重新设计主要体现在以下 3 个方面：
- 对 API 的请求体、返回体和错误码等进行了标准规范；
- 默认启用并优化 AdminAPI 的身份验证，确保了安全性；
- 提供了 Maintainer-SDK，支持开发自定义管理程序。
4、按 API 类型默认启用安全认证
在 Nacos 3.0 版本之前存在以下两个问题：
- 所有的 API 都共用一套安全认证机制，但这种一刀切的做法，对于像 InnerAPI 和 AdminAPI 这种主要用在内部调用的接口来说并不合适。
- 所有的 API 安全认证依赖统一的开关，会导致在客户端和应用程序完成身份配置之前，没办法直接启用安全认证，增加了系统的安全隐患。
针对这些问题，Nacos 3.0 对安全认证进行了优化：
说白了，说是对不同类型的 API 默认采用不同的安全认证策略：
- InnerAPI 和 AdminAPI 默认通过 ServerIdentity 来做身份校验；
- ConsoleAPI 默认启用基于用户名密码的身份认证和权限控制；
- OpenAPI 则继续沿用 Nacos 2.0 的做法，默认不开启认证，需要用户根据需求手动配置开启。
通过这种更细致的设计，不仅提高了 Nacos 集群的数据安全性，也兼顾了可信环境下的使用便捷性，还保证了从未启用到启用安全认证过程中的平滑过渡。
5、优化默认命名空间
在 Nacos 中，命名空间 ID 是每个命名空间的唯一标识符。
不过，很多人在用默认的 "public" 命名空间时，常常搞错，把 "public" 这个名字直接当成了 ID 配置到应用里，而它的真正的 ID 是 "" 空字符串，这样就会出现混乱和错误问题。
所以，为了解决这个问题，Nacos 3.0 对默认命名空间的ID进行调整，将默认命名空间的 ID 也修改为 "public"，和名称保持一致。
如图所示：
同进，Nacos 3.0.0 这项改动也能兼容旧客户端的访问请求，如果访问 API 时未传入命名空间 ID 或空字符串，Nacos 会自动将其匹配为 "public" 值进行处理。
6、支持先进的 xDS 协议
xDS 是一套由 Envoy proxy 团队提出的动态服务发现和配置标准协议，支持服务注册、路由、负载均衡等配置的统一管理，广泛应用于云原生和微服务系统中。
在 Nacos 2.0 时代，服务数据的获取是通过接入 Istio 的 MCP 协议来实现的，拿到数据后再转换成 xDS 协议格式。这种方式虽然可行，但中间还得依赖 Istio 这个组件，结果不仅让整体架构变得更复杂，在稳定性方面也有隐患。
Nacos 3.0 版本开始，直接原生支持 xDS 协议中的 EDS、LDS、RDS、CDS 协议，省去了对 Istio 的依赖，系统变得更简洁，部署起来也更轻松，整体的稳定性和易用性都得到了明显提升。
7、Server 及 Console 拆分部署
在 Nacos 3.0.0 版本之前，Server 及 Console 是一起部署的，只要部署了 Nacos Server，就能访问 Console 控制台，这样不是很灵活，安全性也彼此互相绑定。
Nacos 3.0.0 实现了控制台和引擎节点的灵活拆分部署，如图所示：
拆分部署后，它们就能够在不同节点上运行，也能进一步提高安全性。
Nacos 3.0.0 不仅实现了拆分部署，还完成了控制台和引擎的端口拆分，以及新增了 ADMIN API和Console API，允许用户设定独立的访问端口，运维人员能够更灵活地配置网络访问控制列表。
Spring Cloud Alibaba 中的其他组件，如 RocketMQ、Sentinel 的控制台，它们都是单独部署的，这次 Nacos 也终于和它们保持同步了。
8、支持 MCP 协议
MCP 扫盲：
MCP 全称为：Model Context Protocol，即：模型上下文协议，它是一种 AI 开放协议，它标准化了应用向 AI 应用提供上下文的方式。
MCP 自推出以来，火爆全网，它的发展速度真是超出了我的想象，今年 2 月份开始，像国外的 Cursur、Winsurf、Cline、OpenAI 这些 AI 工具就陆续支持了 MCP 协议，国内也没闲着，比如：百度地图、高德地图也纷纷上线了自家的 MCP Server，MCP 一时成为了 AI 界的新宠，炙手可热。
Nacos 也没有落下，在最新的 Nacao 3.0.0 版本中，官方声称 “0改动” 适配 MCP Server，如图所示：
Nacos 作为 MCP Registry，扮演控制面的角色，不仅管理 Tool 的元信息，还可以在存量接口不改动的情况下，快速把业务已有的 API 接口转换成 MCP 协议接口，结合 Higress AI 网关，实现 MCP 协议和存量协议的转换。
使用 Nacos 管理 MCP 的优势：
- 存量 API 可以快速构建 MCP Server；
- MCP 信息动态下发实时生效；
- MCP 信息历史版本管理；
- MCP 信息灰度管理；
- 密码配置加密；
- MCP 返回格式 JSON 转换 XML；
- MCP 服务管理及健康检查；
看得出来，现在各大技术框架也都在卷 AI，相信随着 AI 技术的不断发展，Nacos 后面也会推出越来越多 AI 相关的能力，跟上时代。
更多 MCP 可以参考我写的文章：MCP 系列文章合集
9、支持分布式锁（实验性功能）
分布式锁在分布式系统里算是个很常见、很基础的功能了，现在市面上，大多数分布式锁主要还是依赖 Redis、Zookeeper 这样的组件来实现。
现在随着微服务以及 Nacos 的流行，很多分布式系统已经用 Nacos 做服务注册和配置管理了，但 Nacos 一直没有支持分布式锁，大家不得不单独维护一套 Redis、Zookeeper 集群，不仅加重了运维的负担，整体系统的复杂度也跟着上去了。
所以，到了 Nacos 3.0.0 版本，官方决定引入分布式锁功能，从而减少系统对额外组件的依赖，从而简化微服务应用架构。
需要注意的是：
分布式锁功能是在 Nacos 3.0.0 版本中新出的，目前还处于实验性阶段，功能生态还未完善，可能存在一定的问题，请谨慎使用。
10、支持模糊订阅（实验性功能）
支持配置和服务的模糊订阅也是 Nacos 3.0.0 的呼声最高功能之一，本来官方计划在 Nacos 3.1 中支持的，参与开源的同学们积极贡献，模糊订阅的功能在 Nacos 3.0.0 版本中提前作为实验性功能加入了。
要实现模糊订阅，需要通过 fuzzyWatch 接口，可以使用一定的表达式，并对指定分组、服务和配置进行批量订阅，目前可通过 * 进行前缀模糊，后缀模糊，双边模糊匹配。
需要注意的是：
1、模糊订阅功能仅会推送服务、配置的新增以及删除事件，并不会直接推送服务下实例列表，可在服务模糊订阅的监听器中结合
subscribe接口实现服务下实例列表的变更监听。2、出于稳定性考虑，Nacos 对模糊订阅的规则数量以及单个规则匹配的服务数量有上限保护。
3、模糊订阅功能是在 Nacos 3.0.0 版本中新出的，目前还处于实验性阶段，功能生态还未完善，可能存在一定的问题，请谨慎使用。
总结
这次 Nacos 3.0.0 的重磅升级，功能真多真强啊。
Nacos 3.0.0 不仅底层环境进行了大幅度升级，比如抛弃了 JDK 8，拥抱了 JDK 17 和 Spring Boot 3.x，还从架构设计到安全机制全面优化，比如 API 分类更精细、安全认证更灵活、默认命名空间更合理，甚至控制台都能单独部署了，这种全方位增强真是少见。
此外，新版本还积极跟进了行业趋势，比如原生支持 xDS 协议、MCP 协议，新推出的分布式锁和模糊订阅等新特性，这些虽然有些还处于实验阶段，但足以看出 Nacos 团队紧跟云原生和 AI 浪潮的决心。
我能明显感受到的是，Nacos 已经不单单是一个传统意义上的注册中心或者配置中心了，更是在积极布局未来分布式系统和 AI 智能应用场景。
未来已经到来，Nacos 也在悄悄进化，如果你手头的微服务架构还停留在旧版本，想享受更好的安全性、性能、AI 加持，以及未来扩展能力，可以考虑升级。
Nacos 的崛起
现在 Spring Cloud Alibaba 微服务技术非常火啊，但早期的许多 Spring Cloud Netflix 相关组件，比如 Eureka 2.x、Ribbon、Zuul、Hystrix…等这些，它们都早已停止维护更新了，属于老破旧技术了，我劝大家别再浪费时间学这些了。
鉴于 Spring Cloud 各种组件的停止维护，学习 Spring Cloud Alibaba 是目前最正确的姿势：
- Spring Cloud Alibaba 基于 Spring Cloud 构建，提供了对 Alibaba 组件的封装而已，比如：Nacos、Sentinel 等，其最顶层的抽象还是 Spring Cloud，所以学习 Spring Cloud Alibaba 就是学习 Spring Cloud。
- Spring Cloud Alibaba 作为 Spring Cloud 的官方顶级项目，也是国内最强微服务框架及事实上的标准，没有之一。
Spring Cloud Alibaba 最新技术栈如下：
| 组件 | Spring Cloud Netflix | Spring Cloud Alibaba |
|---|---|---|
| 注册中心 | Eureka 1.x |
Nacos |
| 配置中心 | Nacos | |
| 服务容错 | Sentinel | |
| 消息队列 | – | RocketMQ |
| 分布式事务 | – | Seata |
可以看到，Nacos 是 Spring Cloud Alibaba 微服务体系中最重要的成员之一，Nacos 同时扮演了注册中心和配置中心的双重角色，并且用过 Nacos 的都知道它功能和性能都非常强悍。
如今，Nacos 变得越来越强了，作为 Spring Cloud Alibaba 的主要成员之一，不管是工作需要，或者是跳槽面试，Nacos 都是必学的，它已成为了 Java 程序员必备的技术之一，所以，大家有时间还是要多更新一些技能储备。
最后，如果你想系统学习 Spring Cloud Alibaba 微服务，建议报名R哥最新出品的《Spring Cloud Alibaba 微服务课程》，一次付费，后续都提供免费更新，永久学习。
好了，今天的分享就到这里了，后续R哥也会继续关注并分享更多的 Java 技术干货，关注公众号Java技术栈第一时间推送。
参考链接：
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
