一种参数修改方法、装置及分布式平台与流程

本申请涉及数据处理技术领域，尤其涉及一种参数修改方法、装置及系统。

背景技术：

随着业务量和数据处理量的不断增加，银行系统中需要越来越多的服务器来共同工作，有的服务器器用来作为规则引擎，有的服务器用来作为计算引擎，有的服务器作为全局路由。各自完成各自的工作，进而实现整个银行系统有条不紊的进行业务处理。

为了更好的协调和管理服务器间的工作，通常情况下，会将多个服务器构建为分布式平台，将数据存储、数据分析和计算等构建在由多个服务器构成的软件平台，以实现多个服务器间资源共享，并且，能够灵活调度各个服务器，具有高度灵活性。

但是，分布式平台中的各个服务器都需要在分别配置好运行参数后，才能正常工作。而且，在实际工作中，也有可能出现实时调整修改运行参数的情况。由于分布式平台中的服务器数量多，类型多样，从而使得参数的修改过程非常繁琐。

技术实现要素：

有鉴于此，本申请提供了一种参数修改方法、装置和系统，以解决现有技术中对分布式平台中的服务器进行参数修改过程繁琐的问题。

一种参数修改方法，应用于依据zookeeper建立的分布式平台，所述分布式平台包括配置服务器和至少一个应用服务器，所述应用服务器与所述配置服务器通过tcp长连接相连，所述配置服务器中存储有各个应用服务器的所有参数信息，所述方法包括：

配置服务器在检测到参数修改指令时，所述参数修改指令中包括：待修改参数标识、修改类型，确定与所述待修改参数标识对应的待修改参数，对所述待修改参数按照所述修改类型进行修改；

发送参数修改消息给所述待修改参数标识对应的应用服务器，所述参数修改消息包括：所述待修改参数标识和修改类型，所述参数修改消息为所述应用服务器对所述待修改参数标识对应的参数按照所述修改类型进行修改的依据。

优选的，所述待修改参数标识对应的应用服务器包括：设置有所述待修改参数的应用服务器。

优选的，所述待修改参数标识对应的应用服务器还包括：预先设定的与所述待修改参数相关联的关联应用服务器。

优选的，所述配置服务器检测参数修改指令包括：

检测是否接收到通过java或C接口发送的参数修改指令。

优选的，所述检测到的参数修改指令包括：

检测是否接收到通过设置在应用服务器上的客户端发送的参数修改指令。

优选的，所述分布式平台还包括配置客户端，所述检测到的参数修改指令包括：

检测是否接收到配置客户端发送的参数修改指令。

优选的，当所述应用服务器为业务处理服务器时，所述配置服务器检测参数修改指令包括：

检测是否接收所述业务处理服务器通过客户端发送的参数修改指令，所述参数修改指令中包括：待修改参数标识和修改类型，其中所述待修改参数标识：所述业务处理服务器的地址，所述修改类型为：增加；

所述对所述待修改参数标识对应的参数按照所述修改类型进行修改包括：

新增所述业务处理服务器的地址到预设的应用服务器地址列表中；

所述发送参数修改消息给所述待修改参数标识对应的应用服务器包括：

按照预先设定的关联关系，确定与所述业务处理服务器对应的关联应用服务器；

发送参数修改消息给所述关联应用服务器。

优选的，所述方法还包括：

实时检测与业务处理服务器的链接状态；

在检测到所述链接状态为中断时，所述检测参数修改指令包括：

检测是否生成参数修改指令，所述参数修改指令中包括：待修改参数标识和修改类型，其中所述待修改参数标识为：所述断开链接的业务处理服务器的地址，所述修改类型为：删除；

所述对所述待修改参数标识对应的参数按照所述修改类型进行修改包括：

从预设的应用服务器地址列表中删除所述断开链接的业务处理服务器的地址；

所述发送参数修改消息给所述待修改参数标识对应的应用服务器包括：

按照预先设定的关联关系，确定与所述业务处理服务器对应的关联应用服务器；

发送所述参数修改消息给所述关联应用服务器。

优选的，所述与所述业务处理服务器关联的应用服务器为全局路由。

