概述
随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高：配置修改后实时生效，分环境、分集群管理配置，代码安全、审核机制……
在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。
所以，配置中心应运而生。
环境简介
目前公司使用阿里云管理所有服务，原因是为了降低运维成本——傻瓜式运维。
服务部署使用edas，配置管理使用acm。
调研目的
将所有代码中的基础依赖（如数据库、分布式存储等）相关配置回收到配置中心（acm或其他开源工具）管理，提升安全性，使资源可复用，减少因版本差异带来的开发工作量。
方案比较
| 方案 |
优点 |
缺点 |
备注 |
| edas-acm |
运维介入少，便于维护 |
扩容不方便，每次扩容都要重新为ecs实例单独授权，授权期间扩容实例服务不可用（4xx、5xx） |
edas团队有优化计划，但目前无排期 |
| 第三方 |
扩容方便 |
运维成本较高（服务器、人力），负载能力、稳定性待验证 |
|
第三方配置中心产品
- Disconf：百度开源的配置管理中心，目前已经不维护了
- Spring Cloud Config： Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
- Apollo： 携程开源的配置管理中心，具备规范的权限、流程治理等特性。
- Nacos： 阿里开源的配置中心，也可以做DNS和RPC的服务发现。
由于Disconf不再维护，下面对比一下Spring Cloud Config、Apollo和Nacos。
产品功能特点比较
| 功能点 |
Spring Cloud Config |
Apollo |
Nacos |
| 开源时间 |
2014.9 |
2016.5 |
2018.6 |
| 配置实时推送 |
支持（Spring Cloud Bus） |
支持（HTTP长轮询1S内） |
支持（HTTP长轮询1S内） |
| 版本管理 |
支持（Git） |
支持 |
支持 |
| 配置回滚 |
支持（Git） |
支持 |
支持 |
| 灰度发布 |
支持 |
支持 |
待支持 |
| 权限管理 |
支持 |
支持 |
待支持 |
| 多集群 |
支持 |
支持 |
支持 |
| 多环境 |
支持 |
支持 |
支持 |
| 监听查询 |
支持 |
支持 |
支持 |
| 多语言 |
只支持java |
Go、C++、java、Python、PHP、.net、OpenAPI |
Python、Java、Node.js、OpenAPI |
| 单机部署 |
Config-server+Git+Spring Cloud Bus（支持配置实时推送） |
Apollo-quikstart+MySQL |
Nacos单节点 |
| 分布式部署 |
Config-server+Git+MQ（部署复杂） |
Config+Admin+Portal+MySQL（部署复杂） |
Nacos+MySQL（部署简单） |
| 配置格式校验 |
不支持 |
支持 |
支持 |
| 通信协议 |
HTTP和AMQP |
HTTP |
HTTP |
| 数据一致性 |
Git保证数据一致性，Config-server从Git读数据 |
数据库模拟消息队列，Apollo定时读消息 |
HTTP异步通知 |
| 单机读 |
7（限流所致） |
9000 |
15000 |
| 单机写 |
5（限流所致） |
1100 |
1800 |
| 3节点读 |
21（限流所致） |
27000 |
45000 |
| 3节点写 |
5（限流所致） |
3300 |
5600 |
| 文档 |
详细 |
详细 |
有待完善（目前只有java开发相关文档） |
说明：
- 压测环境：
- 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（功能简单，配置简单，能满足要求，但是文档不够丰富）。
参考文档
剧终
最终还是选择等待阿里云做优化了...
吐槽： 时间都浪费在LD的犹豫和不明确表达需求上...
