动态负载的优化方法及系统

技术领域

本发明涉及计算机软件领域，具体地，涉及一种动态负载的优化方法及系统。

背景技术

首先市场上使用较多的是NGINX来进行软件上的负载均衡。当网站规模变大，通常会进行服务的拆分，各个服务独立部署，并通过远程调用的方式来进行协同工作。随着系统的继续扩大与演进，服务器的数量会增多，相对应的NGINX软件的数量也会增多，其相对应的NGINX部署与配置工作也会增加，这时就会有一些小麻烦，例如：(1)配置维护的成本变高，因为节点太多；(2)单点故障的风险增加了，因为热点服务的访问量很高，如果这个服务集群内的负载均衡服务出现问题，这个服务将失效。

其中第一个问题，可以通过自己开发程序解决，但只是降低复杂度，并没有实际解决。第二个问题，可以通过双机高可用部署方案，使用另一台NGINX负载均衡服务器随时待命，只是成本较高。

专利文献CN101605144A(申请号：CN200910054349.2)公开了种Web软件系统吞吐量优化方法，包括如下步骤：a.为Web软件系统设定一个初始的在线人数限制，并使得该系统在相应的在线人数控制机制下进行运行；b.定时收集Web软件系统在最近一段时间内的运行信息；c.优化控制器中的反馈控制机制根据所述运行信息对在线人数限制进行动态调节，使得服务器的吞吐量进一步得到提高或者稳定在一个较高的水平上；d.间隔一定时间后重复执行步骤b-d。但该专利文献没有采用部署ZooKeeper集群的方式进行负载优化。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种动态负载的优化方法及系统。

根据本发明提供的一种动态负载的优化方法，包括：

步骤S1：令应用程序自启动后调用ZooKeeper注册代码向ZooKeeper集群进行注册；

步骤S2：令ZooKeeper集群监控服务器；

步骤S3：令客户端通过接口向ZooKeeper集群查询注册服务器列表；

步骤S4：令客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，ZooKeeper通知重新获取服务器列表。

优选地，在所述步骤S1中：

搭建相关ZooKeeper集群的相关环境，以及下载相关工具包；

在每台应用程序中，编写ZooKeeper的注册代码，让程序自启动后调用该注册代码向ZooKeeper集群进行注册。

优选地，在所述步骤S2中：

通过注册后，该服务器已处于ZooKeeper集群的监控之下，如服务器不可达，无法连上，自动从服务器列表中移除无法连上的服务器的信息，待服务器回复后，继续添加至服务器列表中；

监控程序针对每一个接入的实例进行数据监控，把预设时间之内的剩余资源信息写入服务器对应的地址信息中。

优选地，在所述步骤S3中：

客户端通过接口向ZooKeeper集群中查询注册服务器列表，查询成功进行接入的服务器列表，根据内部的算法或者策略，决定需要连接到哪一台服务器上。

优选地，在所述步骤S4中：

客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，变化包括某台服务器宕机下线，或者新加了服务器，ZooKeeper自动通知调用者重新获取服务器列表。

根据本发明提供的一种动态负载的优化系统，包括：

模块M1：令应用程序自启动后调用ZooKeeper注册代码向ZooKeeper集群进行注册；

模块M2：令ZooKeeper集群监控服务器；

模块M3：令客户端通过接口向ZooKeeper集群查询注册服务器列表；

模块M4：令客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，ZooKeeper通知重新获取服务器列表。

优选地，在所述模块M1中：

搭建相关ZooKeeper集群的相关环境，以及下载相关工具包；

在每台应用程序中，编写ZooKeeper的注册代码，让程序自启动后调用该注册代码向ZooKeeper集群进行注册。

优选地，在所述模块M2中：

通过注册后，该服务器已处于ZooKeeper集群的监控之下，如服务器不可达，无法连上，自动从服务器列表中移除无法连上的服务器的信息，待服务器回复后，继续添加至服务器列表中；

监控程序针对每一个接入的实例进行数据监控，把预设时间之内的剩余资源信息写入服务器对应的地址信息中。

优选地，在所述模块M3中：

客户端通过接口向ZooKeeper集群中查询注册服务器列表，查询成功进行接入的服务器列表，根据内部的算法或者策略，决定需要连接到哪一台服务器上。

优选地，在所述模块M4中：

客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，变化包括某台服务器宕机下线，或者新加了服务器，ZooKeeper自动通知调用者重新获取服务器列表。

与现有技术相比，本发明具有如下的有益效果：

1、本发明采用ZooKeeper的方式来实现NGINX的功能，采用部署ZooKeeper集群的方式，减少单点故障；

2、本发明实现了NGINX的功能，负载功能，同时，还不需要动态的配置相关信息，直接服务自启动，通过代码的方式去注册，减少了大量的配置功能。

3、本发明增加监控程序，增加了调用的效率，减少无效调用。

附图说明

通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：

图1为ZooKeeper集群示意图；

图2为本发明流程图。

具体实施方式

下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。

实施例1：

本发明采用ZooKeeper的方式来实现NGINX的功能，采用部署ZooKeeper集群的方式，减少单点故障，同时，每个服务启动时，直接通过服务内部代码调用ZooKeeper方法，直接向ZooKeeper集群注册自身的相关服务器信息，此时，自身服务器已处于ZooKeeper集群的监控之下，而客户端只需要向ZooKeeper注册中心获取服务器列表，根据自身的自定义算法，决定连接到哪台服务器上。同时，ZooKeeper自动监控每台已注册服务器，当某台服务器不可达，宕机或者其他原因无法连上，则自动从服务器列表中移除无法连上的服务器的信息，待其回复后，则继续添加至服务器列表中。

