【编者按】在写这篇技术选型文章之前，我一直在犹豫。因为，作为开源项目的开发者之一，去写三个开源项目的对比，即使是很克制的客观对比，也很难有说服力。就像，你是选手，想当裁判，观众肯定不买账。但是***，我还是决定写一篇配置中心的技术选型参考文章，因为要做一个简单易用的开源产品，尝试提供类似功能的开源产品是很有必要的。为了找出优点，弥补不足；用户需要比较选择和比较提供相似功能的产品是引入开源项目必须要做的。如果有参考，肯定能提供一些帮助；（建议：即使有参考资料，技术选型的工作还是需要自己动手，实际的业务场景和资源配置是技术选型最重要的依据）；微服务配置中心是一个微服务组件，不是一个大Framework，选型成本小，客观比较不容易出错；本文将从四个纬度对产品功能、用户体验、实现过程、性能进行比较。所有素材均来自开源项目官网或GitHub项目页面。如果你对微服务配置中心的功能不是很熟悉，可以阅读下面的背景介绍。熟悉的可以直接跳过。为什么配置中心的配置需要实时生效：在传统的静态配置方式中，如果要修改某个配置，只能在修改后重新发布应用。要实现动态化，您可以选择使用数据库并通过定期轮询访问数据库以感知配置变化。如果轮询频率低，则感知配置更改的延迟时间长，如果轮询频率高，则感知配置更改的延迟时间短。但是，性能的损失需要在实时性能和性能之间进行折衷。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。配置管理流程：配置权限控制、灰度发布、版本管理、格式验证、安全配置等与配置管理相关的一系列特性，也是配置中心无法获取的部分。开源配置中心基本介绍目前市面上的配置中心很多（按开源时间排序）：百度2014年7月开源的配置管理中心Disconf也有配置管理功能，但不再维护。最后一次提交是两年前。SpringCloudConfig于2014年9月开源，是一个可以与SpringCloud系统无缝集成的SpringCloud生态组件。Apollo发布于2016年5月，是携程开源的配置管理中心，具有标准化权限、流程治理等特点。Nacos，2018年6月，阿里巴巴开源的配置中心，也可以做DNS和RPC服务发现。配置中心核心概念对比既然Disconf已经不再维护，那么我们来对比一下SpringCloudConfig、Apollo和Nacos。SpringCloudConfig、Apollo、Nacos在配置管理领域的概念基本相同，但也有一些区别。在使用配置的过程中会涉及到一些重要的概念。应用程序应用程序是客户端系统的基本单元。SpringCloudConfig将应用名与Git中对应的文件名关联起来，从而实现多个应用配置相互隔离。Apollo的配置都在某个应用下（公共配置除外），也起到了多个应用配置相互隔离的作用。Nacos的应用概念比较弱，只有一个附加属性用来区分配置，但是Group可以作为一个应用字段，可以起到隔离的作用。不同的集群环境可以搭建不同的集群，可以起到物理隔离的作用。SpringCloudConfig、Apollo、Nacos都支持多集群。LabelProfile&Environment&NamespaceSpringCloudConfig可以使用Label和Profile进行逻辑隔离。标签是指远程仓库的分支。Profile类似于MavenProfile区分环境，如{application}-{profile}.properties。Nacos命名空间和Apollo环境一样，是一个逻辑概念，可以作为环境逻辑隔离开来。Apollo中的命名空间是指配置的名称，具体的配置项是指配置文件中的一个Property。配置管理功能比较作为一个配置中心，整个配置管理过程应该具备精简的能力。灰度发布配置灰度发布是配置中心的一项重要功能。当配置变更的影响比较大时，需要在部分应用实例中验证配置变更是否符合预期，然后再推送到所有应用实例。SpringCloudConfig支持通过/bus/refresh端点的destination参数指定更新配置的机器，但整个过程不够自动化和系统化。Apollo可以直接在控制台灰度发布指定发布机器的IP，然后全额发布，更加系统化。Nacos目前发布到0.9版本，不支持灰度发布。权限管理配置的改变和代码的改变，都是对应用运行逻辑的改变。重要的配置变化往往会带来核弹的效果。配置变更的权限控制和审计能力也是配置中心的重要功能。SpringCloudConfig依赖于Git的权限管理能力。开源的GitHub权限控制分为Admin、Write和Read权限，权限管理比较完善。Apollo通过项目的维度来管理配置的权限。项目的所有者可以授权其他用户修改和发布配置。Nacos目前没有管理权限的功能。版本管理&回滚当配置变更不符合预期时，需要根据配置的发布版本进行回滚。SpringCloudConfig、Apollo、Nacos都具备配置版本管理和回滚能力，可以在控制台查看配置变更或进行回滚操作。SpringCloudConfig使用Git进行版本管理，更加方便。配置格式校验应用的配置数据一般以配置格式存储在配置中心，如Properties、Json、Yaml等，如果配置格式错误，会导致客户端无法解析配置，导致生产失败。格式校验可以有效防止人为错误操作的发生，这在配置中心的核心功能中是刚需。SpringCloudConfig使用的是Git，目前不支持格式验证，格式的正确性取决于开发者自己。Apollo和Nacos都会检查配置格式的正确性，可以有效防止人为错误。监听查询在排查问题或者做统计的时候，需要知道一个配置使用了哪些应用实例，一个实例使用了哪些配置。SpringCloudConfig使用SpringCloudBus推送配置更改。SpringCloudBus兼容RabbitMQ、Kafka等，支持查询订阅Topic和Consumer的订阅关系。Apollo可以通过灰度实例列表查看监控配置的实例列表，但是实例监控的配置（Apollo称之为命名空间）还没有显示出来。Nacos可以查看监控配置的实例，也可以查看实例监控的配置。基本上这三款产品都具备监控查询的能力。在我们自己的使用中，Nacos使用起来还是比较简单的，易用性也比较好。多环境在实际生产中，配置中心往往需要涉及多环境或多集群。在业务开发过程中，开发环境和生产环境可以分离，也可以根据不同的业务线存在多个生产环境。如果各个环境之间的相互影响比较小（开发环境影响生产环境的稳定性），配置中心可以通过逻辑隔离来支持多环境。SpringCloudConfig支持配置文件来隔离多个环境。通过在Git上配置多个profile配置文件，客户端在启动时可以通过指定一个profile来访问对应的配置文件。Apollo还支持多种环境。在控制台创建配置时，需要指定配置所在的环境。客户端启动时指定JVM参数ENV访问对应环境的配置文件。Nacos通过命名空间支持多种环境。每个命名空间的配置是相互隔离的，客户端指定要访问的命名空间，实现逻辑隔离。多集群当对稳定性要求比较高，不允许各个环境相互影响时，需要通过多集群实现多个环境的物理隔离。SpringCloudConfig可以通过搭建多套ConfigServer实现物理隔离，Git使用同一个Git的多个仓库。Apollo可以搭建多套集群。Apollo的控制台和数据更新推送服务是分开部署的，一套控制台可以管控多个集群。Nacos控制台和后端配置服务部署在一起，通过不同的域名切换可以支持多集群。配置实时推送对比当配置发生变化时，配置中心需要将配置实时推送到应用客户端。Nacos和Apollo配置推送都是基于HTTP长轮询的。客户端与配置中心建立HTTP长连接。当配置发生变化时，配置中心将配置推送给客户端。SpringCloudConfig本身不支持配置的实时推送，需要依赖Git的WebHook、SpringCloudBus和client/bus/refresh端点：基于Git的WebHook，配置变更触发服务端刷新。服务端接收请求并发送给SpringCloudBusSpringCloudBus接收消息并通知客户端。客户端收到通知，请求服务器获取最新的配置。总体来说，Nacos和Apollo在配置实时推送链接方面都比较简单高效。SpringCloudConfig将配置推送引入到SpringCloudBus中，链接比较长，比较复杂。SpringCloudConfig的部署结构&高可用比较SpringCloudConfig由三个组件组成：config-server、Git和SpringCloudBus：config-server提供客户端访问配置；Git用于存储和修改配置；SpringCloudBus通知客户端配置变更；在本地测试模式下，SpringCloudBus和config-server需要部署一个节点，Git可以使用GitHub。在生产环境中，SpringCloudConfig、config-server至少需要部署两个节点。如果SpringCloudBus使用RabbitMQ，普通集群模式至少需要两个节点。如果Git服务使用GitHub，就不用考虑高可用的问题了。如果考虑安全，自己搭建Git私有仓库，整体成本比较高。可以使用多个节点部署Web服务以支持高可用性。由于Git存在数据一致性问题，可以通过以下方式支持高可用：Git+Keepalived冷备模式，当主Git挂了，可以立即切换到备Git；Git多节点部署和存储使用网络文件系统或DRBD实现多个Git节点的数据同步；ApolloApollo分为四个模块：MySQL、ConfigService、AdminService和Portal：MySQL存储Apollo元数据和用户配置数据；ConfigService提供配置读取和推送等功能，客户端请求落在ConfigService上；AdminService提供配置修改、发布等功能，Portal运营的服务为AdminService；Portal提供用户配置管理界面；本地测试ConfigService，AdminService和Portal这三个模块可以组合在一起部署，MySQL单独安装并创建需要的表结构。在生产环境使用Apollo，Portal可以独立部署在两个节点上。如果对稳定性要求不是那么高，可以将ConfigService和AdminService一起部署，数据库支持主备容灾。NacosNacos部署需要NacosService和MySQL：Nacos对外提供服务，支持配置管理和服务发现；MySQL为Nacos提供持久化数据存储；在单机模式下，Nacos可以使用嵌入式数据库部署一个节点并启动。如果你熟悉MySQL，想了解整体的数据流向，可以安装MySQL来提供Nacos的数据持久化服务。生产环境使用Nacos，Nacos服务至少需要部署三个节点，外加MySQL主备。整体来说，Nacos的部署结构比较简单，运维成本较低。Apollo部署组件较多，运维成本高于Nacos。SpringCloudConfig产生高可用成本***。多语言支持对比一个公司的各个系统可能有不同的语言，比如现在广泛使用的有C++、Java、PHP、Python、Nodejs、Go。引入配置中心后，如果配置中心想要让多语言系统享受动态配置能力，就需要支持多语言生态。多语言支持SpringCloud服务于Java生态。一开始，它只是针对Java微服务应用。对于非Java应用的微服务调用，可以使用Sidecar提供HTTPAPI，但动态配置支持不佳。Apollo已经支持多种语言并提供了开放的API。对于其他不支持的语言，Apollo的接入成本相对较低。Nacos支持主流语言，如Java、Go、Python、Nodejs、PHP等，同时还提供了开放的API。国内主流互联网公司的迁移支持还是以Java为主。除了原生的JavaSDK，在对整个Java生态的支持上，比如SpringBoot、SpringCloud，三个产品都支持。SpringCloudConfig原生支持SpringBoot和SpringCloud，Nacos通过SpringCloudforAlibaba支持SpringBoot和SpringCloud生态，符合Spring生态中的标准实现方式，可以从SpringCloudConig无缝迁移到Nacos。Apollo支持SpringBoot和SpringCloud项目，但实现方式与标准不同，无法无缝迁移。从SpringCloud迁移到Apollo需要代码转换和兼容成本。性能对比性能也是配置中心的一部分。在相同的机器规格下，如果能够支持更大的业务量，势必会为公司节省更多的资源成本，提高资源利用率。应用客户端对配置中心的接口操作有读、写、变通知。由于变更通知需要大量的客户端实例，因此很难模拟测试场景。下面只测试读写操作。硬件环境Nacos和Apollo使用同一个数据库（32C128G），部署Server服务的机器使用配置8C16G的容器，磁盘为100GSSD。版本SpringCloudConfig使用2.0.0.M9版本，Apollo使用1.2.0版本发布，Nacos使用0.5版本。单机读取场景的客户端测试程序部署多台机器，每台机器启动多个线程从配置中心读取不同的配置（3000个）。NacosQPS可以达到15000。Apollo分为两种方式：读取内存缓存和从数据库读取。从数据库读取性能可达7500，从内存缓存读取性能可达9000QPS。SpringCloudConfig使用jGit读写Git。由于客户端限制，单机读取能力限制为7QPS。3节点读取场景，配置中心压测节点数部署为3节点。NacosQPS可以达到45000QPS，Apollo读内存缓存可以达到27000QPS。由于Nacos和Apollo的阅读场景中每个节点都是独立的，所以关系基本上是单机阅读场景的三倍。SpringCloudConfig三个节点的读取能力可达21QPS。和单机写场景一样，多台机器同时在配置中心修改不同的配置。NacosQPS可以达到1800，Apollo不使用默认数据库连接池（10）QPS只能达到800QPS（CPU未满），调整连接池为100达到1100QPS（CPU已满）。Git在提交同一个项目时会加锁。单机Git可以写在5QPS左右。SpringCloudConfig使用项目作为数据源时，写能力受限于Git。与3节点写入场景相同，配置中心压测节点数部署为3节点。NacosQPS可以达到6000，Apollo可以达到3300QPS（CPU满）。此时MySQL数据库并没有因为配置高而成为性能瓶颈。当SpringCloudConfig有3个节点时，Git也是一个节点，写入QPS为5。综合来看，Nacos的读写性能最好，其次是Apollo。SpringCloudConfig依赖Git的场景不适合开放大规模的自动化运维API。功能特性对比总结这里有一张表格总结了三款产品的功能特性。总的来说，Apollo和Nacos比SpringCloudConfig有更广泛的生态支持，在配置管理过程中做的更好。与Nacos相比，Apollo在配置管理上更加全面，但是使用起来也比较麻烦。Nacos使用起来比较简单，更适用于对性能要求较高的大规模场景。此外，Nacos除了配置中心功能外，还提供了动态的服务发现、服务共享和管理功能，降低了服务改造过程中的难度。上面我们从产品功能、用户体验、实现过程和性能四个维度对SpringCloudConfig、Apollo和Nacos进行了比较。但是对于一个开源项目的选择，除了以上四个方面，项目的人力投入（迭代进度、文档的完整性）、社区活跃度（问题数量和解决速度、Contributors数量、社区交流频率）等），社区监管程度（免责声明、安全声明等），这些可能是用户比较关注的内容。作者：冯青，Nacos社区committer
