配置中心 | spring cloud config | Apollo | Nacos(重点) |
动态配置管理 | Spring Cloud Bus自动刷新 | 支持 | 支持 |
服务发现与服务健康检查 | Eureka或Consul实现 | 不支持 | 支持 |
配置格式 | Properties、yaml | 只支持xml、text、Properties | 支持yaml、text、json、xml、html、Properties |
配置格式校验 | 不支持 | 支持 | 支持 |
监听查询 | 支持 | 支持 | 支持 |
配置实时推送 | 弱支持(Spring Cloud Bus) | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
配置的灰度发布 | 理念上支持,可操作性不强 | 支持 | 1.1.0开始支持 |
权限管理 | 不支持(没有区分用户、角色、权限的概念) | 支持 | 1.2.0开始支持 |
单机部署 | Config+server+Git+Spring Cloud Bus | Config+Admin+Portal+Mysql*2 | Nacos+MySql |
分布式高可用最小集群数量 | Config-Server2+Git+MQ | Config*2+Admin*3+Portal*2+Mysql*2=9 | Nacos*3+MySql=4 |
单机读(tps) | 7 | 9000 | 15000 |
单机写(tps) | 5 | 1100 | 1800 |
3节点读(tps) | 21 | 27000 | 45000 |
3节点(tps) | 5 | 3300 | 5600 |
Nacos与Apollo对比结论:
1、部署方面:
Nacos部署简化,Nacos整合了注册中心、配置中心功能,且部署相比Apollo简单,方便管理和监控;
Apollo需要部署3个服务(adminservice、configservice、portal),分别使用8070, 8080, 8090端口,Apollo服务端共需要两个数据库:ApolloPortalDB和ApolloConfigDB,配置文件多,数据库表多;
Apollo容器化较困难,Nacos有官网的镜像可以直接部署,总体来说,Nacos比Apollo更符合KISS原则;
整体上:Nacos的部署结构比较简单,运维成本较低。Apollo部署组件较多,运维成本比Nacos高。Spring Cloud Config生产高可用的成本最高。
2、配置中心:
Nacos和Apollo均支持动态发布配置,配置中心监听器,配置中心发生配置变化,监听器会通知服务做出配置更新通知;
Nacos配置文件支持比较多的格式,支持yaml、text、json、xml、html、Properties;
Apollo只支持xml、text、Properties的格式,没有兼容springboot中比较通用的yaml配置。
配置对比:Nacos和Apollo都有对比功能,不过Nacos比较粗糙一些,只能再发布的时候与上一个版本进行对比,Apollo支持不同环境 不同版本上的杜比。
注册发现与健康检查:
Nacos内置监听心跳检测机制,每5秒、15秒、30秒对服务进行心跳探测,标注为健康、不健康、剔除;
3、性能方面:
Nacos读写tps比Apollo稍强一些,Nacos : 性能最好(默认使用hibernate连接池,可以自定);
4、界面方面:
Apollo也许经过的迭代更久,功能上比Nacos更加完善,权限管理做的全面,配置上可能会做的更细节一些,不过操作比较繁琐,比较适合多业务 多团队的业务场景。
Nacos做的比较简洁直观,一目了然,操作简单些。
5、生态方面:
Nacos当前作为阿里巴巴主开源的项目,社区活跃,生态链完整,版本更新迭代中;
Apollo目前在国内开发者社区比较热,在Github上有超过5k颗星,在国内众多互联网公司有落地案例,可以说Apollo是目前配置中心产品领域Number1的产品,其成熟度和企业级特性要远远强于Spring Cloud体系中的Spring Cloud Config产品。
eureka上手简单,社区完善,但已于2018年七月停止开源计划。