CN106484602B - 一种配置数据读取方法和装置 - Google Patents

Abstract

本申请提供一种配置数据读取方法和装置，其中方法包括：获取所在服务器的标识；由配置数据库中读取分组数据，所述分组数据用于表示将各服务器进行分组后的服务器组，并根据所述分组数据确定与所述服务器的标识对应的服务器组；由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。本申请提高了配置数据隔离的可靠性。

Description

一种配置数据读取方法和装置

技术领域

本申请涉及计算机技术，特别涉及一种配置数据读取方法和装置。

背景技术

一般互联网应用发布的过程中存在代码验证环节，即先尝试将最新的应用代码发布到集群的部分机器上，进行内部测试验证代码；待验证完毕后再将最新代码发布到其他机器。在验证代码的过程中可能使用到配置数据，配置数据例如可以是应用代码执行中的关键性参数，配置数据存储在配置数据库中，代码所在的服务器可以由配置数据库中读取待验证的应用代码需要的配置数据，来执行代码的验证。而由于上述存在部分服务器执行代码验证的需求，对应的配置数据也需要发布到部分服务器而并非集群全部服务器上，这种区分服务器来发布配置数据的情况可以称为配置数据的隔离。

相关技术中，为了实现配置数据的隔离，可以通过向部分服务器定向发送指令的方式，只向需要发布配置数据的服务器发送指令以指示服务器读取新配置数据，未接收到指令的机器仍然使用老配置。这种方案在大部分情况下工作很好，但是仍然可能出现在新配置刚更新到配置数据库之后，部分服务器有可能由于某些原因(如内存溢出)需要重启，那么这些重启的服务器即使未接收到指令也会读取到最新的配置数据。而这有可能导致这些为在线用户提供服务的服务器展示未被验证的功能，更严重的是有些配置修改可能导致老代码无法工作产生不可预期的结果，直接影响在线用户的体验。

发明内容

有鉴于此，本申请提供一种配置数据读取方法和装置，以提高配置数据隔离的可靠性。

具体地，本申请是通过如下技术方案实现的：

第一方面，提供一种配置数据读取方法，所述方法用于读取配置数据库中的配置数据；所述方法包括：

获取所在服务器的标识；

由所述配置数据库中读取分组数据，所述分组数据用于表示将各服务器进行分组后的服务器组，并根据所述分组数据确定与所述服务器的标识对应的服务器组；

由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。

第二方面，提供一种配置数据读取装置，包括：

标识获取模块，用于获取所在服务器的标识；

分组识别模块，用于由所述配置数据库中读取分组数据，所述分组数据用于表示将各服务器进行分组后的服务器组，并根据所述分组数据确定与所述服务器的标识对应的服务器组；

数据读取模块，用于由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。

本申请提供的配置数据读取方法和装置，通过获取服务器所在的服务器组，并获取该服务器组对应的配置数据作为服务器应用的配置数据，这种方式能够保证读取到的配置数据是该服务器应该使用的配置数据，避免出现配置数据与服务器不对应的情况，从而提高了配置数据隔离的可靠性。

附图说明

图1是本申请一示例性实施例示出的一种应用于互联网应用的测试验证的网络系统；

图2是本申请一示例性实施例示出的一种配置数据读取方法的流程图；

图3是本申请一示例性实施例示出的另一种配置数据读取方法的流程图；

图4是本申请一示例性实施例示出的一种配置数据读取装置的结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

图1示例了一个可以应用于互联网应用的测试验证的网络系统，该系统可以包括服务器集群，图1示例了集群中的三个服务器，包括：服务器A、服务器B和服务器C；该系统还可以包括配置数据库，用于存储配置数据。

