CN115904537A - 开关管理方法、***、计算机设备和存储介质 - Google Patents

Abstract

本发明提供了一种开关管理方法，方法包括，将软件开发工具包引入客户端，并将客户端的唯一标识配置入软件开发工具包；软件开发工具的预设程序执行下列操作：根据唯一标识从服务端获取开关数据，并缓存到内存中；其中，服务端预先根据各个客户端的唯一标识配置各个客户端的开关数据；在接收到客户端的开关数据请求时，判断客户端所需开关数据的开关类型；若开关类型为第一类型时，直接从服务端拉取最新的开关数据至客户端；若开关类型为第二类型时，优先从内存中拉取缓存的开关数据至客户端，提供一SDK包在发布后自动配置开关，实现统一配置管理，同时SDK包有两种获取数据模式，能够最大限度保证客户端的数据实时性。

Description

开关管理方法、***、计算机设备和存储介质

技术领域

本申请涉及开关管理技术领域，特别是涉及一种开关管理方法、***、计算机设备和存储介质。

背景技术

在分布式项目中，随着微服务的盛行以及项目的复杂度增长，各中间件相互配合并发挥优势，导致各种配置在所难免，配置中心也正是在这种背景下诞生。现在市面上的配置中心为了做大做全，支持多种场景，功能越来越复杂。随着***的增长，配置中心的配置项也越来越臃肿，一些开关配置亟需单独放在一个地方进行管理和配置。本专利开关中心，是将以往配置中心的开关配置抽离出来，进行功能和业务上隔离。

当前分布式***基本基于Spring Cloud实现。而大部分项目做配置中心的选型的时候，也会优先选择Spring Cloud Config。使用Spring Cloud Config做配置中心时，存储介质的选择一般按照官网推荐的Git方式，即将配置文件放在Git中，服务端从Git中读取配置文件信息。但Git权限管理粒度太粗，不能做到对目录级别的不可读。每次对一条配置发生增删改查的操作，其带来的影响是整个文件发生变动。如果将来我们需要对某条配置做灰度发布，基于Git来做是比较麻烦的。当然Spring Cloud Config也支持数据库这种存储介质，但是因为数据库没有(SVN、Github等)这种Webhook机制，需要依赖刷新机制依赖于消息总线，这就会给***增加复杂度。

也有项目引用Apollo配置中心，但是Apollo配置中心较为复杂，不管是开发人员还是运营人员学习成本较高，上手周期较长。因为Apollo主体是配置中心，其中会糅杂太多项目的配置，在具体使用过程中，操作灵活度会变低。在业务繁杂的使用场景中，很难直观地去单独操作想要的开关。

因此，如何进行开关统一配置和管理成了亟待解决的问题。

发明内容

本发明实施例提供了一种开关管理法、***、计算机设备和存储介质，以至少解决相关技术中开关统一配置和管理的问题。

根据本发明的一个实施例，提供了一种开关管理方法，方法包括：

将软件开发工具包引入客户端，并将客户端的唯一标识配置入软件开发工具包；软件开发工具的预设程序执行下列操作：

根据唯一标识从服务端获取开关数据，并缓存到内存中；

其中，服务端预先根据各个客户端的唯一标识配置各个客户端的开关数据；

在接收到客户端的开关数据请求时，判断客户端所需开关数据的开关类型；

若开关类型为第一类型时，直接从服务端拉取最新的开关数据至客户端；

若开关类型为第二类型时，优先从内存中拉取缓存的开关数据至客户端。

进一步地，根据唯一标识从服务端获取开关数据，并缓存到内存中，包括：

接收服务端的刷新通知；其中，当开关数据被更新时，服务端根据唯一标识发送刷新通知；

根据刷新通知，清空内存中缓存的开关数据；

并将服务端最新的开关数据，缓存到内存中。

进一步地，根据唯一标识从服务端获取开关数据，并缓存到内存中，包括：

获取更新指令；

根据更新指令，基于唯一标识从服务端拉取最新的开关数据，缓存到内存中。

进一步地，更新指令基于预设条件触发；

预设条件包括：检测到客户端重启服务时，或与服务端网络通信发生波动时，或距离上次获取开关数据间隔预定时长。

进一步地，若开关类型为第二类型时，优先从内存中拉取缓存的开关数据，包括：

查找内存中是否缓存有客户端所需的开关数据；

如有，则将开关数据推送至客户端；

如无，则向服务端重新请求获取开关数据。

