配置检查方法、装置、计算机系统及存储介质与流程

本发明涉及数据处理技术领域，尤其涉及一种配置检查方法、装置、计算机系统及存储介质。

背景技术：

在计算机技术领域中的配置包括设备及其上运行的操作系统、服务器应用和用户应用等计算机程序中的各种配置项，配置项对设备及计算机程序的正常运行来说是必不可少的。在产品的开发、更新以及维护等过程中，往往需要在不同的环境下对配置中的配置项进行修改，一个配置项的错误就会导致业务无法继续进行，因此需要对配置项进行管理。

技术实现要素：

本发明的目的在于提供一种配置检查方法、装置、计算机系统及存储介质，以解决上述现有技术中的问题。

为了实现上述目的，本发明提供一种配置检查方法，包括以下步骤：

步骤s10、检入系统版本号，该系统版本号对应第一配置方案和第二配置方案；

步骤s20、分别提取第一配置方案中的各配置项与第二配置方案中的各配置项；

步骤s30、将第一配置方案与第二配置方案的配置项进行比对；

步骤s40、将不同值的配置项在用户界面中进行标注，通过异步消息推送进行检出。

进一步的，读取的配置项的信息以链表的方式保存块、键和值，当需要查询某个块以及键对应的值时，先遍历到相应的块，再遍历到键处，下一个节点即为需要查询的值。

进一步的，提取配置项的方式采用springboot读取配置文件，包括使用environment类读取、使用@value读取或使用@configurationproperties读取。

进一步的，检入系统版本号时设置基线，所述基线的属性包括名称、标识符和日期。

进一步的，配置项进行比对的方式包括文本对比和赋值大小判断。

进一步的，通过异步消息推送的方式包括采用轮询、长连接、flashsocket或websocket。

进一步的，配置项以键值的方式配置，键值的类型包括int，string和list。

为了实现上述目的，本发明提供一种配置检查装置，包括系统版本检入模块、提取模块、比对模块和输出模块，所述系统版本检入模块用于检入系统版本号，该系统版本号对应第一配置方案和第二配置方案，所述提取模块用于分别提取一配置方案中的各配置项与第二配置方案中的各配置项，所述比对模块用于将第一配置方案的配置项与第二配置方案的配置项进行对比，所述输出模块用于将不同值的配置项在用户界面中进行标注，通过异步消息推送进行检出。

为了实现上述目的，本发明还提供一种计算机系统，其包括多个计算机设备，各计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述多个计算机设备的处理器执行所述计算机程序时共同实现前述方法的步骤。

为了实现上述目的，本发明还提供一种计算机可读存储介质，存储介质上存储有计算机程序，所述存储介质存储的所述计算机程序被处理器执行时实现前述方法的步骤。

通过采用上述技术方案，本发明相对于现有技术具有如下有益效果：

本发明提供的配置检查方法、装置、计算机系统及存储介质能够在用户界面通过选择需要检入的系统版本号，该系统版本号对应两套不同的配置方案，可将不同环境下变更的配置项提取出来进行比对，在用户界面可显示出不同环境下配置项的差异并推送进行检出，提高配置项检查的效率，从而减少配置项错误的概率。

附图说明

图1为本发明配置检查方法的流程图；

图2为本发明配置检查装置的一个实施例的结构框图；

图3为本发明计算机设备的一个实施例的硬件架构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

参阅图1，示出了本发明一种配置检查方法，包括以下步骤：

步骤s10、检入系统版本号，该系统版本号对应第一配置方案和第二配置方案；

步骤s20、分别提取第一配置方案中的各配置项与第二配置方案中的各配置项；

步骤s30、将第一配置方案的配置项与第二配置方案的配置项进行比对；

步骤s40、将不同值的配置项在用户界面中进行标注，通过异步消息推送进行检出。

