关于配置中心调研
概述
随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关、参数的配置、服务器的地址……
对程序配置的期望值也越来越高:配置修改后实时生效,分环境、分集群管理配置,代码安全、审核机制……
在这样的大环境下,传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。
所以,配置中心应运而生。
环境简介
目前公司使用阿里云管理所有服务,原因是为了降低运维成本——傻瓜式运维。
服务部署使用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的犹豫和不明确表达需求上...
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
加速数字化转型 平安云全方位赋能中小银行科技创新能力
【线上直播】11月21日晚8点贝壳技术总监侯圣文《数据安全之数据库安全黄金法则》 【51CTO.com原创稿件】数字经济早已成为全球经济的重要组成部分,并且在逐步推动着产业界的数字化转型。而我国数字经济也进入到快速发展的新阶段,数字化转型势在必行。然而,在数字化浪潮的推动下,传统中小型银行的转型面临着众多挑战。 利率市场化加速推进,金融监管日益严格,金融脱媒化显现,来自金融市场环境以及监管的双重压力,迫使中小银行的数字化转型加速进行。此外,由于银行制度创新相对较慢,银行产品同质化较为严重,民营、网络银行等机构发展迅猛,跨界的竞争愈演愈烈,如何通过数字化的方式,来扩展业务类型,从而找到创新业务模式,提高盈利,是众多中小银行所关注的。 传统金融机构在数字化转型过程中,既需要满足稳定性、可靠性、安全性等多方面的要求,同时,又要拥抱互联网化、移动化等新兴技术趋势。而云计算技术作为底层的架构支撑,既满足了传统金融机构对安全性的要求,又可以快速部署应用、拓展新业务,实现数字化转型需求,促进银行业快速发展。 在数字化转型浪潮下,平安云作为金融领域重要的云计算平台,凭借IaaS、PaaS、SaaS全栈...
- 下一篇
Spring Cloud Gateway 、Zuul、EdgeService性能对比
关键字:网关,Zuul,Gateway,Spring Cloud, ServiceComb,Edge Service性能测试,微服务 作者 | 李昂 导读 本文对几种流行的 API 网关以关键指标 RPS 为依据,利用 wrk 做出性能测评并且给出结论。本文所有使用的软件、命令、以及代码均在文中注明,以便读者搭建本地环境进行测试。注意性能测试的数据在不同的运行环境中差别较大,但总体上来说各项数据会成比例变化,本文的测试过程和结论可以较准确地反应出各 API 网关之间的性能差异。 背景知识介绍 API 网关 近些年来,在云时代的背景下,为了适应互联网和大数据的高速发展,随着微服务架构的持续火热,对 API 网关的诉求越来越强烈,API 网关的产品也层出不穷。除了传统的 Zuul 和 SpringCloud Gateway, 还诞生了很多优秀的网关,本文选取了Edge Service 作为比较对象与传统的网关进行了 API 网关的性能测评。 究竟是久经沙场的老牌网关更经得起考验,还是新兴的网关性能更优?本文将给出详细的测评过程和结果。 Netflix Zuul Zuul 在这三个网关中是...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8编译安装MySQL8.0.19
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker安装Oracle12C,快速搭建Oracle学习环境