所谓的动态负载，就是指被调用方向ZooKeeper集群注册信息，生成列表，调用方可以根据自身预设的规则，选择合适的地址进行调用。同时，当某个被调用方故障时，会由ZooKeeper集群监控，并实时通知调用方清除该故障机器，则调用方不会再次请求故障机器。通过这种自主选择调用地址，并且从调用列表中动态清除故障机器的方式，就是一种动态负载的模式。

根据本发明提供的一种动态负载的优化方法，如图1-图2所示，包括：

步骤S1：令应用程序自启动后调用ZooKeeper注册代码向ZooKeeper集群进行注册；

具体地，在所述步骤S1中：

搭建相关ZooKeeper集群的相关环境，以及下载相关工具包；

在每台应用程序中，编写ZooKeeper的注册代码，让程序自启动后调用该注册代码向ZooKeeper集群进行注册。

步骤S2：令ZooKeeper集群监控服务器；

具体地，在所述步骤S2中：

通过注册后，该服务器已处于ZooKeeper集群的监控之下，如服务器不可达，无法连上，自动从服务器列表中移除无法连上的服务器的信息，待服务器回复后，继续添加至服务器列表中；

监控程序针对每一个接入的实例进行数据监控，把预设时间之内的资源剩余资源信息写入服务器对应的地址信息中。

步骤S3：令客户端通过接口向ZooKeeper集群查询注册服务器列表；

具体地，在所述步骤S3中：

客户端通过接口向ZooKeeper集群中查询注册服务器列表，查询成功进行接入的服务器列表，根据内部的算法或者策略，决定需要连接到哪一台服务器上。

步骤S4：令客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，ZooKeeper通知重新获取服务器列表。

具体地，在所述步骤S4中：

客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，变化包括某台服务器宕机下线，或者新加了服务器，ZooKeeper自动通知调用者重新获取服务器列表。

实施例2：

实施例2为实施例1的优选例，以更为具体地对本发明进行说明。

本发明还提供一种动态负载的优化系统，所述动态负载的优化系统可以通过执行所述动态负载的优化方法的流程步骤予以实现，即本领域技术人员可以将所述动态负载的优化方法理解为所述动态负载的优化系统的优选实施方式。

根据本发明提供的一种动态负载的优化系统，包括：

模块M1：令应用程序自启动后调用ZooKeeper注册代码向ZooKeeper集群进行注册；

具体地，在所述模块M1中：

搭建相关ZooKeeper集群的相关环境，以及下载相关工具包；

在每台应用程序中，编写ZooKeeper的注册代码，让程序自启动后调用该注册代码向ZooKeeper集群进行注册。

模块M2：令ZooKeeper集群监控服务器；

具体地，在所述模块M2中：

通过注册后，该服务器已处于ZooKeeper集群的监控之下，如服务器不可达，无法连上，自动从服务器列表中移除无法连上的服务器的信息，待服务器回复后，继续添加至服务器列表中；

监控程序针对每一个接入的实例进行数据监控，把预设时间之内的资源剩余资源信息写入服务器对应的地址信息中。

模块M3：令客户端通过接口向ZooKeeper集群查询注册服务器列表；

具体地，在所述模块M3中：

客户端通过接口向ZooKeeper集群中查询注册服务器列表，查询成功进行接入的服务器列表，根据内部的算法或者策略，决定需要连接到哪一台服务器上。

模块M4：令客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，ZooKeeper通知重新获取服务器列表。

具体地，在所述模块M4中：

客户端获取到服务器列表后缓存到内部，当服务器列表发生变化，变化包括某台服务器宕机下线，或者新加了服务器，ZooKeeper自动通知调用者重新获取服务器列表。

实施例3：

实施例3为实施例1的优选例，以更为具体地对本发明进行说明。

目前旧有方式下只会返回实例正常的列表地址，本发明有一定的改进。存在一个监控程序，会针对每一个接入的实例进行数据监控，监控实例的CPU，内存以及IO等相关信息，把一段时间之内的剩余资源信息写入该台机器对应的地址信息中。当客户端从ZooKeeper中获取到接入地址列表时，根据自身的业务需要，比如自身业务需要内存较多的，则会优先自主选择内存资源较多的地址，进行接入，需要其他资源的场景也是类似的实现方式。

步骤1.搭建相关ZooKeeper集群的相关环境，以及下载相关工具包。

步骤2.在每台应用程序中，需要编写ZooKeeper的注册代码，让程序自启动后调用该注册代码向ZooKeeper集群(配置中心)进行相关的注册动作。

步骤3.此时，通过注册后，该服务器已处于ZooKeeper集群的监控之下，如某台服务器不可达，宕机或者其他原因无法连上，则自动从服务器列表中移除无法连上的服务器的信息，待其回复后，则继续添加至服务器列表中。

步骤4.客户端需要通过接口向ZooKeeper集群中查询注册服务器列表。查询出现在可以成功进行接入的服务器列表，然后，根据自己内部的算法或者策略，决定需要连接到哪一台的服务器上。

步骤5.客户端获取到服务器列表后，就可以缓存到自己内部，省得下次再取，当服务器列表发生变化，例如某台服务器宕机下线，或者新加了服务器，ZooKeeper会自动通知调用者重新获取服务器列表。

步骤6。通过以上的方式，来实现了NGINX的功能，负载功能，同时，还不需要动态的配置相关信息，直接服务自启动，通过代码的方式去注册就行了，减少了大量的配置功能。

本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。

以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。