CN116149745A - 应用配置数据的管理方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种应用配置数据的管理方法、装置、电子设备及存储介质，该方法包括：响应于接收到的应用配置请求，生成与所述应用配置请求相对应的应用配置数据，将所述应用配置数据存储至配置代码仓库；获取与所述应用配置请求相对应的待配置应用的配置文件读取类型，并确定与所述配置文件读取类型相对应的配置文件读取位置；在所述配置文件读取位置与所述配置代码仓库不一致的情况下，若存在配置数据同步事件，则将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，以在所述待配置应用启动时，从所述配置文件读取位置加载所述应用配置数据。该方式通过配置管理数据库统一管理，降低了出错率，简化了配置管理的复杂度。

Description

应用配置数据的管理方法、装置、电子设备及存储介质

技术领域

本申请涉及通信技术领域，特别涉及一种应用配置数据的管理方法、装置、电子设备及存储介质。

背景技术

随着微服务/容器技术/虚拟化/分布式等技术的快速发展，实际业务中需要部署的应用数量越来越多，技术栈也变得更加丰富。并且，不同类型的应用的配置方式各不相同，由此为统一管理带来了较大的难度。

据统计，线上问题中的70％都与应用配置变更相关。因此，对于应用配置文件的统一管理显得尤为重要。通过配置文件的统一管理，能够减少线上问题的发生率，保障线上系统的稳定运行，方便后续的数据分析、功能调整、逻辑优化等。

在相关技术中，为了实现应用配置文件的统一管理，由研发人员将需要变更的应用配置数据通过邮件方式发送给配置管理人员。配置管理人员根据邮件对配置代码仓库中存储的应用配置数据进行变更处理。

但是，通过邮件方式变更应用配置数据至少存在如下缺陷：邮件交互效率低下，且容易因疏忽等因素而导致数据遗漏、错误等问题。并且，针对不同类型的应用需要由配置管理人员人工确定对应的配置文件管理方式，操作繁琐且不够智能。

发明内容

本申请提供一种应用配置数据的管理方法、装置、电子设备及存储介质，用于解决通过邮件方式变更应用配置数据所导致的数据错误、操作繁琐等问题。

第一方面，本申请提供了一种应用配置数据的管理方法，应用于配置管理数据库，该方法包括：

响应于接收到的应用配置请求，生成与所述应用配置请求相对应的应用配置数据，将所述应用配置数据存储至配置代码仓库；

获取与所述应用配置请求相对应的待配置应用的配置文件读取类型，并确定与所述配置文件读取类型相对应的配置文件读取位置；

在所述配置文件读取位置与所述配置代码仓库不一致的情况下，若存在配置数据同步事件，则将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，以在所述待配置应用启动时，从所述配置文件读取位置加载所述应用配置数据。

第二方面，本申请提供了一种应用配置数据的管理装置，包括：

生成模块，适于响应于接收到的应用配置请求，生成与所述应用配置请求相对应的应用配置数据，将所述应用配置数据存储至配置代码仓库；

确定模块，适于获取与所述应用配置请求相对应的待配置应用的配置文件读取类型，并确定与所述配置文件读取类型相对应的配置文件读取位置；

同步模块，适于在所述配置文件读取位置与所述配置代码仓库不一致的情况下，若存在配置数据同步事件，则将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，以在所述待配置应用启动时，从所述配置文件读取位置加载所述应用配置数据。

第三方面，本申请提供了一种电子设备，该电子设备包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述方法。

第四方面，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器/处理核执行时实现上述方法。

本申请所提供的实施例，在生成与接收到的应用配置请求相对应的应用配置数据，将应用配置数据存储至配置代码仓库之后，还能够获取与应用配置请求相对应的待配置应用的配置文件读取类型，从而确定与配置文件读取类型相对应的配置文件读取位置；并且，在配置文件读取位置与配置代码仓库不一致的情况下，若存在配置数据同步事件，则将应用配置数据从配置代码仓库同步至配置文件读取位置，以使待配置应用启动时，能够从配置文件读取位置加载该应用配置数据。由此可见，该方式通过配置管理数据库统一管理应用配置数据，并且，能够确定待配置应用的配置文件读取类型及其对应的配置文件读取位置，进而在配置文件读取位置与配置代码仓库不一致的情况下，自动将应用配置数据同步至配置文件读取位置，因而能够灵活适配各种类型的应用，实现各类应用的配置数据的统一管理。与传统的邮件方式相比，该方式通过配置管理数据库统一管理，降低了出错率，简化了配置管理的复杂度。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用来提供对本申请的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请，并不构成对本申请的限制。通过参考附图对详细示例实施例进行描述，以上和其他特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为本申请一个实施例提供的一种应用配置数据的管理方法的流程图；

图2为本申请又一实施例提供的一种应用配置数据的管理方法的流程图；

图3示出了本示例中的应用配置数据的管理系统的架构示意图；

图4为本申请实施例提供的一种应用配置数据的管理装置的框图；

图5为本申请实施例提供的一种电子设备的框图。

具体实施方式

为使本领域的技术人员更好地理解本申请的技术方案，以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在不冲突的情况下，本申请各实施例及实施例中的各特征可相互组合。

如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本申请。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本申请的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

根据本申请实施例的应用配置数据的管理方法可以由终端设备或服务器等电子设备执行，终端设备可以为车载设备、用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等；所述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。所述方法具体可以是通过处理器调用存储器中存储的计算机程序的方式来实现。

