章节一Nacos 概况一、前言NacosDynamic Naming and Configuration Service是阿里巴巴开源的一款集服务发现、配置管理和服务管理于一体的平台 。它旨在帮助开发者更敏捷地构建、交付和管理云原生及微服务应用是构建现代分布式架构的核心基础设施。Nacos 的核心价值在于“一站式”解决微服务架构中的两大核心痛点服务如何相互发现以及配置如何集中、动态地管理。它无缝集成了服务注册中心与配置中心相比传统的 Eureka Spring Cloud Config 组合在实时性、可用性和易用性上都有显著提升。二、核心架构与工作原理Nacos 的架构设计清晰分层从客户端到存储层各司其职。其服务注册发现的底层巧妙地采用了双协议设计以适应不同的一致性需求。双协议引擎AP与CP的智慧选择Nacos 允许用户根据业务场景在服务的可用性AP和一致性CP之间做出灵活选择。Distro 协议 (AP模式)这是 Nacos 的默认模式优先保证服务的高可用性。它采用去中心化的 Gossip 协议进行数据同步在网络分区发生时各节点仍能独立提供服务但不同节点间的数据可能存在短暂不一致。适用于对服务发现实时性要求极高且能容忍短暂数据不一致的场景如大多数电商核心交易链路。Raft 协议 (CP模式)当用户通过控制台或API将服务切换到 CP 模式时Nacos 会使用 Raft 共识算法来保证数据的强一致性。在此模式下集群会选举出一个 Leader 节点处理所有写请求并同步给 Follower 节点确保所有节点数据一致。这牺牲了一定的可用性Leader 宕机时会有短暂的选举期但保证了配置信息的绝对准确适用于分布式锁、主备选举等场景。在配置管理方面Nacos 实现了高效的“推拉结合”机制。客户端会定时拉取配置同时与服务端保持一个长连接。当配置发生变更时服务端会通过这个长连接主动将变更推送给客户端实现了配置的近实时动态刷新无需重启应用。三、关键概念与数据模型要深入使用 Nacos必须理解其核心数据模型。这些概念构成了 Nacos 管理和隔离服务与配置的基石。️ Nacos 的核心数据维度1命名空间 (Namespace)用于实现租户级或环境级的配置隔离。最常见的用法是区分开发、测试、生产等不同环境确保各环境的配置互不干扰。2分组 (Group)在同一个命名空间内对配置集进行进一步分组。默认分组为DEFAULT_GROUP。例如可以为“交易系统”和“用户系统”分别创建不同的 Group即使它们有相同 Data ID 的数据库配置。3数据 ID (Data ID)一个配置集通常对应一个配置文件的唯一标识符。建议采用类似 Java 包名的命名规则如com.example.app.db-config来保证全局唯一性。一个完整的配置定位通常由Namespace Group Data ID三者共同决定。在服务模型中服务Service是一等公民一个服务下包含多个提供相同功能的实例Instance。Nacos 通过持续的健康检查来监控实例状态自动将不健康的实例从服务列表中剔除保障流量只会被路由到健康的节点。四、Nacos 3.0迈向AI原生的演进Nacos 3.0 标志着其从“微服务基础设施”向“AI原生应用平台”的跨越。其核心愿景是成为全面拥抱AI时代的服务、配置与AI注册中心。这一演进主要体现在三大新能力上AI RegistryAI注册中心这是 Nacos 3.0 最核心的规划。它分为模型层、工具层和应用层旨在管理AI模型的动态参数如Prompt、学习率并帮助AI智能体自动发现和调用外部的MCP工具减少Token消耗提升协作效率。MCP服务管理Nacos 可以作为 MCPModel Context Protocol服务的注册中心支持将存量HTTP/RPC服务零代码改造成MCP服务也支持新MCP服务的自动注册与发现。零信任安全架构针对Nacos 2.0 API暴露的安全风险3.0版本通过独立部署控制台、拆分鉴权开关、分类API并默认开启鉴权以及与KMS等云产品合作实现运行时数据库凭据的动态轮转构建了更坚固的安全防线。4.1、MCP RegistryNacos 3.0 最主要的能力就是作为MCP Registry支持了MCP服务的注册管理和发现的能力。Nacos MCP Registry支持三类MCP 服务的注册方式第一类是将存量HTTP或RPC的服务通过声明自动转化为MCP服务配合Higress的协议转换能力 实现0代码改造成MCP服务协议如何将存量API转化为MCP服务详情可参见存量API转换MCP手册。第二类就是新构建的MCP服务注册 配合Spring AI等AI Agent应用框架和Nacos-MCP的sdk能够做到像微服务一样自动注册到Nacos中进行统一的管理和维护如何通过Spring AI或Nacos-MCP的sdk进行MCP服务的自动注册与发现请参见MCP Server自动注册手册。第三类就是已经构建好的或其他供应商提供的MCP服务可以导入到Nacos中进行其描述、工具列表、工具Schema等内容的动态修改和维护让调试MCP服务变得更加简单。4.2、Nacos MCP RouterNacos MCP Router是一个基于MCP官方SDK开发的标准MCP Server为MCP Client提供MCP Server的智能搜索、安装、代理等功能极大地简化了MCP服务的使用流程。 同时Nacos MCP Router跟Nacos MCP Registry结合可以实现MCP Server治理如MCP Server及工具可见性、版本管理等。五、部署模式Nacos 提供了两种部署运行模式单机模式和集群模式5.1、单机模式单机模式又称单例模式, 拥有所有Nacos的功能及特性具有极易部署、快速启动等优点。但无法与其他节点组成集群无法在节点或网络故障时提供高可用能力。单机模式同样可以使用内置Derby数据库默认和外置数据库进行存储。单机模式主要适合于工程师于本地搭建或于测试环境中搭建Nacos环境主要用于开发调试及测试使用也能够兼顾部分对稳定性和可用性要求不高的业务场景。5.2、集群模式集群模式通过自研一致性协议Distro以及Raft协议将多个Nacos节点构建成了高可用的Nacos集群。数据将在集群中各个节点进行同步保证数据的一致性。集群模式具有高可用、高扩展、高并发等优点确保在故障发生时不影响业务的运行。集群模式默认采用外置数据库进行存储但也可以通过内置数据库进行存储。该模式主要适合于生产环境也是社区最为推荐的部署模式。六、生态组件七、路线规划八、生态与最佳实践Nacos 拥有强大的生态集成能力与主流微服务框架无缝对接。在 Spring Cloud 体系中通过引入spring-cloud-starter-alibaba-nacos-discovery和spring-cloud-starter-alibaba-nacos-config依赖即可快速集成服务发现与配置管理功能。集成框架主要作用关键优势Spring Cloud / Spring Boot作为默认的服务注册与配置中心开箱即用注解驱动与Spring生态深度绑定Dubbo替代Zookeeper作为RPC服务的注册中心提供更丰富的元数据管理和健康检查机制Kubernetes与K8s Service互通统一管理容器内外服务打通虚拟机与容器化部署的服务网络一个典型的 Spring Boot 项目集成 Nacos 配置中心的步骤包括在bootstrap.properties中配置 Nacos 服务器地址、命名空间等在 Nacos 控制台创建对应的配置文件Data ID最后在代码中使用Value或ConfigurationProperties注解注入配置值并享受配置动态更新的能力。九、总结与展望Nacos 通过将服务发现、配置管理、服务元数据管理等核心能力融为一体极大地简化了微服务架构的复杂度。其双协议设计、推拉结合的配置更新机制以及面向云原生的架构使其在生产环境中表现出极高的可靠性和灵活性。而 Nacos 3.0 向 AI 原生的演进更是展现了其作为基础设施平台的远见。它不再仅仅服务于传统的微服务开始为AI智能体、大模型应用提供“服务发现”和“配置管理”能力试图成为连接传统IT与AI应用的新一代枢纽。对于开发者而言理解 Nacos 不仅是掌握了一个工具更是把握了云原生向AI原生演进的技术脉搏。十、写在最后的话“Nacos 相信一切都是服务每个服务节点被构想为一个星球每个服务都是一个星系Nacos 致力于帮助这些服务建立连接赋予智能助力每个有面向星辰的梦想能够透过云层飞在云上更好的链接整片星空。”章节二Nacos AP/CP模式切换指南一、前言在微服务架构中服务注册与发现的一致性模型选择直接影响系统的可用性和数据可靠性。Nacos作为阿里巴巴开源的服务发现和配置管理平台提供了AP可用性优先和CP一致性优先两种集群模式开发者可以根据业务场景灵活切换。默认情况下Nacos集群运行在AP模式确保高可用性当需要强一致性保证时可以切换到CP模式。二、两种切换方式Nacos提供了两种主要的模式切换方法通过HTTP API动态切换和通过配置文件静态设置。动态切换无需重启服务但需要确保所有集群节点同步操作配置文件设置则需要在启动前配置重启后生效。1、HTTP API动态切换这是最常用的切换方式通过向Nacos Server发送HTTP PUT请求即可完成模式切换。切换后需要重启Nacos服务使配置生效。# 切换到CP模式curl -X PUT http://nacos-server-ip:8848/nacos/v1/ns/operator/switches?entryserverModevalueCP# 切换回AP模式curl -X PUT http://nacos-server-ip:8848/nacos/v1/ns/operator/switches?entryserverModevalueAP⚠️重要注意事项集群环境下所有节点都需要执行相同的切换命令否则会导致数据不一致必须使用PUT请求GET和POST请求均无效生产环境建议通过控制台操作避免直接调用API带来的风险2、配置文件静态设置在Nacos Server的配置文件中预先设置默认模式这种方式需要在服务启动前配置重启后生效。# application.properties配置示例# 配置中心默认使用CP模式nacos.naming.data.consistencyCP# 服务发现默认使用AP模式spring.cloud.nacos.discovery.consistencyAP三、模式选择与实例配置不同的模式对应不同的实例类型。AP模式只支持临时实例ephemeraltrue而CP模式支持永久实例ephemeralfalse。在切换模式时需要同步调整客户端实例的配置。 客户端实例配置AP模式配置# bootstrap.properties spring.cloud.nacos.discovery.ephemeraltrue临时实例客户端主动发送心跳维持注册状态适合动态变化频繁的服务实例。CP模式配置# bootstrap.properties spring.cloud.nacos.discovery.ephemeralfalse永久实例服务端主动探测实例健康状态适合需要强一致性的配置信息。混合模式支持Nacos支持在同一集群中混合使用AP和CP模式。可以通过服务元数据配置让部分服务使用临时实例AP部分服务使用永久实例CP实现灵活的业务适配。四、核心差异对比AP和CP模式在一致性、可用性、性能等方面存在显著差异了解这些差异有助于做出正确的模式选择决策。对比维度AP模式CP模式一致性保证最终一致性5-30秒强一致性毫秒级可用性分区期间仍可用分区期间不可用协议基础Distro协议去中心化Raft协议强一致性数据存储内存存储临时实例磁盘内存持久实例健康检查客户端心跳15秒超时服务端主动探测注册延迟10ms100-500ms查询延迟1ms约10ms吞吐量10,000 TPS单节点约2,000 TPS受Raft限制五、适用场景建议根据业务特性和一致性要求合理选择AP或CP模式可以最大化系统效能。大多数微服务场景建议使用默认的AP模式仅在特定场景下切换到CP模式。✓选择AP模式当服务实例动态变化频繁如电商秒杀、促销活动等场景允许短暂数据不一致如缓存更新、推荐系统等容忍延迟的场景需要容忍网络分区跨机房、跨地域部署的微服务架构高并发注册发现需要快速注册和下线的服务治理场景✓选择CP模式当配置信息需要严格同步如灰度发布开关、功能开关等服务地址变更需立即生效如数据库主从切换、服务熔断配置金融级数据一致性要求支付状态、交易流水等关键业务数据基础设施注册Redis集群地址、数据库连接池等需要强一致性的配置六、故障恢复与监控不同模式下的故障恢复机制和监控指标各有侧重。了解这些差异有助于在出现问题时快速定位和恢复。 Leader节点宕机场景对比AP模式恢复客户端自动重试其他节点新Leader在3秒内选举完成服务注册不受影响仅元数据短暂不可查CP模式恢复新注册请求被阻塞持续3-10秒客户端SDK自动重试默认5次数据恢复后继续处理关键监控指标AP模式关注• naming_sync_success_rate数据同步成功率• 客户端心跳成功率• 注册/发现延迟CP模式关注• raft_leader_election_countLeader选举次数• 数据同步延迟• 读写请求成功率七、写在最后的话在分布式系统的世界里没有完美的选择只有最适合的权衡。Nacos的AP/CP双模式设计本质上是CAP定理在工程实践中的智慧体现——它不强迫你在一致性和可用性之间二选一而是让你根据业务场景自由调配。就像优秀的厨师懂得根据食材调整火候优秀的架构师也懂得根据业务特性选择合适的一致性模型。记住默认AP按需CP——这八个字能帮你避开大多数坑。