一种参数修改装置，应用于依据zookeeper建立的分布式平台，所述分布式平台包括配置服务器和至少一个应用服务器，所述应用服务器与所述配置服务器通过tcp长连接相连，所述配置服务器中存储有各个应用服务器的所有参数信息，所述装置包括：

参数修改模块，用于配置服务器在检测到参数修改指令时，所述参数修改指令中包括：待修改参数标识、修改类型，确定与所述待修改参数标识对应的待修改参数，对所述待修改参数按照所述修改类型进行修改；

参数修改消息发送模块，用于发送参数修改消息给所述待修改参数标识对应的应用服务器，所述参数修改消息包括：所述待修改参数标识和修改类型，所述参数修改消息为所述应用服务器对所述待修改参数标识对应的参数按照所述修改类型进行修改的依据。

一种分布式平台，依据zookeeper建立，包括：配置服务器和至少一个应用服务器，所述应用服务器与所述配置服务器通过tcp长连接相连，所述配置服务器中存储有各个应用服务器的所有参数信息；

所述配置服务器在检测到参数修改指令时，对所述待修改参数标识对应的参数按照所述修改类型进行修改，所述参数修改指令中包括：待修改参数标识、修改类型，发送参数修改消息给所述待修改参数标识对应的应用服务器，所述参数修改消息包括：所述待修改参数标识和修改类型；

所述应用服务器接收所述参数修改消息，并对所述待修改参数标识按照所述参数修改类型进行修改。

经由上述的技术方案可知，本申请实施例公开的参数修改方法通过配置服务器来实现对所有应用服务器的参数管理和修改，只需要在配置服务器端修改参数，即可实现该参数在对应的应用服务器上被修改。从而无需再对每一服务器分别进行参数调整，简化了参数的修改流程，提升了工作效率。并且，由于参数对应的服务器除了其自身运行的应用服务器外，还包括与该参数相关的应用服务器，而该修改过程同时包含了这两种情况，因此实现了数据在不同应用服务器间的同步，保证了数据的一致性。进一步提升了整个分布式平台工作的准确性和有效性。

附图说明

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

图1为本申请实施例公开的一种分布式平台的结构示意图；

图2为本申请实施例公开的存储参数的树形结构示意图；

图3为本申请实施例公开的一种参数修改方法的流程图；

图4为本申请实施例公开的又一参数修改方法的流程图；

图5为本申请实施例公开的又一参数修改方法的流程图；

图6为本申请实施例公开的一种参数修改装置的结构示意图。

具体实施方式

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

本申请实施例公开了一种应用于分布式平台的参数修改方法。分布式平台依据分布式的，开放源码的分布式应用程序协调服务zookeeper建立，其结构如图1所示，包括：配置服务器101和至少一个应用服务器102。配置服务器101和应用服务器102之间通过tcp(Transmission Control Protocol，传输控制协议)长连接相连。配置服务器101中的存储器存储有所有应用服务器的所有参数信息。

应用服务器包括：后台服务器，例如全局路由、规则引擎等，同样还包括业务处理服务器，例如综合积分账户服务器，综合积分兑换服务器，综合积分报表服务器等。业务处理服务器是提供业务服务的服务器，能够接收用户的服务请求，并对请求进行响应处理，完成业务服务。而后台服务器则是辅助业务处理服务实现服务的服务器，其可以为业务处理服务器分担处理任务，计算、查找等具体的操作，但是其本身无需直接面对用户。

工作人员可以通过分布式平台的java或C接口向配置服务器发送参数修改指令。利用java或C接口发送的参数修改指令可以针对当前正在运行的程序的参数，或者没有运行的程序的参数。

此外，工作人员还可以通过运行在各个应用服务器上的客户端来发送参数修改指令，该参数修改指令仅能对没有运行的程序的参数做出修改，即静态修改。此外，各个客户端也可以通过应用服务器预先设定的规则，在某一时刻或者某一事件发生时自动触发发送修改指令的操作。例如，遇到节假日等情况，某个组件下的某个模块下的某个服务，需要就此节假日做出类似积分累计或兑换的计算规则调整，则到了该节假日，发布此服务的应用服务器上的客户端，可以向配置服务器发送参数修改指令，来进行规则的变更。