在相关技术中，研发人员将应用配置变更信息通过邮件方式发送给配置管理人员。配置管理人员根据接收到的邮件中包含的应用配置变更信息，直接向配置代码仓库发送包含应用配置变更信息的操作指令，以变更配置代码仓库中存储的应用配置数据。但是，在上述方式中，配置管理人员接收到邮件之后，需要手动处理邮件，并手动实施配置文件的变更操作，繁琐且容易出错。

为了解决上述问题，图1提供了本申请的一个实施例的一种应用配置数据的管理方法的流程图。该管理方法应用于配置管理数据库。参照图1，该方法包括：

步骤S110：响应于接收到的应用配置请求，生成与应用配置请求相对应的应用配置数据，将应用配置数据存储至配置代码仓库。

本实施例的执行主体为配置管理数据库(简称CMDB)，配置管理数据库可以配置在电子设备中，当配置管理数据库接收到用户发送的应用配置请求后，获取该应用配置请求中包含的应用配置项，根据获取到的应用配置项生成对应的应用配置数据，并将应用配置数据存储至配置代码仓库。其中，应用配置数据用于对待配置应用进行配置操作，具体可实现配置初始化、配置更新等各类操作。

配置代码仓库用于实现应用配置数据的持久化存储。具体实施时，可以同时在配置管理数据库以及配置代码仓库中存储应用配置数据，以使同一份应用配置数据同时存储在配置管理数据库以及配置代码仓库中，从而便于实现配置数据的灾备处理。

步骤S120：获取与应用配置请求相对应的待配置应用的配置文件读取类型，并确定与配置文件读取类型相对应的配置文件读取位置。

其中，待配置应用是指需要通过应用配置请求进行配置的指定应用，具体可根据应用配置请求中包含的应用标识确定待配置应用。不同种类的待配置应用所对应的配置文件读取类型也各不相同。因此，在本实施例中，需要进一步确定待配置应用的配置文件读取类型。

作为一种可选的实施方式，可以直接在应用配置请求中包含读取类型标识信息，读取类型标识信息用于标识一种配置文件读取类型，如此一来，配置管理数据库可以根据该读取类型标识信息确定待配置应用的配置文件读取类型。

作为另一种可选的实施方式，可以预先在配置管理数据库中存储各个应用的应用基础信息，各个应用的应用基础信息中包括各个应用对应的配置文件读取类型，如此一来，配置管理数据库可以在各个应用的应用基础信息中查找到待配置应用的应用基础信息，然后从待配置应用的应用基础信息中获取该待配置应用对应的配置文件读取类型。

其中，待配置应用的配置文件读取类型用于指示待配置应用在启动时需要从何处加载配置文件。相应的，与配置文件读取类型相对应的配置文件读取位置是指：待配置应用在启动时加载配置文件的位置。由于不同类型的应用在启动过程中加载配置文件的位置各不相同，也即不同配置文件读取类型会对应不同的因此，需要确定与配置文件读取类型相对应的配置文件读取位置。

具体实现中，配置文件读取类型和配置文件读取位置之间存在对应关系，可以根据两者之间的对应关系，获取待配置应用的配置文件读取类型对应的配置文件读取位置。具体地，配置文件读取类型和配置文件读取位置之间的对应关系可以为：若所述配置文件读取类型为本地读取类型，则确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库一致；若所述配置文件读取类型为服务器读取类型，则确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库不一致，且所述配置文件读取位置位于所述待配置应用的应用服务器中；若所述配置文件读取类型为源码读取类型，则确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库不一致，且所述配置文件读取位置位于所述待配置应用的源码中。

步骤S130：在配置文件读取位置与配置代码仓库不一致的情况下，若存在配置数据同步事件，则将应用配置数据从配置代码仓库同步至配置文件读取位置，以在待配置应用启动时，从配置文件读取位置加载应用配置数据。

在本步骤中，需要判断配置文件读取位置与配置代码仓库是否一致，若配置文件读取位置位于配置代码仓库中，则说明二者一致，否则，说明二者不一致。在二者不一致的情况下，需要在检测到配置数据同步事件的情况下，将应用配置数据从配置代码仓库中同步至配置文件读取位置，以供待配置应用启动时，从配置文件读取位置加载应用配置数据。

例如，有些待配置应用的配置文件读取位置即为配置代码仓库，针对这些待配置应用，则可以不需要执行本步骤。又如，有些待配置应用的配置文件读取位置为应用服务器或应用源码，针对这些待配置的应用，则需要将应用配置数据从配置代码仓库同步至应用服务器或应用源码，以供待配置应用启动时加载。其中，配置数据同步事件是用于触发应用配置数据的同步操作的，具体可通过多种方式触发该配置数据同步事件。例如，可以根据预先设定的触发时机和/或触发条件触发该配置数据同步事件。其中，触发时机可为接收到应用配置请求后的预设时间触发该配置数据同步事件。或者，触发条件可为检测到预设操作或预设指令时触发，例如，在接收到应用部署系统发送的应用部署通知消息或应用打包通知消息时触发该配置数据同步事件。本发明对配置数据同步事件的具体触发方式不做限定。

在本申请所提供的实施例中，通过配置管理数据库统一管理应用配置数据，并且，能够确定待配置应用的配置文件读取类型及其对应的配置文件读取位置，进而在配置文件读取位置与配置代码仓库不一致的情况下，自动将应用配置数据同步至配置文件读取位置，能够灵活适配各种类型的应用，实现各类应用的配置数据的统一管理。与传统的邮件方式相比，该方式通过配置管理数据库统一管理，降低了出错率，简化了配置管理的复杂度。

