Nacos简介

什么是Nacos？

服务是Nacos世界的一等公民。Nacos支持几乎所有的主流类型的”服务“ 的发现配置和管理：
Kubernetes Service
gRPC & Dubbo RPC Service
Spring Cloud RESTful Service
Nacos的关键特性包括：
1、服务发现和服务健康检测
Nacos支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的AgentTODO注册Service后、服务消费者可以使用DNSTODO或HTTP&API查找或发现服务。
Nacos提供对服务的实时的健康检测，阻止向不健康的主机或服务实例发送请求。Nacos支持传输层（PING或TCP）和应用层（如HTTP、MySQL、用户自定义）的健康检测。对于复杂的云环境和网络拓扑环境中（如VPC、边缘网络等）服务的健康检查，Nacos提供了agent上报模式和服务端主动检测2中健康检查模式。Nacos还提供了通一的健康检查仪表盘，帮助您根据健康状态管理服务放入可用性及流量。

动态配置服务

动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的用配置和服务配置。
动态配置消除了以配置变更时重新部署应用和服务的需要，让配置管理变得更加高和敏捷。
配置中心化管理让实现无服务变得更简单，让服务按需弹性扩展变得更容易。
Nacos提供了一个简介易用的Ui帮助您管理所有的服务和应用的配置，Nacos还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来风险。

动态DNS服务

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

服务列表详情调整权重
报错：

caused: errCode: 500, errMsg: do metadata operation failed ;caused: com.alibaba.nacos.consistency.exception.ConsistencyException: com.alibaba.nacos.core.distributed.raft.exception.NoLeaderException: The Raft Group [naming_instance_metadata] did not find the Leader node;caused: com.alibaba.nacos.core.distributed.raft.exception.NoLeaderException: The Raft Group [naming_instance_metadata] did not find the Leader node;

停掉nacos服务
将nacos文件夹下data中的protocol文件夹删除
重启nacos服务即可

服务及其元数据管理

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

Nacos无缝支持一些主流的开源生态，例如
SpringCloud、Apache Dubbo and DubboMesh、Kubernetes and CNCF
使用Nacos简化服务发现、配置管理、服务治理及管理的解决方案、让微服务的发现、管理共享、组合更加容易。

Nacos概念

地域：物理的数据中心，资源创建成功后不能更换。
可用区：同一地域内，电力和网络互相的独立的物理区域。同一可用区内，实例的网络延迟较低。
接入点：地域的某个服务的入口域名。
命名空间：用于进行租户粒度的配置隔离。不同的命名空间下，可以在存在相同的Group或DataID的配置。Namrepace的常用场景之一是不同环境的配置的区分隔离，例如开发环境和生产环境的资源如配置服务隔离等。
配置： 在系统开发过程中，开发者通常将一些需要变更的参数，变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工作或者交付物（如WAR,JAR包等）更好的和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中，有系统管理或者运维人员完成。配置变更是调整系统运行时的行为的有效手段。
配置管理： 系统配置的编辑、存储、分发、变更管理、历史版本管理变更审计等所有与配置相关的活动。
配置项： 一个具体的配置的参数与其值域，通常param-key=param-vale的形式存在。例如我们常配置系统的日志输出及别就是一个配置项
配置集 一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配置集，包含了系统各方面的配置。例如，一个配置集可能包含了数据源、线程持、日志级别等配置项。
配置ID
Nacos中的某个配置集的ID。配置集ID是组织划分配置的维度之一。DateID通常用与组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。DateID通常采用类java包的命名规则保证全局唯一性。此命名规则非强制。
配置分组
Maocs中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串对配置就进行分组，从而区分DateID相同配置集。当您在Nacos上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用DEFAULT_GROUP配置分组的常见场景：不同的因引用场景或组件使用了相同的配置类型，如database_url配置和MQ_tiopic配置。
配置快照
Nacos的客户端SDK会在本地生成配置的快照。当客户端无法连接到NacosServer时，可以使用配置快照显示系统色整体容灾能力。配置快照类似与Git中的本地cimmit，也类似与缓存，会在适当的时机更新，但是并没有缓存过期的概念。
服务
通过预定义接口网络访问的提供给客户端的软件功能。
服务名
服务提供的标识，通过改标识可以唯一确定其指代的服务。
服务的注册中心
存储服务实例和服务负载均衡策略的数据库。
服务发现
在计算机网络上，对服务下的实例的地址和数据进行探测，并以预先定义的接口提供给客户端进行查询。
虚拟集群
同一个服务下的服务实例组成一个默认集群，集群可以被进一步按需求划分，划分的单位可以时虚拟集群。
实例
提供一个或多个服务的具有可访问网路地址的进程。
权重
实例级别的配置。权重为浮点数。权重越大，分配给实力的流量越大。
健康检查
以指定方式检查服务下挂载的实例的健康度，从而确认改实例是否提供服务。根据检查结果，实例会被判断为健康或不健康。对服务发起解析请求时，不健康的实例不会返回给客户端。
健康保护阀值
为了防止因为多实例不健康导致流量全部流向健康实例，继而造成流量压力把健康实例压垮并形成雪崩效应，应将健康保护阈值定义为一个0到1之间的浮点数，当域名健康实例数占总服务数的比例小于该值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失了一部分流量，但是保证了集群中剩余健康实例能整正常工作。