什么是软件配置管理?

关注者
54
被浏览
65,042

7 个回答

之前培训时专门总结过这个问题,正好看到就和大家简单一下。

要理解什么是软件配置管理,就要先理解什么是配置文件。

什么是配置文件?

配置文件是用来存储相关软件的一些信息,如初始化的信息,初始路径和帐号等等,方便程序的移植。

配置文件类型:

按照配置文件的形态分为以下几类:

1. 硬编码型

用开发语言来说就是hard code,即:将软件中配置的数据直接写死在代码中,例如:路径,IP,等待时间等。这种方式不利于数据的修改,但是另一方面来说如果某些数据比较重要且固定,用硬编码的方式可以保护这类的数据不被修改。

2. 文件类型

也就是目前单体应用架构中常用的方式,将源代码与配置文件分开管理,程序在启动时读取指定目录下的文件内容来加载配置信息。这种方式十分有利于制品的晋升,即程序在不同环境中运行时,无须修改代码,只需变更配置文件即可,例如在测试环境需要连接192.168.1.1:3306数据库,而在生产环境运行时,需要连接192.168.1.2:3306数据库,这时只需要变更配置文件即可。

3. 数据库类型

我们一般会将非文本形式的配置的信息存放在数据库中,这种配置一般为功能和业务上的配置,可以动态变更,例如功能开关(新功能上线后,先隐藏起来,等待可以发布时,修改数据库中的数据,即可将功能页面开放出来)。

4. 远程调用型

即所有的配置集中管理起来,所有服务启动或运行时通过接口加载配置,也就是我们所熟知的配置中心的方式。


按照加载类型可分为:

1. 单次加载类型

程序启动时读取的初始化配置,一般不会变化,例如连接数据库的凭据信息等。

2. 动态加载类型

程序运行时,根据业务需求变更的配置信息,例如功能开关,日志级别等。

为什么要应用(软件)配置管理?

随着数字化转型的发展,线下业务逐渐线上化,应用数量与日俱增,应用架构也趋于多样化和复杂化,这对于应用的配置也提出了越来越高的要求。

最初配置信息硬编码在代码中,与代码一起放在源代码仓库中;为了安全性与管理的方便,将配置以文件的形式从代码中分离出来管理,有的方式是将配置文件分发到目标机器的目录上,程序启动时直接读取。有的方式是CI打包时,在不同环境晋升时将配置文件打入程序包内,程序解压运行时从相对目录读取配置。

应用配置管理

这些方式的特点是,配置变化慢,配置变更后需要重启服务,所以在应用数量少,架构简单的单体应用阶段,是完全可以满足业务的需求的。但是随着微服务阶段,尤其是容器化应用的到来,服务节点数量指数级增长,按照上述的方式来管理配置就无法满足业务的需求了,这时候,应用(软件)配置中心应运而生。

什么是应用(软件)配置管理?

简单的来说就是将配置信息集中管控,当然随着业务的发展和应用架构的复杂度,对于配置中心的功能要求也非常的多,但总的来讲至少需要满足下面几个需求:

1. 高可用

所有的配置信息集中管理,配置中心的重要性不言而喻。

2. 实时性:

业务的需求需要配置的更新尽快通知到客户端,比如说蓝绿发布,主备切换等场景。

3. 多环境多集群管理:

配置文件的主要场景还是在不同环境下支持同一个程序的运行,所以针对于环境的管理需要保证隔离与统一管理。很多应用还需要多集群部署,所以对于多集群的管理也是十分必要的。

4. 治理:

配置的版本控制,配置的审计,配置权限的控制,配置的灰度发布等。

有人可能会问:热加载也是配置中心非常常用的功能场景呀,其实配置的热加载取决于应用是否支持配置的热加载,如果这个应用在将配置加载在内存后,除了重启进程,没有任何方法能变更内存里的配置,那么对于配置中心来说它也无能为力,配置中心核心的职责是快速将配置的变更通知到目标客户端。

码字不易,若觉得对你有所帮助,欢迎点赞收藏。

按自己的理解简单回答:

先举个贴近生活好理解的例子,你开车去加油站加油,你的车需要95号油,工作人员从标着95号油的油枪中给你加了,这个过程类似于把用户需要的软件从产品库中交付给用户的过程。

那么,配置管理就是在汽油这个产品从原油开采到提炼加工再到运输装入相应的油库再到给你的车加上你需要的汽油这整个过程中,确保每个环节的产出物清楚无误就行了。

在软件开发的过程中,从需求、设计、编码到测试、交付、使用,由很多人共同协作,产生大量的文档和代码,这些工作产品怎么清楚无误的显示自己当前的状态(一般采用版本号),多次变更后怎么追溯,就是配置管理考虑的。

再举个例子结束,吃饭点菜的时候,服务员把你要点的菜记下来(配置项标识),给你重复一遍确认(建立基线),发给后厨10分钟后你说要加个菜(配置项变更),服务员再次点菜重复确认(变更过程),吃完饭结账拿账单给你确认(状态确认),如果没问题就掏钱,有问题再变更。

基本就是这样,在整个过程中如果有工具支持,其实非常简单,没有工具也可以做,只是时间长了容易乱,还是建议用工具(现在最好用的是git),至于每个基线、配置项发布或变更批准的权限,就要结合公司实际来制定了。