主流配置中心 Apollo、Nacos 的比较。
一. 功能特性对比
| 对比项目 | Apollo | Nacos |
|---|---|---|
| 开源时间 | 2016.5 | 2018.6 |
| 配置实时推送 | 支持（HTTP长轮询1s内） | 支持（HTTP长轮询1s内） |
| 版本管理 | 自动管理 | 自动管理 |
| 配置回滚 | 支持 | 支持 |
| 灰度发布 | 支持 | 支持 |
| 权限管理 | 支持 | 不支持（粗粒度） |
| 多集群 | 支持 | 支持 |
| 多环境 | 支持 | 支持 |
| 多语言 | 主流语言，提供Open API | 主流语言，提供Open API |
| 监听查询 | 支持 | 支持 |
| 分布式高可用最小集群数量 | Config2 + Admin3 + Portal * 2 + MySql = 8 | Nacos * 3 + MySql = 4 |
| 配置格式校验 | 支持 | 支持 |
| 通信协议 | HTTP | HTTP（2.0新增gRPC） |
| 数据一致性 | 数据库模拟消息队列，Apollo定时读消息 | HTTP异步通知 |
| 单机读（tps） | 9000 | 15000 |
| 单机写（tps） | 1100 | 1800 |
| 3节点读 | 27000 | 45000 |
| 3节点写 | 3300 | 5600 |
1.1 监听查询
当排查问题或者进行统计的时候，需要知道一个配置被哪些应用实例使用到，以及一个实例使用到了哪些配置。
Apollo 可以通过灰度实例列表查看监听配置的实例列表，但实例监听的配置（
Apollo称为命名空间）目前还没有展示出来。Nacos 可以查看监听配置的实例，也可以查看实例监听的配置情况。
这两个产品都具备监听查询能力，Nacos 使用起来相对简单，易用性相对更好些。
1.2 分布式高可用最小集群数量
1.2.1 Apollo
Apollo 分为 MySQL、Config Service、Admin Service、Portal 四个模块：
MySQL存储 Apollo 元数据和用户配置数据Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin ServicePortal提供给用户配置管理界面
开发、测试环境 Config Service、Admin Service、Portal 三个模块可以合并一起部署，MySQL 单独安装并创建需要的表结构。
生产环境 Portal 可以两个节点单独部署，稳定性要求没那么高的话，Config Service 和 Admin Service 可以部署在一起，数据库支持主备容灾。
1.2.2 Nacos
Nacos 部署需要 Nacos Service 和 MySQL：
Nacos对外提供服务，支持配置管理和服务发现MySQL提供Nacos的数据持久化存储
单机模式下，Nacos 可以使用嵌入式数据库部署一个节点，就能启动。如果对 MySQL 比较熟悉，想要了解整体数据流向，可以安装 MySQL 提供给 Nacos 数据持久化服务。生产环境使用 Nacos，Nacos 服务需要至少部署三个节点，再加上 MySQL 主备。
二. 总结
性能方面：
Nacos的读写性能最高，Apollo次之功能方面：
Apollo最为完善，Nacos具有Apollo大部分配置管理功能部署方面：
Nacos部署简化，相比Apollo简单，方便管理和监控；Apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比Apollo更符合KISS原则
总的来看， Apollo 和 Nacos 在软件配置管理步骤上做的都很好。Apollo 相对性于 Nacos 在软件配置管理做的更为全方位；Nacos则应用起來相对性较为简约，在对特性规定较为高的规模性情景更合适。
Nacos 的一大优势是整合了注册中心、配置中心功能，部署和操作相比 Apollo 都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。
针对企业现阶段而言，改动配备的频次并不是尤其的经常，针对配备管理权限的管理方法并不是尤其严苛的，且对读写能力特性有一定规定的，可选用 Nacos，相反应用Apollo。
