差异对比表格:
功能点 | Disconf | Apollo | Nacos |
---|---|---|---|
依赖高可用框架 | 完全依赖于Zookeeper来实现监听拉取,向外提供了HTTP拉取数据接口 | 依赖于Eureka实现内部服务发现注册,提供HTTP接口给Client SDK拉取监听数据 | 内部自研实现框架高可用 |
CAP理论偏重点 | Zookeeper是CP,因此是CP | Eureka为AP,因此为AP | 尽管Nacos支持CP和AP两种模式,但作为配置中心官方定义只能为AP |
开源方 | 百度 | 携程 | 阿里 |
开源社区情况 | 停止维护,star5.5K | 社区活跃,star27.7K | 社区活跃,star25.4K |
Spring集成情况 | 没有提供集成包,需要自行根据需求配置对应的SpringBean | 支持Springbot和SpringCloud,没有传统SpringMVC集成包 | 支持SpringMVC、Springboot和Springcloud |
配置界面功能 | 功能较少,无配置审计 | 提供审计、灰度发布、版本回滚和编辑发布 | 提供审计、回滚和灰度发布 |
开源时间 | 2016 | 2016 | 2018 |
配置实时推送 | HTTP拉取,Zookeeper长连接监听 | http long polling拉取监听 | 2.0长连接拉取监听,1.0 http long polling拉取监听 |
配置格式校验 | 不支持 | 支持 | 支持 |
分布式配置 | 中等,需配置Zookeeper集群和Server | 复杂,需配置Portal、Admin Service和Config Service | 简单,仅需配置Nacos Server即可 |
数据一致性协议 | ZAB协议 | Eureka协议 | CP的raft协议,AP的Distro协议 |
多机房 | 不支持多机房的负载均衡,需要依赖于SLB等三方组件 | 支持 | 支持自身多机房和SLB三方组件 |
多环境 | 支持 | 支持 | 支持 |
综合来看,Nacos的优势是毋庸置疑的,承受住了双十一的流量,且进步十分迅速,有阿里背书,维护团队无需担心。
如果还有其它的功能差异点需要了解欢迎评论提出,我也查漏补缺研究一波。
三个配置框架原理传送门:
*注:本表格数据截止2023.2.20