分布式配置中心选型
安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏。
时效性：修改配置，需要重启服务才能生效。
局限性：无法支持动态调整：例如日志开关、功能开关。
因此，分布式配置中心应运而生！
范围：Apollo，Consul，Nacos，Spring cloud config
配置中心需要符合的条件：
作为配置中心，配置的整个管理流程应该具备流程化能力，那些停更的组件就不考虑了，有问题都没处问去，最好是操作简单，依赖简单，维护简单，功能稳定。
灰度发布
配置的灰度发布是配置中心比较重要的功能，当配置的变更影响比较大的时候，需要先在部分应用实例中验证配置的变更是否符合预期，然后再推送到所有应用实例。
Spring Cloud Config支持通过/bus/refresh端点的destination参数来指定要更新配置的机器，不过整个流程不够自动化和体系化。
Apollo可以直接在控制台上点灰度发布指定发布机器的IP，接着再全量发布，做得比较体系化。Nacos支持灰度发布。
CAP
CAP理论是分布式架构中重要理论
一致性(Consistency) (所有节点在同一时间具有相同的数据)
可用性(Availability) (保证每个请求不管成功或者失败都有响应)
分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
Nacos CP+AP, Consul AP
权限管理
配置的变更和代码变更都是对应用运行逻辑的改变，重要的配置变更常常会带来核弹的效果，对于配置变更的权限管控和审计能力同样是配置中心重要的功能。
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控制台和后端配置服务是部署在一起的，可以通过不同的域名切换来支持多集群。
讨论
1.Spring Cloud Config原生不支持配置的实时推送，需要依赖Git的WebHook用于存储和修改配置、Spring Cloud Bus通知客户端配置变更，和客户端/bus/refresh端点，高可用方案成本较高
2.Apollo分为MySQL，Config Service，Admin Service，Portal四个模块，MySQL存储Apollo元数据和用户配置数据; Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上; Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service; Portal提供给用户配置管理界面;功能强大，社区活跃，但较为复杂，部署组件较多，运维成本比高。
符合条件的组件consul，nacos
consul
依赖：不依赖其他组件
应用内/外：属于外部应用，侵入性小
ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。
版本迭代：目前仍然进行版本迭代
集成支持：支持SpringCloud K8S集成
访问协议：HTTP/DNS
雪崩保护：不支持雪崩保护
集成：SpringCloud集成，K8S集成
自动注销实例：不支持
界面：英文界面，不符合国人习惯
上手：复杂一点
nacos
依赖：mysql
应用内/外：属于外部应用，侵入性小
ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍）
版本迭代：目前仍然进行版本迭代，最近的提交是几天前
集成支持：支持Dubbo 、SpringCloud、K8S集成
访问协议：HTTP/动态DNS/UDP
雪崩保护：支持雪崩保护
集成：SpringCloud集成，Dubbo集成，K8S集成
自动注销实例：支持
界面：国产服务，中文界面，符合国人习惯
上手：极易，中文文档，案例，社区活跃
Consul实际上是和Nacos比较相似的产品，虽然Consul目前的主要发展方向放在了Service Mesh，但是Consul最初支持的服务发现和配置管理，也是Nacos的两大功能。
虽然Nacos在Consul之后以与之相似的部署架构开源，但这并不意味着Nacos在功能和架构上也模仿Consul，Nacos的架构和功能是由阿里巴巴内部十年的运行演进经验得来，所以二者的比较也一定会让大家更加了解他们的定位和演进方向是完全不一样的。
