CN104618466A - 基于消息传递的负载均衡和过负荷控制系统及其控制方法 - Google Patents

Abstract

本发明公开一种基于消息传递的负载均衡和过负荷控制系统，包括客户端模块、路由模块、消息传递模块、资源信息收集模块、业务服务端模块和性能监控模块；及其控制方法。本发明增强了系统的可靠性，系统中任何一个节点失效，都不会影响业务的正常运行，避免了负载过大而造成的事务处理延迟过高的情况。

Description

基于消息传递的负载均衡和过负荷控制系统及其控制方法

技术领域

本发明涉及的是基于消息传递的负载均衡以及过负荷控制技术领域，具体是一种对云化业务进行负载均衡以及过负荷控制的系统，具有高可用和高可靠的特性。

背景技术

随着移动业务平台和网关的集中化部署，物理和虚拟资源的调度策略呈现出多层次的特性，同时各个业务平台/网关的负载在时间、空间上呈现出不平衡分布的特性，需要根据负载状况动态调整资源供给，现有基于独立建设的烟囱模式无法满足移动通信网中业务云化后的特殊性要求(如峰谷时段的不平衡性、多种业务之间的非线性交叉影响等)，单一的过负荷控制策略很难适应于具有访问模式差异的业务类型，并且由于传统的容灾方式都基于单个业务考虑，具有效率低、冗余度小等特点，无法适应集中化场景下业务的连续性、可靠性的要求。

为了解决这个问题，必须将业务分布式化，而在一个分布式系统中，往往需要一个消息中间件来对前后端进行解耦，为前端应用提供更大的吞吐量，使得前端应用不会因为后端处理速度的瓶颈而阻塞，从而提高系统的可用性和可扩展性。有些消息中间件还能对消息进行持久化，保证消息在传递过程中不会丢失，来保证系统的容错性以及可靠性。

另外当一个分布式应用牵涉到很多个节点之间的交流协作时，通常都需要一个协调者，或者一个协调协议来对应用群组进行组织协调。很多应用都是内置了这样一个模块，也可以使用一个独立的组件来为系统提供分布式的一些服务。比较有名的有Google在GFS中用到的Chubby，阿里巴巴开发的Dubbo，另外是应用最广泛的Apache Zookeeper。这种分布式协调系统能很大程度的增加分布式应用的容错性以及可扩展性，也大大的降低了开发的复杂度。

在分布式应用中，性能指标是比较重要的，而影响性能指标的原因却是复杂的。当一个分布式应用性能异于平常表现出比较差的性能时，很有可能是分布式应用中的某一个模块出现了错误，但被应用所捕捉，从而变成了软错误。软错误就是指应用可以产生正确的结果，但相对正常情况有着低吞吐量和高延迟。由于在系统中各模块交互比较复杂，造成低性能的原因往往是难以捉摸的，性能的瓶颈可以存在于系统中的任一模块中，所以一个性能监控框架是在分布式系统中必不可少的，不仅是生产环境还是测试环境，性能监控都能带来诊断分布式系统问题的依据。

发明内容

本发明针对上述移动业务所遇到的问题，提出了一种在云化环境中基于消息传递的负载均衡和过负荷控制系统架构，将移动业务完全分布式化，并且对其进行负载均衡以及过负荷控制。

本发明的技术方案如下：

一种基于消息传递的负载均衡和过负荷控制系统，其特点在于，包括客户端模块、路由模块、消息传递模块、资源信息收集模块、业务服务端模块和性能监控模块。

所述的客户端模块主要为客户端提供了简单快捷的借口，将程序员的命令传递给路由模块和消息传递模块；

所述的路由模块主要负责对目前系统中活跃的消息代理进行管理，并且根据一系列消息代理的状态信息，为客户端推送一个最优的消息代理地址；

所述的消息传递模块主要负责系统的消息传递，主要由消息中间件来完成，消息中间件将前端的客户端模块发送的消息传递给后端的对应业务服务端模块进行处理；

