写点什么

我们实施 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:062540

评论

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

你的数据库真的规范吗?小心这些“潜在风险”!

NineData

DevOps 数据库规范 审计日志 NineData SQL 规范

用不了ChatGPT?快试试免费又强大的Anthropic Claude

蓉蓉

GPT Claude

基于 Groq 和 Cartesia 的高速 AI 语音助手发布;xAI 将自行打造超级计算机丨 RTE 开发者日报

声网

百度安全大模型智能体实践入选信通院“安全守卫者计划”优秀案例

百度安全

平凯星辰黄东旭出席 2024 全球数字经济大会 · 开放原子开源数据库生态论坛

PingCAP

开源 金融行业 #TiDB 开放原子 平凯星辰

Apache IoTDB & TsFile 智慧能源应用“上会”啦!

Apache IoTDB

AI“语速”知多少?基于云拨测的国产大模型使用体验测评!

火山引擎边缘云

AI 大模型 云拨测、 云拨测 #大模型

华为云Astro Zero低代码平台案例:小、轻、快、准助力销售作战数字化经营

轶天下事

唐刘:当 SaaS 爱上 TiDB(一)- 行业挑战与 TiDB 的应对之道

PingCAP

数据库 SaaS #TiDB 洞察 资源管控

RPA助力企业财税业务智能化转型:深入探索与实践

不在线第一只蜗牛

全球销量领先车企基于Serverless服务构建数据实时处理的千万级车联网业务

轶天下事

CodeArts加速软件智能化开发,携手HarmonyOS重塑企业应用创新体验

轶天下事

深入理解 Nginx 与 Kong 的配置与实践

左诗右码

Kong 网关

推荐个人或企业使用的4个虚拟桌面解决方案 – 云桌面

青椒云云电脑

云桌面 云桌面解决方案 虚拟云桌面解决方案

云桌面系统解决方案-青椒云

青椒云云电脑

云桌面 云桌面厂家 云桌面解决方案 云桌面系统

《Google SRE工作手册》系列读书分享之GitOps实践之渐进式交付(视频+文字版)

雅菲奥朗

k8s SRE gitops Google SRE工作手册 SRE培训

《Google SRE工作手册》系列读书分享之美图SRE团队的「稳定性运营」实践篇一(视频+文字版)

雅菲奥朗

运维 SRE Google SRE工作手册 SRE培训

数业智能亮相AI论坛,共探数字心理健康新领域

心大陆多智能体

智能体 AI大模型 心理健康 数字心理

利用Altair One 云平台,轻松实现全球企业产品研发创新与优化

Altair RapidMiner

人工智能 软件 数据分析 制造 altair

使用 Protobuf 实现高效数据交换

左诗右码

protobuf

华为云发布ServiceStage:内置优秀业界实践「云应用管理和运维」模板

轶天下事

Persistent在《机构投资者》(Institutional Investor)2024年度亚洲高管团队调查中被评为管理和高管领导力卓越企业

财见

华为云CodeArts 12大安全防护机制,端到端全面保障软件供应链安全!

轶天下事

《Google SRE工作手册》系列读书分享之 组织视角下的金融企业SRE实践探讨 (视频+文字版)

雅菲奥朗

运维 金融 SRE Google SRE工作手册

积分经济学指南:掌握加密货币激励的新语言

TechubNews

Docker 安装 KONG 带你玩转 API 网关

左诗右码

Kong 网关

《Google SRE工作手册》系列读书分享之 B站SRE流程中心实践分享 (视频+文字版)

雅菲奥朗

SRE Google SRE工作手册 SRE培训

微服务nacos默认开启鉴权JeecgBoot

JEECG低代码

微服务 nacos

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