首先，在步骤s10中，通过对接代码库可检入系统版本号，代码库可采用svn或git，如可查询出最近需要发版的系统版本号，系统版本号在代码库中通常是需要不断的更新，对应程序代码及配置项也随之更新，以当前最新的系统版本号为例进行说明，系统版本号可以用时间轴对应每个时间节点上的更新的版本号，也可以是重大版本改进和小改动的版本号编号，在版本库中有相应的地址找到系统版本号的信息。在该系统版本号对应第一配置方案和第二配置方案，例如在开发环境、测试环境和生产环境等形成不同的配置方案，可在开发环境采用第一配置方案，在生产环境或测试环境采用第二配置方案，程序代码在每次新建一个版本的时候都会在版本管理系统中新建一个系统版本号，配置检测时可以检入每个系统版本号。

系统版本号可采用三位符号表示如“x.y.z”，“x”为主版本号，对产品作重大调整，或与已发行的版本相比在功能与性能上有较大改善时版本号增加，当产品或项目概念全新时设立初始版本号，“y”可为版本升级号，表示增加功能时的版本升级，可用一位数字表示“0～9”，与上一产品或项目相比，功能进行了小量的增加或修正时版本升级号递增，“z”可为修正号，表示纠正错误时的版本升级，对上一次产品或项目中的缺陷做修正，也可以通过递增的一位数字表示。检入操作实现文件的上传，可包括指定文件对象与其它对象的关联关系、确定文件的id号以及确定文件的作者等，解锁对应的文件。检出操作能形成配置方案的副本，解锁对应的文件。

系统版本号还可以划分为内测版、公测版、候选版和正式版。内测版表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，或者专业测试人员测试用，一般而言，该版本软件的bug较多，需要继续修改；公测版相对于内测版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除。候选版表明该版本已经相当成熟了，完成全部功能并清除大部分的bug，基本上不存在导致错误的bug，与即将发行的正式版相差无几；正式版在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本，该版本有时也称为标准版。

配置方案包括了即将受控的所有产品特性，其内容及相关文档、软件版本、变更文档、软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的配置项包括更多的内容并具有易变性。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置方案即配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。

接着，在步骤s20中，在选择需要检查的系统版本号后，通常以当前最新(或正在使用中)的系统版本号为检查对象，也可以回溯到之前的系统版本号对以往的配置项进行检查，对配置方案进行查询，分别将第一配置方案中的各配置项和第二配置方案中的各配置项提取出来，可以罗列出对应的配置项，配置方案中包括名配置项的信息，配置项对应的内容可包括开关、文件路径、参数和秘钥等，配置项可以包括静态配置项和动态配置项，静态配置项是指对应的取值不会发生变化的配置项，动态配置项是指对就的取值根据运行环境不同可发生变化的配置项。

