差异对比表格：
| 功能点 | 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
