负载均衡引擎，客户端，分布式计算系统以及负载均衡方法与流程

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

背景技术：

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

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

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

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

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

技术实现要素：

本发明实施例提供一种新的负载均衡方案，以解决现有技术无法处理大流量的服务调用的问题，同时，可以节约开发成本，利于升级维护。

第一方面，本发明实施例提供了一种负载均衡引擎，应用于分布式计算系统，包括：负载信息管理模块，用于获取所述分布式计算系统的全局负载信息，所述全局负载信息指示了所述分布式计算系统中的m个计算节点各自的负载；服务信息管理模块，用于获取所述分布式计算系统的全局服务信息，所述全局服务信息指示了所述m个计算节点所提供的服务的类型，其中，m为大于1的自然数；策略计算模块，用于针对第一服务类型，利用所述全局负载信息以及所述全局服务信息进行负载均衡计算，生成与所述第一服务类型相对应的第一负载均衡策略，其中，所述第一服务类型为所述m个计算节点所提供的服务的类型中的至少一种，所述第一负载均衡策略指示了与所述第一服务类型对应的服务消息在所述m个计算节点中的分发信息；策略发布模块，用于将所述第一负载均衡策略发布给客户端。由于负载均衡引擎只负责负载均衡策略的计算，并将生成的负载均衡策略发送给客户端，由各个客户端独立进行服务消息的调度，从而可以避免大量服务调用对于负载均衡引擎的冲击，不会因为集中处理服务调用时，因无法应对大流量的服务调用而导致系统障碍。同时，当开发者升级分布式系统时，只需要升级负载均衡引擎即可，便于升级。此外，即便开发者使用多种语言栈，也只需针对不同语言栈开发一个负载均衡引擎即可，而客户端使用通用代码来调用负载均衡引擎发布的负载均衡策略，可以节省大量的开发成本。

在一种可能的实施方式中，所述负载均衡引擎还包括：服务全局视图，用于获取所述m个计算节点之间的服务调用关系；所述策略计算模块则用于用于针对所述第一服务类型，利用所述负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成所述第一负载均衡策略。由于一个服务可能需要调用其它服务来处理客户端的服务消息，如果第一服务类型的服务所在的计算节点的负载低，但是该计算节点调用的其它服务所在的计算节点的负载高，同样会影响服务质量，因此，在生成第一负载均衡策略时，将与第一服务类型的服务所在的计算节点，以及与该计算节点存在调用关系的其他计算节点的负载均考虑进来，有利于提高分布式计算系统整体的计算性能，降低服务时延。

在一种可能的实施方式中，所述策略计算模块具体用于：根据所述全局服务信息，从所述m个计算节点中确定提供所述第一服务类型的服务的目标计算节点；根据所述服务调用关系，从所述m个计算节点中确定与所述目标计算节点提供的所述第一服务类型的服务存在调用关系的相关计算节点；根据所述全局负载信息，确定所述目标计算节点以及所述相关计算节点的负载，并进行负载均衡计算，生成所述第一负载均衡策略。

在一种可能的实施方式中，所述策略计算模块具体用于根据如下目标函数生成所述第一负载均衡策略，

其中，t(si)表示第i个服务消息的消息链的服务时延，t表示n个服务消息的消息链的服务时延的平均值。本实施方式中，通过平衡吞吐量与响应时间的关系，可以实现较好的负载均衡。

在一种可能的实施方式中，所述策略计算模块还用于：基于预设的服务时延，利用所述全局负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成第二负载均衡策略，所述第二负载均衡策略用于指示所述m个计算节点进行服务调整；所述策略发布模块，还用于将所述第二负载均衡策略发布给所述m个计算节点。通过对m个计算节点现有的服务进行调整，可以进一步优化分布式计算系统的计算性能，降低服务时延。

在一种可能的实施方式中，所述第二负载均衡策略指示了对存在服务调用关系的至少两个计算节点之间的服务消息的分发比例进行调整。

在一种可能的实施方式中，所述第二负载均衡策略指示了对存在服务调用关系的计算节点之间的服务位置进行调整。

在一种可能的实施方式中，所述第二负载均衡策略指示了对存在服务调用关系的计算节点之间的服务进行扩容或者删减。

在一种可能的实施方式中，所述全局负载信息，所述全局服务信息以及所述服务调用关系均是周期性获取的；所述策略计算模块，用于周期性地计算所述第一负载均衡策略或所述第二负载均衡策略，并通过所述策略发布模块进行周期性地发布。通过周期性地更新负载均衡策略，可以使分布式计算系统的性能，始终保持在一个较高的水平上。

第二方面，本发明实施例提供了一种客户端，应用于分布式计算系统，所述分布式计算系统包括负载均衡引擎以及m个计算节点，其中，m为大于1的自然数，所述客户端包括：本地缓存，用于获取并缓存由所述负载均衡引擎发布的第一负载均衡策略，所述第一负载均衡策略指示了第一服务类型的服务消息的分发信息；服务管理模块，用于接收第一服务请求；负载策略计算模块，用于查询所述本地缓存，在所述本地缓存存储的所述第一负载均衡策略与所述第一服务请求匹配的情况下，根据所述第一负载均衡策略指示的分发信息，从所述m个计算节点中确定与所述第一服务请求相匹配的目标计算节点；所述服务管理模块，还用于根据所述第一负载均衡策略指示的分发信息，将所述第一服务请求对应的服务消息，发送给所述目标计算节点。由于客户端只需接收并缓存与每种服务类型对应的负载均衡策略，当与某种服务类型对应的服务消息需要调用时，查询缓存的负载均衡策略，即可完成服务消息调度。因此，即使开发者使用不同的语言栈，也不需要针对每种语言栈分别开发客户端，可以采用一些通用的代码即可实现负载均衡策略的接收以及查询，从而节约了大量的研发成本，也降低了升级分布式计算系统时的阻力。

