微服务架构中主流的配置中心对比分析？

为什么需要配置中心

配置实时生效：

传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。

配置管理流程：

配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。

开源配置中心基本介绍

目前市面上用的比较多的配置中心有：（按开源时间排序）

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可以直接在控制台上点灰度发布指定发布机器的