作者：风卿，Nacos 社区 committer
在撰写这篇技术选型的文章之前，是比拟犹豫的。因为，以其中一个开源我的项目开发者的身份，去写一篇三个开源我的项目的比照，即使很克服的去主观的比拟，也很难有服气力。这就像，既是参赛选手，又想做裁判，观众必定是不买账的。
但最初，依然决定去写一篇配置核心的技术选型参考文，是因为：
- 工作所需，要做一款好用的开源产品，去试用提供类似性能的开源产品是必要的环节，以找出劣势，补救有余；
- 用户所需，对于提供类似性能的产品进行选型比照，是引入某个开源我的项目必须要做的事，如果有一份参考，那么势必能提供一些帮忙；（倡议：即使有一份可参考的资料，技术选型的工作仍须要亲力亲为，理论的业务场景和资源配置才是技术选型最重要的根据）；
- 微服务配置核心是一个微服务组件，而不是一个大的框架，选型老本较小，主观比照时不易走偏；
本文将从产品性能、应用体验、施行过程和性能 4 个纬度进行比照，所有素材均来源于该开源我的项目的官网或 GitHub 我的项目页。
如果您对微服务配置核心的性能不是很理解，能够看下以下的背景介绍，若比拟相熟能够间接跳过。
为什么须要配置核心
配置实时失效：
传统的动态配置形式要想批改某个配置只能批改之后从新公布利用，要实现动态性，能够抉择应用数据库，通过定时轮询拜访数据库来感知配置的变动。轮询频率低感知配置变动的延时就长，轮询频率高，感知配置变动的延时就短，但比拟损耗性能，须要在实时性和性能之间做折中。配置核心专门针对这个业务场景，兼顾实时性和一致性来治理动静配置。
配置管理流程：
配置的权限管控、灰度公布、版本治理、格局测验和平安配置等一系列的配置管理相干的个性也是配置核心不可获取的一部分。
开源配置核心根本介绍
目前市面上用的比拟多的配置核心有：（按开源工夫排序）
Disconf
2014 年 7 月百度开源的配置管理核心，同样具备配置的治理能力，不过目前曾经不保护了，最近的一次提交是两年前了。
Spring Cloud Config
2014 年 9 月开源，Spring Cloud 生态组件，能够和 Spring Cloud 体系无缝整合。
Apollo
2016 年 5 月，携程开源的配置管理核心，具备标准的权限、流程治理等个性。
Nacos
2018 年 6 月，阿里开源的配置核心，也能够做 DNS 和 RPC 的服务发现。
配置核心外围概念的比照
因为 Disconf 不再保护，上面比照一下 Spring Cloud Config、Apollo 和 Nacos。
Spring Cloud Config、Apollo 和 Nacos 在配置管理畛域的概念基本相同，然而也存在一些不同的点，应用配置的过程中会波及到一些比拟重要的概念。
利用
利用是客户端零碎的根本单位，Spring Cloud Config 将利用名称和对应 Git 中的文件名称关联起来了，这样能够起到多个利用配置互相隔离的作用。Apollo 的配置都是在某个利用上面的（除了公共配置），也起到了多个利用配置互相隔离的作用。Nacos 的利用概念比拟弱，只有一个用于辨别配置的额定属性，不过能够应用 Group 来做利用字段，能够起到隔离作用。
集群
不同的环境能够搭建不同的集群，这样能够起到物理隔离的作用，Spring Cloud Config、Apollo、Nacos 都反对多个集群。
Label Profile & 环境 & 命名空间
Spring Cloud Config 能够应用 Label 和 Profile 来做逻辑隔离，Label 指近程仓库的分支，Profile 相似 Maven Profile 能够辨别环境，比方{application}-{profile}.properties。
Nacos 的命名空间和 Apollo 的环境一样，是一个逻辑概念，能够作为环境逻辑隔离。Apollo 中的命名空间指配置的名称，具体的配置项指配置文件中的一个 Property。
配置管理性能的比照
作为配置核心，配置的整个治理流程应该具备流程化能力。
灰度公布
配置的灰度公布是配置核心比拟重要的性能，当配置的变更影响比拟大的时候，须要先在局部利用实例中验证配置的变更是否合乎预期，而后再推送到所有利用实例。
Spring Cloud Config 反对通过 /bus/refresh 端点的 destination 参数来指定要更新配置的机器，不过整个流程不够自动化和体系化。
Apollo 能够间接在管制台上点灰度公布指定公布机器的 IP，接着再全量公布，做得比拟体系化。
Nacos 目前公布到 0.9 版本，还不反对灰度公布。
权限治理
配置的变更和代码变更都是对利用运行逻辑的扭转，重要的配置变更经常会带来核弹的成果，对于配置变更的权限管控和审计能力同样是配置核心重要的性能。
Spring Cloud Config 依赖 Git 的权限治理能力，开源的 GitHub 权限管制能够分为 Admin、Write 和 Read 权限，权限治理比较完善。
Apollo 通过我的项目的维度来对配置进行权限治理，一个我的项目的 owner 能够受权给其余用户配置的批改公布权限。
Nacos 目前看还不具备权限治理能力。
版本治理 & 回滚
当配置变更不合乎预期的时候，须要依据配置的公布版本进行回滚。Spring Cloud Config、Apollo 和 Nacos 都具备配置的版本治理和回滚能力，能够在管制台上查看配置的变更状况或进行回滚操作。Spring Cloud Config 通过 Git 来做版本治理，更不便些。
配置格局校验
利用的配置数据存储在配置核心个别都会以一种配置格局存储，比方 Properties、Json、Yaml 等，如果配置格局谬误，会导致客户端解析配置失败引起生产故障，配置核心对配置的格局校验可能无效避免人为错误操作的产生，是配置核心外围性能中的刚需。
Spring Cloud Config 应用 Git，目前还不反对格局测验，格局的正确性依赖研发人员本人。
Apollo 和 Nacos 都会对配置格局的正确性进行测验，能够无效避免人为谬误。
监听查问
当排查问题或者进行统计的时候，须要晓得一个配置被哪些利用实例应用到，以及一个实例应用到了哪些配置。
Spring Cloud Config 应用 Spring Cloud Bus 推送配置变更，Spring Cloud Bus 兼容 RabbitMQ、Kafka 等，反对查问订阅 Topic 和 Consumer 的订阅关系。
Apollo 能够通过灰度实例列表查看监听配置的实例列表，但实例监听的配置 (Apollo 称为命名空间) 目前还没有展现进去。
Nacos 能够查看监听配置的实例，也能够查看实例监听的配置状况。
基本上，这三个产品都具备监听查问能力，在咱们本人的应用过程中，Nacos 应用起来绝对简略，易用性绝对更好些。
多环境
在理论生产中，配置核心经常须要波及多环境或者多集群，业务在开发的时候能够将开发环境和生产环境离开，或者依据不同的业务线存在多个生产环境。如果各个环境之间的相互影响比拟小（开发环境影响到生产环境稳定性），配置核心能够通过逻辑隔离的形式反对多环境。
Spring Cloud Config 反对 Profile 的形式隔离多个环境，通过在 Git 上配置多个 Profile 的配置文件，客户端启动时指定 Profile 就能够拜访对应的配置文件。
Apollo 也反对多环境，在控制台创立配置的时候就要指定配置所在的环境，客户端在启动的时候指定 JVM 参数 ENV 来拜访对应环境的配置文件。
Nacos 通过命名空间来反对多环境，每个命名空间的配置互相隔离，客户端指定想要拜访的命名空间就能够达到逻辑隔离的作用。
多集群
当对稳定性要求比拟高，不容许各个环境相互影响的时候，须要将多个环境通过多集群的形式进行物理隔离。
Spring Cloud Config 能够通过搭建多套 Config Server，Git 应用同一个 Git 的多个仓库，来实现物理隔离。
Apollo 能够搭建多套集群，Apollo 的控制台和数据更新推送服务离开部署，控制台部署一套就能够管控多个集群。
Nacos 控制台和后端配置服务是部署在一起的，能够通过不同的域名切换来反对多集群。
配置实时推送的比照
当配置变更的时候，配置核心须要将配置实时推送到利用客户端。
Nacos 和 Apollo 配置推送都是基于 HTTP 长轮询，客户端和配置核心建设 HTTP 长联接，当配置变更的的时候，配置核心把配置推送到客户端。
Spring Cloud Config 原生不反对配置的实时推送，须要依赖 Git 的 WebHook、Spring Cloud Bus 和客户端 /bus/refresh 端点:
- 基于 Git 的 WebHook，配置变更触发 server 端 refresh
- Server 端接管到申请并发送给 Spring Cloud Bus
- Spring Cloud Bus 接到音讯并告诉给客户端
- 客户端接管到告诉，申请 Server 端获取最新配置
整体比拟下来，Nacos 和 Apollo 在配置实时推送链路上是比较简单高效的，Spring Cloud Config 的配置推送引入 Spring Cloud Bus，链路较长，比较复杂。
部署构造 & 高可用的比照
Spring Cloud Config
Spring Cloud Config 蕴含 config-server、Git 和 Spring Cloud Bus 三大组件：
- config-server 提供给客户端获取配置;
- Git 用于存储和批改配置;
- Spring Cloud Bus 告诉客户端配置变更;
本地测试模式下，Spring Cloud Bus 和 config-server 须要部署一个节点，Git 应用 GitHub 就能够。在生产环境中，Spring Cloud Config，config-server 须要部署至多两个节点。Spring Cloud Bus 如果应用 RabbitMQ，一般集群模式至多须要两个节点。SpringCloud 配置核心高可用搭建，更多微服务文章请关注 Java 技术栈微信公众号，在后盾回复 ” 微服务 ” 即可获取。
Git 服务如果应用 GitHub 就不必思考高可用问题，如果思考到安全性要自建 Git 公有仓库，整体的老本比拟高。Web 服务能够部署多节点反对高可用，因为 Git 有数据的一致性问题，能够通过以下的形式来反对高可用：
- Git+Keepalived 冷备模式，当主 Git 挂了能够马上切到备 Git;
- Git 多节点部署，存储应用网络文件系统或者通过 DRBD 实现多个 Git 节点的数据同步;
Apollo
Apollo 分为 MySQL，Config Service，Admin Service，Portal 四个模块：
- MySQL 存储 Apollo 元数据和用户配置数据;
- Config Service 提供配置的读取、推送等性能，客户端申请都是落到 Config Service 上;
- Admin Service 提供配置的批改、公布等性能，Portal 操作的服务就是 Admin Service;
- Portal 提供给用户配置管理界面;
本地测试 Config Service，Admin Service，Portal 三个模块能够合并一起部署，MySQL 独自装置并创立须要的表构造。在生产环境应用 Apollo，Portal 能够两个节点独自部署，稳定性要求没那么高的话，Config Service 和 Admin Service 能够部署在一起，数据库反对主备容灾。
Nacos
Nacos 部署须要 Nacos Service 和 MySQL：
- Nacos 对外提供服务，反对配置管理和服务发现;
- MySQL 提供 Nacos 的数据长久化存储;
单机模式下，Nacos 能够应用嵌入式数据库部署一个节点，就能启动。如果对 MySQL 比拟相熟，想要理解整体数据流向，能够装置 MySQL 提供给 Nacos 数据长久化服务。生产环境应用 Nacos，Nacos 服务须要至多部署三个节点，再加上 MySQL 主备。阿里启动新我的项目：Nacos，比 Eureka 更强更多微服务文章请关注 Java 技术栈微信公众号，在后盾回复 ” 微服务 ” 即可获取。
整体来看
Nacos 的部署构造比较简单，运维老本较低。Apollo 部署组件较多，运维老本比 Nacos 高。Spring Cloud Config 生产高可用的老本最高。
多语言反对的比照
一个公司的各个系统可能语言不尽相同，当初应用的比拟多的比方 C ++，Java，PHP，Python，Nodejs，还有 Go 等。引入配置核心之后，配置核心要想让多语言的零碎都能享受到动静配置的能力，须要反对多语言生态。
多语言反对
Spring Cloud 服务于 Java 生态，一开始只是针对 Java 微服务利用，对于非 Java 利用的微服务调用，能够应用 Sidecar 提供了 HTTP API，但动静配置方面还不能很好的反对。
Apollo 曾经反对了多种语言，并且提供了 open API。其余不反对的语言，Apollo 的接入老本绝对较低。
Nacos 反对支流的语言，例如 Java、Go、Python、Nodejs、PHP 等，也提供了 open API。
迁徙反对
国内支流的互联网公司仍是以 Java 为主，除了原生 Java SDK，在对整个 Java 生态，比方 Spring Boot 和 Spring Cloud 的反对上，三个产品都是反对的。Spring MVC & Boot & Cloud 系列干货，2019 最新版，更多微服务文章请关注 Java 技术栈微信公众号，在后盾回复 ”cloud” 即可获取。
Spring Cloud Config 原生就反对 Spring Boot 和 Spring Cloud，Nacos 通过 Spring Cloud for Alibaba 反对 Spring Boot 和 Spring Cloud 生态，合乎 Spring 生态中的规范实现形式，能够无缝从 Spring Cloud Conig 迁徙到 Nacos。
Apollo 反对 Spring Boot 和 Spring Cloud 我的项目，然而实现形式不同于规范，无奈做无缝迁徙，从 Spring Cloud 迁徙到 Apollo，存在代码革新和兼容性老本。
性能比照
性能也是配置核心绕不过的一环，在同样的机器规格下，如果能撑持更大的业务量，势必能替公司节俭更多的资源老本，进步资源利用率。利用客户端对配置核心的接口操作有读、写和变更告诉，因为变更告诉须要大量的客户端实例，不好模仿测试场景，上面仅对读和写操作做了测试。
硬件环境
Nacos 和 Apollo 应用同样的数据库（32C128G），部署 Server 服务的机器应用的 8C16G 配置的容器，磁盘是 100G SSD。
版本
Spring Cloud Config 应用 2.0.0.M9 版本，Apollo 应用 1.2.0 release 版本，Nacos 应用 0.5 版本。
单机读场景
客户端测试程序通过部署多台机器，每台机器开启多个线程从配置核心读取不同的配置（3000 个）。Nacos QPS 能够达到 15000，Apollo 分为读内存缓存和从数据库中读两种形式，从数据库中读能达到 7500，从内存读缓存性能能够达到 9000QPS。Spring Cloud Config 应用 jGit 读写 Git，因为有客户端限度，单机读能力被限度在 7QPS。
3 节点读场景
将配置核心的压测节点数都部署成 3 个节点。Nacos QPS 能够达到 45000 QPS，Apollo 读内存缓存能够达到 27000 QPS。Nacos 和 Apollo 因为读场景各个节点是独立的，根本就是单机读场景的 3 倍关系。Spring Cloud Config 三个节点读能力能够达到 21QPS。
单机写场景
同样的形式，多台机器同时在配置核心批改不同的配置。Nacos QPS 能够达到 1800，Apollo 未应用默认的数据库连接池（10）QPS 只能达到 800 QPS（CPU 未压满），调整连接池至 100 能够达到 1100 QPS（CPU 压满）。Git 在提交同一个我的项目的时候会加锁，单机 Git 写能在 5QPS 左右，Spring Cloud Config 在应用的时候以一个我的项目作为数据源，写能力受到 Git 限度。
3 节点写场景
同样的形式，将配置核心的压测节点数都部署成 3 个节点。Nacos QPS 能够达到 6000，Apollo 能够达到 3300 QPS（CPU 压满），此时 MySQL 数据库因为配置较高，未成为性能瓶颈。Spring Cloud Config 三个节点时候，Git 也是一个节点，写 QPS 为 5。
整体上来看，Nacos 的读写性能最高，Apollo 次之，Spring Cloud Config 的依赖 Git 场景不适宜凋谢的大规模自动化运维 API。
性能个性比照总结
这里列一个表格总结一下三个产品的性能特点。
总的来说，Apollo 和 Nacos 绝对于 Spring Cloud Config 的生态反对更广，在配置管理流程上做的更好。Apollo 绝对于 Nacos 在配置管理做的更加全面，不过应用起来也要麻烦一些。Nacos 应用起来绝对比拟简洁，在对性能要求比拟高的大规模场景更适宜。
此外，Nacos 除了提供配置核心的性能，还提供了动静服务发现、服务共享与治理的性能，升高了服务化革新过程中的难度。
以上，咱们从产品性能、应用体验、施行过程和性能 4 个纬度对 Spring Cloud Config、Apollo 和 Nacos 进行比照。但对于一个开源我的项目的选型，除了以上这 4 个方面，我的项目上的人力投入（迭代进度、文档的完整性）、社区的活跃度（issue 的数量和解决速度、Contributor 数量、社群的交换频次等）、社区的标准水平（免责阐明、安全性阐明等），这些可能才是用户更关注的内容。
参考文档
https://springcloud.cc/spring…
https://github.com/ctripcorp/…
https://nacos.io/
近期热文举荐：
1.600+ 道 Java 面试题及答案整顿(2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！