本文将从产品功能、使用体验、实施过程和性能4个纬度进行对比，全部素材均来源于该开源项目的官网或GitHub项目页。html
若是您对微服务配置中心的功能不是很了解，能够看下如下的背景介绍，若比较熟悉能够直接跳过。git
为何须要配置中心
配置实时生效：github
传统的静态配置方式要想修改某个配置只能修改以后从新发布应用，要实现动态性，能够选择使用数据库，经过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，须要在实时性和性能之间作折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。spring
配置管理流程：数据库
配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。后端
开源配置中心基本介绍
目前市面上用的比较多的配置中心有：（按开源时间排序）缓存
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，普通集群模式至少须要两个节点。
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的部署结构比较简单，运维成本较低。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 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-cloud-config.html
https://github.com/ctripcorp/apollo
https://nacos.io/