配置中心Spring cloud config、Apollo、Nacos对比
| 配置中心 | 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年七月停止开源计划。
