Nacos

一、Nacos简介

nacos致力于发现、配置、管理微服务，快速实现动态服务发现服务配置、服务元数据以及流量管理。

1.核心功能：

• 服务注册：发送REST请求向Nacos Server注册自己的服务
• 服务心跳：通过心跳机制维护Nacos Server，说明服务一直处于可用状态，防止被剔除，默认5s发送一次心跳
• 服务同步:集群之间会相互同步服务实例，用来保证服务信息一致性
• 服务发现：服务消费者获取Nacos Server上面注册的服务清单，缓存到Nacos Client本地会在Nacos Client开启一个定时任务的拉取服务最新的注册表信息更新到本地缓存。
• 服务健康检查：开启一个定时任务来检查服务实例的健康情况，超过15s没有心跳的实例会将它的healthy属性设置为false，实例超过30s没有心跳。直接剔除该实例，如果被剔除的实例回复心跳则重新注册

2.Nacos中的基本概念
地域

物理的数据中心，资源创建成功后不能更换。

可用区

同一地域内，电力和网络互相独立的物理区域。同一可用区内，实例的网络延迟较低。
接入点

地域的某个服务的入口域名。
命名空间

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

在系统开发过程中，开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。
目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。
配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成。
配置变更是调整系统运行时的行为的有效手段。
配置管理

系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。
配置项

一个具体的可配置的参数与其值域
通常以 param-key=param-value 的形式存在。
例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。
配置集

一组相关或者不相关的配置项的集合称为配置集。
在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。
例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。
配置集 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 时，可以使用配置快照显示系统的整体容灾能力。
配置快照类似于 Git 中的本地 commit，也类似于缓存，会在适当的时机更新，但是并没有缓存过期（expiration）的概念。
服务

通过预定义接口网络访问的提供给客户端的软件功能。
服务名

服务提供的标识，通过该标识可以唯一确定其指代的服务。
服务注册中心

存储服务实例和服务负载均衡策略的数据库。
服务发现

在计算机网络上，（通常使用服务名）对服务下的实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。
元信息

Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。
应用

用于标识服务提供方的服务的属性。
服务分组

不同的服务可以归类到同一分组。
虚拟集群

同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。
实例

提供一个或多个服务的具有可访问网络地址（IP:Port）的进程。
权重

实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。
健康检查

以指定方式检查服务下挂载的实例 (Instance) 的健康度，从而确认该实例 (Instance) 是否能提供服务。根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端。
健康保护阈值

为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，继而造成流量压力把健康实例 (Instance) 压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。
当域名健康实例数 (Instance) 占总服务实例数 (Instance) 的比例小于该值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。
这样做虽然损失了一部分流量，但是保证了集群中剩余健康实例 (Instance) 能正常工作。

二、主要功能

1.服务 (Service)

服务是指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。
Nacos 支持主流的服务生态，如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service。

2.服务注册中心 (Service Registry)

服务注册中心，它是服务，其实例及元数据的数据库。
服务实例在启动时注册到服务注册表，并在关闭时注销。
服务和路由器的客户端查询服务注册表以查找服务的可用实例。
服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。

3.服务元数据 (Service Metadata)

服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。

4.服务提供方 (Service Provider)

是指提供可复用和可调用服务的应用方。

5.服务消费方 (Service Consumer)

是指会发起对某个服务调用的应用方。

6.配置 (Configuration)

在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。
目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。
配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成这个步骤。
配置变更是调整系统运行时的行为的有效手段之一。

7.配置管理 (Configuration Management)

在数据中心中，系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。

8.名字服务 (Naming Service)

提供分布式系统中所有对象(Object)、实体(Entity)的“名字”到关联的元数据之间的映射管理服务
例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info,
DNS Domain Name -> IP List,
服务发现和 DNS 就是名字服务的2大场景。

9.配置服务 (Configuration Service)

在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

原理

nacos 配置中心采用

客户端 long pull 的方式
Nacos 客户端会循环请求服务端变更的数据，并且超时时间设置为30s，当配置发生变化时，请求的响应会立即返回，否则会一直等到 29.5s+ 之后再返回响应
客户端的请求到达服务端后，服务端将该请求加入到一个叫 allSubs 的队列中，等待配置发生变更时 DataChangeTask主动去触发，并将变更后的数据写入响应对象。
与此同时服务端也将该请求封装成一个调度任务去执行，等待调度的期间就是等DataChangeTask 主动触发的，如果延迟时间到了 DataChangeTask 还未触发的话，则调度任务开始执行数据变更的检查，然后将检查的结果写入响应对象（基于文件的MD5）
nacos注册中心采用了