进一步地，在将软件开发工具包引入客户端，并将客户端的唯一标识配置入软件开发工具包，包括：

请求与服务端建立通信；

通信建立后，根据唯一标识在服务端查找对应的开关数据；

若未查找到，则请求服务端配置客户端的开关数据；

其中，服务端配置完成后，修改开关启用状态，将开关发布并通知到客户端。

进一步地，方法还包括：

当接收到服务端关闭客户端开关的通知时，将内存中缓存的开关数据设置不可调取状态，

在不可调取状态下，接收到客户端的开关数据请求时，返回不可调取状态信息。

根据本发明的另一个实施例，提供了一种开关管理***，***包括：

引入模块：将软件开发工具包引入客户端，并将客户端的唯一标识配置入所述软件开发工具包；

数据获取模块：所述软件开发工具的预设程序根据所述唯一标识从服务端获取开关数据；

内存模块，用于缓存数据获取模块从服务端获取的开关数据；

判断模块：在接收到客户端的开关数据请求时，判断客户端所需开关数据的开关类型；

执行模块：若所述开关类型为第一类型时，直接从所述服务端拉取最新的开关数据至所述客户端；若所述开关类型为第二类型时，优先从所述内存中拉取缓存的开关数据至所述客户端。

根据本发明的又一个实施例，提供了一种计算机设备，包括存储器和处理器，处理器与存储器耦合，其特征在于，存储器中存储有至少一条程序指令或代码，至少一条程序指令或代码由处理器加载并执行，以使计算机设备实现开关管理方法。

根据本发明的又一个实施例，提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，计算机程序被执行时实现开关管理方法中任一项的方法的步骤。

通过本发明，提供一SDK包的预设程序，实现客户端只需要配置唯一标识并修改开关启用状态，自动配置开关，实现统一配置管理，同时SDK包有两种获取数据模式，根据不同情况选择从客户端直接获取或从服务端获取，能够最大限度保证客户端的数据实时性。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本申请实施例提供的一种开关管理方法的架构图；

图2为本申请的应用环境的示意图；

图3为一个实施例中的一种开关管理方法的流程示意图；

图4为一个实施例中一种开关管理方法装置的示意性结构框图；

图5为一个实施例中计算机设备的示意性结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

请参阅图1，为本申请实施例提供的一种开关管理***的一个架构图，其中包括由管理员控制的管理平台，管理平台用于开关管理，具体包括新增开关、删除开关、修改开关、查看开关和开关回滚等。service部分就是本申请中对应的客户端，客户端中包括项目和服务内容，SDK包根据客户端的情况分别选择调用内存中的开关数据或是服务端中的缓存数据。

其中，该开关管理节点和开关缓存节点可以是计算机设备，例如服务器，台式计算机，笔记本电脑等，或者还可以是其他具有存储功能的设备，具体此处不做限定。

需要说明的是，在实际应用过程中，该开关管理***还可以包括更多的设备。例如，还可以包括用户设备，在需要使用该开关管理***时，用户设备会内置处理器通过配置开关数据并发布，并与客户端进行通信。

基于上述图2所示的开关管理***架构，以下对本申请实施例中的方法作详细说明。

本申请提供的开关管理方法，可以全部在服务器一侧执行，也可以全部在客户端一侧执行，还可以由服务器和客户端共同执行。在开关管理方法由服务器和客户端共同执行时，可以应用于如图2所示的应用环境中。其中，客户端102与服务器104通过网络进行通信。

服务器104可以获取到终端102发送的通信请求，且服务器104可以执行根据唯一标识从服务端拉取配置数据缓存到内存中，并交互配置开关数据。

其中，客户端102执行引入软件开发工具包并进行配置，以及与服务端进行通信。

其中，客户端102可以但不限于是各种计算机、笔记本电脑、智能手机、平板电脑和便携式智能设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

请参阅图3，为本申请实施例提供的开关管理方法一个流程示意图，具体包括以下步骤：

S301：将软件开发工具包引入客户端，并将客户端的唯一标识配置入软件开发工具包；具体地，服务端根据各个客户端的id(唯一标识)去配置各个客户端自己的开关，然后需要引入软件开发工具包sdk的客户端，在自己项目代码里也要配置这个id这个id是用来去拉取数据还有服务端根据这个去推送数据给客户端用的；

SDK：全称software development kit，软件开发工具包。通常意义上是指提供了一组统一的API和工具供使用方调用。本专利里的SDK提供了一系列获取和操作开关数据的方法，能够方便使用方便更便利的使用该技术。

