Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、mysql、用户自定义）的健康检查。对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

动态配置服务

动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。

动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。

配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

动态 DNS 服务

动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。

Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.

服务及其元数据管理

Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。

Nacos 地图

特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求

架构大图：通过清晰架构，让您快速进入 Nacos 世界

业务大图：利用当前特性可以支持的业务场景，及其最佳实践

生态大图：系统梳理 Nacos 和主流技术生态的关系

优势大图：展示 Nacos 核心竞争力

战略大图：要从战略到战术层面讲 Nacos 的宏观优势

Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

使用 Nacos 简化服务发现、配置管理、服务治理及管理的解决方案，让微服务的发现、管理、共享、组合更加容易。

各种服务注册中心模型区别

Nacos的AP和CP

Nacos无缝支持一些主流的开源生态，同时再阿里进行Nacos设计的时候重复的考虑到了市场化的运作（市面上大多都是以单一的实现形式为主，例如：Zookeeper使用的是 CP、而 Eureka采用的是AP），在Nacos中提供了两种模式的动态切换。

Nacos 何时选择切换模式

1.一般来说，如果不需要储存服务界别的信息且服务实例通过nacos-client注册，并能够保持心跳上报，那么就可以选择AP模式。如Spring Cloud和Dubbo,都适用于AP模式, AP模式为了服务的可用性减弱了一致性,因此AP模式下只支持注册临时实例。

2.如果需要在服务级别编辑或者储存配置信息,那么CP是必须的，K8S服务和DNS服务则是用于CP模式。CP模式下则支持注册持久化实例，此时则是以Raft协议为集群运行模式，该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误。

3. 切换命令（默认是AP）：

cur1 -X PUT 'SNACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

注意：临时和持久化的区别主要在健康检查失败后的表现，持久化实例健康检查失败后会被标记成不健康，而临时实例会直接从列表中被删除。

命名空间、分组和DataId

名词解释

命名空间(Namespace)

用于进行租户粒度的配置隔离。不同的命名空间下,可以存在相同的Group或Data ID的配置。Namespace的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务)隔离等。

配置分组（Group)

Nacos中的一组配置集,是组织配置的维度之一。通过一个有意义的字符串(如 Buy 或Trade )对配置集进行分组,从而区分DataID相同的配置集（即一个命名空间下，不同的分组，可以有相同名称的配置文件）。当您在Nacos上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用DEFAULT_GROUP。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

配置集ID (Data ID)

Nacos中的某个配置集的ID。配置集 ID 是组织划分配置的维度之一（一个真实的系统有一个或者多个dataId）。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。Data ID通常采用类Java包(如com.taobao.tc.refund.log.level)的命名规则保证全局唯一性。此命名规则非强制。

配置集:一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。

三者关系

这三者的关系类似于Java里面的package名和类名，最外层的Namespace是可以用于区分部署环境的，Group和DatalD逻辑上区分两个目标对象。

默认情况

Namespace=public, Group=DEFAULT_GROUP,默认Cluster是DEFAULT

具体情况

Nacos默认的命名空间是public，我们就可以利用Namespace来实现隔离，比如我们现在有三个环境：开发、测试、生产环境，我们就可以创建三个Namespace，不同的N amespace之间是隔离的。

Group本身就是分组的意思，它可以把不同的微服务划分到同一个分组里面去。

剩下的就是具体微服务，一个Service可以包含多个Cluster, Nacos默认Cluster是DEFAULT, Cluster是对指定微服务的一个虚拟划分。比如说，将一个Service部署在北京和和杭州的机房中，北京机房的Service就可以起名为（BJ），杭州机房中的Service就可以起名为（HZ），这样就可以尽量让同一个机房的微服务互相调用，提升性能。

Nacos集群

Nacos支持三种部署模式

1.单机模式-用于测试和单机试用

2.集群模式-用于生产环境，确保高可用

3.多集群模式 - 用于多数据中心场景

集群部署说明

参考网站: https://nacos.io/zh-cn/docs/cluster-mode-quick-start.html

架构图：部署生产使用的集群模式

预备环境

默认Nacos使用嵌入式数据库实现数据的存储，所以，如果启动多个默认配置下的Nacos节点，数据储存存在一致性问题，为了解决这个问题，Nacos采用了集中存储方式来支持集群化部署，目前仅支持MySql的存储。

1.推荐使用Linux

2.可以使用内部数据源或者外部数据源（推荐使用外部）MySql

Nacos持久化配置