参见图2，为本申请提供的另一种应用配置数据的管理方法的流程图。参照图2，该方法可包括如下步骤：

步骤S200：响应于接收到的应用配置请求，生成与应用配置请求相对应的应用配置数据。

具体的，解析该应用配置请求，获取应用配置请求中包含的账号标识信息以及配置对象；判断账号标识信息对应的账号权限是否与配置对象匹配；若是，则生成与应用配置请求相对应的应用配置数据，并将应用配置数据存储至配置管理数据库中。

其中，账号权限包括：对应于项目类型的配置对象的项目权限、对应于应用类型的配置对象的应用权限、对应于文件类型的配置对象的文件权限中的至少一种。

由此可见，在本实施例中，能够根据用户所处的研发部门、项目角色、职位等因素，针对不同用户设置不同账号权限的用户账号，相应的，能够针对不同用户设置不同的权限粒度，便于权限粒度的细分，防止非授权用户恶意篡改应用配置数据，提升应用配置数据的安全性。

步骤S210：将应用配置数据存储至配置代码仓库。

在上一步骤中，已经将应用配置数据存储至配置管理数据库，在本步骤中，进一步将应用配置数据存储至配置代码仓库。其中，配置代码仓库用于实现应用配置数据的持久化存储，具体可以为Gitlab，也可以为Mysql、MongoDb等各类数据库。总之，只要能够实现配置数据的统一管理即可，本申请不限定配置代码仓库的具体类型。

步骤S220：获取与应用配置请求相对应的待配置应用的配置文件读取类型，确定与配置文件读取类型相对应的配置文件读取位置。

具体的，若获取到的与应用配置请求相对应的待配置应用的配置文件读取类型为本地读取类型，确定与配置文件读取类型相对应的配置文件读取位置与配置代码仓库一致。若获取到的与应用配置请求相对应的待配置应用的配置文件读取类型为服务器读取类型，确定与配置文件读取类型相对应的配置文件读取位置与配置代码仓库不一致，且配置文件读取位置位于待配置应用的应用服务器中。若获取到的与应用配置请求相对应的待配置应用的配置文件读取类型为源码读取类型，确定与配置文件读取类型相对应的配置文件读取位置与配置代码仓库不一致，且配置文件读取位置位于待配置应用的源码中。总之，由于不同类型的应用读取配置文件的方式不同，因此，需要根据待配置应用的类型，确定待配置应用的配置文件读取类型，进而确定与配置文件读取类型相对应的配置文件读取位置。

在一种实现方式中，用户在发送应用配置请求时，需要输入读取类型标识信息。相应的，配置管理数据库获取应用配置请求中包含的读取类型标识信息，根据读取类型标识信息中包含的读取位置信息，确定与配置文件读取类型相对应的配置文件读取位置。例如，若配置文件读取类型为服务器读取类型，则需要在读取类型标识信息中进一步包含配置文件在服务器中的存储位置；又如，若配置文件读取类型为源码读取类型，则需要在读取类型标识信息中进一步包含配置文件在源码中的对应位置。

在又一种实现方式中，预先在配置管理数据库中存储各个应用的应用标识及其对应的应用基础信息，其中，应用基础信息中包含应用的配置文件读取类型、配置文件读取地址、应用部署方式等各项信息。相应的，获取应用配置请求中包含的待配置应用的应用标识，根据预先配置的应用基础信息确定与该应用标识相对应的配置文件读取类型以及与该配置文件读取类型相对应的配置文件读取位置。

步骤S230：判断配置文件读取位置与配置代码仓库是否一致。

具体的，若配置文件读取位置位于配置代码仓库中，则说明二者一致；反之，则说明二者不一致。

步骤S240：在配置文件读取位置与配置代码仓库不一致的情况下，将应用配置数据从配置代码仓库同步至配置文件读取位置。

在一种实现方式中，在配置文件读取位置与配置代码仓库不一致的情况下，若存在配置数据同步事件，则将应用配置数据从配置代码仓库同步至配置文件读取位置，以在待配置应用启动时，从配置文件读取位置加载应用配置数据。

其中，配置文件读取位置与配置代码仓库不一致的情况主要包括两种，下面分别加以介绍：

(1)针对配置文件读取位置位于待配置应用的应用服务器中的情况：

由于配置文件读取位置位于待配置应用的应用服务器中，因此，待配置应用需要在应用部署过程中，从应用服务器中读取配置文件。配置数据同步事件是指接收到的应用部署系统发送的应用部署通知消息；相应的，在本步骤中，需要根据待配置应用所对应的应用服务器，将应用配置数据从配置代码仓库同步至应用服务器中对应于配置文件读取位置的区域。

在一种实现方式中，通过以下方式进行应用配置数据的同步：

首先，获取应用部署通知消息中包含的待部署应用的应用标识。其中，应用部署系统用于实现应用的打包、编译、部署等操作。在本实施例中，应用部署系统可以为持续集成(Continuous Integration)/持续交付(Continuous Delivery)、持续部署(ContinuousDeployment)系统，简称CICD系统。应用部署通知消息用于通知配置管理数据库即将执行待配置应用的部署操作。由此可见，应用部署通知消息的发送时机为：在应用打包操作执行完毕之后，且在应用部署操作执行之前。