第三方面，本发明实施例还提供了一种分布式计算系统，包括：如第一方面以及第一方面的任一可能的实施方式中所述的负载均衡引擎，以及耦合至所述负载均衡引擎的m个计算节点。本实施例提供的分布式计算系统中，由于负载均衡引擎负责负载均衡策略的计算，而各个客户端分别根据负载均衡策略进行服务调用，也就是说，对负载均衡策略的计算及执行进行了分离，避免了图1所示的集中式负载方均衡案中，因负载均衡器12难以处理大流量的服务调用而制约系统性能的问题，同时，当开发者采用了多种不同的语言栈时，由于客户端中进行服务调用的代码可以保持一致，因此不需要开发多种版本的客户端，而只需要针对不同的语言栈开发不同的负载均衡引擎即可，后续如果分布式计算系统需要升级时，也只需要对负载均衡引擎进行更新，因而可以节约开发成本，以及减少升级阻力。

在一种可能的实施方式中，所述分布式计算系统还包括：如第二方面所述的客户端。

在一种可能的实施方式中，所述分布式计算系统还包括：注册服务器，用于收集所述m个计算节点的所述全局服务信息，并将所述全局服务信息发送给所述负载均衡引擎。

在一种可能的实施方式中，所述分布式计算系统还包括：

监控模块，用于通过监控所述m个计算节点的负载，获取所述全局负载信息并发送给所述负载均衡引擎。

在一种可能的实施方式中，所述分布式计算系统还包括：管理节点，用于接收所述负载均衡引擎发送的所述第二负载均衡策略，并根据所述第二负载均衡策略，对所述m个计算节点进行服务调整。

第四方面，本发明实施例还提供了一种负载均衡方法，应用于分布式计算系统，包括：获取所述分布式计算系统的全局负载信息，所述全局负载信息指示了所述分布式计算系统中的m个计算节点各自的负载；获取所述分布式计算系统的全局服务信息，所述全局服务信息指示了所述m个计算节点所提供的服务的类型，其中，m为大于1的自然数；针对第一服务类型，利用所述全局负载信息以及所述全局服务信息进行负载均衡计算，生成与所述第一服务类型相对应的第一负载均衡策略，其中，所述第一服务类型为所述m个计算节点所提供的服务的类型中的至少一种，所述第一负载均衡策略指示了与所述第一服务类型对应的服务消息的分发信息；将所述第一负载均衡策略发布给客户端。本实施例提供的方法中，由于负载均衡引擎负责负载均衡策略的计算，而各个客户端分别根据负载均衡策略进行服务调用，也就是说，对负载均衡策略的计算及执行进行了分离，避免了难以处理大流量的服务调用而制约系统性能的问题，同时，当开发者采用了多种不同的语言栈时，不需要开发多种版本的客户端，而只需要针对不同的语言栈开发不同的负载均衡引擎即可，后续升级时，也只需要对负载均衡引擎进行更新，因而可以节约开发成本，以及减少升级阻力。

在一种可能的实施方式中，所述方法还包括获取所述m个计算节点之间的服务调用关系；则针对第一服务类型，利用所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成与所述第一服务类型相对应的第一负载均衡策略的步骤包括：针对所述第一服务类型，利用所述全局负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成所述第一负载均衡策略。

在一种可能的实施方式中，针对所述第一服务类型，利用所述全局负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成所述第一负载均衡策略的步骤包括：根据所述全局服务信息，从所述m个计算节点中确定提供所述第一服务类型的服务的目标计算节点；根据所述服务调用关系，从所述m个计算节点中确定与所述目标计算节点提供的所述第一服务类型的服务存在调用关系的相关计算节点；根据所述全局负载信息，确定所述目标计算节点以及所述相关计算节点的负载，并进行负载均衡计算，生成所述第一负载均衡策略。

在一种可能的实施方式中，所述方法还包括：基于预设的服务时延，利用所述全局负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成第二负载均衡策略，所述第二负载均衡策略用于指示所述m个计算节点进行服务调整；将所述第二负载均衡策略发布给所述m个计算节点。

在一种可能的实施方式中，所述第二负载均衡策略指示了对存在服务调用关系的至少两个计算节点之间的服务消息的分发比例进行调整。

在一种可能的实施方式中，所述第二负载均衡策略指示了对存在服务调用关系的计算节点之间的服务位置进行调整。

在一种可能的实施方式中，所述第二负载均衡策略指示了对存在服务调用关系的计算节点之间的服务进行扩容或者删减。

第五方面，本发明实施例还提供了一种负载均衡方法，应用于分布式计算系统中的客户端，所述方法包括：获取并缓存由所述负载均衡引擎发布的第一负载均衡策略，所述第一负载均衡策略指示了第一服务类型的服务消息的分发信息；接收第一服务请求；查询缓存的所述第一负载均衡策略，在缓存的所述第一负载均衡策略与所述第一服务请求匹配的情况下，根据所述第一负载均衡策略指示的分发信息，从所述m个计算节点中确定与所述第一服务请求相匹配的目标计算节点；根据所述第一负载均衡策略指示的分发信息，将所述第一服务请求对应的服务消息，发送给所述目标计算节点。

第六方面，本发明实施例还提供了一种负载均衡方法，应用于分布式计算系统中的计算节点或者管理节点，所述方法包括：接收负载均衡引擎发送的第二负载均衡策略；根据所述第二负载均衡策略，对计算节点进行服务调整。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1为现有技术提供的一种集中式负载均衡方案的示意图；

图2为现有技术提供的另一种负载均衡方案的示意图；

图3为本发明实施例提供的一种分布式计算系统的架构图；

图4为图3所示的分布式计算系统中的各个装置的结构示意图；

图5为本发明实施例提供的一种服务间调用关系的示意图；

图6为本发明实施例提供的一种针对存在服务调用关系的计算节点进行负载均衡的示意图；

