Disconf、Apollo和Nacos分布式配置框架差异对比

差异对比表格：

功能点	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的优势是毋庸置疑的，承受住了双十一的流量，且进步十分迅速，有阿里背书，维护团队无需担心。

如果还有其它的功能差异点需要了解欢迎评论提出，我也查漏补缺研究一波。

三个配置框架原理传送门：

1. Apollo原理浅析；
2. Nacos框架服务注册发现和配置中心原理；
3. Disconf-Client端原理分析和使用思考。

*注：本表格数据截止2023.2.20