然后，根据待部署应用的应用标识，从配置代码仓库中获取待同步的应用配置数据。由于配置代码仓库中存储有各个应用的配置数据，因此，需要根据应用标识，筛选待同步的应用配置数据。由此可见，待同步的应用配置数据是指：与待部署应用的应用标识相匹配的应用所对应的配置数据。另外，进一步的，由于待同步的应用配置数据可能包含多条配置数据记录，因此，可以在步骤S230中判断出配置文件读取位置与配置代码仓库不一致时，针对本次存储至配置代码仓库中的配置数据记录设置未同步标识，相应的，在获取待同步的应用配置数据时，从与待部署应用的应用标识相匹配的应用所对应的配置数据中，筛选设置有未同步标识的配置数据记录作为上述待同步的应用配置数据。

最后，将待同步的应用配置数据发送给代理模块，以由代理模块将待同步的应用配置数据同步至应用服务器中的配置文件读取位置。其中，代理模块既可以为一个单独的服务器，也可以为设置在应用服务器内部的虚拟模块或实体设备，总之，代理模块旨在实现针对应用服务器的操作。另外，在同步成功之后，向应用部署系统返回同步成功消息，以供应用部署系统响应于同步成功消息执行应用部署操作。

通过该方式，由于已经预先针对应用部署过程中需要访问的应用服务器中存储的配置文件进行了更新，因此，能够确保应用部署操作的可靠执行。

由此可见，在待部署应用的配置文件读取类型为服务器读取类型的情况下，本实施例在应用部署系统执行应用部署操作之前，更新应用服务器中存储的配置文件。该更新时机的设定是基于该类待部署应用的配置文件加载特点决定的。通过该方式，能够确保应用部署操作的正确性。若更新时机过早，可能导致在应用服务器中的配置文件更新之后，应用部署情况又发生了变更；若更新时机过晚，将导致应用部署操作所依赖的配置文件尚未更新，从而影响部署操作的可靠性。

另外，在实际情况中，可以预先针对应用部署系统进行配置，以使应用部署系统在判断出待部署应用的配置文件读取类型为服务器读取类型的情况下，向配置管理数据库发送应用部署通知消息。在该方式中，由应用部署系统判断待部署应用的配置文件读取类型，并在对应的更新时机触发对应的通知消息。

在其他实现方式中，为了简化应用部署系统的执行逻辑，降低应用部署系统的负担，可以将判断待部署应用的配置文件读取类型的操作由配置管理数据库实现。在该实现方式中，无论待配置应用为何种类型，应用部署系统都会在待部署应用执行部署操作之前，触发应用部署通知消息。相应的，配置管理数据库在获取应用部署通知消息中包含的部署服务器标识以及待部署应用的应用标识之后，进一步根据待部署应用的应用标识，判断待部署应用的配置文件读取类型是否为服务器读取类型。相应的，在判断出待部署应用的配置文件读取类型为服务器读取类型的情况下，从配置代码仓库中获取待同步的应用配置数据。若判断出待部署应用的配置文件读取类型不是服务器读取类型，则不执行后续操作。

总之，在配置文件读取位置位于待配置应用的应用服务器中的情况下，配置数据同步事件是指接收到应用部署系统发送的应用部署通知消息。

(2)针对配置文件读取位置位于待配置应用的源码中的情况：

由于配置文件读取位置位于待配置应用的源码中，因此，待配置应用需要在应用启动过程中，从应用源码中读取配置文件。配置数据同步事件是指接收到的应用部署系统发送的应用打包通知消息；相应的，在本步骤中，需要将应用配置数据从配置代码仓库同步至源码中。

在一种实现方式中，通过以下方式进行应用配置数据的同步：

首先，获取应用打包通知消息中包含的待部署应用的应用标识。应用打包通知消息用于通知配置管理数据库即将执行待配置应用的打包操作。由此可见，应用打包通知消息的发送时机为：在应用打包操作执行之前。

然后，根据待部署应用的应用标识，从配置代码仓库中获取待同步的应用配置数据。由于配置代码仓库中存储有各个应用的配置数据，因此，需要根据应用标识，筛选待同步的应用配置数据。由此可见，待同步的应用配置数据是指：与待部署应用的应用标识相匹配的应用所对应的配置数据。另外，进一步的，由于待同步的应用配置数据可能包含多条配置数据记录，因此，可以在步骤S230中判断出配置文件读取位置与配置代码仓库不一致时，针对本次存储至配置代码仓库中的配置数据记录设置未同步标识，相应的，在获取待同步的应用配置数据时，从与待部署应用的应用标识相匹配的应用所对应的配置数据中，筛选设置有未同步标识的配置数据记录作为上述待同步的应用配置数据。

最后，根据待同步的应用配置数据修改待配置应用的源码，以将待同步的应用配置数据同步至配置文件读取位置，并向应用部署系统返回源码修改成功消息，以供应用部署系统响应于该源码修改成功消息执行应用打包操作。

通过该方式，由于已经预先针对应用打包过程中需要访问的应用源码中存储的配置文件进行了更新，因此，能够确保应用打包操作的可靠执行。