图7a、7b为本发明实施例提供的一种对服务消息的分发比例进行调整的示意图；

图8a、8b为本发明实施例提供的一种对服务位置进行调整的示意图；

图9a、9b、9c为本发明实施例提供的一种对服务进行扩容的示意图；

图10为本发明实施例提供的另一种负载均衡引擎的装置示意图；

图11为本发明实施例提供的一种客户端的装置示意图；

图12为本发明实施例提供的一种应用于负载均衡引擎的负载均衡方法的流程示意图；

图13为本发明实施例提供的一种应用于客户端的负载均衡方法的流程示意图；

图14为本发明实施例提供的一种应用于计算节点(或管理节点)的负载均衡方法的流程示意图。

具体实施方式

本发明实施例提供了一种分布式计算系统的架构图。如图3所示，该分布式计算系统30可以包括：客户端31，负载均衡引擎32，以及包括m个计算节点的服务提供方(serviceprovider)33，其中，客户端31，负载均衡引擎32以及服务提供方33中的各个计算节点，分别通过网络34进行相互通信，m为大于1的整数。本实施例中，网络34可以是有线网络，无线网络，局域网(lan)，广域网(wan)，以及移动通信网络等。示例性的，客户端31可以通过接入点(accesspoint，ap)341接入网络34，以便与负载均衡引擎32或服务提供方33中的任一计算节点进行通信。

需要说明的是，为了简便起见，在图3中只示出了3个计算节点，即计算节点331，计算节点332，以及计算节点333，在实际应用中，计算节点的数量可以根据分布式计算系统对计算资源的需求进行部署，不限于3个。此外，在分布式计算系统中，计算节点通常采用集群式部署，也就是说，分布式计算系统中的所有计算节点可以分为多个集群，而本实施例中所说的m个计算节点，可以是所有集群中的计算节点，也可以是其中一个或者多个集群中的计算节点。

图4进一步示出了分布式计算系统30中的各个装置的内部结构，以下结合图4，对分布式计算系统30做进一步说明。

如图4所示，负载均衡引擎32可以包括：负载信息管理模块321，服务信息管理模块322，策略计算模块323以及策略发布模块324；其中，

负载信息管理模块321，用于获取分布式计算系统30的全局负载信息，所述全局负载信息指示了服务提供方33中的所述m个计算节点各自的负载；

服务信息管理模块322，用于获取全局服务信息，所述全局服务信息指示了所述m个计算节点所提供的服务的类型，其中，每个计算节点可以提供至少一种类型的服务，本领域技术人员应当知道，在分布式计算系统中，计算节点，可以是个人电脑，工作站，服务器或者其它类型的物理机，或者还可以是虚拟机。而计算节点上的服务通常以进程的形式，运行在物理机或者虚拟机上，因此，一个计算节点上通常可以提供多种服务；

策略计算模块323，用于针对第一服务类型，利用所述全局负载信息以及所述全局服务信息进行负载均衡计算，得到与所述第一服务类型相对应的第一负载均衡策略，其中，所述第一服务类型为所述m个计算节点所提供的服务的类型中的至少一种，所述第一负载均衡策略指示了与所述第一服务类型对应的服务消息在所述m个计算节点中的分发信息，所述分发信息包括：分发对象，或者，所述分发信息包括：分发对象和分发比例；示例性的，在一种应用场景下，如果计算节点331、计算节点332和计算节点333都提供第一服务类型的服务，策略计算模块323根据全局负载信息，了解到计算节点331和计算节点332的负载过高，则可以生成第一负载均衡策略，以指示将计算节点333作为与第一服务类型的服务消息的分发对象；在另一种应用场景下，同样假设计算节点331、计算节点332和计算节点333都提供第一服务类型的服务，策略计算模块323根据全局负载信息，了解到计算节点331的负载过高，而计算节点332和计算节点333分别可以提供一部分处理能力，则可以生成第一负载均衡策略，以指示将计算节点332和计算节点333作为与第一服务类型的服务消息的分发对象，同时，第一负载均衡策略还可以分别指示计算节点332和计算节点333各自的分发比例；

策略发布模块323，用于将所述第一负载均衡策略发布给客户端31。

本实施例中，客户端31可以包括：

本地缓存311，用于获取并缓存由负载均衡引擎32发布的第一负载均衡策略，所述第一负载均衡策略指示了第一服务类型的服务消息的分发信息；

服务管理模块312，用于接收客户的第一服务请求；

负载策略计算模块313，用于响应所述第一服务请求，通过查询所述本地缓存311，确定所述本地缓存311存储的所述第一负载均衡策略与所述第一服务请求是否匹配，当所述本地缓存311存储的所述第一负载均衡策略与所述第一服务请求匹配时，就根据所述第一负载均衡策略指示的分发信息，从所述m个计算节点中确定与所述第一服务请求相匹配的目标计算节点，应当知道，由于第一负载均衡策略是针对第一服务类型指定的，当第一服务请求对应的服务也属于第一服务类型时，负载策略计算模块313就可以认为所述第一负载均衡策略与所述第一服务请求匹配，反之，则认为不匹配；

所述服务管理模块312，还用于根据所述第一负载均衡策略指示的分发信息，将所述第一服务请求对应的服务消息，发送给所述目标计算节点，从而使所述目标节点响应所述第一服务请求并提供服务。

这里对服务请求和服务消息的关系进行简要说明，在分布式计算领域，客户端31请求服务提供方33提供服务时，首先需要向服务提供方33提出服务请求，当服务提供方33相应该请求之后，将相应的服务消息发送给服务提供方33，由服务提供方33进行相应的运算处理，最后将处理后的结果反馈给客户端31，才算完成了一次服务。

