应用配置的几个原则

之前在 《应用配置管理实践》 中提到过配置的管理方式,这次我专门来说说在工程实践中总结的一些应用配置原则。

简单友好原则

我们先回顾下一些常用的配置文件格式

ini,xml,json,yaml,toml

从 ini 开始,方便好用,但是无法支持复杂些的数据结构,之后是 xml ,但是配置文件太庞大,导致可读性也不好;json 的机器可读性更好,但是不支持注释,而且灵活性不高,一旦多加了个逗号都能导致加载失败;yaml 是随着 ruby 的发展而逐渐发展起来了,是一种非常优秀的配置格式,数据结构丰富,允许层级以及注释,只是同样是格式太严格,容错率不高,toml 灵活性较高,有着 yaml 的优点,只是不足之处在于还比较新,使用者少,而且支持的软件也不多。

不难发现,它们的可读性越来越强,容错率越来越高,支持丰富的数据结构,当然,规则也越来越复杂,并且目前主流软件的配置都在向 yaml 靠拢,于是对于系统管理人员来说,便越来越受欢迎。

所以,用 yaml 或者 toml 吧,它们是目前能满足你配置需求的最佳选择。

可动态重载原则

一般来说,在 Linux/Unix 下的软件,我们会使用以下几种方式来重新加载配置:

  • SIGHUP 信号:使用 kill -SIGHUP {PID} 来触发重新加载操作;
  • 专门的接口:对于网络服务型的应用,我们也可以用比如 POST /reload 来触发重新加载,Prometheus 就是使用 POST /-/reload 来重新加载配置的;
  • 文件的 hash:实时或者周期性监测配置文件的 hash 来判断是否需要重新加载,logstash 就是这么干的;
  • 强一致性数据库:就是将变化非常频繁的配置加入到 etcd/zk/consul 等强一致性数据库中,在服务注册发现中会使用到;

这个功能非常有意义,因为不是每次重新更新配置都需要重启应用。

只是,这对于开发者的要求会比较高,因为得考虑到配置的重新加载,而有些模块的重新加载会很危险,就比网络应用中,重新加载数据库,会导致应用暂时无法提供服务。并且,有些模块会有繁杂的依赖问题,如果设计成动态重新加载的话,会导致软件架构非常复杂。

因此,有些时候,我们会考虑宁可简单处理:重启应用。

顺便提一句,在 k8s 中,我们使用配置的最佳方式莫过于将配置放进版本管理,也做成 Deployment 的一部分,将配置变动当做一次应用的升级。

具体来说,我们在 k8s 中会使用 ConfigMap 或者 Secret 的方式管理,然后在 Deployment 中,将配置当成 Volume 挂载到 Container 中,那么,这时候,我们可以将配置文件的 hash 加到 Deployment 的描述中去,一旦 hash 更改,Deployment 就会更改,k8s 就会自动使用滚动更新的方式来更新应用。这么做还有一个好处便是,一旦配置错误了导致应用无法提供时候,k8s 也会拒绝升级,避免了线上应用出错。

吝啬配置原则

如果你的程序中,有大量可配置选项的存在,你就该思考,是否有必要有那么多的配置,假如你是这个软件的用户,你会希望配置那么多的选项吗?

在实践中,我们认为,应当使用尽可能少的配置,如果一些配置能够自动检测的话,就不要劳烦用户去配置了,或者,大部分配置给出默认或者推荐选项即可。

另外,如果某个配置是必须的,不存在便会让程序无法启动的话,这时候考虑也要加个默认配置,尤其是在团队开发的情况下,更新代码后应用无法启动是会让我们发飙的。

依赖倒置原则

我觉得我们使用配置的意义就在于:给用户最大的自由度,用户可以自由地使用配置来组装一个系统,或者说使用配置去模块编程。

这同时也是一种设计的原则:依赖倒置,我们不可能对每一个用户都给编译一个单独的镜像,依赖她们的需求来设计我们的系统,那么最佳的做法便是做好所有的模块,然后交给他们自己去配置即可。电脑组装就是个例子,所有的模块都是标准的(主板、CPU、内存、硬盘等),用户只需要根据自己的需求与预算挑选合适的模块,然后就能组装成一台自己想要的电脑了。

就比如创业初期,我们不想给每一个运营人员每次都单独拉数据,那么,将所有数据同步到 ES 里面,他们可以学习下如何使用 kibana 的图表,然后就可以定制自己的需求了,这就是将依赖给倒置了。-

同时,对于业务开发的工程师来说,一旦产品说要写死代码,就意味着我们必须将相关的代码加入可配置选项,因为有经验的工程师都知道这是个不靠谱的产品,他以后肯定会反悔,然后死乞白赖地求你改功能的。于是等那天来的时候,你就告诉他,你可以今晚通宵加班赶工,明天早上就能上线,但是想吃高级日料外卖,而其实你只是打算看一集冰与火之歌,然后下班的时候改个配置🙈。

Ref

  1. https://stackoverflow.com/questions/37317003/restart-pods-when-configmap-updates-in-kubernetes
  2. http://blog.zengrong.net/post/2360.html
  3. 《Unix 编程艺术》

原链接:https://xizhibei.github.io/2017/08/28/principles-about-app-configuration/

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,525评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,203评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,862评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,728评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,743评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,590评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,330评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,244评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,693评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,885评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,001评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,723评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,343评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,919评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,042评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,191评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,955评论 2 355

推荐阅读更多精彩内容