什么是Nacos

Nacos(官网 site: https://nacos.io ) 致力于帮助您发现、配置和管理您的微服务。它提供了一组简单而有用的特性，使您能够实现动态服务发现、服务配置管理以及服务和流量管理。

Nacos使您更容易、更快地构建、交付和管理微服务平台。它是支持以服务为中心的现代应用程序体系结构的基础设施，该体系结构采用微服务或云本机方法。

服务(Service)是Nacos的一等公民。Nacos支持几乎所有主流类型的“服务”的发现、配置和管理：

Kubernetes Service

gRPC

| Dubbo RPC Service

Spring Cloud RESTful Service

Nacos的主要特点：

Nacos 英文全称 Dynamic Naming and Configuration Service，它是 Spring Cloud Alibaba 的核心组件之一，致力于微服务架构中的服务注册与发现、配置管理。

Nacos 将注册中心和配置中心整合在一起，提供了两个核心功能，即服务注册与发现和动态配置服务。

Nacos 支持基于 DNS 和 基于 RPC 的服务发现，服务提供者向 Nacos 服务端注册服务后，服务消费者可以从 Nacos 服务端获取注册列表。

提供了一个简洁易用的 UI，方便用户管理所有环境的应用配置和服务配置，消除了配置变更时服务需重新部署的过程。还提供了包括 配置版本跟踪 、 金丝雀发布 、 一键回滚配置 以及 客户端配置更新状态跟踪 在内的一系列开箱即用的配置管理特性，大大降低配置变更带来的风险。

Nacos 分为服务端和客户端，服务端用来提供服务发现与注册等功能，客户端就是不同的应用和服务。

在 Nacos 的 Release Notes 可以看到每个版本的相关介绍。当前最新的稳定版本是 1.4.0。

Nacos 服务需要 Java 运行环境，因此，在启动服务之前需要确保你的服务器已经有了 Java 运行环境，并且配置好了 JAVA_HOME 。

参数说明：

-m：指定运行模式，standalone 表示单机模式

在 Nacos 配置文件中配置服务器ip，默认的端口号为8848，默认的用户名和密码均为nacos，访问 http://ip:8848/nacos/index.html 便能够成功登Nacos管理后台。

(1) 引入依赖

在 SpringBoot 项目中引入 Nacos 客户端依赖，pom.xml 添加如下内容：

(2) 修改配置

在 application.properties 配置文件中添加 Nacos 的基本配置 (也可以是 application.yml )

1）application.properties

2）application.yml

(3) @EnableDiscoveryClient 注解

在 SpringBoot 的启动类上添加 @EnableDiscoveryClient 注解来开启服务注册。

Nacos Discovery 默认集成了 Netflix Ribbon，服务消费者可以使用 RestTemplate 或 OpenFeign 进行服务的调用。

(1) Nacos 启动时报如下错误

问题原因：通过yum命令安装的普通的openJDK没有javac等工具，而且安装完以后连环境变量都不需要配置，就能使用 java -version 验证。

解决方案：重新安装devel开发版openJDK，开发版的openJDK有javac工具，然后配置java环境变量即可。

(2) Nacos Provider 启动报错

问题原因：没有配置 Nacos 服务端的地址，因此，当 Nacos Provider 启动的时候，无法与注册中心通信

解决方案：在配置文件中配置 Nacos 服务端地址，如下所示：

最近有项目组同学问到为什么自己配置了nacos，但配置不生效？我简单看了下，发现问题出在相关配置的优先级模式不同。

spring-boot项目，有bootstrap、application两个配置文件，结合profile，和支持的文件格式properties、yaml，已经有6个配置文件了。然后使用了spring-cloud-starter-alibaba-nacos-config 后，又提供了三级配置。这些配置之间的组合关系，将在无形中影响配置的效果。很多同学只知道其中的一种，因此在无意识引入两种或以上的配置后，就会发现有奇怪的配置不生效问题发生。

spring-boot项目依赖bootstrap.yml 用于应用程序上下文的引导阶段，由父Spring ApplicationContext加载，其工作的阶段为父ApplicationContext 被加载到使用application.yml的之前。也就是说 bootstrap 加载优先于 applicaton。

bootstrap 主要用于从额外的资源来加载配置信息，还可以在本地外部配置文件中解密属性。这两个上下文共用一个环境，它是任何Spring应用程序的外部属性的来源。bootstrap 里面的属性会优先加载，它们默认也不能被本地相同配置覆盖。

bootstrap 配置文件有以下几个应用场景：

由于spring-boot支持多种文件格式，所以多种格式之间，其优先级是平等的，只要找到了一个，就会被使用。一般有：.properties、.yaml、.xml等格式。

应用级别的spring-boot配置文件，主要用于 Spring Boot 项目的自动化配置，其加载优先级低于bootstrap.yaml。

nacos作为外部配置服务器，通过spring-boot的bootstrap.yaml引入。但nacos本身，也提供了三级配置体系：主配置(只有一个，但会按照不同后缀名，去找到相关配置）、扩展配置、共享配置。

三级配置的优先级如下：主配置 >扩展配置 >共享配置

nacos提供的配置路径 spring.cloud.nacos.config 下，有一系列的属性用于定位主配置。基于 prefix（默认为 ${spring.application.name} 的值）、namespace、group（默认为字符串 DEFAULT_GROUP ）、file-extension（默认为字符串 .properties ），按组装规则 ${prefix}-${spring.profiles.active}.${file-extension} 去找到一个配置。

在nacos的所有配置中，主配置（存在的情况下）具有最高的优先级，其同名配置值不能被扩展配置或共享配置中定义的同名属性所覆盖。

上述两类配置都支持三个属性： data-id 、 group （默认为字符串 DEFAULT_GROUP ）、 refresh （默认为 true ）。

实际上，nacos中并未对 extension-configs 和 shared-configs 的差别进行详细阐述。我们从他们的结构，看不出本质差别；除了优先级不同以外，也没有其他差别。那么，nacos项目组为什么要引入两个类似的配置呢?我们可以从当初 该功能的需求（issue） 上找到其原始目的。

摘要其核心内容如下：

---