配置更新方法、装置和电子设备

技术领域

本发明涉及计算机技术领域，尤其是涉及一种配置更新方法、装置和电子设备。

背景技术

Tengine是一种基于Nginx的web平台，对于tengine线上集群来说，当用户需要调整监听器的相关配置，比如，需要增加或删除某个监听端口时，通常会触发reload，由于reload会在Nginx架构中创建一个新的worker子进程处理新的用户请求，旧的worker子进程在处理完当前正在处理的请求之后会平滑退出，根据这个过程可知在某些时刻是新老进程共存的，如果在某个时间段内reload的用户过多，频繁reload会导致未退出的worker子进程数目过多，导致对内存的占用会成倍增长，该方式较为浪费Nginx服务器的计算资源和存储资源。

发明内容

有鉴于此，本发明的目的在于提供一种配置更新方法、装置和电子设备，以减少对Nginx服务器的计算资源和存储资源的占用。

本发明提供的一种配置更新方法，方法应用于Nginx服务器，Nginx服务器中设置有共享存储模块；Nginx服务器中运行有至少一个工作子进程；每个工作子进程连接共享存储模块；方法包括：接收针对监听端口的配置更新请求；其中，配置更新请求中携带有监听端口的更新配置信息；将更新配置信息保存至共享存储模块；控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。

进一步的，更新配置信息包括：待增加的监听端口对应的第一配置信息，和/或，待删除的监听端口对应的第二配置信息，和/或，待修改的监听端口对应的第三配置信息。

进一步的，控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口的步骤包括：如果更新配置信息为第一配置信息，控制每个工作子进程从共享存储模块中获取第一配置信息，以增加第一配置信息对应的监听端口；如果更新配置信息为第二配置信息，控制每个工作子进程从共享存储模块中获取第二配置信息，以删除第二配置信息对应的监听端口；如果更新配置信息为第三配置信息，控制每个工作子进程从共享存储模块中获取第三配置信息，以修改第三配置信息对应的监听端口。

进一步的，Nginx服务器中包括第一配置文件和第二配置文件；其中，第一配置文件用于存储启动Nginx服务器时所设置的初始化配置信息；第二配置文件用于存储Nginx服务器运行过程中更新的配置信息。

进一步的，接收针对监听端口的配置更新请求的步骤之后，方法还包括：将更新配置信息保存至第二配置文件。

进一步的，Nginx服务器中运行有主进程；方法还包括：如果接收到针对Nginx服务器的重新启动指令，加载第一配置文件和第二配置文件，通过主进程将第一配置文件中的配置信息和第二配置文件中的配置信息发送至每个工作子进程，以使主进程和每个工作子进程根据接收到的配置信息运行。

进一步的，第二配置文件为json格式的文件。

本发明提供的一种配置更新装置，装置设置于Nginx服务器，Nginx服务器中设置有共享存储模块；Nginx服务器中运行有至少一个工作子进程；每个工作子进程连接共享存储模块；装置包括：接收模块，用于接收针对监听端口的配置更新请求；其中，配置更新请求中携带有监听端口的更新配置信息；保存模块，用于将更新配置信息保存至共享存储模块；更新模块，用于控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。

本发明提供的一种电子设备，包括处理器和存储器，存储器存储有能够被处理器执行的机器可执行指令，处理器执行机器可执行指令以实现上述任一项的配置更新方法。

本发明提供的一种机器可读存储介质，机器可读存储介质存储有机器可执行指令，机器可执行指令在被处理器调用和执行时，机器可执行指令促使处理器实现上述任一项的配置更新方法。

本发明提供的配置更新方法、装置和电子设备，首先接收针对监听端口的配置更新请求，然后将更新配置信息保存至共享存储模块，最后控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。该方式在接收到配置更新请求后，可以直接将其携带的更新配置信息直接保存至共享存储模块，以使每个工作子进程更新监听端口，由于不需要reload过程，从而可以避免因reload过程导致的内存过度占用的问题，节省了Nginx服务器的计算资源和存储资源。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种配置更新方法的流程图；

图2为本发明实施例提供的另一种配置更新方法的流程图；

图3为本发明实施例提供的另一种配置更新方法的流程图；

图4为本发明实施例提供的一种Nginx架构示意图；

图5为本发明实施例提供的另一种Nginx架构示意图；

图6为本发明实施例提供的一种配置更新装置的结构示意图；

图7为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

