Nacos概念和功能介绍，与Eureka&Apollo&Zookeeper的比较
Nacos概念和功能介绍，与Eureka&Apollo&Zookeeper的比较
Nacos
Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。
官方文档：https://nacos.io/zh-cn/docs/what-is-nacos.html
概念
命名空间：用于进行租户粒度的配置隔离，常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。
配置：需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。通常以 param-key=param-value 的形式存在。
配置集：一组相关的配置项的集合称。一个配置文件通常就是一个配置集，一个系统或者应用可以包含多个配置集。常用于不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
服务注册中心：存储服务实例和服务负载均衡策略的数据库。通过服务名可以唯一确定其指代的服务。不同的服务可以归类到同一分组。
服务发现：（通常使用服务名）对服务下的实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。
元信息：Nacos配置和服务描述信息，如服务版本、权重、策略。
权重：实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。
健康检查：检查实例是否能提供服务，不健康的实例不会返回给客户端。
健康保护阈值：为了防止因过多实例不健康导致流量全部流向健康实例，继而造成流量压力把健健康实例压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例占总服务实例的比例小于该值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例能正常工作。
架构
基本架构及概念
服务 (Service)、服务注册中心 (Service Registry)、服务元数据 (Service Metadata)、服务提供方 (Service Provider)、服务消费方 (Service Consumer)
配置 (Configuration)、配置管理 (Configuration Management)、名字服务 (Naming Service)、配置服务 (Configuration Service)
逻辑架构及其组件介绍
功能
1、服务发现与服务健康检查
Nacos使服务更容易注册自己并通过DNS或HTTP接口发现其他服务。Nacos还提供服务的实时健康检查，以防止向不健康的主机或服务实例发送请求。
2、动态配置管理
动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新部署应用程序和服务的需要，这使配置更改更加高效和灵活。
3、动态DNS服务
Nacos支持加权路由，使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。
4、服务和元数据管理
Nacos提供易于使用的服务仪表板，可帮助您管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计。
服务管理
在服务列表页面点击详情，可以看到服务的详情。可以查看服务、集群和实例的基本信息。
服务流量权重支持及流量保护
Nacos 为用户提供了流量权重控制的能力，同时开放了服务流量的阈值保护，以帮助用户更好的保护服务服务提供者集群不被意外打垮。可以点击实例的编辑按钮，修改实例的权重。如果想增加实例的流量，可以将权重调大，如果不想实例接收流量，则可以将权重设为0。
服务优雅上下线
Nacos还提供服务实例的上下线操作，在服务详情页面，可以点击实例的“上线”或者“下线”按钮，被下线的实例，将不会包含在健康的实例列表里。
配置管理
Nacos支持基于Namespace和Group的配置分组管理，以便用户更灵活的根据自己的需要按照环境或者应用、模块等分组管理微服务以及Spring的大量配置，在配置管理中主要提供了配置历史版本、回滚、订阅者查询等核心管理能力。
命名空间管理
Nacos 基于Namespace 帮助用户逻辑隔离多个命名空间，这可以帮助用户更好的管理测试、预发、生产等多环境服务和配置，让每个环境的同一个配置（如数据库数据源）可以定义不同的值。
Nacos其他特性
Nacos Sync的价值
- NacosSync是一个支持多种注册中心的同步组件,基于Spring boot开发框架,数据层采用Spring Data JPA,遵循了标准的JPA访问规范,支持多种数据源存储,默认使用Hibernate实现,更加方便的支持表的自动创建更新
- 使用了高效的事件异步驱动模型, 支持多种自定义事件,使得同步任务处理的延时控制在3s,8C16G的单机能够支持6K的同步任务
- NacosSync除了单机部署,也提供了高可用的集群部署模式,NacosSync是无状态设计,将任务等状态数据迁移到了数据库,使得集群扩展非常方便
- 抽象出了Sync组件核心接口,通过注解对同步类型进行区分,使得开发者可以很容易的根据自己需求,去扩展不同注册中心,目前已支持的同步类型:
- Nacos数据同步到Nacos
- Zookeeper数据同步到Nacos
- Nacos数据同步到Zookeeper
- Eureka数据同步到Nacos
- Consul数据同步到Nacos
使用场景：多个网络互通的Region之间服务共享,打破Region之间的服务调用限制
DNS - F 的技术价值
- 填补了内部微服务业务没有全局动态调度能力的空白
- 解决了服务端棉铃挑战：时延大、解析不准、故障牵引慢
- 支持服务端多种调度需要
- 加速外部域名解析
- 服务故障牵引秒级生效
- 提供专线流量牵引能力
Nacos与Eureka注册中心的比较
对比项目\注册中心 | Spring Cloud Nacos | Spring Cloud Eureka |
|---|---|---|
CAP模型 | 支持AP和CP模型 | AP模型 |
客户端更新服务信息 | 使用注册+DNS-f+健康检查模式。 DNS-F客户端使用监听模式push/pull拉取更新信息 | 客户端定时轮询服务端获取其他服务ip信息并对比，相比之下服务端压力较大、延迟较大 |
伸缩性 | 使用Raft选举算法性能、可用性、容错性均比较好，新加入节点无需与所有节点互相广播同步信息 | 由于使用广播同步信息，集群超过1000台机器后对eureka集群压力很大 |
健康检查模式/方式 | 支持服务端/客户端/关闭检查模式，检查方式有tcp、http、sql。支持自己构建健康检查器 | 客户端向服务端发送http心跳 |
负载均衡 | 支持 | 支持 |
手动上下线服务方式 | 通过控制台页面和API | 通过调用API |
跨中心同步 | 支持 | 不支持 |
k8s集成 | 支持 | 不支持 |
分组 | Nacos可用根据业务和环境进行分组管理 | 不支持 |
权重 | Nacos默认提供权重设置功能，调整承载流量压力 | 不支持 |
厂商 | 阿里巴巴 | Netflix |
Nacos与Apollo服务配置中心对比
nacos具有Apollo大部分功能，最重要的是配置中心与注册中心打通，可以省去我们在微服务治理方面 的一些投入（比如通过动态配置来启停线程池等操作）。
对比项目/配置中心 | apollo | nacos |
|---|---|---|
开源时间 | 2016.5 | 2018.6 |
配置实时推送 | 支持（HTTP长轮询1s内） | 支持（HTTP长轮询1s内） |
版本管理 | 自动管理 | 自动管理 |
配置回滚 | 支持 | 支持 |
权限管理 | 支持 | 待支持 |
多集群多环境 | 支持 | 支持 |
监听查询 | 支持 | 支持 |
多语言 | Go,C++,Python,Java,.net,OpenAPI | Python,Java,Nodejs,OpenAPI |
分布式高可用最小集群数量 | Config2+Admin3+Portal*2+Mysql=8 | Nacos*3+MySql=4 |
配置格式校验 | 支持 | 支持 |
通信协议 | HTTP | HTTP |
数据一致性 | 数据库模拟消息队列，Apollo定时读消息 | HTTP异步通知 |
单机读（tps） | 9000 | 15000 |
单机写（tps） | 1100 | 1800 |
Eureka与ZooKeeper注册中心比较
Eureka保证AP。Eureka各个节点都是平等的，master挂掉剩余节点依然可以提供注册和查询服务。向某个Eureka注册时如果发现连接失败，则会自动切换至其它节点。
ZooKeeper保证CP。当zk的master节点挂了/网络故障，slave选举leader期间，整个zk集群都是不可用的。
服务注册功能对可用性的要求要高于一致性。注册中心不能因为自身的任何原因破坏服务之间本身的可连通性，这是注册中心设计应该遵循的
ZooKeeper的特性更适合用于大数据处理、分布式协调。在粗粒度分布式锁，分布式选主，主备高可用切换等不需要高TPS 支持的场景下有不可替代的作用，而这些需求往往多集中在大数据、离线任务等相关的业务领域，因为大数据领域，讲究分割数据集，并且大部分时间分任务多进程/线程并行处理这些数据集，但是总是有一些点上需要将这些任务和进程统一协调，这时候就是 ZooKeeper 发挥巨大作用的用武之地。
Nacos | Eureka | Consul | CoreDNS | Zookeeper | |
|---|---|---|---|---|---|
一致性协议 | CP+AP | AP | CP | — | CP |
健康检查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | — | Keep Alive |
负载均衡策略 | 权重/ metadata/Selector | Ribbon | Fabio | RoundRobin | — |
雪崩保护 | 有 | 有 | 无 | 无 | 无 |
自动注销实例 | 支持 | 支持 | 支持 | 不支持 | 支持 |
访问协议 | HTTP/DNS | HTTP | HTTP/DNS | DNS | TCP |
监听支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
多数据中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
跨注册中心同步 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 | 支持 |
Dubbo集成 | 支持 | 不支持 | 支持 | 不支持 | 支持 |
K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
结论
初步结论为：使用Nacos代替Eureka和apollo，主要理由为：
相比与Eureka：
(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。
(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护
(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势
(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。
(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。
相比于apollo
(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。
(2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则
(3)性能方面，Nacos读写tps比apollo稍强一些
参考：
nacos简介以及作为注册/配置中心与Eureka、apollo的选型比较：https://www.jianshu.com/p/afd7776a64c6
Nacos与Eureka、apollo的比较：https://note.youdao.com/ynoteshare1/index.html?id=26e0ef701bf7ca22d3dec90f54050cf5&type=note
Nacos,Eureka与ZooKeeper的比较：https://blog.csdn.net/caodongfang126/article/details/104718064/
ZooKeeper、Eureka、Consul 、Nacos，微服务注册中心怎么选：https://my.oschina.net/javaroad/blog/4959630
阿里巴巴为什么不用 ZooKeeper 做服务发现：https://developer.aliyun.com/article/601745
采用zookeeper的EPHEMERAL节点机制实现服务集群的陷阱：https://developer.aliyun.com/article/227260