结合图1说明配置数据的读取：以互联网应用的测试为例，当一个应用增加了新的功能时，需要对该新功能对应的新应用代码进行验证后才能发布(例如，验证是否出错)。而在验证过程中执行应用代码时，可能使用到配置数据，配置数据可以是在执行应用代码限定的功能时相关的一些关键参数，例如，在应用执行时界面显示“Hello”，或者，设置最高转账限额为3万，那么这些“Hello”、3万都可以称为配置数据，存储在配置数据库中，由新应用代码执行时读取，进而实现代码对应的应用功能。当然，即使在非测试阶段，应用也可以由配置数据库读取配置数据，以实现应用功能。

而在应用测试中，可能会遇到配置数据的隔离，即不同服务器需要读取的配置数据不同。例如，在图1中，假设待验证的新代码设置在服务器A和服务器B，而服务器C上仍然为老代码；当前在配置数据库中，已经存储有新代码要使用的配置数据，例如为“HelloWorld”，这个新的配置数据只需要由新代码执行读取，老代码在执行时仍然读取旧的配置数据“Hello”。那么，本申请的配置数据读取方法，将描述服务器如何读取配置数据，才能保证各个服务器能够准确读取到其所需要的配置数据，不会出现配置数据读取错误(例如，服务器C的老代码读取了新配置数据)，详见下述的方案：

继续参见图1，本申请为了提高配置数据隔离的准确性，在各个服务器中都设置了“配置客户端”，由配置客户端为所在的服务器读取配置数据库中的配置数据，而应用代码只要读取配置客户端读取的配置数据即可。配置客户端执行的配置数据读取方法可以参见图2示例，包括：

201、获取所在服务器的标识；

202、由所述配置数据库中读取分组数据，所述分组数据用于表示将各服务器进行分组后的服务器组，并根据所述分组数据确定与所述服务器的标识对应的服务器组；

203、由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。

本申请实施例中，配置客户端可在读取服务器对应的配置数据后，基于获取到的新的配置数据对服务器上原有的配置数据进行更新，以使得服务器可基于更新后的配置数据进行相应的操作。

在上述图2的流程中，配置客户端读取的应用代码要使用的配置数据，在配置数据库中的存储结构已经与传统方式有所不同，而是对应于本申请的配置数据读取方法，提供了新的配置数据存储结构。因此，为了对上述的配置客户端执行的方法描述更加清楚，首先说明配置数据库中如何存储应用要读取的配置数据。

如下的表1，示例了分组数据：

表1 分组数据

Host_group	Host_list	priority
			beta	[‘host 1’,‘host 2’]	0
prod	[‘host.*’]	1

结合图1，上述的分组数据，可以用于将集群中的各个服务器进行分组。举例如下：假设验证的新应用代码设置在服务器A和服务器B上，并且新应用代码使用的配置数据也做了更改，例如由“Hello”改成“Hello World”，那么新配置数据需要由服务器A和服务器B读取，而服务器C不应读取。据此，可以将服务器A和服务器B分成一组，而服务器C在另一个组中。也就是说，本例子中的分组数据，在为服务器分组时，分组依据可以是：将能够读取同一配置数据的各个服务器划分在同一服务器组中。

在表1中，host_group表示服务器组的组名，例如，beta表示在应用代码发布前需要测试的服务器组，即该组中的服务器上要部署待测试的代码；而prod可以表示生产环境的服务器集群，即应用正常使用时的部署服务器，当然该集群中可以包含beta的服务器，因为测试服务器可以是由集群中选择的部分服务器。

而host_list可以用于表示host_group这个服务器组中包括的成员，即包括哪些服务器，例如表1中的host1、host2。需要说明的是，在表示服务器时，可以用服务器的主机名hostname，例如上述的host2；也可以使用服务器的IP地址等其他能够表示服务器的标识，只要该服务器标识能被配置客户端获取到即可。在本申请后续的例子中，均是以服务器的主机名为例来描述。

有时服务器组中包括的成员的数量可能很多，比如，可能包括上百台的服务器，如果一一指定成员名(例如，host1、host2)，可能容易出错且工作量大，可以采用正则匹配的方式来表示，如表1中的[‘host.*’]就可以表示所有以host开头的服务器都可以分到服务器组prod中。