Tengine是一种基于Nginx的web平台，对于tengine线上集群来说，在运行过程中，当用户需要调整监听器的相关配置，比如，需要增加或删除某个监听端口时，通常可以采用以下两种方式，其中一种方式是触发tengine reload，由于reload Nginx的过程是新创建一个新的进程处理新的用户请求，老的Nginx进程在处理完当前正在处理的请求之后平滑退出，根据这个过程可知在某些时刻是新老进程共存的，频繁reload会导致未退出的worker数目过多，挤占内存，同时还可能引发一些其他的问题，该方式较为浪费Nginx服务器的计算资源和存储资源。

另一种方式中，可以采用配置增量的方式，由master进程向所管理的worker进程发出配置更新指令，worker进程收到该配置更新指令后重读更新后的配置文件，比较两个文件的差异性，并根据差异性新增或者关闭监听端口。该方式需要修改Nginx原有的架构，并修改Nginx核心代码才能实现上述过程，对开发者来说开发成本较高，并且，由于如果修改了Nginx原有的架构，相当于改变了Nginx原有的运行方式，如果Nginx社区版有更新，就无法随社区版的更新而同步更新。另外，由于需要重读配置文件并比较配置文件差异性，因此对Nginx性能存在一定程度的消耗，有可能影响到在这期间用户请求的处理，因此无论对用户还是开发者来说，该方式都是代价较高的方案。

基于此，本发明实施例提供的一种配置更新方法、装置以及系统，该技术可以应用于需要对Nginx监听器进行配置更新的场景中。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种配置更新方法进行详细介绍，方法应用于Nginx服务器，Nginx服务器中设置有共享存储模块；Nginx服务器中运行有至少一个工作子进程；每个工作子进程连接共享存储模块；该Nginx服务器是一种高性能的HTTP(Hyper Text Transfer Protocol，超文本传输协议)和反向代理服务器；上述共享存储模块可以以share memory表示，是一块共享内存存储空间；上述工作子进程可以理解为在Nginx服务器中运行的worker进程，该worker进程的数量可以是一个或多个，是实际处理用户请求的进程；每个worker进程与上述共享存储模块连接；如图1所示，该方法包括如下步骤：

步骤S102，接收针对监听端口的配置更新请求；其中，配置更新请求中携带有监听端口的更新配置信息。

在Nginx服务器中通常包括监听器，该监听器是七层负载均衡中实现负载均衡的主要载体，主要实现形式为操作系统监听一个ip:port，可以理解为网络请求的入口；上述更新配置信息可以理解为对监听端口的配置进行变更的相关配置信息，如，待新增的监听端口的相关配置信息、待删除的监听端口的相关配置信息或待修改的监听端口的相关配置信息等；在实际实现时，当用户需要对监听器的监听端口进行修改、变更时，可以以网络请求的方式发送给Nginx服务器进行处理，具体的，可以通过API接口发出上述配置更新请求，该配置更新请求中通常携带有上述更新配置信息。

步骤S104，将更新配置信息保存至共享存储模块。

在实际实现时，当Nginx服务器接收到上述配置更新请求后，可以将该配置更新请求中携带的更新配置信息直接保存至共享存储模块。

步骤S106，控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。

由于每个工作子进程都与共享存储模块连接，因此，当共享存储模块中保存上述更新配置信息后，可以控制每个工作子进程从该共享存储模块中直接拉取上述更新配置信息，根据该更新配置信息更新监听端口，实现同步，比如，如果该更新配置信息指示需要删除某个指定监听端口，则每个工作子进程都删除该指定监听端口。

上述配置更新方法，首先接收针对监听端口的配置更新请求；然后将更新配置信息保存至共享存储模块，最后控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。该方式在接收到配置更新请求后，可以直接将其携带的更新配置信息直接保存至共享存储模块，以使每个工作子进程更新监听端口，由于不需要reload过程，从而可以避免因reload过程导致的内存过度占用的问题，节省了Nginx服务器的计算资源和存储资源。

本发明实施例还提供了另一种配置更新方法，该方法在上述实施例方法的基础上实现；该方法重点描述控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口的具体过程，具体对应下述步骤S206至步骤S210，如图2所示，该方法包括如下步骤：

步骤S202，接收针对监听端口的配置更新请求；其中，配置更新请求中携带有监听端口的更新配置信息。