总之，在配置文件读取位置位于待配置应用的源码中的情况下，配置数据同步事件是指接收到应用部署系统发送的应用打包通知消息。由此可见，在待部署应用的配置文件读取类型为源码读取类型的情况下，本实施例在应用部署系统执行应用打包操作之前，更新应用服务器中存储的配置文件。该更新时机的设定是基于该类待部署应用的配置文件加载特点决定的。通过该方式，能够确保应用打包操作的正确性。若更新时机过早，可能导致在应用服务器中的配置文件更新之后，应用打包情况又发生了变更；若更新时机过晚，将导致应用打包操作所依赖的配置文件尚未更新，从而影响打包操作的可靠性。

另外，在实际情况中，可以预先针对应用部署系统进行配置，以使应用部署系统在判断出待部署应用的配置文件读取类型为源码读取类型的情况下，向配置管理数据库发送应用打包通知消息。在该方式中，由应用部署系统判断待部署应用的配置文件读取类型，并在对应的更新时机触发对应的通知消息。

在其他实现方式中，为了简化应用部署系统的执行逻辑，降低应用部署系统的负担，可以将判断待部署应用的配置文件读取类型的操作由配置管理数据库实现。在该实现方式中，无论待配置应用为何种类型，应用部署系统都会在待部署应用执行打包操作之前，触发应用打包通知消息。相应的，配置管理数据库获取应用打包通知消息中包含的待部署应用的应用标识之后，进一步根据待部署应用的应用标识，判断待部署应用的配置文件读取类型是否为源码读取类型。相应的，在判断出待部署应用的配置文件读取类型为源码读取类型的情况下，从配置代码仓库中获取待同步的应用配置数据。

由此可见，在上述两种实现方式中，在从配置代码仓库中获取待同步的应用配置数据时，都可以从配置代码仓库中查询与应用标识相对应的应用配置数据，若查询到的应用配置数据设置有未同步标记，将查询到的应用配置数据确定为待同步的应用配置数据。并且，在将查询到的应用配置数据确定为待同步的应用配置数据之后，进一步将配置代码仓库中与待同步的应用配置数据对应的未同步标记删除。通过该方式，能够确保配置文件的可靠同步。

另外，为了避免因配置数据更新时出现异常所导致的错误，在待配置应用启动时，从配置文件读取位置加载应用配置数据时，进一步判断配置管理数据库中存储的应用配置数据与配置代码仓库中存储的应用配置数据是否一致；若一致，则从配置文件读取位置加载所述应用配置数据；若不一致，则生成配置异常提示消息。若应用配置数据在更新过程中出现异常，则会导致配置管理数据库中存储的应用配置数据与配置代码仓库中存储的应用配置数据不一致，由此可见，通过在应用启动环节增加判断步骤，能够避免错误，提升系统稳定性。

综上可知，在本实施例中，通过配置管理数据库统一管理应用配置数据，并且，能够确定待配置应用的配置文件读取类型及其对应的配置文件读取位置，进而在配置文件读取位置与配置代码仓库不一致的情况下，自动将应用配置数据同步至配置文件读取位置，因而能够灵活适配各种类型的应用，实现各类应用的配置数据的统一管理。与传统的邮件方式相比，该方式通过配置管理数据库统一管理，降低了出错率，简化了配置管理的复杂度。该方式能够分别针对不同类型的应用选择不同的配置文件更新方式，并且，该方式能够与应用部署系统等外部系统联动，从而提升配置文件管理的全面性，避免各个系统之间不同步所导致的异常问题。

为了便于理解，下面以一个具体示例为例，详细描述本实施例的具体实现细节。

由于传统的基于邮件更新配置文件的方式至少存在以下缺陷：首先，基于邮件的方式缺乏操作规范，通过邮件交互时效太低，需要人工手动添加调整内容，且无规则校验环节，容易出错。另外，配置变更操作的校验规范欠缺，未接入复审机制。并且，操作权限仅能通过Gitlab来限制，权限控制粒度过大，不能从用户角色的角度对权限进行细分。并且，Gitlab只用于实现文件存储，无法对文件中的数据格式内容进行校验，无法避免对应的低级问题。

图3示出了一种应用配置数据的管理系统的架构图。如图3所示，该系统包括：配置管理数据库31、配置代码仓库32、应用服务器33、代理模块34以及应用部署系统35。如图3所示，配置管理数据库31与配置代码仓库32相连，配置管理数据库31通过代理模块34与应用服务器33相连。并且，配置管理数据库31进一步与应用部署系统35相连。

具体的，研发用户通过自身账号登录配置管理数据库31，对指定应用的配置文件进行更新操作。配置管理数据库31接收到研发用户触发的应用配置请求之后，将对应的应用配置数据存储在配置管理数据库中。另外，在应用上线流程中，将配置管理数据库中记录的应用配置更新情况显示给配置管理人员，系统能够自动对比显示出更新前后的差异点，以供配置管理人员实现信息对比校验。在校验通过的情况下，由配置管理人员触发同步指令，从而将对应的应用配置数据同步存储至配置代码仓库中。另外，流程管理系统还可以在应用上线前对配置管理数据库以及配置代码仓库中的应用配置数据进行校验，以判断是否正确。

另外，配置管理数据库会进一步根据待配置应用的配置文件读取类型，判断是否需要将应用配置数据从配置代码仓库同步至配置文件读取位置。并且，在同步过程中，可进一步根据待配置应用的种类，灵活选择不同的同步方式。

其中，待配置应用的配置文件读取类型包括以下三种：

第一种配置文件读取类型为本地读取类型，即：应用直接从Gitlab等配置代码仓库中读取，该类应用主要包括使用springcloud实现的java应用。针对该类应用，处理逻辑如下：用户提交配置文件，管理员确认配置后提交。配置管理数据库直接将内容写入到Gitlab中，Gitlab中会存储对应的配置文件。在应用启动的时候直接读取Gitlab中的数据。