在本实施全中，配置项提取出来的方式采用springboot读取配置文件，包括使用environment类读取、使用@value读取或使用@configurationproperties读取。使用environment类读取依赖注入evnironment来完成，在创建的成员变量privateenvironmentenv上加上@autowired注解即可完成依赖注入，然后使用env.getproperty("键名")即可读取出对应的值。使用@value读取将配置文件的属性读出来，包括@value(“${}”)和@value(“#{}”)两种方式，使用@value注解读取时读取properties配置文件时，默认读取的是application.properties，如果@value${}所包含的键名在application.properties配置文件中不存在的话，会得出异常。使用@configurationproperties读取包括：(1)添加一个配置类，在类名上面使用@configurationproperties，若读取的配置文件不是默认的application.properties，则需再添加@propertysource(“xxx.properties”)注解；(2)在引导类上面添加@enableconfigurationproperties(value＝类名.class)；(3)在需要的地方使用@autowired注入该对象。

每个系统版本事情中的配置项是相对确定的，而第一配置方案与对第二配置方案对应于不同的工作场景，使得在一些配置项上具有不同的配置信息，同一配置项上在不同的配置方案中的配置信息的不同导致产品运行的差异，有可能导致产品运行故障，就可以通过配置检查找出故障原因。查询配置文件的操作可由accesscfgfile函数完成，该函数首先判断配置文件的后缀，获取带全路径的配置文件名，最后判断配置文件的存在。

在一个计算机程序的开发和运行过程中，配置项会不断的进行修改，例如在测试环境中会采用一套配置方案，而到了生产阶段则会采用另一套配置方案，也就是对某个或某些配置项的值进行了修改，以适用于不同的应用场景，在步骤s30中，可对不同环境下的配置方案的配置项进行对比，从而检查出配置项的变更，可采用文本对比技术得出配置项的变更，如对配置项的语法进行检查或对字符逐个比较，也可对赋值大小判断从而得出配置项是否发生变更。

文本对比可采用lcs算法查找出两个字符串的最长公共子序列，设x＝(x1,x2,.....xn)和y＝{y1,y2,.....ym}是两个配置项的序列，将x和y的最长公共子序列记为lcs(x,y)，如果x1＝y1，……，xn＝ym，即x的第一个元素到最后一个元素与y的第一元素到最后一个元素相同，这说明该配置项相同。赋值大小判断可采用比较运算对第一配置方案的配置项与第二配置方案的配置项进行比较运算，运算返回布尔值，比较大小的运算符有4个，包括<、<＝、>＝和>。采用“<”，如果第一配置项的操作数小于第二个配置项的操作数，则返回true，否则返回false；采用“<＝”，如果第一配置项的操作数小于或等于第二个配置项的操作数，则返回true，否则返回false；采用“>＝”，如果第一配置项的操作数大于或等于第二个配置项的操作数，则返回true，否则返回false；采用“<”，如果第一配置项的操作数大于第二个配置项的操作数，则返回true，否则返回false，可根据需要选择<或<运算符。

可将配置项的类型进行分类，包括其属性和关联以及各种配置项类型之间的关联规则，并可以在用户界面显出分类和属性，还可以建立配置项的类型列表，对配置项的子集进行查看，还可以指定配置项与另一个配置项之间的关联，形成配置项集从而对配置方案进行管理。

读取的配置项的信息以链表的方式保存块、键、值，并按顺序串联起来，当需要查询某个块以及键对应的值时，先遍历到相应的块，再遍历到键处，下一个节点即为需要查询的值。还可将配置信息分为公有配置和私有配置，公有配置是指在对象外可以访问到对象内的属性，私有配置只有函数内部可以访问，在类中使用的变更或者不想被外部调用的变量设为私有配置。

当配置项以键值的方式配置时，值的类型支持int，string和list，以表示符号分割，如：names＝lily,john。在所有键值存入链表的时候都是string时，支持int时候只要做下atoi转换即可；当键值类型为list时候，读取值的时候增加个index下标即可：getvalue(stringkey,stringblock,intvalue_index)。

例如在mysql通过变量来定义主机运行的特性、状态等，变量可以定义在配置文件中，也可以直接在服务器运行时定义，查看mysql程序可配置的变量可以通过以下三种方式：

shell>mysqld--help–verbose；查看可以配置的变量列表

mysql>showglobalvariables；查看当前服务器的全局变量状态

mysql>showsessionvariables；查看当前会话变量状态

在步骤s40中，可通过不同的底色来标注出配置项做了哪种修改操作，例如可通过不同颜色区分新增、删除或修改等操作，还可以通过高亮显示来进行提醒，同时，为了确保配置项的改动被知悉，通过异步消息推送变更的配置项，一旦发生改动的操作即可触发，发送消息到指定的接收方，针对不同环境之间的配置项的变更做出提醒，以便于审核配置项做出变更的正确性，确保所需版本的配置方案正确无误。异步指暂时搁置当前请求的响应，处理下一个请求，当通过轮询或其他方式得到回调通知后，开始运行，在多线程中可将异步操作放入另一线程中运行，通过轮询或回调方法得到完成通知，但是完成端口，由操作系统接管异步操作的调度，通过硬件中断，在完成时触发回调方法，此方式不需要占用额外线程。

当不同环境下的配置项在修改后发生异常故障时，本方案的配置检查方案可对比出开发、测试、生产等环节中配置项的值之间的差异来提醒开发人员，使差异容易被注意到，使其确保配置方案的准确性。采用配置检查方法可得到各环境中配置项的逻辑模型和这些配置项的变更，可检查基础结构中的相关项、决定要管理哪些项，以及要管理的这些项的哪些属性和关系、确定变更流程以及审计每个配置项的实际版本和授权版本，通过配置检查方法可帮助确保提供服务时必需的配置项的完整和准确。规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。

在进行产品开发明，配置方案的配置项可集中写到properties文件里面，properties文件是属于公共的文件，一个系统可能涉及到几十个开发人员都有可能修改这个文件，上线前保证每个配置项都正确是一件非常重要的事情，线下找开发人员一个一个核对程序代码中的配置项，不仅效率低时间较长，而且最后也不一定正确；但是因为开发人员的疏忽导致错误配置项上了生产环境又经常出现，如：把生产的值配置成了测试的值、某些属性值生产环境本来需要配置为n结果配置成了y等等情况，通过本发明的配置检查方法能够快速的定位到可以产生问题的配置项，从而快速的解决出现的故障。

消息推送是针对web应用开发领域的技术，指以主动方式将信息送达，可以通过套接字接口进行全双工通讯。消息推送的方式可以采用轮询、长连接、flashsocket或websocket等，轮询通过定明发送ajax(asynchronousjavascriptandxml)请求，可在接到请求后返回响应信息对应的系统版本号，长连接可通过嵌入一个iframe，将这个iframe的src属性设置为一个请求或者采用xrh(xmlhttprequest)请求，可发送系统版本号信号，flashsocket通过嵌入socket类的flash程序，调用flash程序提供的socket接口进行通信，websocket是html5提供的一种全双工通讯的技术实现实时通讯。另一种基于http协议进行“推送”实现，可发起http请求轮询，并在请求后返回响应。推送出来的信息可采用文本的格式，可形成邮件内容直接对接到相应的邮箱中。

在检入系统版本号时设置基线，基线的属性包括名称、标识符和日期，基线指配置方案在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素(配置项)的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑(milestone)处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。基线在今后为更进一步的开发作为基础而服务。并且基线只能够通过控制过程来变更。基线为每一个配置项和它的相关实体分配一个标识。基线的分发包括批准一套来自配置管理系统的经过同意的配置项的配置数据和为今后的开发分发基线。在产品的开发周期中，可能是多种基线定义一个发展中的产品。通常包括系统级的需求，系统单元级的设计需求，以及产品开发前期/后期的产品定义，这些被称为“功能基线”、“本地基线”和“产品基线”。

建立基线的好处包括：

1)、重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法；