本实施例提供的分布式计算系统30中，由于负载均衡引擎32负责负载均衡策略的计算，而各个客户端31分别根据负载均衡策略进行服务调用，也就是说，对负载均衡策略的计算及执行进行了分离，避免了图1所示的集中式负载方均衡案中，因负载均衡器12难以处理大流量的服务调用而制约系统性能的问题，同时，当开发者采用了多种不同的语言栈时，由于客户端31中进行服务调用的代码可以保持一致，因此不需要开发多种版本的客户端，而只需要针对不同的语言栈开发不同的负载均衡引擎32即可，后续如果分布式计算系统需要升级时，也只需要对负载均衡引擎32进行更新，因而可以节约开发成本，以及减少升级阻力。

本实施例中，负载均衡引擎32在获取全局负载信息时，可以直接收集所述m个计算节点各自的负载信息，通过汇总收集到的负载信息，得到所述全局负载信息；也可以在分布式计算系统30中设置用于监控所述m个计算节点的工作状态的监控模块35，例如：指标监控模块(metricmonitor)，并通过监控模块35获取所述全局负载信息。

进一步地，从所述m个计算节点收集的全局负载信息，包括但不限于如下几类负载：

1、资源占用信息，例如：中央处理器(cpu)占用率，内存占用率，网络带宽等占用率等；

2、吞吐量信息，例如：单位时间内每个服务收到的服务消息的数量，以及单位时间内每个服务对外发送的服务消息的数量以及发送对象的数量等；

3、服务时延信息，例如：服务消息的平均处理时延，服务消息在处理前的平均等待时延，服务间的通信时延等，需要说明的是，一个服务消息的处理时延与如下几项因素相关：1、服务所在的计算节点的中央处理器(cpu)或输入输出设备(i/o)等物理硬件的能力，2、服务所在的计算节点上是否有其它类型的服务会占用物理硬件等资源，3、与服务自身的处理逻辑相关，逻辑越复杂，相应的消息处理时延就会越多，本领域技术人员应当知道，与处理逻辑相关的消息处理时延，可以通过在一定时间段内采样进行确定；而服务消息的通信时延则与如下几项因素相关：1、该服务所在的计算节点的网络能力，例如网络带宽是1gb的还是10gb的，2、该服务所在的计算节点的网络是否有其它服务抢占，3、两个服务之间的通信距离，比如在两个服务在同一个计算节点上，则通信时延最小，跨计算节点通信则通信时延会长一些，跨数据中心通信，则通信时延更长；

4、剩余资源信息，例如：服务所在的计算节点的物理资源的剩余情况等。

本实施例中，服务信息管理模块322可以分别从所述m个计算节点收集服务信息，然后汇总收集到的服务信息，得到所述全局服务信息；也可以通过在分布式计算系统30中设置的注册服务器(serviceregister)34获取所述m个计算节点的全局服务信息，其中，每个计算节点在初始化时，会将该计算节点的服务信息注册到注册服务器34。

进一步地，全局服务信息具体可以包括：服务群组信息和部署信息，其中，服务群组信息指示了每个计算节点上部署的服务，按照服务类型进行分组后的分组信息，部署信息则指示了每个计算节点上部署的服务的处理能力以及每个计算节点的总处理能力等。需要说明的是，在计算机术语中，计算节点上部署的服务通常叫做服务实例(serviceinstance)，指计算节点上的服务的具体运行实体，而服务群组指由某一种服务类型(servicetype)的若干实例组成的集合，共同提供一种服务。

本实施例中，策略计算模块323，可以针对第一服务类型，利用所述全局负载信息以及所述全局服务信息，并基于预设的负载均衡算法进行负载均衡计算，得到与所述第一服务类型相对应的负载均衡策略。需要说明的是，策略计算模块323所采用的负载均衡的算法，通常可以分为两种：静态负载均衡算法和动态负载均衡算法。

其中，静态负载均衡算法可以包括：

1、轮询(roundrobin)：每一次轮循中，顺序地询问所述m个计算节点。当其中某个计算节点出现过载或故障时，就将该计算节点从由所述m个计算节点组成的顺序循环队列中拿出，不参加下一次的轮询，直到该计算节点恢复正常；

2、比例(ratio)：给每个计算节点分别设置一个加权值，以表征消息分配的比例，根椐这个比例，把客户端发送的服务消息分配到每个计算节点，当其中某个计算节点发生过载或故障时，就把该计算节点从所述m个计算节点组成的队列中拿出，不参加下一次的服务消息的分配，直到其恢复正常；

3、优先权(priority)：给所述m个计算节点分组，给每个组设置不同的优先级，然后将客户端的服务消息分配给优先级最高的计算节点组(在同一计算节点组内，采用轮询或比例算法，分配服务消息)，当最高优先级对应的计算节点组中所有计算节点出现过载或故障后，就将服务请求发送给优先级次高的计算节点组。

而动态负载均衡算法则可以包括：

1、最少的连接方式(leastconnection)：将服务消息分配给那些连接最少的计算节点处理，当连接最少的某个计算节点发生过载或故障，就不让该计算节点参加下一次的服务消息的分配，直到其恢复正常，其中，连接是指客户端与计算节点之间为了接收或者发送服务消息而保持的通信连接，连接数与该计算节点的吞吐量成正比；

2、最快模式(fastest)：将服务消息分配给那些响应最快的计算节点处理，当某个响应最快的计算节点发生过载或故障，就不让该计算节点参加下一次的服务消息的分配，直到其恢复正常，其中，每个计算节点的响应时间包括接收和发送服务消息的时间，以及处理服务消息的时间，应当知道，响应越快，则说明计算节点处理服务消息的时间越短，或者该计算节点与客户端之间的通信时间越短；

3、观察模式(observed)：以连接数目和响应时间之间的平衡为依据，将服务消息分配给平衡度最佳的计算节点处理，本领域技术人员应当知道，连接数目与响应时间是相互矛盾的，连接数越多，则意味着服务消息的吞吐量越大，相应的，处理服务消息所需的时间也就越多，因此，需要在两者之间寻求平衡，在不显著降低响应速度的前提下，尽可能处理更多的服务消息；

