关于配置中心调研技术指南

概述

随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……

对程序配置的期望值也越来越高：配置修改后实时生效，分环境、分集群管理配置，代码安全、审核机制……

在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。

所以，配置中心应运而生。

环境简介

目前公司使用阿里云管理所有服务，原因是为了降低运维成本——傻瓜式运维。

服务部署使用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的犹豫和不明确表达需求上...

本文发表于2019年11月12日 15:00
(c)注：本文转载自https://my.oschina.net/adailinux/blog/3128606，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如有侵权行为，请联系我们，我们会及时删除.

阅读 1676 讨论 0 喜欢 0

快捷链接
网站地图
提交友链