其中，加载于客户端的软件开发工具的预设程序执行下列操作：

首先请求与服务端建立通信；通信建立后，根据唯一标识在服务端查找对应的开关数据；若未查找到，则请求服务端配置客户端的开关数据；其中，服务端配置完成后，修改开关启用状态，将开关发布并通知到客户端。

在本实施例中，客户端只需要配置开关的唯一标识，其软件开发工具包，即可识别此开关的唯一标识，并将此标识配置至SDK包，其中客户端引入SDK启动时，SDK首先会跟服务端进行通信，若通信失败，服务会打印失败日志，协助排查。

S302：所述软件开发工具的预设程序执行下列操作：根据所述唯一标识从服务端获取开关数据，并缓存到内存中；

在本实施例中，识别唯一标识后，直接拉取开关的上述数据，如果通信成功SDK则去服务端拉取已配置过的属于本项目和服务的开关数据存储到内存中进行缓存，缓存时间默认为10分钟。

具体的，接收服务端的刷新通知；其中，当开关数据被更新时，服务端根据唯一标识发送刷新通知；根据刷新通知，清空内存中缓存的开关数据；并将服务端最新的开关数据，缓存到内存中。

在本实施例中，此功能命名为“推”，即当服务端新增或者修改或者回滚开关内容，服务端会第一时间发送Feign调用通知到服务端，SDK接收到刷新通知，会清空内存缓存，并重新将服务端新的开关数据存入内存。

Feign：是一种声明式服务调用组件，它在RestTemplate的基础上做了进一步的封装。通过Feign，我们只需要声明一个接口并通过注解进行简单的配置即可实现对HTTP接口的绑定。通过Feign，我们可以像调用本地方法一样来调用远程服务，而完全感觉不到这是在进行远程调用。

具体的，获取更新指令；根据更新指令，基于唯一标识从服务端拉取最新的开关数据，缓存到内存中。

更具体的，更新指令基于预设条件触发；预设条件包括：检测到客户端重启服务时，或与服务端网络通信发生波动时，或距离上次获取开关数据间隔预定时长。

在本实施例中，在本实施例中，此功能命名为“拉”，即客户端可能会有重启服务或者与服务端出现网络波动的情况，导致服务端更新数据时推送失败，没有第一时间获取到服务端的最新数据。SDK中的程序为了保证这种情况下的数据实时性，会每隔十分钟主动去服务端拉取最新的缓存数据并更新到客户端的内存里，供客户端程序使用。

接入方(客户端)使用开关中心的SDK包连接开关中心(服务端)，将服务端获取到的开关数据存入客户端的内存中，并采用“推-拉”两种模式和服务端进行通信，保证数据的实时性。

其中，服务端预先根据各个客户端的唯一标识配置各个客户端的开关数据；

在本实施例中，其中服务端配置的开关类型支持布尔型、数字型、字符型和浮点型四种，并且支持配置单条开关是否缓存到内存。具体的，开关分为***级开关、应用级开关和业务级开关，其中***级开关为项目级粒度，应用级和业务级开关为服务级粒度，开关数据包括开关键、开关名、开关类型和开关策略的配置。

S303：在接收到客户端的开关数据请求时，判断客户端所需开关数据的开关类型；

具体的，判断开关数据的类型为第一类型还是第二类型。

具体的，客户端的程序使用SDK包内的API来使用开关，API会判断当前开关是否是需要缓存的开关类型。如果是不需要缓存，实时性很强的开关，则SDK会直接请求服务端并拉取最新开关数据。如果是需要缓存的开关，则优先查看内存缓存里是否有此开关，有会直接使用，没有则请求服务端重新获取开关数据。

S304：若开关类型为第一类型时，直接从服务端拉取最新的开关数据至客户端；若开关类型为第二类型时，优先从内存中拉取缓存的开关数据至客户端。其中，第一类型即为不需要缓存，实时性很强的开关；第二类型即为可以使用缓存，实时性要求不高的开关；

具体的，查找内存中是否缓存有客户端所需的开关数据；如有，则将开关数据推送至客户端；如无，则向服务端重新请求获取开关数据。

进一步地，根据软件开发工具包内置的应用程序接口内容判断开关是否为需要缓存的开关，如判断结果为否，则调用软件开发工具包的预设程序请求服务端的开关数据；如判断结果为是，则调用软件开发工具包的预设程序，查看内存的缓存中是否存在此开关数据，如存在此开关数据，则直接调用此开关数据，如没有此开关数据则直接请求服务端重新获取开关数据。