4、预测模式(predictive)：收集所述m个计算节点当前的各项性能指标，进行预测分析，在下一个时间段内，将服务消息分配给性能预测将达到最佳的计算节点处理；

5、动态性能分配(dynamicratio-apm):实时收集所述m个计算节点的各项性能参数并分析，并根据这些性能参数动态地进行服务消息的分配；

6、动态计算节点补充(dynamicserveract.):将所述m个计算节点的一部分设置为主计算节点群，其余的作为备份计算节点，当主计算节点群中因过载或故障导致数量减少时，动态地将备份计算节点补充至主计算节点群。

需要说明的是，本实施例中的负载均衡算法包括但不限于以上算法，示例性的，可以是以上的几种算法的组合，或者，还可以是客户根据自定义的规则指定的算法，以及现有技术中使用的各种算法。

本实施例中，可以通过负载均衡算法插件326，将客户自定义的负载均衡算法导入策略计算模块323并参与负载均衡策略的计算。通过这种方式，可以使分布式计算系统的运营者以更便利的方式参与的维护，比如：通过负载均衡算法插件326更新负载均衡算法，以实现系统升级。

随着分布式计算技术的发展，不同的服务间也会存在相互调用，也就是说，一个服务自身即是服务的提供者，又是服务的消费者，特别是随着分布式微服务的快速发展，微服务的消息链深度一般都大于1，其中，消息链大于1，表示一个服务需要调用至少一个其它服务。如图5所示，将服务(service)a看成是一个服务的消费者时，由于servicea需要调用serviceb，而serviceb依赖servicec来提供服务，因此，servicea的消息链为2。进一步地，现有的分布式计算系统中，每个服务只关注了下一级的服务的负载，也就是说，当servicea调用两个serviceb时，它的负载均衡策略只考虑2个serviceb自身的负载，以及2个serviceb所在的计算节点的负载，而不会考虑3个servicec以及3个servicec所在的计算节点的负载，而serviceb在调用servicec时，会根据3个serviceb的负载独立地做一次负载均衡，也就是说，当前的分布式计算系统在计算负载均衡策略是，并未关注servicea→servicec的整体负载均衡。

基于此，如图4所示的分布式计算系统30还可以包括：服务全局视图325，用于获取所述m个计算节点之间的服务调用关系。需要说明的是，图4中所示的servicea，serviceb以及servicec，可以是由同一个计算节点提供的，也可以是由不同的计算节点分别提供，因此，服务全局视图325获取的服务调用关系，既包括同一个计算节点上的不同服务之间的调用关系，又包括不同计算节点之间服务调用关系。此外，servicea调用serviceb，意味着servicea要提供完整的服务，依赖于serviceb所提供的部分服务。

相应的，所述策略计算模块323，可以具体用于针对所述第一服务类型，利用所述全局负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成所述第一负载均衡策略。

在一种可能的实施方式中，所述策略计算模块323可以具体用于：

基于全局服务信息，从所述m个计算节点中确定提供第一服务类型的服务的目标计算节点，其中，目标计算节点的数量可以为一个或者多个；

基于所述服务调用关系，从所述m个计算节点中确定与所述目标计算节点提供的第一服务类型的服务存在调用关系的相关计算节点，需要说明的是，这里使用目标计算节点和相关计算节点的说法，只是为了便于表述，应当知道，目标计算节点和相关计算节点，指的都是所述m个计算节点中，所提供的服务与第一服务类型相对应的计算节点；

根据全局负载信息，确定所述目标计算节点以及所述相关计算节点的负载，并基于预设的负载均衡算法进行负载均衡计算，生成所述第一负载均衡策略，其中，负载均衡算法可以参考前面关于静态负载均衡算法以及动态负载均衡算法的描述，不再赘述。

本实施例中，结合图6，假设第一服务类型的服务是servicea，则负载均衡引擎32中的策略计算模块323，将分别提供servicea计算节点1和计算节点2确定为目标计算节点；同时，由于无论计算节点1还是计算节点2所提供的servicea，与计算节点4和计算节点5提供的servicec之间都存在调用关系，因此，策略计算模块323还可以根据获取的服务调用关系，将计算节点4和计算节点5确定为相关计算节点；接下来，策略计算模块323根据全局负载信息，可以得到所述目标计算节点以及所述相关计算节点(即计算节点1，计算节点2，计算节点4以及计算节点5)各自的负载，然后通过负载均衡计算，生成所述第一负载均衡策略。后续当客户端31发出服务请求是servicea时，负载均衡引擎32就可以响应该服务请求并根据第一负载均衡策略，确定该服务请求相对应的服务消息的分发信息。

需要说明的是，本实施例中虽然只描述了如何计算与第一服务类型相匹配的第一负载均衡策略，本领域技术人员应当知道，分布式计算系统通常提供不止一种服务类型的服务，在实际应用中，负载均衡引擎还可以针对分布式计算系统所提供的每一种服务类型，生成一一对应的负载均衡策略，以支持对来自不同客户端的不同服务类型的服务消息的调度，其中，生成其它服务类型对应的负载均衡策略的方法，可以参考生成第一负载均衡策略的方法，不再赘述。

为了便于更好地说明本发明的技术方案，下面以采用观察模式作为负载均衡算法为例，对负载均衡策略的计算进行举例说明：

假设在当前的吞吐量水平下，分布式计算系统30所需调度的消息流中包括n个服务消息，如公式(1)所示，：

σ＝{σ1,σ2,...σi,...,σn}(1)

其中，σ表示n个服务消息的集合，即消息流，σi表示第i个服务消息，i和n均为自然数，且1≤i≤n；

n个服务消息的消息链如公式(2)所示：