对于表1中的priority字段，并不是在每次配置数据读取中都使用到，后续在对读取方法描述时再进行说明。此外，表1是以表格的方式描述了分组数据的记录方式，本实施例并不对分组数据的格式进行限制，只要能表述各个服务器组与组成员的对应关系即可。

如下的表2，示例了应用配置数据：

表2 应用配置数据

id	config_name	config_value	Host_group
				1	config Key 1	Hello	prod
2	config Key 2	.....	prod
				3	config Key 1	Hello World	beta

如上表2，应用配置数据是应用代码在执行时使用到的参数，比如，上述的“Hello”、“Hello World”都可以是代码在执行时要使用到的参数。本例子中，可以将对应每一个id的应用配置数据称为配置数据，比如在表2中，对应id＝1的“config Key 1，Hello”为一个配置数据，对应id＝3的“config Key1，Hello World”为另一个配置数据。

本例子中将每个配置数据，都对应关联一个服务器组，即与表1中的服务器组对应，例如，id＝3的配置数据的数据如果要被beta组中的服务器读取，则可以在表2中将该数据项对应beta。应用配置项与服务器组的对应关系，用于表示这个应用配置项中的数据可以被对应的服务器组中的各个服务器成员读取。

在上述介绍表1和表2的基础上，对图2的流程继续说明：

在步骤201中，配置客户端可以获取所在服务器的标识。

例如，客户端可以通过服务器的操作系统提供的接口，获取到服务器的IP地址，hostname等服务器标识。

在得到服务器标识后，配置客户端可以在步骤202中，首先读取配置数据库中的分组数据，由分组数据中得到与服务器标识对应的服务器组。

例如，在分组数据中，各个服务器组的组成员，可以是用服务器标识表示或者某种表达式表示，如表1示例的，可以将[‘host 1’,‘host 2’]称为一个服务器列表项，这个列表项中包括各个组成员。配置客户端可以对比各个服务器列表项，查找包括自己所在的服务器的标识的服务器列表项，将与该服务器列表项对应的服务器组，作为与服务器标识对应的服务器组。比如，如果配置客户端所在的服务器是host3，那么客户端可以得到[‘host.*’]这个服务器列表项包括自己所在的服务器标识，则自己所在服务器属于prod服务器组。

在步骤203中，配置客户端再读取配置数据库中的应用配置数据，读取与在202中得到的服务器组对应的配置数据，该配置数据即客户端所在的服务器上的应用代码需要使用的配置数据。

例如，假设配置客户端确定的服务器组为beta，在表2中，与beta对应的配置数据为“config Key 1，Hello World”，包括应用代码执行中使用的参数Hello World。

由上述例子可以看到，如果要将新的配置数据发布到集群中的部分服务器上，只要在配置数据库进行设置，比如，将上述的待发布至的部分服务器组成一个新的服务器组，并将新配置数据关联到该新服务器组即可，这样服务器自己在读取配置数据时，将按照图2的流程，自动找到属于自己的配置数据；而不应该读取新配置数据的老代码服务器，由于其所对应的服务器组并未关联新配置数据，也不会读取到新配置数据。因此，这种方式大大提高了配置数据隔离的准确性，不论服务器何时读取配置数据，都可以按需索取。

在另一个例子中，配置客户端由分组数据中读取到的与所在服务器标识对应的服务器组的数量可以为至少两个，例如，以服务器host 1为例，结合表1的示例，host 1属于服务器组beta的成员，同时也属于服务器组prod的成员。这种情况下，配置客户端可以根据表1中的优先级priority来确定自己对应的服务器组。参见表1，每个服务器组都有各自对应的优先级，beta的优先级是0，prod的优先级是1，假设随着数字从小到大表示组的优先级递减，那么客户端可以选择优先级0对应的beta组作为自己所属的服务器组。

