写点什么

我们实施 DevOps 的挑战之二 -- 配置文件的困惑

  • 2020-04-17
  • 本文字数:1821 字

    阅读完需:约 6 分钟

我们实施DevOps的挑战之二 -- 配置文件的困惑

在上一篇中谈到了「敏捷文化」,很多朋友质问我,上来就谈所谓“文化”太虚了吧,这不像你的风格啊。可我想说的是,在 DevOps 的路上,每天让我们感到最困难的,其实不是技术攻关,也未必是业务场景,而恰恰是敏捷思路与传统观念的转变。


技术,可以一针见血,无非出血量的多少罢了。


思路,只能慢慢培养,和谈恋爱其实差不多,开房很容易,但能一见面这就结婚吗?当然,这也可以,这却增加了离婚的可能性。


其实没什么,就是写写心得罢了。


当然,这种回复被身边的朋友叫做「这 B 装的我们给 100 分」「说不过你」。对此我来了个广告「请关注下一篇」。


没有 DevOps 之前,配置文件是怎么玩的呢?


在「群雄割据」的时代里,通常一个 Jar 或一个 War 就可以打天下,以 Spring+properties 为例,对配置文件的适用场景基本可分为两种类型:


配置文件位于 classpath 下


使用 spring 的 org.springframework.beans.factory.config.PropertyPlaceholderConfigurer 类加载 Properties 配置文件,通过源码可以知道,默认加载的是 classpath 下的文件,配置如下:



如果有多个配置文件加载,则:



配置文件位于外部目录


但是对于外部目录的配置文件,使用 org.springframework.beans.factory.config.PropertyPlaceholderConfigurer 也是可以加载的,不过要修改他的路径配置方式,如下:



这样就可以成功加载外部目录的配置文件了,${user.dir}是系统变量,指用户当前目录所在。


当我们从「群雄割据」来到「天下一统」的时期后,虽然 DevOps 提升了交付效率,越来越满足快速试错的原则,可随之而来的「技术污染」却与日体现:


…………


配置文件的版本如何与程序版本对应?


配置文件的管理如何更加简便?


配置文件的修改该有谁来操作?


配置文件的更新是否可以不影响正常服务?


…………


无论哪一项污染,只会与 DevOps 扯上关系,都是让人头痛不已。


撸起袖子,不要怂,咱们搞个配置中心吧。


有了 DevOps 之后,配置文件又是怎么玩的呢?


其实想通过 DevOps 获得业务收益,无论从哪个环节启动,都将是一场持久战。


随着系统产品化的改造,通过 DevOps 流水线的快速交付通道,任何一个交付版本都可以通过 CI 与 CD 环节后,利用自动化部署工具,轻松地完成升级或发布;


这段看似美妙的诱惑,首先挡住去路的,就是配置文件的使用与加载方式。


如果不将配置信息外移至配置中心,在 DevOps 中会出现哪些问题呢?


维护成本:系统拆分了更细了,增添 CI 与 CD 环境后,每个应用在每个节点下,都需要在本地维护一套完整的配置文件;


操作风险:配置修改随意,无操作痕迹,易出错;


版本需求:一切皆产品,一切皆版本,配置文件如何解决版本化控制问题?



图 1:配置中心在 DevOps 快速交付通道中


你不是常说你们的场景都是持续污染的吗?谈谈如何在污染环境下接入吧


的确,在整个接入过程中可以说是一波三折,原因很简单,之前「群雄割据」时期的每一位诸侯都有自己玩转配置的一套方案,现在你说统一就统一?


无法满足我要求的,我不接


这话表面看起来有些生硬,不过想想挺有道理的,所以在配置中心的方案中,我们提出了“三种适配器,两种推进器”的理念。


三种适配器



图 2:适配器 Trade,满足原有使用 Properites 的诸侯们



图 3:适配器 Native,满足已使用过自研独立配置服务的诸侯们



图 4:适配器 Ccms,满足使用 Key/Value 的诸侯们


两种推进器



图 5:希望采用 “文件被动加载” 的诸侯们



图 6:希望采用 “Key/Value 实时推送” 的诸侯们


从某种角度来说,就算没有配置中心的存在,我相信 DevOps 的推进也会顺理成章,只不过相对不会如此平滑,或多或少给未来造成风险


有了配置中心,诸侯们的确享受到了福利:


配置统一在服务端维护,同一环境下所有应用节点共享同一份配置;


配置控制台提供鉴权、操作日志等服务;


配置控制台实现了版本控制,修改的配置需要发布后生效,减少误操作;


