不同环境下的应用配置管理

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了不同环境下的应用配置管理相关的知识,希望对你有一定的参考价值。

从生命周期的角度,环境主要包括如下:

  • 开发环境,主要是在应用或软件开发过程中或完成后,开发人员对自己实现的代码进行单元测试、联调和基本的业务功能验证;
  • 集成环境,开发人员完成代码开发并自验证通过后,将应用软件发布部署到这个环境,测试人员再确保软件业务功能可用,整个业务流程是可以走通的;
  • 预发环境,在真实的生产数据环境下进行验证,但是不会接入线上流量,这也是上线前比较重要的一个验证环节;
  • Beta 环境,也就是灰度环境或者叫金丝雀发布模式。为了整个系统的稳定性,对于核心应用,通常会再经历一个 Beta 环境,引入线上万分之一,或千分之一的用户流量到这个环境中;
  • 线上环境,经历了前面几个阶段的业务功能和流程验证,我们就可以放心地进行版本发布了,这个时候就会将应用软件包正式发布到线上 。

不同的环境,配置是不完全相同的。

方案一,多个配置文件,构建时替换

这是一个比较简单且直接有效的方式,就是不同环境会分别定义一个配置文件,比如:

  • 开发环境 dev_config.properties
  • 预发环境 pre_config.properties
  • 线上环境 online_config.properties

然后在构建时,我们会根据当前所选定的环境进行替换。比如,我们现在构建开发环境的软件包,这时就会选择 dev_config.properties 作为配置文件,并将其文件名替换为 config.properties 打包到整个软件包中。

我们看下这种方案的优缺点:

  • 优点,就是简单直接。在环境相对固定且配置项变化不大的情况下,是最为简便的一种环境配置管理方式。
  • 缺点,也比较明显。首先是在实际的场景中,我们的环境可能会更多,且交付上线后可能还会有线上多环境。这时每多出一个环境,就要多一个配置文件,这时配置项的同步就会成为大问题,极有可能会出现配置项不同步,配置错误这些问题。特别是如果配置项也不断地增加和变化,管理上会变得非常繁琐。再就是,这里需要针对不同环境进行单独的构建过程,也就是要多次打包,这一点是跟持续发布的指导建议相悖的。

方案二,占位符(PlaceHolder)模板模式

这种方案在 Maven 这样的构建工具中就可以很好地支持,直接示例如下:

cache.app.url=$cache.app.url

我们可以看到,这种模式下,配置项的值用变量来替代了,具体的值我们可以设置到另外一个文件中,比如 antx.properits,这里面保存的才是真正的实际值。

不过,这个方案仍然不能很好地解决上面第一种方案提到的问题,配置文件是可以保留一个了,但是取值的 antx.properties 文件是不是要保留多个?同时,对于配置文件中配置项增加后,antx.propertis 文件中是否同步增加了配置,或者配置项名称是否完全匹配,这一点 Maven 是不会帮我们去检查的,只能在软件运行时才能验证配置是否正确。

最后,这个方案还是没有解决只打包一次的问题,因为 Maven 一旦帮我们构建完成软件包之后,它并没有提供直接针对软件包变更的方式。所以,针对不同的环境,我们仍然要打包多次。

方案三,AutoConfig 方案

AutoConfig 是阿里开源的 Webx 框架中的一个工具包,在阿里的整个持续交付体系中被广泛应用,它继承了 Maven 的配置管理方式,同时还可以作为插件直接与 Maven 配合工作,针对我们上面提到的部分问题,它也针对性地进行了加强和改进,比如:

  • 配置校验问题。AutoConfig 仍然是以上述第二种方案的模板模式为基础,最终通过 antx.properties 文件中的配置值来替换,但是它会做严格校验;同时也可以自定义校验规则,来检查配置项是否与模板中的设定严格匹配,如果不匹配,就会在构建时报错,这样就可以让我们提前发现问题,而不是软件包交付到环境中运行时才发现。
  • 只打包一次的问题。AutoConfig 不需要重新构建就可以对软件包,比如 war 包或 jar 包的配置文件进行变更,所以它很好地解决了针对不同环境需要重复构建的问题。但是,比较遗憾的是,它的 Maven 插件模式并没有解决这个问题,还需要与 AutoConfig 工具模式配合才可以。

可以看到 AutoConfig 的方案已经相对完善了,也可以满足我们的大部分需求,但是它仍然没有解决多环境配置值管理的问题,我们是通过多个 antx.properties 文件来管理,这就需要基于 AutoConfig 做一下二次开发了。


Windows下的用户配置文件管理

用户配置文件定义保存了用户的工作环境。根据工作环境的不同,Windows支持三种类型配置文件:

    本地用户配置文件

    漫游用户配置文件

    强制用户配置文件

另外,系统还提供了默认本地配置文件、默认域配置文件的支持。


一、本地用户配置文件

    当用户第一次登记计算机时,系统就会在本地磁盘上为用户建立一个本地配置文件。用户的工作环境设置(如开始菜单、文档等信息)会被存储在此文件夹内。用户下次登灵活时,系统会使用此文件夹的内容来设置用户的工作环境。

    特点:用户可以修改自己配置文件内容

    1、存储用户配置文件的文件夹

    %SystemDriver%\用户 文件夹

    查看时需选择“显示隐藏的文件、文件夹和驱动器”。

技术分享


浏览到用户名所在文件夹下:

下图一些带快捷箭头的文件,其实质是一些目录联接,即链接到另外一位置的文件。

技术分享

用户可以命令行状态下,输入 Dir /AD显示联接信息。

