创建配置中⼼，将配置从各个应⽤中剥离出来，对配置进⾏统⼀管理，应⽤⾃身不需要⾃⼰去
管理配置.
1.概述
随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高：配置修改后实时生效，分环境、分集群管理配置，代码安全、审核机制……
在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。
所以，配置中心应运而生。
2.环境简介
目前公司使用阿里云管理所有服务，原因是为了降低运维成本——傻瓜式运维。
服务部署使用edas，配置管理使用acm。
调研目的
将所有代码中的基础依赖（如数据库、分布式存储等）相关配置回收到配置中心（acm或其他开源工具）管理，提升安全性，使资源可复用，减少因版本差异带来的开发工作量。
3.方案比较
第三方配置中心产品
Disconf：百度开源的配置管理中心，目前已经不维护了
Spring Cloud Config： Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
Apollo： 携程开源的配置管理中心，具备规范的权限、流程治理等特性。
Nacos： 阿里开源的配置中心，也可以做DNS和RPC的服务发现。
由于Disconf不再维护，下面对比一下Spring Cloud Config、Apollo和Nacos。
4.产品功能特点比较：
都支持版本管理，配置回滚，灰度发布，权限管理，多集群，多环境，单机部署，分布式部署，http协议
apollo：支持java,net,go,c++,php,openapi
nacos:支持java,node.js,python,openapi
说明：
压测环境：Nacos和Apollo使用同样的数据库（32C128G）部署Server服务的机器使用的8C16G配置的容器，磁盘是100G SSD。
Spring Cloud Config使用2.0.0.M9版本，Apollo使用1.2.0 release版本，Nacos使用0.5版本。
Spring Cloud Config 依赖git，使用局限性较大。
调研结果
首先会进一步跟进阿里云edas优化的排期，但是眼下好像是很渺茫... ...
其次，如果接入开源配置中心，根据以上数据分析，建议使用Apollo（功能完善，但是配置复杂）或nacos（功能简单，配置简单，能满足要求，但是文档不够丰富）。