基本架构
如上图，Nacos作为独立运行的服务为应用提供服务注册和服务配置的功能，应用与Nacos服务之间通过客户端SDK或者sidecar进行通信。
Nacos服务端除了提供核心的应用配置和命名服务之外，还对外提供了接口。同时，Nascos服务端支持集群部署，同时还具备一个可视化的管理后台。
基础概念
物理概念
地域：Region，物理的数据中心，资源创建成功后不能更换。
可用区：Available Zone，简称AZ，同一地域内，电力和网络互相独立的物理区域。同一可用区内，实例的网络延迟较低。
逻辑概念
接入点：地域的某个服务的入口域名。
命名空间：Namespace，用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的Group或Data ID的配置。
配置：在系统开发过程中，开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。
配置管理：系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。
配置项：一个具体的可配置的参数与其值域，通常以param-key=param-value的形式存在。
配置集：一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。
配置集ID：Nacos中的某个配置集的ID。配置集ID是组织划分配置的维度之一。Data ID通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID通常采用类Java包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性，此命名规则非强制。
配置分组：Nacos中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy或Trade）对配置集进行分组，从而区分Data ID相同的配置集。当在Nacos上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如：database_url配置和MQ_topic配置。
配置快照：Nacos的客户端SDK会在本地生成配置的快照。当客户端无法连接到Nacos Server时，可以使用配置快照显示系统的整体容灾能力。
服务：通过预定义接口网络访问的提供给客户端的软件功能。
服务名：服务提供的标识，通过该标识可以唯一确定其指代的服务。
服务注册中心：存储服务实例和服务负载均衡策略的数据库。
服务发现：在计算机网络上，（通常使用服务名）对服务下的实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。
元信息：Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。
应用：用于标识服务提供方的服务的属性。
服务分组：不同的服务可以归类到同一分组。
虚拟集群：同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。
实例：提供一个或多个服务的具有可访问网络地址（IP:Port）的进程。
权重：实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。
健康检查：以指定方式检查服务下挂载的实例 (Instance) 的健康度，从而确认该实例 (Instance) 是否能提供服务。根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端。
健康保护阈值：为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，继而造成流量压力把健康实例 (Instance) 压垮并形成雪崩效应，应将健康保护阈值定义为一个0到1之间的浮点数。当域名健康实例数 (Instance) 占总服务实例数 (Instance) 的比例小于该值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群中剩余健康实例 (Instance) 能正常工作。