有<JUNCTION>,表示为目录联接,后面有它链接的具体位置。

技术分享

    浏览到到AppData,结果如下:这三个文件夹也存放用户的一些信息。

    Windows 使用 Local及LocalLow文件夹存放非漫游的应用程序数据(类似注册表Local_machine)及一些空间占用大无法漫游的应用程序数据,而Roaming文件夹则用来保存可漫游的用户应用程序数据,如每个用户的个性化设置等。

技术分享

    浏览到Roaming文件夹下:

技术分享

    浏览其Windows文件夹:这时存放着用户Windows的一些设置信息

    如开始菜单、SendTO(发送到)、Libraries(库)等,用户可以直接这些文件下进行相关操作(如建立文件夹等)来改变用户配置的设置。

技术分享

    以下是Appdata\Local文件的内容,Temp用户临时文件夹,用户可以删除这个文件下的内容。

技术分享

    2、查看用户配置文件的类型

    选择“系统属性”下的“用户配置文件”的设置按钮:

    可以查看配置文件的名称、大小、类型、状态以及创建时间。

    如果某一用户有多种类型的配置文件,还可以修改期类型(即用户下一次启动何种配置文件)

    用户还可以将当前配置文件复制给其他用户,这样可以保持配置文件的一致性

    (后面的强制配置文件的建立,就用到配置文件的复制)

技术分享

    3、用户配置文件的建立

    用户首次登录计算机时,会建立用户配置文件设置。它主要由%SystemDriver%\用户\Default(本地默认配置文件)和%SystemDriver%\ProgramData这两个文件夹共同进行设置

    注意:在旧版的操作系统中,这两个文件夹并非用此名,而用Default User与All Users文件夹。为了保持兼容见,Windows 2008等操作系统还保留了这两个文件夹。


二、漫游用户配置文件

    本地用户配置文件随着计算机而异。如果用户希望在任何一台计算机登录,都能够使用相同的配置文件(即相同的工作环境),就要用到漫游用户配置文件或者强制用户配置文件。

    特点:配置文件信息存放在网络服务器上(非本地计算机上);只适合给域用户使用(因为只有域用户才能登录到域内的各台计算机)

    漫游用户配置文件(Roaming User Profile):由于域用户到域内的任何一台计算机登录时会到网络服务器读取相同的漫游用户配置文件,因此可以拥有统一的工作环境。当用户注销时,系统会将配置文件更改保存到网络上漫游用户配置文件,供下一次用户登录使用。


    测试环境:服务器:Windows Server 2008 R2,DCSrv01,DC,FromHeart.Com,用来存放漫游用户配置文件

              客户机:Windows 7,加入到域


    漫游用户配置文件的设置过程:

    1、建立共享文件夹

在服务器建立一个用来存放配置文件的文件夹,将其共享为“配置文件”,同时设置共享权限为读取/写入权限。

    2、设置配置文件路径

    在服务器(DC)上,使用管理员登录计算机,打开活动目录用户和计算机(Dsa.Msc),选择用户,浏览到“配置文件”标签。

    下图是对管理员自己进行的设置.

    配置文件路径:\\DCSrv01\配置文件\Administrator

技术分享

    3、查看结果

    当用户用域内的任何一台计算机登录时,可以看到如下信息:

技术分享

    此时用户有两种类型的配置文件,用户可以更改配置文件类型。

技术分享

    同时在服务器的共享文件下,系统自动建立一个名为Administrator.V2文件夹技术分享


技术分享

    4、用户对漫游用户配置文件的处理

    若用户是第一次使用某台计算机登录,由于用户之前没有登录域内的任何一台计算机,在登录前期漫游配置文件夹下为空。此时登录时,其工作环境是通过Default进行设置;

    若用户之前登录过此台计算机,即以本地用户身份登录过,尽管没有以域用户的身份登录过(漫游用户配置文件为空),此时用户登录进,其工作环境由其本地用户配置文件进行设置;

    

    如果域用户登录时,由于网络故障等原因无法访问网络上的漫游用户配置文件时,此时:

    若用户是第一次使用这台计算机登录,由于以前没登录过,不存在本地用户配置文件,同时网络上漫游用户配置文件也无法访问,此时用户会用Default来设置;当用户注销时,系统不会将配置文件信息写存储到网络上,也不会存储到本地;

    若用户以前登记过此台计算机,存在着本地用户配置文件,此时用户使用本地用户配置文件设置期工作环境;当用户注销时,会将其配置文件(改变)存储到本地配置文件。当下一次用户还用这台计算机登录到域时,即使此时漫游用户配置文件能访问,但由于本地配置文件较新,用户还是会使用本地用户配置文件,只是当用户注销时,会将本地较新用启用配置文件写入到网络上的漫游用户配置文件中,供下一次用户登录使用。


    如果用户同有拥有本地配置文件、漫游配置文件,当用户登录时:

    如果本地较新,则读取本地配置文件;如果网络服务器上的较新,刚读取网络上的;如果两者一样,为了提高访问速度,系统会使用本地。

 

    



本文出自 “从心开始” 博客,请务必保留此出处http://ycrsjxy.blog.51cto.com/618627/1875640

以上是关于不同环境下的应用配置管理的主要内容,如果未能解决你的问题,请参考以下文章

Windows下的用户配置文件管理

MyBatis在Spring环境下的事务管理

宝塔控制面板下的typecho开启伪静态

如何在spring cache java中配置多个缓存管理器

RMAN高级应用之不同环境下的复制流程

vue---不同环境下的配置