除上述通过java或C接口发送修改指令，或配置在应用服务器上的客户端发送修改指令外，还可以通过配置客户端来发送参数修改指令。如图1中所示，配置客户端103是独立于应用服务器和配置服务器之外的工具，通过代码以及脚本命令封装而成，独立部署以及运行，专门用于发送参数修改指令。以减轻接口或者客户端的任务量。并且，使得该操作的实现方式不再局限于接口和客户端。

配置服务器作为所有参数信息的修改接口，能够接收外界发送的参数修改指令，在接收到参数修改指令时，获取指令中的待修改参数标识和修改类型，然后确定与修改参数标识对应的待修改参数，例如，在本地存储的所有参数信息中查找待修改参数标识对应的参数，将该参数按照所述的修改类型进行修改。修改类型包括：删除、更新或者新增。

如果修改类型为删除，则直接删除待修改参数标识对应的参数。

如果修改类型为更新，则在参数修改指令中，还包括更新后的参数值，从而实现将原参数值更新为更新后的参数值。

如果修改类型为新增，如果原来的服务器中就已经存储了和该待修改参数标识对应的参数，则本次的新增意味着再次设置一个相同的参数，则直接查找到该参数，再多增加一条该参数的记录。如果没有这一参数，则参数修改指令中包含的实际是该新增参数的名称和参数值，在此时，将这些内容作为待修改参数的标识。或者，参数修改指令中会包含有与标识对应的参数，再或者，再次与发送参数修改指令的客户端进行通信，提示输入具体的参数等。

以上的操作都是配置服务器在其本地进行的，也就是说，修改的是存在配置服务器上的参数，而并非实际的应用服务器上的参数。为了实现对应用服务器参数的修改，配置服务器给待修改参数标识对应的应用服务器发送参数修改消息，该消息中包含有待修改参数标识和修改类型，以通知该应用服务器，哪个参数发生了什么样的修改，然后，该应用服务器按照该参数修改消息，修改对应的参数，进而完成对参数的修改。

在本实施例中，待修改参数标识对应的应用服务器，其实就是设置有待修改参数标识对应的参数的应用服务器。

除上述示例外，待修改参数标识对应的应用服务器还包括：预先设定的与待修改参数相关联的关联应用服务器。关于关联服务器的介绍如下所述。

在本实施例中，配置服务器上存储有全部的参数信息，具体的，可以按照树形结构，结合各个参数之间的关系进行存储，所有的参数信息可以构建一棵或多棵树。图2为一棵树的示例。其中，组件根节点处的参数，可以应用于组件A，同时应用于组件B，因此，当这一节点处的参数发生变化，相应的组件A和组件B也要发生变化。组件A应用于某一模块根节点，则这个模块根节点也要发生变化。而组件B应用于另一模块根节点，该根节点也发生变化，同时，由该根节点构建的模块A和模块B也要发生参数变化，进一步的，由模块B构建的应用服务器A和应用服务器B也会发生变化。由此可以看出，如果是组件根节点处的这一参数发生了变化，则应用服务器A和应用服务器B都要发生变化。

基于参数间的关系，每个应用服务器都对其需要关注的参数所对应的节点或者自身包含的参数所对应的节点进行监控，一旦这些节点的参数发生变化，就意味着自身也需要进行参数修改，而对某一节点进行监控的应用服务器，即是该节点对应参数相关的关联应用服务器。因为应用服务器可能包含有多个参数，某一参数可以被多个应用服务器进行监控。所以某一参数可能对应多个关联应用服务器。

服务A和服务B分别为运行在应用服务器A和应用服务器B上的应用程序的参数对应的节点。以规则引擎服务器为例。规则引擎服务器C启动后，首先通过TCP长连接与配置服务器相连。然后将配置服务器中自身需要的信息下载到本地缓存，如图1中所示，并且，设置好需要监控的节点，例如服务A，服务器B。如果配置服务器接收到针对服务B的配置参数的修改指令，则会按照步骤S101中所示流程，对配置参数进行修改，在修改后，把参数修改消息通过tcp指令，发送给该参数对应的服务器，即，发送给应用服务器B，以及对该节点进行监控的规则引擎服务器C。应用服务器B利用参数修改消息，修改本地的配置参数。而规则引擎服务器C，利用函数回调，从配置服务器上下载该节点对应的修改后的参数，替换原有的参数，保存在本地缓存中。