当接收到服务端关闭客户端开关的通知时，将内存中缓存的开关数据设置不可调取状态，

在不可调取状态下，接收到客户端的开关数据请求时，返回不可调取状态信息。

本申请通过提供一SDK包的预设程序，实现客户端只需要配置唯一标识并修改开关启用状态，在发布后自动配置开关，实现统一配置管理，同时SDK包有两种获取数据模式，能够最大限度保证客户端的数据实时性。提供内存缓存机制，保证开关数据使用效率。

在一个实施例中，提供了一种开关管理***，如图4所示，包括：

一种开关管理***，包括：

引入模块：将软件开发工具包引入客户端，并将客户端的唯一标识配置入软件开发工具包；

数据获取模块：软件开发工具的预设程序根据唯一标识从服务端获取开关数据；

内存模块，用于缓存数据获取模块从服务端获取的开关数据；

判断模块：在接收到客户端的开关数据请求时，判断客户端所需开关数据的开关类型；

执行模块：若开关类型为第一类型时，直接从服务端拉取最新的开关数据至客户端；若开关类型为第二类型时，优先从内存中拉取缓存的开关数据至客户端。关于开关管理***的具体限定可参见上文中对于开关管理方法的限定，在此不再赘述。上述开关管理***中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，本申请实施例提供的计算机设备，可以是服务器，也可以是客户端：如图5所示，为本申请实施例提供的计算机设备的结构示意图。

处理器1701、存储器1702、总线1705、接口1704，处理器1701与存储器1702、接口1704相连，总线1705分别连接处理器1701、存储器1702以及接口1704，接口1704用于接收或者发送数据，处理器1701是单核或多核中央处理单元，或者为特定集成电路，或者为被配置成实施本发明实施例的一个或多个集成电路。存储器1702可以为随机存取存储器(randomaccess memory，RAM)，也可以为非易失性存储器(non-volatile memory)，例如至少一个硬盘存储器。存储器1702用于存储计算机执行指令。具体的，计算机执行指令中可以包括程序1703。

本实施例中，该处理器1701调用程序1703时，可以使图5中的管理服务器执行开关管理方法的操作，具体此处不再赘述。

应理解，本申请上述实施例提供的处理器，可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application-specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

还应理解，本申请中以上实施例中的计算机设备中的处理器的数量可以是一个，也可以是多个，可以根据实际应用场景调整，此处仅仅是示例性说明，并不作限定。本申请实施例中的存储器的数量可以是一个，也可以是多个，可以根据实际应用场景调整，此处仅仅是示例性说明，并不作限定。

还需要说明的是，当计算机设备包括处理器(或处理单元)与存储器时，本申请中的处理器可以是与存储器集成在一起的，也可以是处理器与存储器通过接口连接，可以根据实际应用场景调整，并不作限定。

本申请提供了一种芯片***，该芯片***包括处理器，用于支持计算机设备(客户端或服务器)实现上述方法中所涉及的控制器的功能，例如处理上述方法中所涉及的数据和/或信息。在一种可能的设计中，芯片***还包括存储器，存储器，用于保存必要的程序指令和数据。该芯片***，可以由芯片构成，也可以包括芯片和其他分立器件。

在另一种可能的设计中，当该芯片***为用户设备或接入网等在内的芯片时，芯片包括：处理单元和通信单元，处理单元例如可以是处理器，通信单元例如可以是输入/输出接口、管脚或电路等。该处理单元可执行存储单元存储的计算机执行指令，以使该客户端或管理服务器等在内的芯片执行一种开关管理方法的步骤。可选地，存储单元为芯片内的存储单元，如寄存器、缓存等，存储单元还可以是客户端或管理服务器等内的位于芯片外部的存储单元，如只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)等。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被计算机执行时实现上述任一方法实施例中与客户端或管理服务器的控制器执行的方法流程。对应的，该计算机可以为上述计算机设备(客户端或服务器)。

应理解，本申请以上实施例中的提及的控制器或处理器，可以是中央处理单元(central processing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等中的一种或多种的组合。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

还应理解，本申请中以上实施例中的计算机设备(客户端或服务器)或芯片***等中的处理器或控制器的数量可以是一个，也可以是多个，可以根据实际应用场景调整，此处仅仅是示例性说明，并不作限定。本申请实施例中的存储器的数量可以是一个，也可以是多个，可以根据实际应用场景调整，此处仅仅是示例性说明，并不作限定。

还应理解，本申请实施例中以上实施例中的计算机设备(客户端或服务器)等中提及的存储器或可读存储介质等，可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasablePROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronousDRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambusRAM，DR RAM)。