pull （客户端的轮询）
push （服务端主动push）
客户端启动时会将当前服务的信息包含ip、端口号、服务名、集群名等信息封装为一个Instance对象然后创建一个定时任务，每隔一段时间向Nacos服务器发送PUT请求并携带相关信息。
nacos服务器端在接收到心跳请求后，会去检查当前服务列表中有没有该实例，如果没有的话将当前服务实例重新注册，注册完成后立即开启一个异步任务，更新客户端实例的最后心跳时间，如果当前实例是非健康状态则将其改为健康状态。
心跳定时任务创建完成后，通过POST请求将当前服务实例信息注册进nacos服务器。
nacos服务器端在接收到注册实例请求后，会将请求携带的数据封装为一个Instance对象，然后为这个服务实例创建一个服务Service，一个Service下可能有多个服务实例，服务在Nacos保存到一个ConcurrentHashMap中Map(namespace,Map(group::serviceName, Service))； 。
nacos将实例添加到对应服务列表中会根据AP和CP不同的模式，采用不同协议。
CP模式就是基于Raft协议（通过leader节点将实例数据更新到内存和磁盘文件中，并且通过CountDownLatch实现了一个简单的raft写入数据的逻辑，必须集群半数以上节点写入成功才会给客户端返回成功）
AP模式基于Distro协议（向任务阻塞队列添加一个本地服务实例改变任务，去更新本地服务列表，然后在遍历集群中所有节点，分别创建数据同步任务放进阻塞队列异步进行集群数据同步，不保证集群节点数据同步完成即可返回）
nacos在将服务实例更新到服务注册表中时，为了防止并发读写冲突，采用的是写时复制的思想，将原注册表数据拷贝一份，添加完成之后再替换回真正的注册表。
nacos在更新完成之后，通过发布服务变化事件，将服务变动通知给客户端，采用的是UDP通信，客户端接收到UDP消息后会返回一个ACK信号，如果一定时间内服务端没有收到ACK信号，还会尝试重发，当超出重发时间后就不在重发。
客户端通过定时任务定时从服务端拉取服务数据保存在本地缓存。
服务端在发生心跳检测、服务列表变更或者健康状态改变时会触发推送事件，在推送事件中会基于UDP通信将服务列表推送到客户端，虽然通过UDP通信不能保证消息的可靠抵达，由于Nacos客户端会开启定时任务，每隔一段时间更新客户端缓存的服务列表，通过定时轮询更新服务列表做兜底，所以不用担心数据不会更新的情况，这样既保证了实时性，又保证了数据更新的可靠性。

心跳机制
服务的健康检查分为两种模式

客户端上报模式：客户端通过心跳上报的方式告知nacos 注册中心健康状态（默认心跳间隔5s，nacos将超过超过15s未收到心跳的实例设置为不健康，超过30s将实例删除）
服务端主动检测：nacos主动检查客户端的健康状态（默认时间间隔20s，健康检查失败后会设置为不健康，不会立即删除）
nacos 目前的instance有一个ephemeral字段属性，该字段表示实例是否是临时实例还是持久化实例。

如果是临时实例则不会在nacos中持久化，需要通过心跳上报，如果一段时间没有上报心跳，则会被nacos服务端删除。
删除后如果又重新开始上报，则会重新实例注册。
而持久化实例会被nacos服务端持久化，此时即使注册实例的进程不存在，这个实例也不会删除，只会将健康状态设置成不健康。
这里就涉及到了nacos的AP和CP模式

默认是AP，即nacos的client的节点注册时ephemeral=true，那么nacos集群中这个client节点就是AP，采用的是distro 协议
而ephemeral=false时就是CP采用的是raft协议实现。所以nacos可以很好的解决了业务常见的不同需求
#false为永久实例，true表⽰临时实例开启，注册为临时实例，默认是true
spring.cloud.nacos.discovery.ephemeral=true

为什么nacos有两种心跳机制？
对于临时实例，健康检查失败，则直接删除。这种特性适合于需要应对流量突增的场景，服务可以弹性扩容，当流量过去后，服务停掉即可自动注销。
对于持久化实例，健康检查失败，会设置为不健康状态。它的优点就是可以实时的监控到实例的健康状态，便于后续的告警和扩容等一系列处理。
自我保护
nacos也有自我保护机制（当前健康实例数/当前服务总实例数），值为0-1之间的浮点类型。
正常情况下nacos 只回健康的实例。
但在高并发场景，如果只返回健康实例的话，流量洪峰到来可能直接打垮剩下的健康实例，产生雪崩效应。
保护阈值存在的意义在于当服务A健康实例数/总实例数 < 保护阈值时，Nacos会把该服务所有的实例信息（健康的+不健康的）全部提供给消费者
消费者可能访问到不健康的实例，请求失败，但这样远比造成雪崩要好。牺牲了请求，保证了整个系统的可用。
简单来说不健康实例的另外一个作用：防止雪崩

总结

服务注册到注册中心后，服务的消费者就可以向注册中心订阅某个服务，并提交一个监听器，当注册中心中服务发生变更时，监听器会收到通知，这时消费者更新本地的服务实例列表，以保证所有的服务均是可用的。
Nacos注册可以概括为以下六步
服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。