其中，s表示n个服务消息的消息链的集合，si表示第i个服务消息的消息链的集合，si^ki表示第i个服务消息的消息链中的第k个服务，k为自然数；其中，消息链是指分布式计算系统中，处理任一个服务消息时所要调用的所有服务形成的链路，消息链可以通过服务全局视图325获取的服务调用关系确定；

其中，t(si)表示第i个服务消息的消息链所需花费的总时间，即服务时延，表示在第i个服务消息的消息链中所需的处理时延，表示在第i个服务消息的消息链中所需的通信时延，处理时延和通信时延可以由负载信息管理模块321获取的全局负载信息所确定；

如公式(4)所示，t表示n个服务消息的消息链的服务时延的平均值；

基于以上公式，可以得到评估吞吐量与响应时间的目标函数，如公式(5)所示：

当φ(s)的值最小时，表示吞吐量与响应时间之间的平衡最好。

本实施例中，进一步地，所述策略计算模块323，还可以用于基于预设的服务时延，利用所述全局负载信息以及所述全局服务信息进行负载均衡计算，生成第二负载均衡策略，所述第二负载均衡策略为指示所述m个计算节点中进行服务调整的策略；相应的，所述策略发布模块324，还可以用于将所述第二负载均衡策略发布给所述m个计算节点。需要说明的是，当一个节点(例如：计算节点a)为另一个节点(例如：计算节点b或者客户端)提供服务时，服务时延是指该节点从响应服务请求，接收服务消息，处理服务消息以及返回处理后的服务消息的全流程所花费的时间，服务时延又可以称为端到端时延。

本实施例中，服务时延具体可以根据不同服务对于时延的容忍度来设定，示例性的，对于低时延服务，则可以基于端到端时延最小的原则来设定，对于高时延服务，则可以综合分布式计算系统的整体性能，以及高时延服务对时延的容忍度，设定服务时延，此处不做具体限定。

在一种可能的实施方式中，所述第二负载均衡策略可以指示对存在服务调用关系的至少两个计算节点的服务的消息分发比例进行调整。以下结合图7a和7b对此做进一步说明。

假设分布式计算系统30当前的服务调用关系以及消息的分发比例如图7a所示，其中，servicea1和servicea2可以是两种不同类型的服务，也可以同一种类型的两个服务，serviceb1，serviceb2和serviceb3则是同一种类型的服务。计算节点331中的servicea1分别与计算节点331中的serviceb1，计算节点332中的serviceb2以及计算节点333中的serviceb3之间存在调用关系，而计算节点333中的servicea2分别与计算节点331中的serviceb1，计算节点332中的serviceb2以及计算节点333中的serviceb3之间存在调用关系；此外，servicea1和servicea2分别可以每秒发送3000消息(3000msg/s)给serviceb1，serviceb2和serviceb3，且3000消息是平均分配serviceb1，serviceb2和serviceb3的，而serviceb1，serviceb2和serviceb3的处理能力均为2000消息/每秒(2000msg/s)。在这种场景中，无论从servicea1发消息给serviceb2和serviceb3，还是从servicea2发消息给serviceb1和serviceb2，都需要进行跨节点通信，也就是说，总计有4000消息需要以跨节点通信的方式进行发送，应当知道，同一个计算节点内的服务之间通信时延，比跨节点通信的时延要小得多，因此，按照图7a所示的消息分发比例进行消息发送，会导致较大的时延，影响分布式计算系统的性能。

本实施例中，策略计算模块可以基于预设的服务时延，生成第二负载均衡策略，以指示对计算节点331，计算节点332以及计算节点333的服务的消息分发比例进行调整。如图7b所示，根据第二负载均衡策略，可以指示servicea1将2000消息发送给位于同一计算节点内的serviceb1，将1000消息发送给计算节点332中的serviceb2，类似的，可以指示servicea2将2000消息发送给位于同一计算节点内的serviceb3，将1000消息发送给计算节点332中的serviceb2，这样调整之后，只有2000消息需要以跨节点通信的方式进行发送，且图7b中的跨节点通信只需要跨一个计算节点，而图7a中需要跨两个计算节点。不难看出，基于服务时延最小原则进行消息分发比例的调整后，减少了不必要的跨节点通信，降低了整个分布式计算机系统的时延，从而提高了分布式计算系统的性能。

在另一种可能的实施方式中，所述第二负载均衡策略可以指示对存在服务调用关系的计算节点之间的服务位置进行调整。以下结合图8a和8b对此做进一步说明。

假设分布式计算系统当前的服务调用关系以及消息分发比例如图8a所示，其中，serviceb1和serviceb2是一种类型的两个服务，servicec1，servicec2和servicec3是另一种类型的服务。计算节点331中的servicea1分别与计算节点332中的serviceb1和serviceb2存在调用关系，而serviceb1和serviceb2又分别与计算节点333中的servicec1，servicec2和servicec3存在调用关系。现有技术中，每个服务只能感知它的下一步调用的服务的负载信息，即servicea只能感知到serviceb1和serviceb2(即计算节点332)的负载，在现有的负载均衡策略下，平均分配是最佳的负载均衡策略，所以servicea每秒发送的3000信息是平均分发给serviceb1和serviceb2。与此类似，serviceb1和serviceb2也是分别将各自的1500消息平均发送给servicec1，servicec2和servicec3。

而本发明实施例中，由于考虑了不同计算节点之间的服务调用关系，在负载均衡策略的计算中，负载均衡引擎可以综合计算节点332以及计算节点333的负载，以及预设的服务时延来计算第二负载均衡策略，以指示对计算节点332和计算节点333上部署的服务的位置进行调整。如图8b所示，第二负载均衡策略可以指示将原来部署在计算节点333上的servicec1部署到计算节点332上，并将原来部署在计算节点332上的servicec2部署到计算节点333上；同时，由于serviceb1和serviceb2的处理能力可以达到2000msg/s，而servicec1，servicec2及servicec3的处理能力为1000msg/s，servicea可以将2000消息分发给serviceb2，再由serviceb2平均分发给servicec2和servicec3，同时将剩下的1000消息分发给serviceb1，再由serviceb1分发给servicec1。从图8a中不难看出，共有6000消息需要进行跨节点通信。而在图8b中，根据第二负载均衡策略进行服务位置调整后，需要跨节点通信的只有3000消息，显著降低了了分布式计算系统的通信时延。