如下以一个验证应用代码的例子，说明如何使用本申请的配置数据读取方法为该应用代码读取配置数据。在进行验证时，假设结合表2的应用配置数据，将原来的旧代码使用的配置数据“config Key 1＝Hello”修改为“config Key 1＝Hello World”，让验证的新代码使用新配置数据Hello World，并且可以是设定先在表1的beta组中的服务器上进行验证(即，新代码配置在beta组中)，待验证通过后再将新配置数据更新到所有服务器，即prod服务器。

为了实现上述的验证，首先，可以由管理员对配置数据库进行数据操作，对配置数据库的操作包括如下两方面：

一方面，在分组数据中，设定想要进行代码验证的服务器，例如，设定在服务器host 1和host 2上进行代码验证，那么可以在分组数据中创建一个服务器组，该服务器组命名为beta，组成员包括host 1和host 2，如表1所示。并且，由于host 1和host 2同时也属于prod组，为了使得客户端在读取时确定自己对应的服务器组，表1中还包括了优先级，beta的优先级更高。

另一方面，在应用配置数据中，旧配置数据“config Key 1＝Hello”先不进行删除，而是另外增加一条新配置数据id＝3“config Key 1＝Hello World”，将这条新配置数据对应关联上服务器组beta，即该新配置数据设定为可以由服务器组beta中的成员服务器读取。

在进行上述的配置数据库修改后，再由各个服务器上的配置客户端进行配置数据的读取，例如，可以是服务器定时读取，或者由服务器再接收到管理设备的通知指示时进行读取。读取方法可以包括：

301、客户端获取所在服务器的标识；

例如，服务器标识可以是服务器的IP地址，或者主机名等。假设本例子中客户端获取的自己所在服务器的标识是host 1。

302、客户端由配置数据库中的分组数据中，获取与服务器的标识对应的服务器组；

例如，客户端可以查找表1中的服务器列表项，并将包括自己所在服务器标识的列表项对应的服务器组，作为自己所属的服务器组。在表1中，host1既位于列表项[‘host 1’,‘host 2’]中，也位于列表项[‘host.*’]中。

303、客户端判断服务器标识对应的服务器组的数量是否为一个；

例如，本例子中，客户端所在的服务器host 1，该标识对应的服务器组包括beta和prod，即对应的服务器组的数量为两个，那么继续执行305；否则，如果是一个，可以继续执行304。

304、客户端将服务器标识对应的服务器组作为所属服务器组；

305、客户端根据各个服务器组分别对应的优先级，选择优先级最高的服务器组为与服务器的标识对应的服务器组；

例如，host 1对应的服务器组包括beta和prod，但是beta的优先级更高，则客户端可以将服务器组beta作为自己所属的服务器组。

306、客户端根据所属服务器组，读取应用配置数据中与所述服务器组对应的配置数据。

例如，客户端可以读取表2中与服务器组beta对应的配置数据，即id＝3的新配置数据Hello World。

在配置客户端读取了配置数据后，服务器上的应用代码根据该配置数据进行代码验证。在验证通过后，管理员可以再次修改配置数据库，例如，删除表2中id＝1的旧配置数据，并将id＝3的新配置数据关联的服务器组，由beta修改为prod，然后通知各个服务器刷新配置数据，即重新读取数据即可。在重新读取数据时，仍然按照图3所示的方法，此时所有的服务器都可以读到新的配置数据Hello World。

此外，上述例子的配置数据读取方法，能够使得配置数据的回滚也较为简单，比如，假设经过上述的代码验证发现验证未通过，也不能使用新配置数据，那么管理员可以将表2中新增的id＝3的配置数据项删除，然后通知所有服务器重新读取一次，那么服务器将读取到旧的配置数据。

在图1中，由配置数据库和服务器上的配置客户端构成的系统可以称为配置数据读取系统，其中，为了使得配置客户端执行上述的配置数据读取方法，本申请可以提供一种配置数据读取装置，该装置可以设置在配置客户端。如图4所示，配置数据读取装置可以包括：标识获取模块41、分组识别模块42和数据读取模块43；其中，