2)、可追踪性：建立项目工件之间的前后继承关系，目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件；

3)、版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立，作为一个单独分支，新项目将与随后对原始项目(在主要分支上)所进行的变更进行隔离。

在本实施例中，建立配置方案空间分配和版本迁移策略，包括：

1)、私有分支(privatebranch)：私有分支对应的是开发人员的私有开发空间，开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素；

2)、集成分支(integrationbranch)：集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得，即各开发人员必须将私有工作空间中的开发成果归并(merge)到该分支后才能进入下一个开发活动，所有涉及多人协调的开发工作(如集成测试等)都必须工作在这一空间中，该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限；

3)、公共分支(commonbranch)：公共分支对应的是整个软件开发组织的公共空间，各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准，该分支对组织内的全体软件人员开放只读权限。

上述定义的3类分支以及文档库可进行统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作，在变更发生时，应及时做好基线的推进。

配置检查用于对软件修改进行标识、组织和控制的方式，用来协调和控制整个过程，能够通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置检查能够记录软件产品的演化过程，确保软件开发者在软件生命周期中各个环境下都能得到精确的不同版本的产品配置。软件配置检查是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程，是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。

实施例二

如图2所示，示出了本实施例的一种配置检查装置10，包括系统版本检入模块11、提取模块12、比对模块13和输出模块14，所述系统版本检入模块11用于检入系统版本号，该系统版本号对应第一配置方案和第二配置方案，所述提取模块12用于分别提取第一配置方案中的各配置项与第二配置方案中的各配置项，所述比对模块13用于将第一配置方案的配置项与第二配置方案的配置项进行比对，所述输出模块14用于将不同值的配置项在用户界面中进行标注，通过异步消息推送进行检出。

