专利名称：一种服务器集群的配置管理系统和方法
技术领域：
本发明涉及服务器集群技术领域，特别是涉及一种服务器集群的配置管理系统和方法。
背景技术：
几乎所有的应用程序都需要配置信息，配置信息使得可以在不修改应用程序的情况下，动态调整系统运行的一些参数。目前广泛应用的配置信息，一般是以文件方式保存在本地，文件格式有XML、Pr0perties、JS0n等。还有一些基础表的内容，比如城市编码、国家代码、邮政编码等，也可以作为配置信息存储在数据库中。在大规模集群应用中，应用程序运行在数百台甚至几千台服务器上，配置信息的维护管理更显得尤为重要。传统的配置信息，基本上是以本地文件为主，格式有XML、Pr0pertieS、JS0n等。这种配置方式，单机修改起来比较方便，但是对于大规模集群应用，如果需要修改上百台甚至几千台服务器就很困难了。而且修改配置文件，大多数时候都需要重启应用才能生效。而将基础配置信息存储在数据库中的方式，可以解决集中修改的问题，但是修改之后不能及时通知应用服务器，也不能及时更新生效。通过应用服务器定时获取最新配置信息的方式不太可行，一是更新不及时，二是如果更新太频繁会浪费大量的网络流量，增加数据库的压力。可见现有的应用配置信息的维护管理方案中要么配置信息的维护特别繁琐，要么配置信息的更新不及时还浪费网络资源。
发明内容
本发明提供了一种服务器集群的配置管理系统，该系统能实现配置信息的集中式管理、维护简单，能实现配置信息的及时更新且节省网络资源。本发明还提供了一种服务器集群的配置管理方法，该方法能实现配置信息的集中式管理、维护简单，能实现配置信息的及时更新且节省网络资源。为达到上述目的，本发明的技术方案是这样实现的本发明公开了一种服务器集群的配置管理系统，该系统包括由多台应用服务器组成的应用服务器集群、配置服务器、配置数据库，其中；配置数据库，用于保存应用服务器的配置信息；应用服务器，用于向配置服务器发送配置信息请求消息，并接收配置服务器返回的配置信息；用于将自身的地址注册到配置服务器；用于在接收到配置服务器下发的更新后的配置信息后，对本地的配置信息进行更新；配置服务器，用于在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器；用于对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息。本发明还公开了一种服务器集群的配置管理方法，对于由多台服务器组成的应用服务器集群，将各应用服务器的配置信息保存到一个配置数据库中，并设置一个配置服务器，该方法包括应用服务器向配置服务器发送配置信息请求消息；配置服务器在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器；应用服务器将自身的地址注册到配置服务器；配置服务器对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息；应用服务器在接收到配置服务器下发的更新后的配置信息后，对本地的配置信息进行更新。由上述可见，本发明这种对于由多台服务器组成的应用服务器集群，将各应用服务器的配置信息保存到一个配置数据库中，并设置一个配置服务器，当应用服务器向配置服务器发送配置信息请求消息时，配置服务器从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器；应用服务器将自身的地址注册到配置服务器；配置服务器对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息的技术方案，能实现配置信息的集中式管理、维护简单，能实现配置信息的及时更新且节省网络资源。
图1是本发明实施例中的一种服务器集群的配置管理系统的组成示意图；图2是本发明实施例中应用服务器主动获取配置信息的流程图；图3是本发明实施例中的配置信息更新的流程图。
具体实施例方式为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。图1是本发明实施例中的一种服务器集群的配置管理系统的组成示意图。如图1 所示，该系统包括由多台应用服务器组成的应用服务器集群、配置服务器、配置数据库和配置控制平台。其中；配置数据库，用于保存应用服务器的配置信息；在每次配置信息更新时自动升级配置信息的版信息。应用服务器，用于向配置服务器发送配置信息请求消息，并接收配置服务器返回的配置信息；用于将自身的地址注册到配置服务器；用于在接收到配置服务器下发的更新后的配置信息后，对本地的配置信息进行更新；配置服务器，用于在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器；用于对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息；应用服务器与配置服务器之间维持一个常连接，应用服务器通过调用配置服务器的远程调用接口从配置服务器获取配置信息。配置控制平台，用于提供人机交互接口，接收用户输入的配置信息添加/修改/删除/更新命令，并转发给配置服务器；配置服务器，用于根据所接收的配置信息添加/修改 /删除/更新命令，在配置数据库中进行相应的操作。该系统能实现配置信息的集中式管理、维护简单，能实现配置信息的及时更新且节省网络资源。在图1所述的系统中，配置服务器还包括一个转化模块，当配置服务器接收到应用服务器的配置请求消息后，先从自身的缓存中查找与该应用服务器的配置信息所对应的配置对象，如果有则直接从缓存中获取该对应的配置对象返回给应用服务器，如果没有，则从数据库中检索出对应的配置信息，并由转化模块将检索出的配置信息转化给配置对象后保存在缓存中，配置服务器将缓存中的配置对象返回给该应用服务器；此外，配置服务器对配置数据库中的应用服务器的配置信息进行更新后，将该更新后的配置信息由转化模块转化为配置对象保存到缓存中，然后配置服务器根据应用服务器的注册地址向相应的应用服务器下发缓存中的与更新后的配置信息对应的配置对象。可见，配置服务器中的转化模块可以将XML、Properties、Json等不同格式的配置文件转化为统一的配置对象，配置对象可以通过统一的序列化方式在不同操作系统、不同开发语言开发的应用之间传输，因此能实现不同操作系统、不同开发语言之间的兼容处理。在图1所述的系统中，配置数据库用于按照配置信息键值(ConfigKey)、应用名称 (AppName)和应用服务器名称(ComputerName)之间的对应关系保存配置信息；应用服务器，用于向配置服务器发送包含配置信息键值、应用名称和应用服务器名称这三个参数的配置信息请求消息；配置服务器，用于在接收应用服务器发送的配置信息请求消息后，先根据其中的配置信息键值、应用名称和应用服务器名称这三个参数去从配置数据库中检索配置信息； 如果没有检索到匹配项，则根据配置信息键值和应用名称这两个参数去从配置数据库中检索配置信息；如果仍没有检索到匹配项，则根据配置信息键值这一个参数去从配置数据库中检索配置信息。这种方案可以实现配置的特例化，在后续部分还会对该方案进行详细说明。在图1所示的系统中，所述配置服务器是由多台服务器组成的集群，该多台服务器之间在对同一配置信息进行修改时，通过数据库排他锁的方式，防止配置信息的修改冲突。在图1所述的系统中，应用服务器包括远程加载模块和本地加载模块；其中，远程加载模块，用于向配置服务器发送配置信息请求消息，并接收配置服务器返回的配置信息；本地加载模块，用于从应用服务器的本地获取配置信息；应用服务器通过切换远程加载模块和本地加载模块，来实现远程从配置服务器获取配置信息的模式以及从本地获取配置信息的模式之间的切换。这种方案可以方便开发时的调试，既能够支持集中式的配置管理，也能够支持从本地文件加载配置信息。
图2是本发明实施例中应用服务器主动获取配置信息的流程图。如图2所示，包括如下步骤步骤1，应用服务器切换远程加载模块；步骤2，应用服务器通过与配置服务器之间的常连接发起一个获取配置信息的配置信息请求消息，该消息中包含参数配置信息键值(ConfigKey)、应用名称(AppName)和应用服务器名称(ComputerName)；步骤3，配置服务器先从自身的缓存中查找配置信息，如果有则转到步骤6，如果没有转到步骤4 ；步骤4，配置服务器到配置数据库查询配置信息。按照配置信息键值(ConfigKey) 进行查询，提取全量信息。因为涉及到配置特例化的问题，获取的配置信息可能不止一条。步骤5，配置服务器的转化模块将此一批配置信息转化为配置对象，并保存到缓存中；步骤6，配置服务器根据配置请求消息中的参数，首先按照配置信息键值 (ConfigKey)、应用名称(AppName)和应用服务器名称(ComputerName)这三个条件检索配置信息，如果没有，按照配置信息键值(ConfigKey)、应用名称(AppName)来检索配置信息， 如果还没有，则按照配置信息键值(ConfigKey)来检索配置信息。步骤7，配置服务器将检索到的配置对象反馈给应用服务器。图3是本发明实施例中的配置信息更新的流程图。如图3所示，包括如下步骤步骤1，用户(一般为运维人员)通过配置控制平台添加或修改配置信息，具体为通过配置控制平台向配置服务器发送相应的命令；步骤2，配置服务器根据命令对配置数据库中的配置信息进行相应的操作，并将更新后的配置信息保存到配置数据库中，配置数据库更新版本信息，并向配置服务器返回最新的版本信息；本步骤中，如果配置信息更新成功则执行后续步骤，如果不成功，则通过配置控制平台的界面向用户提示出错信息，配置信息和版本信息保持原来的数据。步骤3，配置服务器通过转化模块将更新后的配置信息转化为方便内存管理及序列化传输的配置对象。转化模块负责将配置内容转化为配置对象，方便应用服务的使用；配置对象能够被序列化通过网络高效传输；并且使得此配置信息能够在不同的操作系统之间传输:Wind0WS、Linux ；因为基于统一的序列化反序列化算法，所以也能够被不同开发语言开发的应用服务使用如java、Net、C语言开发的应用服务；也能够支持不同的配置格式 Xml.Properties, Json等，并能够根据需求进行扩展。配置服务器通过更新配置的版本信息区分此配置是否最新。步骤4，配置服务器根据存储的应用服务器的地址注册信息，将此更新后的配置信息主动下发各对应的应用服务器。应用服务器通过配置服务器的远程调用接口获取制定的配置信息时，已将自身的地址信息在配置服务器进行注册。此处有错误重试机制，当获取失败后，会间隔一段时间再次重试，重试的时间间隔及次数可以配置。步骤5，应用服务器会根据获取的配置信息和本地配置信息进行比对，如果版本一致，则不需要进行更新；如果版本不一致，更新本地配置信息。最后反馈更新结果。
在实际应用中，不能保证每台应用服务器都工作正常，所以会将配置最新版本号， 和应用服务器下发版本号都存储在配置服务器，对于发送失败的应用服务器，会重复发送， 直至成功。可能在下发过程中，配置信息发生多次变更，只下发最新版本。下面对本发明中的配置特例化的实现进行说明相同的配置信息针对不同的应用可能配置内容不同，相同的配置信息相同的应用也有可能配置内容不同，当对配置信息进行全局化管理时，也必须考虑配置的特例化。假设目前应用服务器集群配置了 100台服务器，40台运行Appl应用，40台运行 App2应用，20台运行其他应用AppX。这100台服务器是分批购买的，所以硬件配置不一样， 假设服务器有两种配置低配置、主流配置。其中App2的应用都运行在主流配置的服务器上面。Appl的应用有三台低配置的服务器(C1，C2，C3)，这三台服务器上需要配置的线程数就要相对小一些。根据性能测试的数据，Appl在低配置上的最佳配置线程数是80，在主流配置上的最佳配置线程数是150 ；App2在主流配置的服务器上的最佳线程数是200。那么配置信息就如表1所示，其中*表示所有。
权利要求
1.一种服务器集群的配置管理系统，其特征在于，该系统包括由多台应用服务器组成的应用服务器集群、配置服务器、配置数据库，其中；配置数据库，用于保存应用服务器的配置信息；应用服务器，用于向配置服务器发送配置信息请求消息，并接收配置服务器返回的配置信息；用于将自身的地址注册到配置服务器；用于在接收到配置服务器下发的更新后的配置信息后，对本地的配置信息进行更新；配置服务器，用于在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器；用于对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配直fe息。
2.根据权利要求1所述的系统，其特征在于，该系统进一步包括配置控制平台，用于提供人机交互接口，接收用户输入的配置信息添加/修改/删除/ 更新命令，并转发给配置服务器；配置服务器，用于根据所接收的配置信息添加/修改/删除/更新命令，在配置数据库中进行相应的操作。
3.根据权利要求1或2所述的系统，其特征在于，所述配置服务器，用于接收到应用服务器的配置请求消息后，先从自身的缓存中查找与该应用服务器的配置信息所对应的配置对象，如果有则直接从缓存中获取该对应的配置对象返回给应用服务器，如果没有，则从数据库中检索出对应的配置信息，并将检索出的配置信息转化给配置对象后保存在缓存中，将缓存中的配置对象返回给该应用服务器；所述配置服务器，用于对配置数据库中的应用服务器的配置信息进行更新后，将该更新后的配置信息转化为配置对象保存到缓存中，并根据应用服务器的注册地址向相应的应用服务器下发缓存中的与更新后的配置信息对应的配置对象。
4.根据权利要求1或2所述的系统，其特征在于，配置数据库，用于按照配置信息键值、应用名称和应用服务器名称之间的对应关系保存配置信息；应用服务器，用于向配置服务器发送包含配置信息键值、应用名称和应用服务器名称这三个参数的配置信息请求消息；配置服务器，用于在接收应用服务器发送的配置信息请求消息后，先根据其中的配置信息键值、应用名称和应用服务器名称这三个参数去从配置数据库中检索配置信息；如果没有检索到匹配项，则根据配置信息键值和应用名称这两个参数去从配置数据库中检索配置信息；如果仍没有检索到匹配项，则根据配置信息键值这一个参数去从配置数据库中检索配置信息。
5.根据权利要求1或2所述的系统，其特征在于，所述配置服务器是由多台服务器组成的集群，该多台服务器之间在对同一配置信息进行修改时，通过数据库排他锁的方式，防止配置信息的修改冲突。
6.根据权利要求1或2所述的系统，其特征在于，应用服务器包括远程加载模块和本地加载模块；其中，远程加载模块，用于向配置服务器发送配置信息请求消息，并接收配置服务器返回的配置信息；本地加载模块，用于从应用服务器的本地获取配置信息；应用服务器通过切换远程加载模块和本地加载模块，来实现远程从配置服务器获取配置信息的模式以及从本地获取配置信息的模式之间的切换。
7.一种服务器集群的配置管理方法，其特征在于，对于由多台服务器组成的应用服务器集群，将各应用服务器的配置信息保存到一个配置数据库中，并设置一个配置服务器，该方法包括应用服务器向配置服务器发送配置信息请求消息；配置服务器在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器；应用服务器将自身的地址注册到配置服务器；配置服务器对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息；应用服务器在接收到配置服务器下发的更新后的配置信息后，对本地的配置信息进行更新。
8.根据权利要求7所述的方法，其特征在于，所述配置服务器在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器包括配置服务器在接收到应用服务器的配置请求消息后，先从自身的缓存中查找与该应用服务器的配置信息所对应的配置对象，如果有则直接从缓存中获取该对应的配置对象返回给应用服务器，如果没有，则从数据库中检索出对应的配置信息，并将检索出的配置信息转化给配置对象后保存在缓存中，将缓存中的配置对象返回给该应用服务器；所述配置服务器对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息包括配置服务器对配置数据库中的应用服务器的配置信息进行更新后，将该更新后的配置信息转化为配置对象保存到缓存中，并根据应用服务器的注册地址向相应的应用服务器下发缓存中的与更新后的配置信息对应的配置对象。
9.根据权利要求7所述的方法，其特征在于，所述将各应用服务器的配置信息保存到一个配置数据库中包括按照配置信息键值、 应用名称和应用服务器名称之间的对应关系保存配置信息；所述应用服务器向配置服务器发送配置信息请求消息包括应用服务器向配置服务器发送包含配置信息键值、应用名称和应用服务器名称这三个参数的配置信息请求消息；所述配置服务器在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息包括配置服务器在接收应用服务器发送的配置信息请求消息后，先根据其中的配置信息键值、应用名称和应用服务器名称这三个参数去从配置数据库中检索配置信息；如果没有检索到匹配项，则根据配置信息键值和应用名称这两个参数去从配置数据库中检索配置信息；如果仍没有检索到匹配项，则根据配置信息键值这一个参数去从配置数据库中检索配置信息。
10.根据权利要求7所述的方法，其特征在于，所述配置服务器是由多台服务器组成的集群，该多台服务器之间在对同一配置信息进行修改时，通过数据库排他锁的方式，防止配置信息的修改冲突； 该方法进一步包括应用服务器从本地获取配置信息。
全文摘要
本发明公开了一种服务器集群的配置管理系统和方法。所述方法包括应用服务器向配置服务器发送配置信息请求消息；配置服务器在接收到应用服务器发送的配置信息请求消息后，从配置数据库检索出该应用服务器的配置信息并返回给该应用服务器；应用服务器将自身的地址注册到配置服务器；配置服务器对配置数据库中的应用服务器的配置信息进行更新，并根据应用服务器的注册地址向相应的应用服务器下发更新后的配置信息；应用服务器在接收到配置服务器下发的更新后的配置信息后，对本地的配置信息进行更新。本发明的技术方案能实现配置信息的集中式管理、维护简单，能实现配置信息的及时更新且节省网络资源。
文档编号H04L29/08GK102255752SQ20111018250
公开日2011年11月23日 申请日期2011年6月30日 优先权日2011年6月30日
发明者李春雷, 高磊 申请人:北京新媒传信科技有限公司