赵成的运维体系管理课
赵成
《进化: 运维技术变革与实践探索》作者
37829 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
开篇词 (1讲)
效率和稳定性最佳实践 (20讲)
赵成的运维体系管理课
15
15
1.0x
00:00/00:00
登录|注册

14 | 如何做好持续交付中的多环境配置管理?

只打包一次的问题
配置校验问题
问题
缺点
优点
方案三:AutoConfig方案
方案二:占位符(PlaceHolder)模板模式
方案一:多个配置文件,构建时替换
应用对基础组件的依赖关系
应用属性信息
线上环境
Beta环境
预发环境
集成环境
开发环境
总结
环境配置管理解决方案
不同环境下的应用配置管理
多环境问题
环境配置管理
如何做好持续交付中的多环境配置管理

该思维导图由 AI 生成,仅供参考

上一篇内容中,我们讲到软件配置中的代码配置和应用配置,这两种配置之间最大的区别就是看跟环境是否相关。由此,就引出了持续交付过程中最为复杂的环境配置管理这个问题,准确地说,应该是不同环境下的应用配置管理。
今天我就结合自己的经验和你聊一聊环境管理的解决方案。

多环境问题

上篇内容我们介绍了应用配置的三种情况,今天我们稍微聚焦一下,以上篇文章中提到的前两种应用配置场景为主进行介绍,也就是平台类的业务。我们一起来看同一套软件在持续交付过程中和交付上线后,多环境情况下的配置管理问题。
我们先从生命周期的角度,对环境做个简单说明,主要包括:
开发环境,主要是在应用或软件开发过程中或完成后,开发人员对自己实现的代码进行单元测试、联调和基本的业务功能验证;
集成环境,开发人员完成代码开发并自验证通过后,将应用软件发布部署到这个环境,测试人员再确保软件业务功能可用,整个业务流程是可以走通的;
预发环境,在真实的生产数据环境下进行验证,但是不会接入线上流量,这也是上线前比较重要的一个验证环节;
Beta 环境,也就是灰度环境或者叫金丝雀发布模式。为了整个系统的稳定性,对于核心应用,通常会再经历一个 Beta 环境,引入线上万分之一,或千分之一的用户流量到这个环境中;
线上环境,经历了前面几个阶段的业务功能和流程验证,我们就可以放心地进行版本发布了,这个时候就会将应用软件包正式发布到线上 。
以上是一个持续交付体系中必须要有的几个环境。环境建设,又是一个比较大的话题,我们后面会专门来讲,今天就聚焦在环境配置管理上。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了持续交付中的多环境配置管理问题,并提出了针对不同环境下的应用配置管理的解决方案。作者首先介绍了开发、集成、预发、Beta和线上环境的生命周期,强调了环境配置管理的重要性。随后,文章详细讨论了不同环境下的应用配置管理,包括应用属性信息和应用对基础组件的依赖关系。针对这一问题,文章提出了三种解决方案:多个配置文件构建时替换、占位符模板模式和AutoConfig方案。每种方案都被详细讨论,并分析了其优缺点。其中,AutoConfig方案被认为相对完善,能满足大部分需求,但仍需要二次开发来解决多环境配置值管理的问题。总的来说,本文通过介绍多环境问题和不同环境下的应用配置管理,为读者提供了解决持续交付中环境配置管理问题的思路和方法。文章内容丰富,深入浅出,对于需要解决类似问题的技术人员具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《赵成的运维体系管理课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • 王德宝
    我们是在第一种基础上做的改进,不同环境有不同的配置文件,但不是打包替换,是不同的环境有系统的环境变量来区分,应用自然就知道加载哪和配置文件了,请老师评价这个方案

    作者回复: 运行时的参数这样做是没问题的,主要是启动时依赖的参数,这个必须是启动前也就是构建后的软件包中,就必须确定好的,所以这部分就要根据不同的环境构建不同的包

    2018-03-15
    4
  • Tom
    淘宝的配置中心还有一个叫diamond的,webx和diamond都是基于JAVA的;现在的业务系统有多种语言,如果是其他语言比如php,python,nodejs和go,这种分布式配置中心可以只使用一个?还是说要根据每个编程语言各自做一个?

    作者回复: 一个就够了,服务端提供不同的语言的client或者http接口就好

    2018-03-05
    2
  • 王德宝
    接我之前的留言,是应用启动时会根据不同的环境变量来加载指定的配置文件。包是同一个。 Spring有这个机制,spring.profiles.active

    作者回复: 针对spring的配置可以这样做,但是有很多配置我们并不是通过spring管理的,这套机制就没法用起来,不过这个思路还是值得借鉴的。

    2018-03-26
    2
    1
  • 张青
    AutoConfig这种思路的静态配置中心,是目前见到最好的处理多环境配置的方案。

    作者回复: 有实践经验吗?可以简单分享下,这块业界分享的确实不多。

    2018-02-06
    1
  • 阳生
    我最近在折腾配置中心,比较纠结服务怎么做自动注册,还是说手动配置再进行注册

    作者回复: 可以先思考下你要解决的问题是什么。

    2018-01-29
    1
  • 哈哈贝贝
    推荐Nacos或者consul,既可以做配置中心又可以做注册中心,还支持多语言

    作者回复: 我写这个专栏,差不多将近三年了,这几年在配置管理这块,社区也好,开源产品也好,确实越来越完善了

    2020-10-21
  • 微笑
    老师,想问一下,文中“再就是,这里需要针对不同环境进行单独的构建过程,也就是要多次打包,这一点是跟持续发布的指导建议相悖的。”,为什么说不同环境多次打包和持续发布是相悖的

    作者回复: 持续发布讲究一次打包,到处发布

    2019-08-09
  • manatee
    想请问下老师,如果在同一个环境下有多个版本在进行同步开发那这个多分支的配置应该如何处理呢

    作者回复: 每个分支,单独一套配置喽。

    2018-01-30
  • 贺明
    集中用携程开源的apollo这类配置中心来管理呢?定个配置型的命名规范和集中管理中心,是不是解决之道
    2018-05-27
    13
  • 无争就是yk
    在开源的分布式配置中心上面二次开发管理界面应该可以满足不同环境的配置问题,比如disconf
    2018-06-14
    1
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部