第二种配置文件读取类型为服务器读取类型，即：应用读取的配置文件放在服务器对应的目录下，该类型的应用包括：使用springboot或者python应用实现的java应用。针对该类应用，处理逻辑如下：用户在CMDB上提交配置数据，需要填写配置文件在服务器上的位置，管理员确认配置后提交。配置管理数据库直接将内容写入到Gitlab中。在应用部署过程中，应用部署系统会通知CMDB应用对应的部署服务器，通过代理模块写入对应的配置。在应用启动的时候，可以读取对应路径下的配置。例如，CMDB接收到请求服务器IP地址后，会将配置文件传递给代理模块，代理模块会根据接收的数据以及应用的部署方式，将配置文件写入对应的路径。其中，应用的部署方式可以进一步划分为如下两种类型：一种为直接部署在服务器(如物理机或虚拟机)中，另一种为直接部署在容器中。对于不同的部署方式，代理模块都可以直接操作，只是操作方式存在差异。例如，若应用直接部署在服务器上，则代理模块在系统层面进行操作，通过触发系统操作命令的方式，将应用配置数据从配置代码仓库同步至应用服务器。又如，若应用部署在容器中，则代理模块借助于容器操作命令，执行文件写入、更新等操作，以应用配置数据从配置代码仓库同步至应用服务器所包含的容器中。

第三种配置文件读取类型为源码读取类型，即：应用读取的配置文件放在源代码中，比如Golang应用，R语言等。其中，配置文件放在源代码中的方式又进一步包括如下两种：一种方式为打包后放在jar包中，如Java应用；另一种为直接放在二进制文件中，如通过其他语言编写的应用。针对该类应用，处理逻辑如下：用户提交配置，需要填写对应的代码根目录下的位置。管理员确认配置后提交。在应用打包前，会通知CMDB让其拉取指定应用的对应配置，并写入对应的代码编译分支中，这样打包后，内部使用的配置就是替换后的文件。在应用启动的时候，可以读取对应的配置。例如，CICD构建前，会通知CMDB。CMDB会将配置文件写入Gitlab中对应编辑分支的源代码中。CICD接收成功结果后，可以直接打包，配置文件就会写入。

综上可知，该示例至少能够实现如下有益效果：

首先，配置文件的管理，统一的操作页面在CMDB中，统一的配置存储在Gitlab中，整个过程更加规范。其次，权限控制更加灵活：配置管理由研发人员处理，对应的配置人员负责审核并提交生效，CMDB可以将权限控制在项目级别/应用级别/配置文件类型等，达到粒度更细。另外，该系统能够与流程系统、应用部署系统等系统对接，增加了对于配置的校验，避免应用上线后，配置未更改等问题,同时简化配置的操作，并提供配置变更记录。并且，所有的配置都有操作记录，便于审计。即使配置调整有问题，可以快速的回滚，将故障的影响范围降低到最低的程度。

可以理解，本申请提及的上述各个方法实施例，在不违背原理逻辑的情况下，均可以彼此相互结合形成结合后的实施例，限于篇幅，本申请不再赘述。本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

此外，本申请还提供了应用配置数据的管理装置、电子设备、计算机可读存储介质，上述均可用来实现本申请提供的任一种应用配置数据的管理方法，相应技术方案和描述和参见方法部分的相应记载，不再赘述。

图4为本申请实施例提供的一种应用配置数据的管理装置40的结构示意图。

参照图4，本申请实施例提供了一种应用配置数据的管理装置40，该应用配置数据的管理装置40包括：

生成模块41，适于响应于接收到的应用配置请求，生成与所述应用配置请求相对应的应用配置数据，将所述应用配置数据存储至配置代码仓库；

确定模块42，适于获取与所述应用配置请求相对应的待配置应用的配置文件读取类型，并确定与所述配置文件读取类型相对应的配置文件读取位置；

同步模块43，适于在所述配置文件读取位置与所述配置代码仓库不一致的情况下，若存在配置数据同步事件，则将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，以在所述待配置应用启动时，从所述配置文件读取位置加载所述应用配置数据。

可选的，所述确定模块42在确定与所述配置文件读取类型相对应的配置文件读取位置时，包括以下至少一种：若获取到的与所述应用配置请求相对应的待配置应用的配置文件读取类型为本地读取类型，确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库一致；若获取到的与所述应用配置请求相对应的待配置应用的配置文件读取类型为服务器读取类型，确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库不一致，且所述配置文件读取位置位于所述待配置应用的应用服务器中；若获取到的与所述应用配置请求相对应的待配置应用的配置文件读取类型为源码读取类型，确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库不一致，且所述配置文件读取位置位于所述待配置应用的源码中。

可选的，在所述配置文件读取位置位于所述待配置应用的应用服务器中的情况下，所述配置数据同步事件是指接收到应用部署系统发送的应用部署通知消息，所述同步模块43在将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置时，执行如下步骤：获取所述应用部署通知消息中包含的待部署应用的应用标识；根据所述待部署应用的应用标识，从所述配置代码仓库中获取待同步的应用配置数据；将所述待同步的应用配置数据发送给代理模块，以由所述代理模块将所述待同步的应用配置数据同步至所述配置文件读取位置；向所述应用部署系统返回同步成功消息，以供所述应用部署系统响应于所述同步成功消息执行应用部署操作。

