[发明专利]负载均衡引擎，客户端，分布式计算系统以及负载均衡方法

说明书

本文公开一种负载均衡引擎，客户端，分布式计算系统以及负载均衡方法，所述负载均衡引擎包括：负载信息管理模块，用于获取分布式计算系统的全局负载信息；服务信息管理模块，用于获取所述分布式计算系统的全局服务信息；策略计算模块，用于针对第一服务类型，利用所述全局负载信息以及所述全局服务信息进行负载均衡计算，生成与所述第一服务类型相对应的第一负载均衡策略，所述第一负载均衡策略指示了与所述第一服务类型对应的服务消息在所述M个计算节点中的分发信息；策略发布模块，用于将所述第一负载均衡策略发布给客户端。采用本发明提供的分布式计算系统，由于策略计算与执行分离，可以处理大流量的服务调用，且便于升级。

技术领域

本发明涉及电子领域，尤其涉及一种负载均衡引擎，客户端，分布式计算系统以及负载均衡方法。

背景技术

随着计算技术的发展，有些任务的计算需要非常大的计算能力才能完成，如果采用集中式计算，需要耗费相当长的时间来完成计算；而采用分布式计算，则可以将该任务分解成许多小的子任务，然后分配给多台计算机进行处理，这样可以节约整体计算时间，大大提高计算效率。

对于分布式计算而言，任务调度是一个最基本且具有挑战性的问题，其中，任务调度问题是指：给定一组任务和若干个可并行执行这些任务的计算节点，寻找一个能够将这一组任务有效调度到各个计算节点进行计算的方法，以获得更好的任务完成时间、吞吐量和资源利用率等。而负载均衡(Load Balance，LB)是进行任务调度时需要考虑的关键因素，也是优化分布式计算性能的关键，负载均衡问题解决得好与坏，直接决定了分布式计算资源的使用效率以及应用性能的高低。

为了解决负载均衡问题，现有技术提供了一种集中式负载均衡方案，如图1所示，在分布式计算系统10中，在客户端11与多个计算节点13之间，设置了独立的负载均衡器12，其中，负载均衡器12可以是专门的硬件设备，如F5公司提供的各种处理负载均衡的硬件，还可以是LVS，HAproxy,Nginx等负载均衡软件。当客户端11调用某个目标服务时，它向负载均衡器12发起服务请求，负载均衡器12根据某种负载均衡策略，将该服务请求转发到提供该目标服务的计算节点13上。而客户端11要发现负载均衡器12，则是通过域名系统(DomainName System，DNS)14实现，具体地，域名系统14为每个服务配置一个DNS 域名，这个域名指向负载均衡器12。然而，集中式负载均衡方案的缺点在于：所有服务调用的流量都经过负载均衡器12，当服务数量和调用量很大的时候，负载均衡器12容易成为制约分布式计算系统10的性能的瓶颈，且一旦负载均衡器12发生故障，对整个分布式计算系统10的影响是灾难性的。

针对集中式负载均衡方案的不足，现有技术还提供了另一种客户端负载均衡方案，也可以称为软负载均衡(Soft Load Balancing)方案，如图2所示，在分布式计算系统20中，负载均衡LB组件211被以库(Library)文件的形式集成到客户端21的服务进程里。此外，服务器23会提供一个服务注册表(Service Registry)支持服务自注册和自发现。每个计算节点 22启动时，首先到服务器23注册，将该计算节点所提供的服务的地址注册到服务注册表中，同时，每个计算节点22还可以定期上报心跳到服务注册表，以表明该计算节点22的服务的存活状态。当客户端21中的服务进程要访问目标服务时，首先通过内置的LB组件211去服务注册表中查询与目标服务对应的地址列表，然后基于某种负载均衡策略选择一个目标服务地址，最后向该目标服务地址所指示的计算节点22发起请求，需要说明的是，本方案中所采用的负载均衡策略，仅需考虑提供目标服务的计算节点的负载均衡问题。然而，客户端负载均衡方案的弊端在于：首先，如果开发企业内使用多种不同的语言栈，相应的，就需要开发多种不同的客户端，会显著增加研发和维护成本；其次，在客户端交付给使用者之后，如果要对库文件进行升级，修改库文件的代码，就需要使用者的配合，可能因使用者的配合程度不够，使得升级过程遭受阻力。

基于此，本发明提供了一种新的负载均衡方案，以克服现有技术中存在的诸多问题。

发明内容