Nacos默认自带嵌入式数据库derby，所以我们每次创建一个Nacos实例就会有一个derby，当有多个Nacos节点的时候，就会出现一致性问题，所以Nacos支持了外部数据库统一数据管理MySql。

Spring Cloud Alibaba基础教程：Nacos配置的加载规则详解

前情回顾：

上一篇，我们学习了如何在Nacos中创建配置，以及如何使用Spring Cloud Alibaba的Nacos客户端模块来加载配置。在入门例子中，我们只配置了Nacos的地址信息，没有配置任何其他与配置加载相关的其他内容。所以，接下来准备分几篇说说大家问的比较多的一些实际使用的问题或疑问。

加载规则

在《Spring Cloud Alibaba基础教程：使用Nacos作为配置中心》一文中，我们的例子完全采用了默认配置完成。所以，一起来看看Spring Cloud Alibaba Nacos模块默认情况下是如何加载配置信息的。

首先，回顾一下，我们在入门例子中，Nacos中创建的配置内容是这样的：

Data ID：alibaba-nacos-config-client.properties
Group：DEFAULT_GROUP

拆解一下，主要有三个元素，它们与具体应用的配置内容对应关系如下：

Data ID中的alibaba-nacos-config-client：对应客户端的配置spring.cloud.nacos.config.prefix，默认值为${spring.application.name}，即：服务名
Data ID中的properties：对应客户端的配置spring.cloud.nacos.config.file-extension，默认值为properties
Group的值DEFAULT_GROUP：对应客户端的配置spring.cloud.nacos.config.group，默认值为DEFAULT_GROUP

在采用默认值的应用要加载的配置规则就是：Data ID=${spring.application.name}.properties，Group=DEFAULT_GROUP。

下面，我们做一些假设例子，方便大家理解这些配置之间的关系：

例子一：如果我们不想通过服务名来加载，那么可以增加如下配置，就会加载到Data ID=example.properties，Group=DEFAULT_GROUP的配置内容了：

spring.cloud.nacos.config.prefix=example

例子二：如果我们想要加载yaml格式的内容，而不是Properties格式的内容，那么可以通过如下配置，实现加载Data ID=example.yaml，Group=DEFAULT_GROUP的配置内容了：

spring.cloud.nacos.config.prefix=example
spring.cloud.nacos.config.file-extension=yaml

例子三：如果我们对配置做了分组管理，那么可以通过如下配置，实现加载Data ID=example.yaml，Group=DEV_GROUP的配置内容了：

spring.cloud.nacos.config.prefix=example
spring.cloud.nacos.config.file-extension=yaml
spring.cloud.nacos.config.group=DEV_GROUP

深入思考

上面，我们具体介绍了在Nacos中添加的各种配置与Spring Cloud应用中客户端配置的对照关系。对于spring.cloud.nacos.config.prefix和spring.cloud.nacos.config.file-extension来说，没有太多的花样可以去揣摩，大部分用户默认配置就可以使用，或者通过spring.cloud.nacos.config.file-extension修改下配置格式的后缀。

但是对于spring.cloud.nacos.config.group的配置来说，还是可以派一些特殊的作用，比如：用它来区分不同的产品组下各个应用的配置内容（解决可能应用名冲突的问题）、或者用它来区分不同用途的配置内容、再或者用它来区分不同环境的配置（Nacos下的配置纬度很多，我们可以通过不同的手段来实现多环境的配置，后面会专门写一篇如何实现多环境的配置）等。

如果您对spring.cloud.nacos.config.group还有什么其他妙用，欢迎留言分享您的使用方案。

参考资料

Nacos官方文档

代码示例

本系列教程的代码案例，都可以通过下面的仓库查看：

Github：https://github.com/dyc87112/SpringCloud-Learning/
Gitee：https://gitee.com/didispace/SpringCloud-Learning/

如果您对这些感兴趣，欢迎star、follow、收藏、转发给予支持！

以下专题教程也许您会有兴趣

以上是关于Spring Cloud Nacos基础的主要内容，如果未能解决你的问题，请参考以下文章

Spring Cloud Alibaba基础教程：Nacos的数据持久化

Spring Cloud Alibaba基础教程：Nacos配置的加载规则详解

Spring Cloud Alibaba基础教程：Nacos配置的多文件加载与共享配置

Spring Cloud Alibaba 使用nacos 注册中心

Spring Cloud Alibaba nacos 配置中心使用

Spring Cloud Alibaba 使用nacos 注册中心