可选的，所述同步模块43还用于：根据所述待部署应用的应用标识，判断所述待部署应用的配置文件读取类型是否为服务器读取类型；在判断出所述待部署应用的配置文件读取类型为服务器读取类型的情况下，从所述配置代码仓库中获取待同步的应用配置数据。

可选的，在所述配置文件读取位置位于所述待配置应用的源码中的情况下，所述配置数据同步事件是指接收到应用部署系统发送的应用打包通知消息，所述同步模块43在将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置时，执行如下步骤：获取所述应用打包通知消息中包含的待部署应用的应用标识；根据所述待部署应用的应用标识，从所述配置代码仓库中获取待同步的应用配置数据；根据所述待同步的应用配置数据修改所述待配置应用的源码，以将所述待同步的应用配置数据同步至所述配置文件读取位置，并向所述应用部署系统返回源码修改成功消息，以供所述应用部署系统响应于所述源码修改成功消息执行应用打包操作。

可选的，所述同步模块43还用于：根据所述待部署应用的应用标识，判断所述待部署应用的配置文件读取类型是否为源码读取类型；在判断出所述待部署应用的配置文件读取类型为源码读取类型的情况下，从所述配置代码仓库中获取待同步的应用配置数据。

可选的，所述同步模块43在从所述配置代码仓库中获取待同步的应用配置数据时，执行如下步骤：从所述配置代码仓库中查询与所述应用标识相对应的应用配置数据，若查询到的应用配置数据设置有未同步标记，将查询到的应用配置数据确定为所述待同步的应用配置数据。可选的，将查询到的应用配置数据确定为所述待同步的应用配置数据之后，同步模块43还用于：在将所述待同步的应用配置数据从所述配置代码仓库同步至所述配置文件读取位置之后，进一步将所述配置代码仓库中与所述应用标识相对应的应用配置数据的未同步标记做删除处理。

可选的，所述确定模块43具体适于：获取所述应用配置请求中包含的读取类型标识信息，根据所述读取类型标识信息中包含的读取位置信息，确定与所述配置文件读取类型相对应的配置文件读取位置；或者，获取所述应用配置请求中包含的待配置应用的应用标识，根据预先配置的应用基础信息确定与所述应用标识相对应的配置文件读取类型以及与所述配置文件读取类型相对应的配置文件读取位置。

可选的，所述生成模块41具体适于：解析所述应用配置请求，获取所述应用配置请求中包含的账号标识信息以及配置对象；判断所述账号标识信息对应的账号权限是否与所述配置对象的对象类型匹配；若是，生成与所述应用配置请求相对应的应用配置数据，并将所述应用配置数据存储至所述配置管理数据库中；其中，所述账号权限包括：对应于项目类型的配置对象的项目权限、对应于应用类型的配置对象的应用权限、对应于文件类型的配置对象的文件权限中的至少一种。

该方式通过配置管理数据库统一管理应用配置数据，并且，能够确定待配置应用的配置文件读取类型及其对应的配置文件读取位置，进而在配置文件读取位置与配置代码仓库不一致的情况下，自动将应用配置数据同步至配置文件读取位置，因而能够灵活适配各种类型的应用，实现各类应用的配置数据的统一管理。与传统的邮件方式相比，该方式通过配置管理数据库统一管理，降低了出错率，简化了配置管理的复杂度。

图5为本申请实施例提供的一种电子设备50的框图。

参照图5，本申请实施例提供了一种电子设备50，该电子设备50包括：至少一个处理器501；至少一个存储器502，以及一个或多个I/O接口503，连接在处理器501与存储器502之间；其中，存储器502存储有可被至少一个处理器501执行的一个或多个计算机程序，一个或多个计算机程序被至少一个处理器501执行上述应用配置数据的管理方法。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器/处理核执行时实现上述的应用配置数据的管理方法。计算机可读存储介质可以是易失性或非易失性计算机可读存储介质。

本申请实施例还提供了一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备的处理器中运行时，所述电子设备中的处理器执行上述应用配置数据的管理方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其

适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读存储介质上，计算机可读存储介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。

如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读程序指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM)、静态随机存取存储器(SRAM)、闪存或其他存储器技术、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读程序指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本申请操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本申请的各个方面。

这里所描述的计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software DevelopmentKit，SDK)等等。

这里参照根据本申请实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本申请的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本申请的范围的情况下，可进行各种形式和细节上的改变。

Claims (14)

1.一种应用配置数据的管理方法，其特征在于，应用于配置管理数据库，该方法包括：

响应于接收到的应用配置请求，生成与所述应用配置请求相对应的应用配置数据，将所述应用配置数据存储至配置代码仓库；

获取与所述应用配置请求相对应的待配置应用的配置文件读取类型，并确定与所述配置文件读取类型相对应的配置文件读取位置；

在所述配置文件读取位置与所述配置代码仓库不一致的情况下，若存在配置数据同步事件，则将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，以在所述待配置应用启动时，从所述配置文件读取位置加载所述应用配置数据。

2.根据权利要求1所述的方法，其特征在于，所述确定与所述配置文件读取类型相对应的配置文件读取位置，包括以下至少一种：

若所述配置文件读取类型为本地读取类型，则确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库一致；

若所述配置文件读取类型为服务器读取类型，则确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库不一致，且所述配置文件读取位置位于所述待配置应用的应用服务器中；