在本实施例中，通过对接代码库检入配置方案，代码库如svn、git，并提供了可视化的用户界面，通过选择需要检入的系统版本号，将每个版本变更的配置项罗列出来，同时对于新增、修改、删除的配置项可分别用不同的底色来标注，高亮突出显示出不同的配置方案，如在测试环境与生产环境在某些配置项上的差别，用来提供给开发、测试、sa来共同核对配置项的正确性，不需要再去代码中一一找开发人员一个个的去核对，也可以很容易发现测试环境配置项与生产环境配置项的差异，从而大大提高检查配置项的效率，也大大减少出错的概率。

一个项目设立之初首先需要制定整个项目的研发计划，之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置检查计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置检查计划在一定程度上是项目成功的重要保证。

配置方案是一个软件程序的基础部分，是用户可以改变的程序运行的方法。配置方案生成的配置文件一般是在程序启动的时候读取，并初始化程序，当然写的好的配置模块也支持在程序运行时重新加载配置文件，并做相关的变化。良好的配置方案应该具体以下功能：配置按可以按块配置，这样就允许不同的块里有相关的配置(程序可能依赖很多外部组件，而外部组件一般都要配置ip)；读取配置项至内存保存。当单机有多个实例时，还有区别公有配置和私有配置初始化配置链表的时候，把两个配置文件都存入配置链表即可。以键值的方式配置，值的类型支持int，string，和list(以表示符号分割，如:names＝lily,john)所有键值存入链表的时候都是string，支持int时候只要做下atoi转换即可，值类型为list时候，读取值的时候增加个index下标即可：getvalue(stringkey,stringblock,intvalue_index)。不重启程序即可重新加载配置文件(此处应判断配置文件是否发生改变)，可通过stat可以储存文件状态(包括文件修改时间，文件大小等)，比对新旧配置文件的stat即可判断配置文件是否发生改变，还可向主进程发送信号量中断主进程，主进程重新加载配置，并完成相关组件连接或状态的重置，参考nginx做法也类似。

处理配置异常包括：

1):没有＝号分隔符的配置行无效；

2):小于3个字符的配置行无效；

3):＝号分隔符之后无字符则配置行无效。

实施例三

本实施例还提供一种计算机系统，如图3所示，该计算机系统包括多个计算机设备20，在实施例二中的配置检查装置的组成部分可分散于不同的计算机设备20中，计算机设备20可以是执行程序的智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。本实施例的计算机设备20至少包括但不限于：可通过系统总线相互通信连接的存储器21、处理器22。需要指出的是，图3仅示出了具有组件21-22的计算机设备20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。

本实施例中，存储器21(即可读存储介质)包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器21可以是计算机设备100的内部存储单元，例如该计算机设备20的硬盘或内存。在另一些实施例中，存储器21也可以是计算机设备20的外部存储设备，例如该计算机设备20上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。当然，存储器21还可以既包括计算机设备20的内部存储单元也包括其外部存储设备。本实施例中，存储器21通常用于存储安装于计算机系统设备的操作系统和各类应用软件。此外，存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器22在一些实施例中可以是中央处理器(centralprocessingunit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制计算机设备20的总体操作。本实施例中，处理器22用于运行存储器21中存储的程序代码或者处理数据。本实施例计算机系统的多个计算机设备20的处理器22共同执行计算机程序时实现实施例一的配置检查方法。

实施例四

本实施例还提供一种计算机可读存储介质，如闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘、服务器、app应用商城等等，其上存储有计算机程序，程序被处理器执行时实现相应功能。本实施例计算机可读存储介质存储实施例二的配置检查装置10，被处理器执行时实现实施例一的配置检查方法。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。