1 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 |
2服务配置中心对比
对比项目/配置中心 | 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 |
nacos具有Apollo大部分功能，最重要的是配置中心与注册中心打通，可以省去我们在微服务治理方面 的一些投入（比如通过动态配置来启停线程池等操作）。
3 初步选型结论
初步结论为：使用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