上述更新配置信息包括：待增加的监听端口对应的第一配置信息，和/或，待删除的监听端口对应的第二配置信息，和/或，待修改的监听端口对应的第三配置信息。上述待增加的监听端口的数量可以是一个或多个，可以理解为用户想要增加的监听端口；上述待删除的监听端口的数量可以是一个或多个，可以理解为用户想要删除或关闭的监听端口；上述待修改的监听端口的数量也可以是一个或多个，可以理解为用户想要修改的监听端口；在实际实现时，用户根据实际需求可能需要增加新的监听端口，也可能需要删除或修改现有监听端口中的指定监听端口，因此，在配置更新请求中携带的更新配置信息可能包括上述第一配置信息、第二配置信息和第三配置信息中的任意一种或多种。

步骤S204，将更新配置信息保存至共享存储模块。

步骤S206，如果更新配置信息为第一配置信息，控制每个工作子进程从共享存储模块中获取第一配置信息，以增加第一配置信息对应的监听端口。

具体而言，如果共享存储模块中保存的更新配置信息为待增加的监听端口对应的第一配置信息，则每个工作子进程可以从该共享存储模块中直接拉取上述第一配置信息，根据该第一配置信息增加对应的待增加监听端口，以实现同步。

步骤S208，如果更新配置信息为第二配置信息，控制每个工作子进程从共享存储模块中获取第二配置信息，以删除第二配置信息对应的监听端口。

如果共享存储模块中保存的更新配置信息为待删除的监听端口对应的第二配置信息，则每个工作子进程可以从该共享存储模块中直接拉取上述第二配置信息，根据该第二配置信息删除或关闭对应的待删除监听端口，以实现同步。

步骤S210，如果更新配置信息为第三配置信息，控制每个工作子进程从共享存储模块中获取第三配置信息，以修改第三配置信息对应的监听端口。

如果共享存储模块中保存的更新配置信息为待修改的监听端口对应的第三配置信息，则每个工作子进程可以从该共享存储模块中直接拉取上述第三配置信息，根据该第三配置信息修改对应的待修改监听端口，以实现同步。

上述配置更新方法，接收针对监听端口的配置更新请求；将更新配置信息保存至共享存储模块。如果更新配置信息为第一配置信息，控制每个工作子进程从共享存储模块中获取第一配置信息，以增加第一配置信息对应的监听端口。如果更新配置信息为第二配置信息，控制每个工作子进程从共享存储模块中获取第二配置信息，以删除第二配置信息对应的监听端口。如果更新配置信息为第三配置信息，控制每个工作子进程从共享存储模块中获取第三配置信息，以修改第三配置信息对应的监听端口。该方式在接收到配置更新请求后，可以直接将其携带的更新配置信息直接保存至共享存储模块，以使每个工作子进程更新监听端口，由于不需要reload过程，从而可以避免因reload过程导致的内存过度占用的问题，节省了Nginx服务器的计算资源和存储资源。

本发明实施例还提供了另一种配置更新方法，该方法在上述实施例方法的基础上实现；Nginx服务器中包括第一配置文件和第二配置文件；其中，第一配置文件用于存储启动Nginx服务器时所设置的初始化配置信息；第二配置文件用于存储Nginx服务器运行过程中更新的配置信息。第二配置文件为json(javascript object notation，一种轻量级的数据交换格式)格式的文件。在实际实现时，该方案在Nginx服务器中引入dysrv(dynamicserver，动态服务)模块，将原有的一个配置文件nginx.conf拆分成了两个文件，即上述第一配置文件和第二配置文件，该第一配置文件可以是nginx.conf配置文件，但仅用于在启动Nginx进程时进行初始化以及预监听等操作，比如，Nginx运行所需的配置，比如，需要多少个worker，监听器要监听多少端口等；后续对监听器的变更不写入此文件，可以认为，nginx.conf文件在启动后就不会再发生变更；第二配置文件可以是dysrv.json等json格式的文件，当Nginx进程初始化完成后，若用户通过API接口对监听器做了修改操作，则需要将该修改操作同步至dysrv.json文件中。Nginx服务器中运行有主进程；Nginx架构中的主进程可以是master进程，主要作用为监听端口并监控后续worker进程的运行状态，并不实际处理用户请求。如图3所示，该方法包括如下步骤：

步骤S302，接收针对监听端口的配置更新请求；其中，配置更新请求中携带有监听端口的更新配置信息。

步骤S304，将更新配置信息保存至第二配置文件。

在实际实现时，为了避免更新配置信息丢失，当用户通过API接口发送配置更新请求时，通常会将该配置更新请求中携带的更新配置信息保存至第二配置文件中，比如，将该更新配置信息保存至dysrv.json中。

步骤S306，将更新配置信息保存至共享存储模块。

步骤S308，控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。