由此可以看出，在配置服务器上对某一个参数进行修改后，除了要修改设置有该参数的应用服务器，还需要去修改与该参数有关联的应用服务器。

在前面的实施例中提到过，应用服务器包括后台服务器和业务处理服务器。在本实施例中，业务处理服务器除了通过TCP长连接与配置服务器相连外，还需要将自身的地址信息动态注册到配置服务器，如图1中所示，由配置服务器进行存储，并同步给其他需要存储该地址信息的应用服务器。也就是说，配置服务器中存储的参数信息中同样也包含有服务器的地址信息。配置服务器会实时的检测与业务处理服务器的链接状态，如果业务处理服务器发生宕机，则TCP连接就会断开，相应的，配置服务器会删除该业务处理服务器的地址信息。一旦连接再次建立，再次进行注册，将地址信息发送给配置服务器，使其进行存储。整个过程本质上就是将服务器的地址信息作为参数进行修改的过程，注册相当于新增该地址，而当断开时，则需要删除该地址。

同样的，在地址信息被新增或删除等修改后，需要将修改信息发送给对应的关联服务器，也就是全局路由。从而保证通过全局路由从配置服务器获取到的地址信息是准确的，并且保证用户发送的业务请求能够被准确发送给对应的应用服务器。在本实施例中，地址信息可以存储到预设的应用服务器地址列表中。

在上述情况下，由于在新增业务处理服务器地址的过程中，无需向该业务处理服务器再发送表示地址新增的参数修改消息，所以，只需要将该消息发送给参数对应的关联应用服务器，也就是，全局路由。同理，在配置服务器发现与某一业务处理应用服务器的链接断开时，会删除该业务处理应用服务器对应的地址，但是也无需再通知该业务处理应用服务器，而只需要通知全局路由即可。

由此可见，并不是每一个参数的修改过程都需要变更该参数所在的应用服务器，也可以仅仅修改与该参数有关联的应用服务器。

上述实施例公开的分布式平台中，通过配置服务器来实现对所有应用服务器的参数管理和修改，只需要在配置服务器端修改参数，即可实现该参数在对应的应用服务器上被修改。从而无需再对每一服务器分别进行参数调整，简化了参数的修改流程，提升了工作效率。

并且，由于本实施例中，由于参数对应的服务器除了其自身运行的应用服务器外，还包括与该参数相关的应用服务器，而该修改过程同时包含了这两种情况，因此实现了数据在不同应用服务器间的同步，保证了数据的一致性。进一步提升了整个分布式平台工作的准确性和有效性。

上述实施例是从分布式平台的角度，对方案进行的描述。为了更好的说明配置服务器的工作流程，下面将从配置服务器的角度，对方案再次进行说明。

本申请实施例公开的通过配置服务器来完成参数修改的流程如图3所示，包括：

步骤S301：配置服务器判断是否检测到参数修改指令。

在该参数修改指令中，包含有待修改参数的标识以及对该参数进行修改的类型。

配置服务器检测到的修改指令可以是工作人员通过配置客户端或者接口例如java或C接口发送的。当然，也可以是配置服务器在检测到某些触发条件或者接收到触发指令后，自动生成的。例如上述实施例中所阐述的，在检测到与应用服务器的长连接断开时，自动生成的参数修改指令。

步骤S302：在检测到参数修改指令时，确定所述待修改参数标识对应的待修改参数，对所述待修改参数按照所述修改类型进行修改。

步骤S303：发送参数修改消息给待修改参数标识对应的应用服务器。

应用服务器在接收到参数修改消息后，确定找待修改参数标识对应的参数，然后对其按照修改类型进行修改。最终完成对参数的修改过程。

本实施例中，与待修改参数标识对应的应用服务器包括设置有待修改参数的应用服务器，除此之外，还可以包括：预先设定的与该待修改参数相关联的关联应用服务器。

对于本实施例中的关联服务器来说，如果应用服务器1中包含参数A，而应用服务器2对该参数A通过watcher程序进行监控，如果应用服务器1中包含参数B，而应用服务器3对参数B通过watcher程序进行监控，则可以认定，当参数A被修改时，与待修改参数标识对应的应用服务器包括服务器1和服务器2，服务器2即为预先设定的与待修改参数相关联的关联应用服务器。而当参数B被修改时，与待修改参数标识对应的应用服务器包括服务器1和服务器3，服务器3即为预先设定的与待修改参数相关联的关联应用服务器。

