基本概念

Nacos是 Dynamic Naming and Configuration Service 的首字母简称；⼀个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。即Nacos 是⼀个集服务注册发现以及配置管理于⼀体的组件。

特点

易用：简单的数据模型，标准的 restfulAPI，易用的控制台，丰富的使用文档
稳定：99.9% 高可用，
实时：数据变更毫秒级推送生效
规模：十万级服务/配置，百万级连接，具备强大扩展性

核心功能点

服务注册
Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。
Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。

服务心跳
在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。

服务健康检查

• 阻止向不健康的主机或服务实例发送请求
• Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的 healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)

服务发现
服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清 单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存 。

• 基于基于DNS和RPC的服务发现。
• 服务提供者：原生SDK，OpenAPI，独立的Agent TODO
• 服务消费者：DNS ，HTTP&API

服务同步
Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性。

服务配置
中心化，外部化，动态化的方式管理应用配置和服务配置

• 动态配置：消除配置变更重新部署应用和服务的需要
• 中心化：实现无状态服务更简单，服务按需弹性扩展更容易
• 具体配置项
  • 在线编辑
  • 历史版本
  • 一键回滚
  • 灰度发布
  • 推送轨迹

对比

eureka对比

• eureka 2.0闭源码了。
• 从官网来看nacos 的注册的实例数是大于eureka的,
• 因为nacos使用的raft协议,nacos集群的一致性要远大于eureka集群.
• 范围不同：Nacos的阈值是针对某个具体服务的，Eureka的自我保护阈值是针对所有服务的
• nacos支持CP和AP两种，eureka只支持AP
• nacos使用netty,长连接；eureka是短连接，定时发送
• 保护方式不同
  • Eureka:当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。
  • Nacos:当域名健康实例占总服务实例的比例小于阈值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失了一部分流量，但保证了集群的剩余健康实例能正常工作。

模块	Nacos	Eureka	说明
注册中心	是	是	服务治理基本功能，负责服务中心化注册
配置中心	是	否	Eureka需要配合Config实现配置中心，且不提供管理界面
动态刷新	是	否	Eureka需要配合MQ实现配置动态刷新，Nacos采用Netty保持TCP长连接实时推送
可用区AZ	是	是	对服务集群划分不同区域，实现区域隔离，并提供容灾自动切换
分组	是	否	Nacos可用根据业务和环境进行分组管理
元数据	是	是	提供服务标签数据，例如环境或服务标识
权重	是	否	Nacos默认提供权重设置功能，调整承载流量压力
健康检查	是	是	Nacos支持由客户端或服务端发起的健康检查，Eureka是由客户端发起心跳
负载均衡	是	是	均提供负责均衡策略，Eureka采用Ribion
管理界面	是	否	Nacos支持对服务在线管理，Eureka只是预览服务状态

springcloud config 对比

• springcloud config大部分场景结合git 使用, 动态变更还需要依赖Spring Cloud Bus 消息总线来通过所有的客户端变化.
• springcloud config不提供可视化界面
• nacos 使用长连接更新配置, 一旦配置有变动后，通知Provider的过程非常的迅速, 从速度上秒杀springcloud原来的config几条街,

相关概念

Nacos服务注册表结构

nacos的配置数据的存储位置

存储于NACOS_PATH/data/目录下的derby-data文件中。本地数据库Derby（java编写）

Raft 的数据一致性策略

Raft 协议强依赖 Leader 节点来确保集群数据一致性。
即 client 发送过来的数据均先到达 Leader 节点，Leader 接收到数据后，先将数据标记为 uncommitted 状态，随后 Leader 开始向所有 Follower 复制数据并等待响应，在获得集群中大于 N/2 个 Follower 的已成功接收数据完毕的响应后，Leader 将数据的状态标记为 committed，随后向 client 发送数据已接收确认，在向 client 发送出已数据接收后，再向所有 Follower 节点发送通知表明该数据状态为committed。

感谢您的阅读，如果您感觉本篇博客还不错，请帮忙留言+点赞+收藏呗。~~