若所述配置文件读取类型为源码读取类型，则确定与所述配置文件读取类型相对应的配置文件读取位置与所述配置代码仓库不一致，且所述配置文件读取位置位于所述待配置应用的源码中。

3.根据权利要求2所述的方法，其特征在于，在所述配置文件读取位置位于所述待配置应用的应用服务器中的情况下，所述配置数据同步事件是指接收到应用部署系统发送的应用部署通知消息，所述将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，包括：

获取所述应用部署通知消息中包含的待部署应用的应用标识；

根据所述待部署应用的应用标识，从所述配置代码仓库中获取待同步的应用配置数据；

将所述待同步的应用配置数据发送给代理模块，以由所述代理模块将所述待同步的应用配置数据同步至所述应用服务器中的配置文件读取位置。

4.根据权利要求3所述的方法，其特征在于，所述获取所述应用部署通知消息中包含的待部署应用的应用标识之后，所述方法还包括：

根据所述待部署应用的应用标识，判断所述待部署应用的配置文件读取类型是否为服务器读取类型；

所述根据所述待部署应用的应用标识，从所述配置代码仓库中获取待同步的应用配置数据，包括：

在判断出所述待部署应用的配置文件读取类型为服务器读取类型的情况下，从所述配置代码仓库中获取待同步的应用配置数据。

5.根据权利要求2所述的方法，其特征在于，在所述配置文件读取位置位于所述待配置应用的源码中的情况下，所述配置数据同步事件是指接收到应用部署系统发送的应用打包通知消息，所述将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，包括：

获取所述应用打包通知消息中包含的待部署应用的应用标识；

根据所述待部署应用的应用标识，从所述配置代码仓库中获取待同步的应用配置数据；

根据所述待同步的应用配置数据修改所述待配置应用的源码，以将所述待同步的应用配置数据同步至所述配置文件读取位置。

6.根据权利要求5所述的方法，其特征在于，所述获取所述应用打包通知消息中包含的待部署应用的应用标识之后，所述方法还包括：

根据所述待部署应用的应用标识，判断所述待部署应用的配置文件读取类型是否为源码读取类型；

所述根据所述待部署应用的应用标识，从所述配置代码仓库中获取待同步的应用配置数据，包括：

在判断出所述待部署应用的配置文件读取类型为源码读取类型的情况下，从所述配置代码仓库中获取待同步的应用配置数据。

7.根据权利要求3-6任一所述的方法，其特征在于，所述从所述配置代码仓库中获取待同步的应用配置数据，包括：

从所述配置代码仓库中查询与所述应用标识相对应的应用配置数据；

若查询到的应用配置数据设置有未同步标记，则将查询到的应用配置数据确定为所述待同步的应用配置数据。

8.根据权利要求7所述的方法，其特征在于，所述将查询到的应用配置数据确定为所述待同步的应用配置数据之后，所述方法还包括：

将所述配置代码仓库中与所述应用标识相对应的应用配置数据对应的未同步标记做删除处理。

9.根据权利要求2所述的方法，其特征在于，所述获取与所述应用配置请求相对应的待配置应用的配置文件读取类型，并确定与所述配置文件读取类型相对应的配置文件读取位置，包括：

获取所述应用配置请求中包含的读取类型标识信息；并根据所述读取类型标识信息中包含的读取位置信息，确定与所述配置文件读取类型相对应的配置文件读取位置；

或者，

获取所述应用配置请求中包含的待配置应用的应用标识，并根据预先配置的应用基础信息确定与所述应用标识相对应的配置文件读取类型以及与所述配置文件读取类型相对应的配置文件读取位置。

10.根据权利要求1所述的方法，其特征在于，所述响应于接收到的应用配置请求，生成与所述应用配置请求相对应的应用配置数据，包括：

解析所述应用配置请求，获取所述应用配置请求中包含的账号标识信息以及配置对象；

若所述账号标识信息对应的账号权限与所述配置对象的对象类型相匹配，则生成与所述应用配置请求相对应的应用配置数据，并将所述应用配置数据存储至所述配置管理数据库中；其中，所述账号权限包括一下任意一种或多种：对应于项目类型的配置对象的项目权限、对应于应用类型的配置对象的应用权限以及对应于文件类型的配置对象的文件权限。

11.根据权利要求10所述的方法，其特征在于，所述在所述待配置应用启动时，从所述配置文件读取位置加载所述应用配置数据，包括：

判断所述配置管理数据库中存储的应用配置数据与所述配置代码仓库中存储的应用配置数据是否一致；

若一致，则从所述配置文件读取位置加载所述应用配置数据；

若不一致，则生成配置异常提示消息。

12.一种应用配置数据的管理装置，其特征在于，包括：

生成模块，适于响应于接收到的应用配置请求，生成与所述应用配置请求相对应的应用配置数据，将所述应用配置数据存储至配置代码仓库；

确定模块，适于获取与所述应用配置请求相对应的待配置应用的配置文件读取类型，并确定与所述配置文件读取类型相对应的配置文件读取位置；

同步模块，适于在所述配置文件读取位置与所述配置代码仓库不一致的情况下，若存在配置数据同步事件，则将所述应用配置数据从所述配置代码仓库同步至所述配置文件读取位置，以在所述待配置应用启动时，从所述配置文件读取位置加载所述应用配置数据。

13.一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-11中任一项所述的方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序在被处理器执行时实现如权利要求1-11中任一项所述的方法。

Images