由于参数的类型多样，每一参数的格式和修改方式也会有差别，因此，在具体的修改过程中，也会有不同。下面以其中一种情况为例，对参数修改方法做进一步的阐述。

在分布式平台中，通常包含作为全局路由的应用服务器。该服务器的功能是接收外部的业务处理请求，通过自身存储的业务处理服务器的地址，将业务处理请求转发给对应的业务处理服务器。在本实施例中，其自身存储的业务处理服务器的地址，也作为该应用服务器的参数，存储在了配置服务器中。如果这些地址出现变更，相应的也是通过配置服务器来进行修改，最后再对应的修改到作为全局路由的应用服务器。

修改方式包括两种，增加和删除，在该基础上，具体的增加参数的修改过程如图4所示，包括：

步骤S401：检测是否接收到业务处理服务器通过客户端发送的参数修改指令。

所述参数修改指令中包括：待修改参数标识和修改类型，其中所述待修改参数标识为：所述业务处理服务器的地址，所述修改类型为：增加

在本实施例中，业务处理器在与配置服务器建立连接的时候，就会向配置服务器发送该参数修改指令。每一业务处理服务器上都设置有与配置服务器进行通信连接的客户端，通过该客户端与配置服务器连接，向配置服务器发送请求，或者接收配置服务器的指令或消息。

步骤S402：新增所述业务处理服务器的地址到预设的应用服务器地址列表中。

将该业务服务器的地址作为参数，添加到预设的应用服务器地址列表中。

步骤S403：按照预先设定的关联关系，确定与待修改参数对应的关联应用服务器。

步骤S404：发送参数修改消息给关联应用服务器。

本实施例中的关联应用服务器为全局路由。

通过图4所示流程，完成了参数的新增。与其对应的，参数的删除如图5所示。包括：

步骤S501：实时检测与业务处理服务器的链接状态。

步骤S502：在检测到与某一业务处理服务器的链接状态为断开时，检测是否生成了参数修改指令。

在本实施例中，由于进行链接状态检测是配置服务器本身，因此，其自己能及时获知是否还与业务处理服务器有正常的连接，一旦连接断开，则触发生成参数修改指令的操作。因此，只需检测是否生成了参数修改指令，即可判断是否要执行参数修改过程。

步骤S503：在检测到参数修改指令时，确定待修改参数标识和修改类型。

步骤S504：从预设的应用服务器地址列表中删除所述断开链接的业务处理服务器的地址。

步骤S505：按照预先设定的关联关系，确定与所述业务处理服务器对应的关联应用服务器。

步骤S506：发送所述参数修改消息给所述关联应用服务器。

本实施例中的关联应用服务器为全局路由。

从上述实施例可以看出，该参数修改方法通过配置服务器来实现对所有应用服务器的参数管理和修改，只需要在配置服务器端修改参数，即可实现该参数在对应的应用服务器上被修改。从而无需再对每一服务器分别进行参数调整，简化了参数的修改流程，提升了工作效率。

并且，由于参数对应的服务器除了其自身运行的应用服务器外，还包括与该参数相关的应用服务器，而该修改过程同时包含了这两种情况，因此实现了数据在不同应用服务器间的同步，保证了数据的一致性。进一步提升了整个分布式平台工作的准确性和有效性。

本申请实施例同时公开了一种与上述参数修改方法对应的参数修改装置，其结构如图6所示，所述装置包括：

参数修改模块601，用于在检测到参数修改指令时，对所述待修改参数标识对应的参数按照所述修改类型进行修改，所述参数修改指令中包括：待修改参数标识、修改类型；

参数修改消息发送模块602，用于发送参数修改消息给所述待修改参数标识对应的应用服务器，所述参数修改消息包括：所述待修改参数标识和修改类型，所述参数修改消息为所述应用服务器对所述待修改参数标识对应的参数按照所述修改类型进行修改的依据。

该装置的具体工作过程可参考图3-5对应的方法实施例。在此不再赘述。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。