作者：风卿，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开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！