Spring Cloud Config、Apollo、Nacos三种配置中心介绍与区别

一、配置中心作用

配置实时生效
传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置
配置管理流程
配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分

2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。

具备权限管理（依赖Git的权限管理能力）
具备版本管理&回滚（通过Git来做版本管理，更方便）
不支持配置文件格式校验
使用Spring Cloud Bus推送配置变更，Spring Cloud Bus兼容 RabbitMQ、Kafka等，支持查询订阅Topic和Consumer的订阅关系
支持多环境，通过Profile的方式隔离多个环境，在Git上配置多个Profile的配置文件，客户端启动时指定Profile就可以访问对应的配置文件
支持多集群部署，搭建多套Config Server，使用同一个Git的多个仓库，来实现物理隔离
原生不支持配置实时推送，但是可以依赖Git的WebHook、Spring Cloud Bus和客户端/bus/refresh端点实现
（1）基于Git的WebHook，配置变更触发Server端refresh
（2）Server端接收到请求并发送给Spring Cloud Bus
（3）Spring Cloud Bus接到消息并通知给客户端
（4）客户端接收到通知，请求Server端获取最新配置
包含config-server、Git和Spring Cloud Bus三大组件
（1）config-server提供给客户端获取配置
（2）Git用于存储和修改配置
（3）Spring Cloud Bus通知客户端配置变更
多语言支持，服务于Java生态，一开始只是针对Java微服务应用；对于非Java应用的微服务调用，可以使用Sidecar提供了HTTP API，但动态配置方面还不能很好的支持

2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性。

Apollo通过项目的维度来对配置进行权限管理，一个项目的owner可以授权给其他用户配置的修改发布权限
具备版本管理&回滚
支持配置文件格式校验
可以通过灰度实例列表查看监听配置的实例列表，但实例监听的配置(Apollo称为命名空间)目前还没有展示出来
支持多环境，在控制台创建配置的时候就要指定配置所在的环境，客户端在启动的时候指定JVM参数ENV来访问对应环境的配置文件
支持多集群部署，Apollo的控制台和数据更新推送服务分开部署，控制台部署一套就可以管控多个集群
基于HTTP长轮询实现配置推送，客户端和配置中心建立HTTP长连接，当配置变更时，配置中心把配置推送到客户端
分为MySQL，Config Service，Admin Service，Portal四个模块
（1）MySQL存储Apollo元数据和用户配置数据
（2）Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上
（3）Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service
（4）Portal提供给用户配置管理界面
多语言支持，提供了Open API。其他不支持的语言，Apollo的接入成本相对较低

2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。