配置发布后,实时通知应用端,无须重启即可使用;


配置版本支持一键回滚;


配置控制台实现了整体复制、导出、批量修改等功能;


写到这里,太阳出来了


每次在结束语中都会诉诉苦,不过年末的各种事项的确有点打乱节奏,写作时间也随之调整到了工作日的清晨 6 点-8 点之间,所以效率与质量也或多或少受到影响。


本文主要讲述围绕配置信息管理和使用在 DevOps 过程中的那点事,所以对配置系统自身的原理与技术实现并未做详细的描述,如对这块有兴趣,欢迎大家在留言区中提出,我将通过独立的整篇文章加以叙述。


本文转载自头哥侃码公众号。


原文链接:https://mp.weixin.qq.com/s/99SqnEe9MGKzSbtvVR6sog


2020-04-17 15:062549

评论

发布
暂无评论
发现更多内容

阿里云正式开源 LoongSuite:打造 AI 时代的高性能低成本可观测采集套件

阿里巴巴云原生

阿里云 开源 云原生 可观测

阶跃星辰端到端语音模型 Step-Audio 2:深度思考+音色切换;11Labs 对话式 AI 增加 WebRTC支持丨日报

RTE开发者社区

WAIC看点:可交付AI登场,场景智能、专属知识将兑现下一代AI价值

Fabarta

人工智能 agent AI 智能体 个人智能体

SearchBox:一个神奇的搜索组件,比传统的搜索框 + 下拉框的方式体验好十倍!

OpenTiny社区

开源 前端 OpenTiny UI组件库

PandasAI连接LLM进行智能数据分析

不在线第一只蜗牛

数据分析

YashanDB ROW_NUMBER函数

YashanDB

数据库

AWS上实现超大规模模型训练的近线性扩展

qife122

AWS 分布式训练

寻疗智慧 IOT 数字健康服务平台

微擎应用市场

铭芯科技共享轮椅租赁系统

微擎应用市场

荣耀应用市场《2025上半年应用合规治理报告》丨开发加油站

荣耀开发者服务平台

应用中心 治理规范 荣耀开发者服务平台 荣耀应用市场

什么是低代码(Low-Code)?2025低代码核心架构技术解析与应用展望

优秀

低代码 低代码开发

GPUStack v0.7重磅更新:macOS与Windows安装包、昇腾MindIE多机推理、模型使用计量与寒武纪MLU支持

GPUStack

人工智能 AI 大模型 LLM

Golang基础笔记十五之sync

Hunter熊

Go 后端 读写锁 互斥锁 对象池

YashanDB ROUND函数

YashanDB

数据库

基于Amazon Translate的深度学习教材自动翻译系统

qife122

机器翻译 Amazon Translate

亚马逊机器人如何应对交通拥堵

qife122

机器人技术 多智能体系统

Vibe Coding 时代的开源社区开发新体验

老纪的技术唠嗑局

AI+ OceanBase 开源 cursor MCP

基于深度学习的YOLO框架的7种交通场景识别项目系统【附完整源码+数据集】

程序员Geek

人工智能 yolo

寻医问药小程序系统

微擎应用市场

基于亮数据 MCP 的 Trae 智能体,让规模化 Google 数据实时分析触手可及

阿Q说代码

亚马逊发布TEACh数据集训练家用机器人

qife122

人工智能 数据集

华为开发者空间部署FastGPT,构建知识库智能体

华为云开发者联盟

华为云ModelArts AI+ FastGPT DeepSeek v3 华为开发者空间

YashanDB ROWIDTOCHAR函数

YashanDB

数据库

YashanDB RIGHT函数

YashanDB

数据库

MySQL有哪些“饮鸩止渴”提高性能的方法?

量贩潮汐·WholesaleTide

MySQL 数据库

Aloudata 入选 IDC “Data Flow Agent 代表厂商”和 DAC “数据资产运营商 TOP10”

Aloudata

agent 指标平台 noetl ChatBI

YashanDB RLIKE_FILTER函数

YashanDB

数据库

新鲜出炉|指标平台「实践案例研究报告」等你来领~

Aloudata

数据分析 ETL 指标平台

使用监督学习训练图像聚类模型

qife122

监督学习 图像聚类

量子计算先驱David Schuster的二十年探索之路

qife122

AWS 量子计算

mdraid、mdadm 与 Linux 软件 RAID 终极指南

Sergey Platonov

raid storage xiRAID MDraid

我们实施DevOps的挑战之二 -- 配置文件的困惑_DevOps & 平台工程_头哥侃码_InfoQ精选文章