nacos知识点

nacos注册中心实现原理分析

1.Nacos架构图

服务注册中心 (Service Registry)：服务注册中心，它是服务，其实例及元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。
服务提供方 (Service Provider)：是指提供可复用和可调用服务的应用方。
服务消费方 (Service Consumer)：是指会发起对某个服务调用的应用方。
配置 (Configuration)：在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成这个步骤。配置变更是调整系统运行时的行为的有效手段之一。
配置管理 (Configuration Management)：数据中心中，系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。
名字服务 (Naming Service)：提供分布式系统中所有对象(Object)、实体(Entity)的“名字”到关联的元数据之间的映射管理服务，例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。
配置服务 (Configuration Service)：在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

整个Nacos集群，服务提供者通过Vip（virtual Ip）访问Nacos Server 高可用集群，基于Open Api 完成服务的注册和服务的查询。Nacos Servcie 本身可以支持主备模式。底层采用数据一致性算法完成从节点的数据同步。

2.Nacos注册中心原理

服务实例启动时启动到服务注册表中，关闭时注销；
服务消费者查询服务注册表，获得可用实例并缓存在本地，服务调用时先从本地读取服务注册表；
服务注册中心需求调用服务实例的健康检查API来验证它是否能够处理请求。

server需要通过nacos官方的OpenApi提供的接口来发起服务注册请求，随后server会定时向nacos发送心跳信息来进行心跳检测，对于使用者来说这一步可以采用ScheduledExecutorService创建定时任务来完成。nacos会异步的处理注册请求任务和心跳任务。

3.nacos心跳机制

nacos和client之间采取推拉结合的交互方式，

一方面client可以通过定时任务每隔10s向nacos发起查询请求，如果服务列表改变nacos就会返回新列表，

另一方面当本地服务实例发生变化时（即server实例注册成功或者心跳停止断开链接），nacos会主动通过UDP协议推送到client，udp协议非常快，不需要保持长连接。在注册中心的场景中client数量往往多于server，如果每一次服务更新，nacos要和成千上万的服务消费者去建立Tcp的话性能肯定是不行的。而如果UDP通知失败，客户端每10秒还会主动去拉一次，客户端拉取和服务器推送是互补的，这样既能保证server实例更新的时效性，又能提高效率。 

server向nacos发起注册任务请求，并维持一个心跳检测的定时任务，naocs会通过阻塞队列异步地处理这些请求，并实时的通过UDP推送到client，为防止UDP数据丢失，client也会通过定时任务每隔10s向nacos发送拉取请求，当服务列表改变，nacos再返回。
 

4.Nacos和CAP

集群下AC模式NACOS所有节点在同一时间看到的数据是一致的；而AP模式的定义是NACOS客户端所有的请求都会收到响应。

何时选择使用何种模式？
1.一般来说，如果不需要存储服务级别的信息且服务实例是通过nacos-client注册，并能够保持心跳上报，那么就可以选择AP模式。当前主流的服务如 Spring cloud 和 Dubbo 服务，都适用于AP模式，AP模式为了服务的可能性而减弱了一致性，因此AP模式下只支持注册临时实例。（注册中心作为系统中很重要的的一个服务，需要尽最大可能对外提供可用的服务，通常选择 AP 来保证服务的高可用）
2.如果需要在服务级别编辑或者存储配置信息，那么 CP 是必须，K8S服务和DNS服务则适用于CP模式。CP模式下则支持注册持久化实例，此时则是以 Raft 协议为集群运行模式，该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误。(采用 CP 协议，则需要当前集群可用的节点数过半才能工作)

临时实例和永久实例的区别
1.临时实例只是临时存在于注册中心中，会在服务下线或不可用时被注册中心剔除，临时实例会与注册中心保持心跳，注册中心会在⼀段时间没有收到来自客户端的心跳后会将实例设置为不健康，然后在⼀段时间后进行剔除。
2.永久实例在被删除之前会永久的存在于注册中心，且有可能并不知道注册中心存在，不会主动向注册中心上报心跳，那么这个时候就需要注册中心主动进行探活。

4.临时实例健康检查机制
在 Nacos 中，用户可以通过两种方式进行临时实例的注册，通过 Nacos 的 OpenAPI 进行服务注册或通过 Nacos 提供的 SDK 进行服务注册。两种方式都是由客户端向注册中心发送心跳，注册中心会在连接断开或是心跳过期后将不健康的实例移除。
OpenAPI 的注册方式实际是用户根据自身需求调用 Http 接口对服务进行注册，然后通过 Http 接口发送心跳到注册中心。在注册服务的同时会注册⼀个全局的客户端心跳检测的任务。在服务⼀段时间没有收到来自客户端的心跳后，该任务会将其标记为不健康，如果在间隔的时间内还未收到心跳，那么该任务会将其剔除。
SDK 的注册方式实际是通过 RPC 与注册中心保持连接（Nacos 2.x 版本中，旧版的还是仍然通过OpenAPI 的方式），客户端会定时的通过 RPC 连接向 Nacos 注册中心发送心跳，保持连接的存活。如果客户端和注册中心的连接断开，那么注册中心会主动剔除该 client 所注册的服务，达到下线的效果。同时 Nacos 注册中心还会在注册中心启动时，注册⼀个过期客户端清除的定时任务，用于删除那些健康状态超过⼀段时间的客户端。

5.负载均衡

 nginx负载均衡和gateway负载均衡是两种不同的负载均衡技术，

nginx负载均衡是通过nginx服务器来分配客户端请求到多个后端服务器，【服务器端负载均衡器】

gateway负载均衡是通过Spring Cloud Gateway来分配客户端请求到多个微服务。

nacos负载均衡是通过阿里巴巴的nacos服务发现和配置中心来实现负载均衡，它可以根据服务的健康状态和负载情况来自动分配请求到可用的实例。

ribbon负载均衡是Spring Cloud中内置的负载均衡组件，它可以通过配置负载均衡策略和服务列表来实现负载均衡。【ribbon将Eureka或者Zookeeper的所有服务缓存到本地，然后通过ribbon的负载均衡策略达到均衡分发服务的目的】

nginx和gateway主要用于分配请求到不同的服务端，nacos和ribbon主要用于服务发现和负载均衡(实现本地负载均衡)。同时，这些负载均衡技术也可以结合使用，比如可以使用nginx或gateway来分配请求，同时使用nacos或ribbon来实现服务发现和负载均衡。

三者的关系：

ribbon

nacos和eureka区别

1 nacos有临时实例（宕机超时剔除服务列表）和非临时实例（宕机不剔除）可配置ephemeral: false # 设置为非临时实例；
2 Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

  共同：都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测。

  区别：Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式。临时实例心跳不正常会被剔除，非临时实例则不会被剔除。Nacos支持服务列表变更的消息推送模式，服务列表更新更及。Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

 

参考链接：https://nacos.io/zh-cn/docs/v2/quickstart/quick-start.html

https://blog.csdn.net/eakom/article/details/126651290

https://blog.csdn.net/qq_36893229/article/details/120201306