标识获取模块41，用于获取所在服务器的标识；

例如，服务器的标识，包括：服务器的IP地址，或者服务器的主机名。

分组识别模块42，用于由所述配置数据库中读取分组数据，所述分组数据用于表示将各服务器进行分组后的服务器组，并根据所述分组数据确定与所述服务器的标识对应的服务器组；

数据读取模块43，用于由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。

进一步的，分组识别模块42，用于由所述分组数据中查找包括所述服务器的标识的服务器列表项；将与所述服务器列表项对应的服务器组，作为与所述服务器的标识对应的服务器组。

进一步的，分组识别模块42，还用于当与所述服务器标识对应的服务器组的数量为至少两个时，根据各个服务器分别对应的优先级，选择优先级最高的服务器组为与服务器的标识对应的服务器组。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种配置数据读取方法，其特征在于，所述方法用于读取配置数据库中的配置数据；所述方法包括：

获取所在服务器的标识；

由所述配置数据库中读取分组数据，所述分组数据用于表示读取同一配置数据的各个服务器被划分在同一服务器组中，并根据所述分组数据确定与所述服务器的标识对应的服务器组；

由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。

2.根据权利要求1所述的方法，其特征在于，所述服务器的标识，包括：服务器的IP地址，或者服务器的主机名。

3.根据权利要求1所述的方法，其特征在于，所述根据分组数据确定与所述服务器的标识对应的服务器组，包括：

由所述分组数据中查找包括所述服务器的标识的服务器列表项；

将与所述服务器列表项对应的服务器组，作为与所述服务器的标识对应的服务器组。

4.根据权利要求1所述的方法，其特征在于，当与所述服务器标识对应的服务器组的数量为至少两个时，所述根据分组数据确定与所述服务器的标识对应的服务器组，包括：

根据各个服务器组分别对应的优先级，选择优先级最高的服务器组为与服务器的标识对应的服务器组。

5.一种配置数据读取装置，其特征在于，包括：

标识获取模块，用于获取所在服务器的标识；

分组识别模块，用于由所述配置数据库中读取分组数据，所述分组数据用于表示读取同一配置数据的各个服务器被划分在同一服务器组中，并根据所述分组数据确定与所述服务器的标识对应的服务器组；

数据读取模块，用于由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。

6.根据权利要求5所述的装置，其特征在于，所述服务器的标识，包括：服务器的IP地址，或者服务器的主机名。

7.根据权利要求5所述的装置，其特征在于，

所述分组识别模块，用于由所述分组数据中查找包括所述服务器的标识的服务器列表项；将与所述服务器列表项对应的服务器组，作为与所述服务器的标识对应的服务器组。

8.根据权利要求5所述的装置，其特征在于，

所述分组识别模块，还用于当与所述服务器标识对应的服务器组的数量为至少两个时，根据各个服务器分别对应的优先级，选择优先级最高的服务器组为与服务器的标识对应的服务器组。

9.一种配置数据读取系统，其特征在于，包括：

配置数据库，用于存储分组数据和应用配置数据，所述分组数据用于表示读取同一配置数据的各个服务器被划分在同一服务器组中，所述应用配置数据用于表示分别与各个服务器组对应的配置数据；

配置客户端，设置在服务器上，用于为所述服务器上的应用代码读取所述配置数据库中的配置数据，包括：获取所在服务器的标识；由所述配置数据库中读取分组数据，所述分组数据用于表示将各服务器进行分组后的服务器组，并根据所述分组数据确定与所述服务器的标识对应的服务器组；由所述配置数据库中读取应用配置数据，所述应用配置数据用于表示分别与各个服务器组对应的配置数据，并根据所述应用配置数据确定与所述服务器组对应的配置数据。

10.根据权利要求9所述的系统，其特征在于，所述配置数据库中的分组数据，还包括：各个服务器组分别对应的优先级。