在又一种可能的实施方式中，所述第二负载均衡策略还可以指示对存在服务调用关系的计算节点之间的服务进行扩容或者删减。以下结合图9a至9c对此做进一步说明。

如图9a所示，servicea的消息发送路径为：servicea→serviceb→servicec→serviced→servicee。当负载均衡引擎通过收集的全局负载信息，发现serviceb的负载过高，且计算节点331和计算节点332均未满载时，可以指示在消息发送路径中扩展一个与serviceb相同类型的serviceb1来分担负载。进一步地，负载均衡引擎可以根据全局服务信息和服务调用关系来判断是在计算节点331还是在计算节点332上扩展serviceb1，考虑到服务时延最小原则，如果在计算节点332上在扩展serviceb1的话，由于从计算节点中的servicea发消息给计算节点332中的serviceb1，以及从serviceb1发消息给计算节点331中的servicec，都需要跨节点通信，从而不利于降低分布式计算系统的通信时延，因此，负载均衡引擎可以确定在计算节点331上扩展serviceb1将是最佳选择。

相应的，如图9b所示，负载均衡引擎可以通过第二负载均衡策略指示在计算节点331上扩展serviceb1来分担负载，以避免引起额外的跨节点通信。

进一步地，如图9c所示，若负载均衡引擎根据全局负载信息，发现serviceb负载过高，且计算节点331已经满载而计算节点332尚未满载时，负载均衡引擎可以指示在计算节点332上扩展一个与serviceb类型相同的服务serviceb2来分担servicebd的负载，同时扩展与servicec类型相同的服务servicec2，相比图9b，同样没有增加额外的跨节点通信，只是由于计算节点332中多扩展了一个servicec2，在节点内通信的时延上略有增加。

随着分布式计算系统的发展，在以集群的方式部署计算节点时，会引入一些先进的系统框架，例如：hadoop，mesos，marathon等框架，相应的，如图4所示，分布式计算系统30还可以引入一个管理节点36(例如：mesosmaster)，并通过一个管理节点去管理各个计算节点。因此，所述策略发布模块324可以将所述第二负载均衡策略发布给管理节点36，并由所述管理节点36指示所述m个计算节点进行服务调整。当然，也可以将管理节点36的管理功能，分散到各个计算节点中，由各个计算节点根据第二负载均衡策略进行服务调整。

如图4所示的分布式计算系统30中，由于每个计算节点的负载会实时变化，且由于通过第二负载均衡策略可以对各个计算节点部署的服务进行调整，因此，所述全局负载信息，所述全局服务信息以及所述服务调用关系，均是周期性获取的；相应的，策略计算模块323，也用于周期性的计算所述第一负载均衡策略以及所述第二负载均衡策略，并通过所述策略发布模块323进行周期性地发布。与此相应的，客户端31也可以周期性地获取负载均衡引擎32发布的所述第一负载均衡策略，而计算节点(或管理节点)也可以周期性地获取负载均衡引擎32发布的所述第二负载均衡策略。

在本实施例中，负载均衡引擎32中的各个模块，可以由集成电路(lsi)，数字信号处理器(dsp)，现场可编程门阵列(fpga)，数字电路等硬件方式实现。类似的，客户端31中的各个模块也可以通过上述硬件来实现。

在另一种实施例中，负载均衡引擎可以采用如图10所示的通用计算设备来实现。图10中，负载均衡引擎400中的元件可以包括但并不限于：系统总线410，处理器420，和系统存储器430。

处理器420通过系统总线410与包括系统存储器430在内的各种系统元件相耦合。系统总线410可以包括：工业标准结构(isa)总线，微通道结构(mca)总线，扩展isa(eisa)总线，视频电子标准协会(vesa)局域总线，以及外围器件互联(pci)总线。

系统存储器430包括：易失性和非易失性的存储器，例如，只读存储器(rom)431和随机存取存储器(ram)432。基本输入/输出系统(bios)433一般存储于rom431中，bios433包含着基本的例行程序，它有助于各元件之间通过系统总线410中进行的信息传输。ram432一般包含着数据和/或程序模块，它可以被处理器420即时访问和/或立即操作。ram432中存储的数据或者程序模块包括但不限于：操作系统434，应用程序435，其他程序模块436和程序数据437等。

负载均衡引擎400还可以包括其他可拆卸/非拆卸，易失性/非易失性的存储介质。示例性的，硬盘存储器441，它可以是非拆卸和非易失性的可读写磁媒介外部存储器451，它可以是可拆卸和非易失性的各类外部存储器，例如光盘、磁盘、闪存或者移动硬盘等；硬盘存储器441一般是通过非拆卸存储接口440与系统总线410相连接，外部存储器一般通过可拆卸存储接口450与系统总线410相连接。

上述所讨论的存储介质提供了可读指令，数据结构，程序模块和负载均衡引擎400的其它数据的存储空间。例如，硬盘驱动器441说明了用于存储操作系统442，应用程序443，其它程序模块444以及程序数据445。值得注意的是，这些元件可以与系统存储器430中存储的操作系统434，应用程序435，其他程序模块436，以及程序数据437可以是相同的或者是不同的。

在本实施例中，前述实施例以及图4中所示的负载均衡引擎32中的各个模块的功能，可以由处理器420通过读取并执行存储在上述存储介质中的代码或者可读指令来实现。