所述的资源信息收集模块负责管理消息代理的加入以及推出，并且需要监控该消息代理的活性，另外资源信息收集模块还需要定期向路由模块发送消息代理机器的资源使用情况；

所述的业务服务端模块负责与消息代理保持长连接，阻塞式的收取消息，并且对相应业务进行处理；

所述的性能监控模块负责对业务服务端模块的性能进行监控，监控指标包括处理消息的吞吐量，大小以及延迟，并定期以某种方式记录下来，以便运维人员查看。

一种基于消息传递的负载均衡和过负荷控制方法，其特点在于，该方法包括如下步骤：

步骤1、业务服务端向路由模块请求消息代理的地址；

步骤2、路由模块向业务服务端返回一个当前连接数最少的消息代理的地址；

步骤3、业务服务端连接该消息代理对消息进行消费；

步骤4、客户端模块向路由模块请求消息代理服务的地址；

步骤5、路由模块向客户端模块返回一个当前连接数最少的消息代理服务的地址；

步骤6、客户端模块连接该消息代理进行消息发布。

与现有方案相比，本发明有以下三个特点：

1.去中心，即整个系统不存在单点故障，这种设计大大的增强了系统的可靠性；

2.无状态，即系统中的单个节点不会储存状态，也就是系统中任何一个节点失效，都不会影响业务的正常运行；

3.过负荷控制，即节点会根据当前负载情况来控制流入消息的速率，来进行过负荷控制，以免造成负载过大而造成的事务处理延迟过高的情况。

附图说明

图1是本发明系统架构示意图

图2是客户端发送消息流程图

图3是业务服务端工作流程图

图4是系统运行示意图。

具体实施方式

下面对本发明的实施例作详细说明，本实施例在本发明技术方案为前提下进行实施，给出了详细的实施方式和具体的操作过程，本发明的适用平台不限于下述的实施例。

请先参阅图1，图1是本发明系统架构示意图，如图所示，一种基于消息传递的负载均衡和过负荷控制系统，包括客户端模块1、路由模块2、由消息传递模块3和资源信息收集模块4构成的消息代理、业务服务端模块5和性能监控模块6。

所述的客户端模块1为客户提供接口，并将命令传递给路由模块2和消息传递模块3；

所述的路由模块2负责对系统中正在运行的消息代理进行管理，并且根据消息代理的状态信息，为客户端模块推送一个当前连接数最少的消息代理地址；

所述的消息传递模块3通过消息中间件将前端的客户端模块1发送的消息传递给后端的对应的业务服务端模块5；

所述的资源信息收集模块4负责管理消息代理的加入以及推出，并且监控该消息代理的活性，同时定期向路由模块2发送消息代理的资源使用情况；

所述的业务服务端模块5负责与消息代理保持长连接，阻塞式的收取消息，并且对接收到的相应业务进行处理；

所述的性能监控模块6负责对业务服务端模块5的性能进行监控及记录，监控指标包括处理消息的吞吐量、大小以及延迟。

客户端模块在实现上相当于一个库，上层程序员通过客户端模块与路由模块进行交互，并且选取一个当前最优的消息代理进行连接，并且发送消息。

路由模块在实现上，选择了Apache Zookeeper。利用Apache Zookeeper的集群部署以及动态添加删除节点的特性，可以协助系统对消息代理的成员进行管理。在Zookeeper中，每种业务在系统命名空间中都会有一个对应的节点，而特定业务的节点的子节点就是表示对应业务处理节点，对于每个子节点，都会保存此业务处理节点地址、内存使用情况、CPU利用率等信息。

消息传递模块在实现上，选择了RabbitMQ这个消息中间件。RabbitMQ支持消息的持久化，并且在集群部署中支持高可用队列配置，另外RabbitMQ还支持图形化管理界面，能友好的显示消息代理服务器当前的状态。

资源信息收集模块是通过在资源信息收集模块中每隔一段时间向消息代理发送一个心跳信息来实现的，具体来说就是向本机的RabbitMQ实例发送一个无意义的心跳信息，如果发送出现异常，那么就说明在本机上的RabbitMQ实例出现了失效，此时就通过Zookeeper连接向路由模块通知，发送节点退出信息。

