文章目录
什么是Nacos
Nacos：(Dynamic) Naming and Configuration Service，动态的服务发现和配置的服务，是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以"服务"为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型"服务"的发现、配置和管理：Kubernetes Service、gRPC & Dubbo RPC Service、Spring Cloud RESTful Service。
Nacos 真正将配置从应用中剥离出来，统一管理，优雅的解决了配置的动态变更、持久化、运维成本等问题。
应用自身既不需要去添加管理配置接口，也不需要自己去实现配置的持久化，更不需要引入"定时任务"以便降低运维成本。Nacos 提供的配置管理功能，将配置相关的所有逻辑都收拢，并且提供简单易用的 SDK，让应用的配置可以非常方便被 Nacos 管理起来。
核心：配置管理、服务发现，即配置中心、服务注册中心。
Nacos 的关键特性包括:
服务发现和服务健康监测
Nacos 支持基于 DNS 和基于 RPC 的服务发现。
Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。
动态配置服务
动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
动态 DNS 服务
动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。
服务及其元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
总结：使用 Nacos 简化服务发现、配置管理、服务治理及管理的解决方案，让微服务的发现、管理、共享、组合更加容易。
基本概念
配置服务 (Configuration Service)
在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。
Namespace
命名空间，租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。默认public。
Configuration Item
配置项。一个具体的可配置的参数与其值域，通常以 param-key=param-value 的形式存在。例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。
Configuration Set
配置集。一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配置集。
Data ID
配置集ID，Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。
Group
配置分组，区分 Data ID 相同的配置集。默认值 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
名字服务 (Naming Service)
提供分布式系统中所有对象(Object)、实体(Entity)的"名字"到关联的元数据之间的映射管理服务，例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。
Service
服务，通过预定义接口提供网络访问给客户端的软件功能。
ServiceName
服务名，服务提供的标识，通过该标识可以唯一确定其指代的服务。
Service Registry
服务注册中心，存储服务实例、服务元数据和服务负载均衡策略的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。
Service Discovery
服务发现，在计算机网络上，（通常使用服务名）对服务下实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。
Metadata
元信息，Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。
Application
应用，服务的属性，用于标识服务提供方。
Service Group
服务分组，不同的服务可以归类到同一分组。
Virtual Claster
虚拟集群，同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。
Instance
实例，提供一个或多个服务的具有可访问网络地址（IP:Port）的进程。
Weight
权重，实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。
Health Check
健康检查，以指定方式检查服务下挂载的实例 (Instance) 的健康度，从而确认该实例 (Instance) 是否能提供服务。根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端。
Protect Threshold
健康保护阈值，为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，继而造成流量压力把健康实例 (Instance) 压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例数 (Instance) 占总服务实例数 (Instance) 的比例小于该值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群中剩余健康实例 (Instance) 能正常工作。
基本架构
逻辑架构及其组件介绍
- OpenAPI：暴露标准Rest风格HTTP接口，简单易用，方便多语言集成
- Console：易用控制台，做服务管理、配置管理等操作
- SDK：多语言sdk
- Agent：dns-f类似模式，或者与mesh等方案集成
- CLI：命令行对产品进行轻量化管理，像git一样好用
领域模型
数据模型
Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），Group默认是 DEFAULT_GROUP。
服务领域模型
配置领域模型
围绕配置，主要有两个关联的实体，一个是配置变更历史，一个是服务标签（用于打标分类，方便索引），由 ID 关联。
下载
在tags中找到想要下载的版本
下载链接
目录结构
配置
standalone单机模式中需要更改bin目录下的startup配置文件
windows修改.bat文件，linux修改.sh文件
找到MODE，将MODE修改为standalone，set MODE="standalone"
Nacos支持多种数据库，默认是Mysql，在conf目录下有对应的Mysql脚本，mysql-schema.sql执行这一个就可以了。
导入mysql后编辑application配置文件将Mysql的信息配置上去
properties
db.url.0=jdbc:mysql://192.168.0.110:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=root!@#123
启动
windows 环境下 进入bin目录下，双击startup.cmd文件
Linux 环境下通过命令启动
shell
./startup.sh