本领域普通技术人员可以理解实现上述实施例的全部或部分由计算机设备(客户端或服务器)或者处理器执行的步骤可以通过硬件或程序来指令相关的硬件完成。程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，随机接入存储器等。具体地，例如：上述处理单元或处理器可以是中央处理器，通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。上述的这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

当使用软件实现时，上述实施例描述的方法步骤可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络，或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)，或者半导体介质等。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别

类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、***、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他单元。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本申请实施例中所使用的单数形式的“一种”、“”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，在本申请的描述中，除非另有说明，“/”表示前后关联的对象是一种“或”的关系，例如，A/B可以表示A或B；本申请中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A，B可以是单数或者复数。

取决于语境，如在此所使用的词语“如果”或“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

以上，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种开关管理方法，其特征在于，所述方法包括：

将软件开发工具包引入客户端，并将客户端的唯一标识配置入所述软件开发工具包；所述软件开发工具的预设程序执行下列操作：

根据所述唯一标识从服务端获取开关数据，并缓存到内存中；

其中，所述服务端预先根据各个所述客户端的唯一标识配置各个客户端的开关数据；

在接收到客户端的开关数据请求时，判断客户端所需开关数据的开关类型；

若所述开关类型为第一类型时，直接从所述服务端拉取最新的开关数据至所述客户端；

若所述开关类型为第二类型时，优先从所述内存中拉取缓存的开关数据至所述客户端。

2.根据权利要求1所述的方法，其特征在于，根据所述唯一标识从服务端获取开关数据，并缓存到内存中，包括：

接收所述服务端的刷新通知；其中，当所述开关数据被更新时，所述服务端根据所述唯一标识发送刷新通知；

根据所述刷新通知，清空所述内存中缓存的开关数据；

并将所述服务端最新的开关数据，缓存到所述内存中。

3.根据权利要求1所述的方法，其特征在于，根据所述唯一标识从服务端获取开关数据，并缓存到内存中，包括：

获取更新指令；

根据所述更新指令，基于所述唯一标识从所述服务端拉取最新的开关数据，缓存到所述内存中。

4.根据权利要求3所述的方法，其特征在于，所述更新指令基于预设条件触发；

所述预设条件包括：检测到客户端重启服务时，或与所述服务端网络通信发生波动时，或距离上次获取开关数据间隔预定时长。

5.根据权利要求1所述的方法，其特征在于，所述若所述开关类型为第二类型时，优先从所述内存中拉取缓存的开关数据，包括：

查找所述内存中是否缓存有客户端所需的开关数据；

如有，则将所述开关数据推送至所述客户端；

如无，则向所述服务端重新请求获取开关数据。

6.根据权利要求1所述的方法，其特征在于，在将软件开发工具包引入客户端，并将客户端的唯一标识配置入所述软件开发工具包，包括：

请求与所述服务端建立通信；

通信建立后，根据所述唯一标识在所述服务端查找对应的开关数据；

若未查找到，则请求服务端配置所述客户端的开关数据；

其中，所述服务端配置完成后，修改开关启用状态，将开关发布并通知到客户端。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当接收到服务端关闭客户端开关的通知时，将所述内存中缓存的开关数据设置不可调取状态，

在不可调取状态下，接收到客户端的开关数据请求时，返回不可调取状态信息。

8.一种开关管理***，其特征在于，所述***包括：

引入模块：将软件开发工具包引入客户端，并将客户端的唯一标识配置入所述软件开发工具包；

数据获取模块：所述软件开发工具的预设程序根据所述唯一标识从服务端获取开关数据；

内存模块，用于缓存数据获取模块从服务端获取的开关数据；

判断模块：在接收到客户端的开关数据请求时，判断客户端所需开关数据的开关类型；

执行模块：若所述开关类型为第一类型时，直接从所述服务端拉取最新的开关数据至所述客户端；若所述开关类型为第二类型时，优先从所述内存中拉取缓存的开关数据至所述客户端。

9.一种计算机设备，包括存储器和处理器，所述处理器与存储器耦合，其特征在于，所述存储器中存储有至少一条程序指令或代码，所述至少一条程序指令或代码由所述处理器加载并执行，以使所述计算机设备实现权利要求1-7所述的开关管理方法。

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

Images