业务服务端模块在实现中会把发送失败的消息储存在Zookeeper的节点中，后台的重发线程会到Zookeeper中寻找发送失败的消息，并发往业务网关，发送成功之后才会将其删除。

性能监控模块在实现时，使用了Metrics性能监控框架来简化系统的复杂度。性能监控模块是嵌入在业务服务端模块中的，系统会对业务服务端收到的消息进行监控，具体指标包括，消息的吞吐量、消息的处理延迟以及已经处理的消息数量和大小。并且Metrics会定时报告当前性能监控的状态。我们可以选择向控制台输出，也可以选择输出到csv文件中，甚至还可以通过http做成网页的形式呈现出来，方便运维人员查看。在本文所实现系统中，为了减少实现复杂度，采用的是向csv文件输出。

客户端运行流程图如图2所示：

客户端开始发送消息后，会判断目前消息是否到达了设定好的阈值(batchNum)，如果未到达，则直接向当前的消息代理连接发送消息，发送消息完毕；如果到达了阈值，则向路由模块重新询问当前连接数最少的消息代理服务器的地址，之后会判断此地址是否在缓存的连接中，如果在缓存中，则更新当前的连接再想其发送消息，如果不在缓存中，则重新建立连接并且将连接存储在本地缓冲中，之后再向其发送消息。

业务服务端运行流程图如图3所示：

业务服务端启动之后，会向路由模块请求消息代理的地址，然后与其连接，连接成功之后开始等待消息到来，如果收到消息，则对消息进行处理，并且将消息发送给业务网关，如果消息发送成功，则继续等待消息，如果消息发送失败则先将消息写入备用服务器(Zookeeper服务器)，然后再继续等待消息。

系统运行流程如图4所示：

(1)业务服务端a会先向路由服务器集群请求消息代理服务器的地址；

(2)路由服务器集群向业务服务端a返回一个当前最优的消息代理服务器消息代理b；

(3)业务服务端a连接消息代理c对消息进行消费；

(4)客户端a向路由服务器集群请求消息代理服务器的地址；

(5)路由服务器集群向客户端a返回一个当前最优的消息代理服务器消息代理a；

(6)客户端a连接消息代理a进行消息发布。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (2)

1.一种基于消息传递的负载均衡和过负荷控制系统，其特征在于，包括客户端模块(1)、路由模块(2)、由消息传递模块(3)和资源信息收集模块(4)构成的消息代理、业务服务端模块(5)和性能监控模块(6)，

所述的客户端模块(1)为客户提供接口，并将命令传递给路由模块(2)和消息传递模块(3)；

所述的路由模块(2)负责对系统中正在运行的消息代理进行管理，并且根据消息代理的状态信息，为客户端模块推送一个当前连接数最少的消息代理地址；

所述的消息传递模块(3)通过消息中间件将前端的客户端模块(1)发送的消息传递给后端的对应的业务服务端模块(5)；

所述的资源信息收集模块(4)负责管理消息代理的加入以及推出，并且监控该消息代理的活性，同时定期向路由模块(2)发送消息代理的资源使用情况；

所述的业务服务端模块(5)负责与消息代理保持长连接，阻塞式的收取消息，并且对接收到的相应业务进行处理；

所述的性能监控模块(6)负责对业务服务端模块(5)的性能进行监控及记录，监控指标包括处理消息的吞吐量、大小以及延迟。

2.一种基于消息传递的负载均衡和过负荷控制方法，其特征在于，该方法包括如下步骤：

步骤1、业务服务端(5)向路由模块(2)请求消息代理的地址；

步骤2、路由模块(2)向业务服务端(5)返回一个当前连接数最少的消息代理的地址；

步骤3、业务服务端(5)连接该消息代理对消息进行消费；

步骤4、客户端模块(1)向路由模块(2)请求消息代理服务的地址；

步骤5、路由模块(2)向客户端模块(1)返回一个当前连接数最少的消息代理服务的地址；

步骤6、客户端模块(1)连接该消息代理进行消息发布。