步骤S310，如果接收到针对Nginx服务器的重新启动指令，加载第一配置文件和第二配置文件，通过主进程将第一配置文件中的配置信息和第二配置文件中的配置信息发送至每个工作子进程，以使主进程和每个工作子进程根据接收到的配置信息运行。

当重启Nginx服务器时，需要同时加载上述第一配置文件和第二配置文件，比如，同时加载nginx.conf以及dysrv.json这两个配置文件，主进程读取两个配置文件中的配置信息，并通知到各个工作子进程，即各个工作子进程从主进程继承上述两个配置文件中的配置信息，主进程和每个工作子进程可以根据接收到的配置信息运行。

上述配置更新方法，接收针对监听端口的配置更新请求；其中，配置更新请求中携带有监听端口的更新配置信息。将更新配置信息保存至第二配置文件。将更新配置信息保存至共享存储模块。控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。如果接收到针对Nginx服务器的重新启动指令，加载第一配置文件和第二配置文件，通过主进程将第一配置文件中的配置信息和第二配置文件中的配置信息发送至每个工作子进程，以使主进程和每个工作子进程根据接收到的配置信息运行。该方式在Nginx服务器中包括第一配置文件和第二配置文件；其中，第一配置文件只存储初始化的信息，其他增量文件存储在第二配置文件中，该方式更便于区分，当写入第二配置文件后，在需要确认是否写入成功时，更方便比对，减少了比对的工作量。

为进一步理解上述实施例，下面提供如图4所示的一种Nginx架构示意图，该示意图为相关技术中采用的Nginx原始架构，图中包括master和所管理的三个worker，该方式中，当Nginx启动时，需要通过neutron将初始化配置信息写入nginx.conf文件中；在Nginx运行过程中，如果用户通过控制台下发针对监听器的变更，也需要通过neutron将变更的配置信息写入该nginx.conf配置文件中，然后reload Nginx进程，该图4中所示的三个worker即为新建的三个worker，master从nginx.conf配置文件中读取配置信息，再下发给所新建的三个worker，即相关技术是先将变更写到配置文件，再把配置文件读到内存中；其中，neutron为网络控制面，负责给Nginx进程下发配置。需要说明的是，原本的旧的worker在处理完对应的请求后会平滑退出，所以，在reload过程中，旧的worker一般不标注出来，体现出来的都是新建的worker；前述提到的双倍或多倍内存占用是一般发生在某个时间段，在该时间段内，旧的worker还没处理完正在处理的请求，同时又有多个用户多次修改配置，此时可能出现多个新建的worker，导致出现双倍或多倍内存占用的情况，等该时间段过去后，如果不出现再次reload的请求，且旧的worker已退出，则理论上就只存在最后新建的worker。

以及图5所示的另一种Nginx架构示意图，该示意图为本方案采用的Nginx架构图，该方案引入了dysrv模块，具体体现为图5中新增了dysrv.json配置文件(对应上述第二配置文件)以及share memory(对应上述共享存储模块)这两个结构；在Nginx运行过程中，当用户调用动态服务模块提供的API接口增加/删除/修改监听器信息时，可以通过该动态服务模块将新增(修改/删除)的配置信息写入到share memory中，同时各个worker进程可以从share memory中，通过拉取配置的操作实现同步，不需要通过master进程读文件，节省了更新配置的时间；但这样会带来一个问题：即增量配置仅仅写入了Nginx运行时的sharememory中，若Nginx需要重启或者reload，则这些存在于内存中的配置有丢失的风险，因此，动态服务模块的用户(即控制面neutron)在调用API接口时，必须同时将该增量文件写入dysrv.json中，并且Nginx下次重启时需要同时加载nginx.conf以及dysrv.json这两个配置文件，这样就实现了用户可通过API接口动态修改监听器内容且在运行过程中无需reload。

下面对本方案涉及的其他相关术语进行解释：Upstream：是Nginx作为反向代理服务器时的一个概念，Nginx在HTTP请求处理过程中只是其中的一环，离消费者(client)近的称为下游(downstream)，离消费者远的称为上游(upstream)，使HTTP请求模块在处理用户请求时可以访问的后端服务器。RS：全称Real Server，是Nginx后端所挂载的真正处理用户请求的服务器。

上述方式利用Nginx能够高效处理网络请求的特性，将监听器的变更以网络请求的方式发送给Nginx处理，Nginx收到监听器变更的请求后处理该请求，并将变更直接存储在共享内存中，相对于图4所示的相关技术通过写入配置文件nginx.conf，然后再reload进程读入内存的方式，省去了reload的过程，避免了reload过程中的内存突增，同时将该变更也写入配置增量文件dysrv.json中，保证了nginx运行内存和配置文件的一致性。且实现该模块的开发方式是利用基于Nginx与lua(一种小巧的脚本语言)的高性能开发平台openresty，研发效率高且性能损耗小。

