本公开涉及计算机技术领域，具体而言，涉及一种配置数据管理方法、配置数据管理装置、电子设备以及计算机可读存储介质。
背景技术：
随着电子商务平台业务的发展，线上配置数据的变更也越来越频繁，比如经常要修改配置文案、降级部分功能。任何配置变更产生的误操作都会对线上环境造成一定的影响，严重时会影响用户体验，甚至无法下单、无法支付。
相关技术中，可通过zookeeper的watch机制实现数据变更实时通知的功能，zookeeper所有的配置数据在业务系统启动时会加载到内存中，当数据变更时会更新内存数据，业务系统只从内存读取配置数据。这种方案中，配置数据的任何变更都是全量的，无法做到白名单、客户端、版本等灰度变更；人为操作造成的失误会导致全量生效而影响线上用户，无法做到先验证再全量的操作，因此使得配置系统存在一定风险。
需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
技术实现要素：
本公开的目的在于提供一种配置数据管理方法及装置、电子设备、存储介质，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的配置数据不支持灰度变更的问题。
本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。
根据本公开的一个方面，提供一种配置数据管理方法，包括：接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略；若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据；若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。
在本公开的一种示例性实施例中，在接收针对客户端的配置数据获取请求之前，所述方法还包括：为配置系统中的存储结构中添加灰度节点；根据所述灰度节点为所述客户端内存数据的存储结构增加灰度存储，以生成所述灰度配置数据。
在本公开的一种示例性实施例中，判断所述配置数据获取请求是否为灰度策略包括：通过所述配置数据获取请求中的请求参数判断所述配置数据获取请求是否为所述灰度策略，所述请求参数包括内存白名单数据、客户端数据以及版本数据中的至少一种。
在本公开的一种示例性实施例中，通过所述配置数据获取请求中的请求参数判断所述配置数据获取请求是否为所述灰度策略包括：将所述请求参数中的所述内存白名单数据与客户端的参考白名单数据进行对比；若所述内存白名单数据与所述参考白名单数据匹配，则确定所述配置数据获取请求属于所述灰度策略。
在本公开的一种示例性实施例中，通过所述配置数据获取请求中的请求参数判断所述配置数据获取请求是否为所述灰度策略包括：将所述请求参数中包含的客户端数据与所述客户端的参考数据进行对比；若所述请求参数中包含的客户端数据与所述客户端的参考数据匹配，则确定所述配置数据获取请求属于所述灰度策略。
在本公开的一种示例性实施例中，所述客户端数据包括所述客户端的版本。
在本公开的一种示例性实施例中，所述配置数据获取请求中的请求参数通过过滤器存储至线程缓存中。
在本公开的一种示例性实施例中，所述方法还包括：若未读取到所述灰度配置数据或所述线上配置数据，则返回与所述配置数据获取请求对应的默认配置数据。
根据本公开的一个方面，提供一种配置数据管理装置，包括：请求判断模块，用于接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略；灰度配置模块，用于若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据；线上配置模块，用于若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。
根据本公开的一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的配置数据管理方法。
根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的配置数据管理方法。
本公开示例性实施例中提供的一种配置数据管理方法、配置数据管理装置、电子设备以及计算机可读存储介质中，一方面，通过判断配置数据获取请求是否为灰度策略，确定返回灰度配置数据或线上配置数据，能够使配置数据支持灰度变更；另一方面，通过判断是否为灰度策略返回对应的配置数据，避免了修改配置数据时全量生效的问题，避免了对线上用户的影响，提高了配置系统安全性，同时提高了用户体验。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1示意性示出本公开示例性实施例中用于实现配置数据管理的系统架构图；
图2示意性示出本公开示例性实施例中一种配置数据管理方法示意图；
图3示意性示出本公开示例性实施例中配置变更的系统结构图；
图4示意性示出本公开示例性实施例中配置系统存储结构示意图；
图5示意性示出本公开示例性实施例中获取配置数据的具体流程图；
图6示意性示出本公开示例性实施例中初始化配置数据的具体流程图；
图7示意性示出本公开示例性实施例中变更配置数据的具体流程图；
图8示意性示出本公开示例性实施例中一种配置数据管理装置的框图；
图9示意性示出本公开示例性实施例中一种电子设备的框图；
图10示意性示出本公开示例性实施例中一种程序产品。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
本示例实施方式中首先提供了一种用于实现配置数据管理方法的系统架构，可以应用于为客户端生成配置数据的应用场景。参考图1所示，该系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送请求指令等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如图片处理应用、购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。
终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所发送的配置数据获取请求进行处理的后台管理服务器(仅为示例)。并可将处理结果(例如匹配结果等)反馈给终端设备。
需要说明的是，本申请实施例所提供的配置数据管理方法一般由服务器105执行，相应地，配置数据管理装置一般设置于终端设备101中。
基于上述系统架构100，本示例中提供了一种配置数据管理方法，参考图2所示，该配置数据管理方法可以包括以下步骤：
在步骤s210中，接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略；
在步骤s220中，若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据；
在步骤s230中，若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。
在本示例性实施例中提供的配置数据管理方法中，一方面，通过判断配置数据获取请求是否为灰度策略，确定返回灰度配置数据或线上配置数据，能够使配置数据支持灰度变更；另一方面，通过判断是否为灰度策略返回对应的配置数据，避免了修改配置数据时全量生效的问题，避免了对线上用户的影响，提高了配置系统安全性，同时提高了用户体验。
接下来，结合附图对本示例性实施例中的配置数据管理方法的具体步骤进行进一步解释说明。
在步骤s210中，接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略。
本示例性实施例中，客户端指的是与服务器相对应，为用户提供本地服务的应用程序。参考图3所示，该系统主要包括soa(service-orientedarchitecture，面向服务的体系结构)、客户端内存数据以及配置系统。其中，面向服务的体系结构(soa)是一个组件模型，它将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来。客户端内存数据指的是客户端中内存数据的存储结构。
本示例性实施例中，可通过feature、consul、etcd、eureka、zookeeper等开源配置系统实现针对客户端的配置功能。其中，eureka使用时需要显式配置健康检查支持；zookeeper、etcd则在失去了和服务进程的连接情况下任务不健康。consul通过wan的gossip协议完成跨数据中心的同步。除了eureka，其他配置系统都能够对外支持kv的存储服务，产品设计中cap理论的取舍zookeeper支持服务器端推送变化，eureka、consul、etcd则都通过长轮询的方式来实现变化的感知。
本示例中，以配置系统为zookeeper配置系统为例进行说明。参考图3所示，该系统主要包括soa、客户端内存数据、zookeeper配置系统以及zookeeper配置系统的watch机制，以通过watch机制检测数据变更。参考图4所示，配置系统中包括线上节点，线上节点包括应用，应用中具体包括线上业务配置和线上开关配置。为了实现灰度发布，对配置系统增加了灰度功能，从而生成了灰度配置数据。具体而言，在线上节点的基础上，为配置系统zookeeper的存储结构中增加灰度节点，例如图4中所示。其中，基于上述增加的灰度节点，可为客户端内存数据的存储结构增加灰度存储，从而生成灰度配置数据。灰度节点中包括应用，应用中具体包括白名单数据、客户端数据以及版本数据等，除此之外还可包括线上业务配置和线上开关配置。
配置数据获取请求中可包括用于描述客户端的请求参数，请求参数包括但不限于内存白名单数据、客户端数据以及版本数据中的至少一种。在得到请求参数之后，可根据请求参数确定配置数据获取请求是否为灰度策略。此处的灰度策略指的是灰度发布，灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。例如，abtest就是一种灰度发布方式，让一部分用户继续用a，一部分用户开始用b，如果用户对b没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到b上面来。通过灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，快速验证新的功能修改，以保证其影响度。
具体而言，可通过配置数据获取请求中的请求参数确定该配置数据获取请求是否为灰度策略。具体可以包括三种方式，例如只通过内存白名单数据判断，或者是只通过客户端数据判断，或者是同时通过内存白名单数据和客户端数据判断。其中，内存白名单数据指的是事先确定的账号pin，即使用客户端的用户账号。客户端数据包括客户端类型以及每个客户端类型对应的版本号的具体数据，例如名称、版本号、标识等等。其中，客户端类型例如可以包括ios、安卓和页面类型h5，版本号指的是应用程序对应的不同版本，例如可包括测试版、稳定版、正式版等等。或者是客户端1安卓版9.2，客户端2的ios版9.2等等。
需要说明的是，可事先通过过滤器将配置数据获取请求中包括的例如内存白名单数据以及客户端数据等请求参数存储在线程缓存中，该线程缓存例如可以为threadlocal，threadlocal为变量在每个线程中都创建了一个副本，那么每个线程可以访问自己内部的副本变量，保证了数据安全。本示例性实施例中，通过将请求参数存储在线程缓存中，可以直接将存储在线程缓存中的请求参数与客户端中存储的参考值进行匹配对比，提高操作效率。需要补充的是，将请求参数存储在线程缓存中的前提条件为，和配置数据获取请求方约定好参数格式，或者是请求方自行实现约定好的一个接口，该接口同样会封装内存白名单数据和客户端数据。
接下来对判断是否为灰度策略进行具体说明。第一种方式中，在使用内存白名单数据判断配置数据获取请求是否为灰度策略时，可将请求参数中的内存白名单数据与客户端的参考白名单数据进行对比；若所述内存白名单数据与所述参考白名单数据匹配，则确定所述配置数据获取请求属于所述灰度策略。客户端的参考白名单数据例如可以为客户端中根据历史数据确定的属于白名单数据的用户账号，例如参考白名单数据可包括账号1、账号2、账号3、账号4等等。请求参数中的内存白名单数据可以与参考白名单数据完全一致，也可不完全一致。针对不同客户端，内存白名单数据均不同。可例如，请求参数中的内存白名单数据包括账号2，由于客户端的参考白名单数据中存在内存白名单数据，则可以认为二者匹配成功，从而可以确定配置数据获取请求属于灰度策略。再例如，请求参数中的内存白名单数据包括账号5，由于客户端的参考白名单数据中并不存在该内存白名单数据，则可以确定配置数据获取请求不属于灰度策略。
第二种方式中，在使用客户端数据判断是否为灰度策略时的具体步骤包括：将所述请求参数中包含的客户端数据与所述客户端的参考数据进行对比；若所述请求参数中包含的客户端数据与所述客户端的参考数据匹配，则确定所述配置数据获取请求属于所述灰度策略。由于并不需要对客户端的所有版本均采用灰度策略，因此本示例中的客户端数据指的是客户端的每个类型的某一个版本，具体是哪个版本可以根据实际需求而确定。举例而言，客户端数据为客户端1安卓版9.2的名称、版本号、标识，客户端的参考数据则为某一个版本的客户端的数据，例如客户端1安卓版9.2对应的名称、版本号、标识等等。接下来，可以将请求参数中包含的客户端1安卓版9.2的客户端数据与客户端1安卓版9.2对应的名称、版本号、标识等进行对比匹配，如果均匹配成功，则可以确定配置数据获取请求属于灰度策略；若客户端数据中的任一个匹配失败，则确定配置数据获取请求不属于灰度策略。
除此之外，还可以采用内存白名单数据结合客户端数据的方式判断配置数据获取请求是否属于灰度策略，具体过程与只采用内存白名单数据以及只采用客户端数据的过程类似，因此此处不作详细描述。
本示例性实施例中对配置系统的存储结构增加了灰度存储，解决业务功能无法部分灰度问题。除此之外，增加了对灰度策略的验证过程，使配置数据支持白名单验证和灰度变更，从而按客户端、版本灰度发布。
在步骤s220中，若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据。
本示例性实施例中，灰度配置数据指的是满足灰度策略的客户端的配置数据，可例如为针对处于内测阶段的客户端的配置数据，灰度配置数据的范围可大于对正式上线的客户端的配置数据范围。本示例中，具体通过为zookeeper配置系统的存储结构中增加灰度节点，并基于增加的灰度节点为客户端内存数据的存储结构增加灰度存储，从而生成灰度配置数据。灰度配置数据可以包括但不限于客户端的名称、版本号、简介、标识、图标，收费情况、截图、灰度发布的时间和数量以及投放对象的用户属性信息等配置参数。在手动变更配置数据时，可以只变更灰度配置数据而不影响其他配置数据。如果配置数据获取请求满足灰度策略，则根据灰度配置数据对客户端进行灰度发布。
通过本示例性实施例中的方法，避免了人工修改配置数据造成误操作后全量生效的问题，避免对线上用户产生影响，从而使得配置数据变更范围可控，使得配置系统更加健全，提高了用户体验。
在步骤s230中，若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。
本示例性实施例中，如果请求参数中的内存白名单数据与客户端的参考白名单数据不匹配，或者是请求参数中的客户端数据与客户端的参考数据不匹配，则可以认为客户端的配置数据获取请求不属于灰度策略。线上配置数据指的是已经上线的客户端对应的配置数据，线上配置数据可以包括但不限于客户端的名称、版本号、简介、标识、图标，收费情况、截图、灰度发布的时间和数量以及投放对象的用户属性信息等配置参数，但是这些配置参数的具体数值可与灰度配置数据不同。如果配置数据获取请求不满足灰度策略，则读取线上配置数据。
需要补充的是，如果未读取到灰度配置数据，也未读取到线上配置数据，则返回与配置数据获取请求对应的默认配置数据。其中，默认配置数据可以根据实际需求事先进行设置，此处不作特殊限定。
通过本示例性实施例中对配置系统的存储结构增加了灰度存储，解决业务功能无法部分灰度变更的问题。除此之外，增加了对灰度策略的验证过程，使其支持白名单验证，从而按客户端、版本灰度发布。另外，避免了人工修改配置数据造成误操作后全量生效的问题，避免对线上用户产生影响，从而使得配置数据变更范围可控，使得配置系统更加健全，提高了用户体验。
图5至图7中示出了管理配置数据的具体流程图，其中图5包括获取配置数据的过程，具体步骤包括：
步骤s500，获取配置数据。步骤s501，读取内存白名单数据、客户端数据以及版本数据等请求参数。步骤s502，根据请求参数作对比判断配置数据获取请求是否为灰度策略。步骤s503，判断配置数据获取请求是否为灰度策略。步骤s504，如果为灰度策略，则返回灰度配置数据。步骤s505，如果不属于灰度策略，则返回线上配置数据。步骤s506，判断是否读到灰度配置数据和线上配置数据。如果读取到，则结束整个过程。步骤s507，如果未读取到灰度配置数据和线上配置数据，则返回默认配置数据。
图6中包括初始化配置数据的过程，具体包括：步骤s610，初始化配置文件。步骤s611，从配置系统zookeeper中读取配置数据。步骤s612，判断是否读取成功。如果读取成功，则执行步骤s613，将配置数据加载至内存。步骤s614，为客户端中内存数据的存储结构增加灰度存储增加灰度数据存储结构。步骤s615，判断加载至内存是否成功。步骤s616，添加数据变更监听。如果读取失败，则执行步骤s617，从本地文件获取配置数据。步骤s618，判断从本地文件读取是否成功。如果成功，则转至步骤s613。如果失败，则转至步骤s619确定启动失败。
除此之外，图7中包括变更配置数据的过程，具体包括：步骤s720，变更配置数据。步骤s721，通过配置系统zookeeper中确定配置数据变更。步骤s722，通知监听者变更。步骤s723，控制内存数据变更。步骤s724，重新监听变更节点。
通过图5至图7中的配置数据管理方法，避免了人工修改配置数据造成误操作后全量生效的问题，避免对线上用户产生影响，从而使得配置数据变更范围可控，使得配置系统更加健全，提高了用户体验。
在本公开的示例性实施例中，还提供了一种配置数据管理装置，参考图8所示，所述装置800包括：
请求判断模块801，用于接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略；
灰度配置模块802，用于若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据；
线上配置模块803，用于若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。
在本公开的一种示例性实施例中，在接收针对客户端的配置数据获取请求之前，所述装置还包括：节点添加模块，用于为配置系统中的存储结构中添加灰度节点；存储结构调整模块，用于根据所述灰度节点为所述客户端内存数据的存储结构增加灰度存储，以生成所述灰度配置数据。
在本公开的一种示例性实施例中，请求判断模块包括：判断控制模块，用于通过所述配置数据获取请求中的请求参数判断所述配置数据获取请求是否为所述灰度策略，所述请求参数包括内存白名单数据、客户端数据以及版本数据中的至少一种。
在本公开的一种示例性实施例中，判断控制模块包括：第一对比模块，用于将所述请求参数中的所述内存白名单数据与客户端的参考白名单数据进行对比；第一确定模块，用于若所述内存白名单数据与所述参考白名单数据匹配，则确定所述配置数据获取请求属于所述灰度策略。
在本公开的一种示例性实施例中，判断控制模块包括：第二对比模块，用于将所述请求参数中包含的客户端数据与所述客户端的参考数据进行对比；第二确定模块，用于若所述请求参数中包含的客户端数据与所述客户端的参考数据匹配，则确定所述配置数据获取请求属于所述灰度策略。
在本公开的一种示例性实施例中，所述客户端数据包括所述客户端的版本。
在本公开的一种示例性实施例中，所述配置数据获取请求中的请求参数通过过滤器存储至线程缓存中。
在本公开的一种示例性实施例中，所述装置还包括：默认读取模块，用于若未读取到所述灰度配置数据或所述线上配置数据，则返回与所述配置数据获取请求对应的默认配置数据。
需要说明的是，上述配置数据管理装置中各模块的具体细节已经在对应的配置数据管理方法中进行了详细描述，因此此处不再赘述。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。
所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。
下面参照图9来描述根据本发明的这种实施方式的电子设备900。图9显示的电子设备900仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
如图9所示，电子设备900以通用计算设备的形式表现。电子设备900的组件可以包括但不限于：上述至少一个处理单元910、上述至少一个存储单元920、连接不同系统组件(包括存储单元920和处理单元910)的总线930。
其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元910执行，使得所述处理单元910执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元910可以执行如图2中所示的步骤。
存储单元920可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)9201和/或高速缓存存储单元9202，还可以进一步包括只读存储单元(rom)9203。
存储单元920还可以包括具有一组(至少一个)程序模块9205的程序/实用工具9204，这样的程序模块9205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
总线930可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
电子设备900也可以与一个或多个外部设备1100(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备900交互的设备通信，和/或与使得该电子设备900能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口950进行。并且，电子设备900还可以通过网络适配器960与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器960通过总线930与电子设备900的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备900使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。
在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施方式的步骤。
参考图10所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品1000，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
此外，上述附图仅是根据本发明示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。
技术特征：
1.一种配置数据管理方法，其特征在于，包括：
接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略；
若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据；
若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。
2.根据权利要求1所述的配置数据管理方法，其特征在于，在接收针对客户端的配置数据获取请求之前，所述方法还包括：
为配置系统中的存储结构中添加灰度节点；
根据所述灰度节点为所述客户端内存数据的存储结构增加灰度存储，以生成所述灰度配置数据。
3.根据权利要求1所述的配置数据管理方法，其特征在于，判断所述配置数据获取请求是否为灰度策略包括：
通过所述配置数据获取请求中的请求参数判断所述配置数据获取请求是否为所述灰度策略，所述请求参数包括内存白名单数据、客户端数据以及版本数据中的至少一种。
4.根据权利要求3所述的配置数据管理方法，其特征在于，通过所述配置数据获取请求中的请求参数判断所述配置数据获取请求是否为所述灰度策略包括：
将所述请求参数中的所述内存白名单数据与客户端的参考白名单数据进行对比；
若所述内存白名单数据与所述参考白名单数据匹配，则确定所述配置数据获取请求属于所述灰度策略。
5.根据权利要求3所述的配置数据管理方法，其特征在于，通过所述配置数据获取请求中的请求参数判断所述配置数据获取请求是否为所述灰度策略包括：
将所述请求参数中包含的客户端数据与所述客户端的参考数据进行对比；
若所述请求参数中包含的客户端数据与所述客户端的参考数据匹配，则确定所述配置数据获取请求属于所述灰度策略。
6.根据权利要求5所述的配置数据管理方法，其特征在于，所述客户端数据包括所述客户端的版本。
7.根据权利要求3所述的配置数据管理方法，其特征在于，所述配置数据获取请求中的请求参数通过过滤器存储至线程缓存中。
8.根据权利要求1所述的配置数据管理方法，其特征在于，所述方法还包括：
若未读取到所述灰度配置数据或所述线上配置数据，则返回与所述配置数据获取请求对应的默认配置数据。
9.一种配置数据管理装置，其特征在于，包括：
请求判断模块，用于接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略；
灰度配置模块，用于若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据；
线上配置模块，用于若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。
10.一种电子设备，其特征在于，包括：
处理器；以及
存储器，用于存储所述处理器的可执行指令；
其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-9任意一项所述的配置数据管理方法。
11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-9任意一项所述的配置数据管理方法。
技术总结
本公开是关于一种配置数据管理方法及装置、电子设备、存储介质，涉及计算机技术领域，该方法包括：接收针对客户端的配置数据获取请求，并判断所述配置数据获取请求是否为灰度策略；若所述配置数据获取请求属于所述灰度策略，则返回与所述配置数据获取请求对应的灰度配置数据；若所述配置数据获取请求属于非灰度策略，则返回与所述配置数据获取请求对应的线上配置数据。本公开能够实现配置数据灰度变更，并且能减少对线上用户的影响。
技术研发人员：叶伟
受保护的技术使用者：北京京东尚科信息技术有限公司;北京京东世纪贸易有限公司
技术研发日：.08.09
技术公布日：.02.21