此外，客户可以通过各类输入/输出(i/o)设备471向负载均衡引擎400输入命令和信息。i/o设备471通常是通过输入/输出接口460与处理器420进行通信。例如，当客户需要采用自定义的负载均衡算法，客户就可以通过i/o设备471将自定义的负载均衡算法提供给处理器420，以便处理器420根据该自定义负载均衡算法计算负载均衡策略。

负载均衡引擎400可以包括网络接口460，处理器420通过网络接口460，与远程计算机461(即分布式计算系统30中的计算节点)进行通信，从而获取前述实施例所描述的全局负载信息，全局服务信息以及服务调用关系，并基于这些信息，通过执行存储介质中的指令，计算负载均衡策略(第一负载均衡策略以及第二负载均衡策略)；然后将计算的负载均衡策略发布给客户端或者计算节点。

在另一种实施例中，客户端可以采用如图11所示的结构来实现。如图11所示，客户端500可以包括：处理器51，存储器52以及网络接口53，其中处理器51，存储器52以及网络接口53通过系统总线54实现相互通信。

网络接口53用于获取由负载均衡引擎发布的第一负载均衡策略并缓存在存储器52中，所述第一负载均衡策略指示了第一服务类型的服务消息的分发信息；

处理器51，用于接收第一服务请求，并查询所述存储器52，确定所述存储器52存储的所述第一负载均衡策略与所述第一服务请求是否匹配；

处理器51，还用于在所述存储器52存储的所述第一负载均衡策略与所述第一服务请求匹配的情况下，根据所述第一负载均衡策略指示的分发信息，从所述m个计算节点中确定与所述第一服务请求相匹配的目标计算节点，并根据所述第一负载均衡策略指示的分发信息，通过网络接口53将所述第一服务请求对应的服务消息，发送给所述目标计算节点。

需要说明的是，处理器51在执行相应的功能时，是根据存储在存储器52或者其它存储装置中的指令进行的。进一步地，图11所示的客户端采用的是通用计算机的结构，而前述的计算节点，也可以是采用通用计算机结构的物理机，因此，计算节点的结构也可以参考图11所示的结构，只是处理器执行不同的功能而已，不再赘述，同时，计算节点所提供的各种服务，也就是运行在处理器上的各种进程。

如图12所示，本发明实施例还提供了一种负载均衡方法，应用于如图3或图4所示的分布式计算系统。所述方法包括如下步骤：

s101：获取所述分布式计算系统的全局负载信息，所述全局负载信息指示了所述分布式计算系统中的m个计算节点各自的负载；

s102：获取所述分布式计算系统的全局服务信息，所述全局服务信息指示了所述m个计算节点所提供的服务的类型，其中，m为大于1的自然数；

s104：针对第一服务类型，利用所述全局负载信息以及所述全局服务信息进行负载均衡计算，生成与所述第一服务类型相对应的第一负载均衡策略，其中，所述第一服务类型为所述m个计算节点所提供的服务的类型中的至少一种，所述第一负载均衡策略指示了与所述第一服务类型对应的服务消息的分发信息；

s105：将所述第一负载均衡策略发布给客户端。

所述方法还可以包括

s105：获取所述m个计算节点之间的服务调用关系；

则步骤s104可以包括：

针对所述第一服务类型，利用所述全局负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成所述第一负载均衡策略。

更具体地，步骤s104可以包括：

根据所述全局服务信息，从所述m个计算节点中确定提供所述第一服务类型的服务的目标计算节点；

根据所述服务调用关系，从所述m个计算节点中确定与所述目标计算节点提供的所述第一服务类型的服务存在调用关系的相关计算节点；

根据所述全局负载信息，确定所述目标计算节点以及所述相关计算节点的负载，并进行负载均衡计算，生成所述第一负载均衡策略。

所述方法还可以包括：

s106：基于预设的服务时延，利用所述全局负载信息，所述全局服务信息以及所述服务调用关系进行负载均衡计算，生成第二负载均衡策略，所述第二负载均衡策略用于指示所述m个计算节点进行服务调整；示例性的，所述第二负载均衡策略可以指示对存在服务调用关系的至少两个计算节点之间的服务消息的分发比例进行调整，或者，所述第二负载均衡策略可以指示对存在服务调用关系的计算节点之间的服务位置进行调整，或者所述第二负载均衡策略还可以指示对存在服务调用关系的计算节点之间的服务进行扩容或者删减。

s107：将所述第二负载均衡策略发布给所述m个计算节点。

需要说明的是，上述负载均衡方法均是由负载均衡引擎实施的，且并未限定各个步骤之间的先后顺序。由于该方法与前述负载均衡引擎的装置实施例相对应，因此，相关的方法细节可以参考前述的负载均衡引擎的装置实施例。此处不再赘述。

进一步地，如图13所示，本实施例还提供了一种负载均衡方法，应用于如图3或图4所示的分布式计算系统中的客户端，所述方法包括如下步骤：

s201：获取并缓存由所述负载均衡引擎发布的第一负载均衡策略，所述第一负载均衡策略指示了第一服务类型的服务消息的分发信息；

s202：接收第一服务请求；

s203：查询缓存的所述第一负载均衡策略，在缓存的所述第一负载均衡策略与所述第一服务请求匹配的情况下，根据所述第一负载均衡策略指示的分发信息，从所述m个计算节点中确定与所述第一服务请求相匹配的目标计算节点；

s204：根据所述第一负载均衡策略指示的分发信息，将所述第一服务请求对应的服务消息，发送给所述目标计算节点。

进一步地，如图14所示，本实施例还提供了一种负载均衡方法，应用于如图3或图4所示的分布式计算系统中的计算节点或者管理节点，所述方法包括如下步骤：

s301：接收负载均衡引擎发送的第二负载均衡策略；

s302：根据所述第二负载均衡策略，对计算节点进行服务调整。

应当理解，此处所描述的具体实施例仅为本发明的普通实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。