该方式利用Nginx生态圈提供的openresty平台，可以天然地介入Nginx处理HTTP请求的过程且代价较小，同时lua作为脚本语言开发成本会相对小些，对开发者来说，开发效率高，对Nginx本身来说，因兼容性高所以性能损耗较小。通过引入dysrv模块，并提供一个动态修改监听器的API接口，使得用户能够通过API接口的方式对监听器进行修改，可以减小reload次数，甚至不需要reload，减少了Nginx server块配置的调整对reload次数的影响。该方案避免了频繁reload造成的内存突增的压力，无需reload Nginx进程就可以动态增加/修改/删除监听器。对开发者而言开发成本更低，便于维护，且利用文件和共享内存的形式比信号的形式更可靠。

本发明实施例提供了一种配置更新装置，装置设置于Nginx服务器，Nginx服务器中设置有共享存储模块；Nginx服务器中运行有至少一个工作子进程；每个工作子进程连接共享存储模块；如图6所示，装置包括：接收模块60，用于接收针对监听端口的配置更新请求；其中，配置更新请求中携带有监听端口的更新配置信息；保存模块61，用于将更新配置信息保存至共享存储模块；更新模块62，用于控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。

上述配置更新装置，首先接收针对监听端口的配置更新请求；然后将更新配置信息保存至共享存储模块，最后控制每个工作子进程从共享存储模块中获取更新配置信息，以根据更新配置信息更新监听端口。该装置在接收到配置更新请求后，可以直接将其携带的更新配置信息直接保存至共享存储模块，以使每个工作子进程更新监听端口，由于不需要reload过程，从而可以避免因reload过程导致的内存过度占用的问题，节省了Nginx服务器的计算资源和存储资源。

进一步的，更新配置信息包括：待增加的监听端口对应的第一配置信息，和/或，待删除的监听端口对应的第二配置信息，和/或，待修改的监听端口对应的第三配置信息。

进一步的，更新模块62还用于：如果更新配置信息为第一配置信息，控制每个工作子进程从共享存储模块中获取第一配置信息，以增加第一配置信息对应的监听端口；如果更新配置信息为第二配置信息，控制每个工作子进程从共享存储模块中获取第二配置信息，以删除第二配置信息对应的监听端口；如果更新配置信息为第三配置信息，控制每个工作子进程从共享存储模块中获取第三配置信息，以修改第三配置信息对应的监听端口。

进一步的，Nginx服务器中包括第一配置文件和第二配置文件；其中，第一配置文件用于存储启动Nginx服务器时所设置的初始化配置信息；第二配置文件用于存储Nginx服务器运行过程中更新的配置信息。

进一步的，该装置还用于：将更新配置信息保存至第二配置文件。

进一步的，Nginx服务器中运行有主进程；该装置还用于：如果接收到针对Nginx服务器的重新启动指令，加载第一配置文件和第二配置文件，通过主进程将第一配置文件中的配置信息和第二配置文件中的配置信息发送至每个工作子进程，以使主进程和每个工作子进程根据接收到的配置信息运行。

进一步的，第二配置文件为json格式的文件。

本发明实施例所提供的配置更新装置，其实现原理及产生的技术效果和前述配置更新方法实施例相同，为简要描述，配置更新装置实施例部分未提及之处，可参考前述配置更新方法实施例中相应内容。

本发明实施例还提供了一种电子设备，参见图7所示，该电子设备包括处理器130和存储器131，该存储器131存储有能够被处理器130执行的机器可执行指令，该处理器130执行机器可执行指令以实现上述配置更新方法。

进一步地，图7所示的电子设备还包括总线132和通信接口133，处理器130、通信接口133和存储器131通过总线132连接。

其中，存储器131可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口133(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线132可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器130可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器130中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器130可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processor，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器131，处理器130读取存储器131中的信息，结合其硬件完成前述实施例的方法的步骤。

本发明实施例还提供了一种机器可读存储介质，该机器可读存储介质存储有机器可执行指令，该机器可执行指令在被处理器调用和执行时，该机器可执行指令促使处理器实现上述配置更新方法，具体实现可参见方法实施例，在此不再赘述。

本发明实施例所提供的配置更新方法、装置和电子设备的计算机程序产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行前面方法实施例中的方法，具体实现可参见方法实施例，在此不再赘述。

功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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