配置中心 |
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年七月停止开源计划。
标签:Spring,配置,Nacos,支持,Apollo,Config From: https://www.cnblogs.com/yang5726685/p/18131746