一种负载均衡方法、装置、电子设备及计算机存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种负载均衡方法、装置、电子设备及计算机存储介质。

背景技术

微服务框架是一种新兴的软件架构，把一个大型复杂的应用程序分解为多个微服务，各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注完成一件任务并很好地完成该任务。

在框架的运行过程中，可能需要对微服务中各个实例的自定义指标进行管理。现有技术方案中，zookeeper(一个分布式的、开放源码的分布式应用程序协调服务)只有服务持久节点可以附加数据，而实例节点作为临时节点不可以附加数据，因此，无法用于同步实例的自定义指标。

而在polaris、istio等大型微服务系统管理工具产品中，实例可以拥有元数据信息，并可以实现基于实例元数据的流量管理方案。尽管如此，像副本活动开启时希望将请求发送到在线玩家最多且没有过载的服务提供端、普通登录时希望将请求发送到玩家较少的服务提供端等场景，玩家数、当前负载等业务自定义指标信息难以使用元数据进行表示，因而上述现有方案中，难以满足这些特殊使用场景。

在这种条件下，如图1所示，业务一般采用单独的调度/状态管理服务来对集群内所有进程进行指标管理，此时业务需要在接入一个名字服务的同时，部署根据业务场景实现的调度服务。特别是如果有些资源是一些全局管理资源，还需要额外的调度中心去做资源管理，这样对基于名字编程的业务来说，十分不友好。另外，还需要考虑调度服务的高可用、容灾方案，有较高的机器成本和运维成本。

发明内容

本申请所要解决的技术问题在于，提供一种负载均衡方法、装置、电子设备及计算机存储介质，能够解决相关技术中存在的上述问题。

为了解决上述技术问题，一方面，本申请提供了一种负载均衡方法，所述方法包括：服务提供端响应于实例变更请求向名字服务服务器发送实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息；所述名字服务服务器将所述实例变更通知转发至集群内其余的名字服务服务器；各个所述名字服务服务器分别向与其连接的服务发起端转发所述实例变更通知；各个所述服务发起端基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表；当任一所述服务发起端接收到来自客户端的访问请求后，所述服务发起端基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

另一方面，本申请提供了一种负载均衡方法，所述方法包括：接收集群中对应的名字服务服务器发送的实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息，所述实例变更通知为服务提供端响应于实例变更请求而向对应的名字服务服务器发送、并由对应的名字服务服务器转发至集群内的其余的名字服务服务器，各个所述名字服务服务器能够分别向与其连接的服务发起端转发所述实例变更通知；基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表；当接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

另一方面，本申请提供了一种负载均衡装置，所述装置包括：通知接收模块，用于接收集群中对应的名字服务服务器发送的实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息，所述实例变更通知为服务提供端响应于实例变更请求而向对应的名字服务服务器发送、并由对应的名字服务服务器转发至集群内的其余的名字服务服务器，各个所述名字服务服务器能够分别向与其连接的服务发起端转发所述实例变更通知；本地路由表更新模块，用于基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表；访问请求处理模块，用于在任一所述服务发起端接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

另一方面，本申请提供了一种电子设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行如上述的方法。

另一方面，本申请提供了一种计算机存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如上述的方法。

在本申请实施例中，服务发起端接收集群中与之对应的名字服务服务器发送的实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息，所述实例变更通知为服务提供端响应于实例变更请求而向对应的名字服务服务器发送、并由对应的名字服务服务器转发至集群内的其余的名字服务服务器，并基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表，以及当接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。如此，可以平衡服务提供端的实例的负载，对服务提供端进行过载保护，以及完成期望的业务逻辑，例如，副本活动开启时将请求发送到在线玩家数量最多且没有过载的服务提供端，而普通登录时则将请求发送到在线玩家数量最多且没有过载的服务提供端；另外，对原本以接入且实现业务调度服务的业务而言，可以将业务模块中的调度服务的功能集成到基础组件中去，减少业务层的服务个数，同时，也不需要考虑调度服务的高可用、容灾方案，可以降低开发、机器和运维成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是现有技术中接入调度服务的示意图；

图2是本申请实施例提供的硬件环境示意图；

图3是本申请实施例提供的一种负载均衡方法的流程图；

图4是本申请实施例提供的一种负载均衡方法的应用场景图；

图5是本申请实施例提供的另一种负载均衡方法的流程图；

图6是本申请实施例提供的一种负载均衡方法中转发访问请求至目标实例的方法的流程图；

图7是本申请实施例提供的一种负载均衡方法中转发访问请求至目标实例的方法的另一流程图；

图8是本申请实施例提供的一种负载均衡方法中确定实例在目标实例组中的权重的方法的流程图；

图9是本申请实施例提供的一种负载均衡方法中对选中的目标实例进行本地指标调整的方法的流程图；

图10是本申请实施例提供的一种负载均衡装置的结构示意图；

图11是本申请实施例提供的一种负载均衡设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述。显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请涉及以下关键术语，以下为各关键术语的含义。

Service/服务：应用程序的功能单元或功能单元的组合，拥有唯一的指定的名称，可包含若干实例。

Instance/实例：Service的实例，提供服务能力的一个进程实现。Service与Instance的关系类似于面向对象中的Class与其Object的关系，即Instance为实例化的Service。

RecvServer/服务提供端：作为目的端和服务提供方，在集群中被SendServer调用。

SendServer/服务发起方：作为发送端和调用发起方，在集群中调用RecvServer。

TbusppNS/名字服务服务器：具有反向通知能力，能将Service/Instance的变更传递给其他Instance。

TbusppAgent：Tbuspp自研的专为游戏开发场景中面向服务架构设计的L4代理和通信总线。

本申请实施例提供了一种负载均衡方法，可选地，在本申请实施例中，上述的负载均衡方法可以应用于如图2所示的服务提供端101、名字服务服务器102、服务发起端103和用户终端104所构成的硬件环境中。其中，服务提供端101的实例的自定义指标信息发生变更时，可以通过名字服务服务器同步至服务发起端103，进而当用户终端104通过安装的客户端向服务发起端103发送访问请求，服务发起端103可以基于本地路由表将访问请求转发给服务提供端101。

其中，服务提供端101、名字服务服务器102和服务发起端103可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

如图2所示，服务提供端101、名字服务服务器102、服务发起端103和用户终端104之间分别通过网络进行连接，上述网络包括但不限于：广域网、城域网或局域网。

作为一个可能的实施方式，服务提供端101、名字服务服务器102、服务发起端103和用户终端104均可以是区块链系统中的节点设备，能够将获取到以及生成的信息共享给区块链系统中的其他节点设备，实现多个节点设备之间的信息共享。区块链系统中的多个节点设备可以配置有同一条区块链，该区块链由多个区块组成，并且前后相邻的区块具有关联关系，使得任一区块中的数据被篡改时都能通过下一区块检测到，从而能够避免区块链中的数据被篡改，保证区块链中数据的安全性和可靠性。

以下对本申请实施例提供的一种负载均衡方法进行说明，如图3所示，所述方法包括：

步骤S301：服务提供端响应于实例变更请求向名字服务服务器发送实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息；

在本申请实施例中，所述实例变更请求包括实例上线请求、实例下线请求和实例运行期间发起的指标同步请求中的至少一种，其中，所述实例上线请求是指实例将自身注册至名字服务服务器，使其能够内集群内其他实例发现的请求，所述实例下线请求是指实例将自身从名字服务服务器中注销，使其不能被集群内其他实例发现的请求，所述实例上线请求一般为进程初始化时的必要过程，进程由初始化至提供服务的过程为：进程开始执行→发送实例上线请求→上线成功→正常服务…。

实例运行期间发起的指标同步请求的触发由业务层决定，可以为周期性发送，也可以为变化达到一定量时进行发送，通常为前者。

所述自定义指标信息可以为非文本内容，无法通过元数据进行表达。假定业务自定义指标为当前在线人数、CPU情况，值分别为10000和90，在序列化为字节时，可能序列化为{"online_users":10000,"cpu":90},也可能序列化为"\020\'\000\000Z\000\000\000"，此处的序列化与程序具体实现有关。

在实际应用中，如图4中的步骤1所示，所述服务提供端可以调用与实例变更请求对应的接口(当实例变更请求为实例上线请求，调用对应的启动接口；当实例变更请求为指标同步请求，调用对应的同步指标接口)，将所述实例上线请求发送至本地的TbusppAgent；如图4中的步骤2所示，TbusppAgent收到服务提供端发送的实例变更请求后将其转发至名字服务服务器。

步骤S303：所述名字服务服务器将所述实例变更通知转发至集群内其余的名字服务服务器；

在实际应用中，所述名字服务服务器在接收到所述实例变更请求后将产生实例变更通知，如图4中的步骤3所示，所述名字服务服务器在接收到实例变更通知后发送至集群内其余所有的名字服务服务器，并同时将实例变更通知中的实例信息和自定义指标信息写入数据库。

步骤S305：各个所述名字服务服务器分别向与其连接的服务发起端转发所述实例变更通知；

在实际应用中，如图4中步骤4所示，所有所述名字服务服务器将实例变更通知发送给与自身建立连接的TbusppAgent；如图4中步骤5所示，TbusppAgent再将实例变更通知转发给其管理的服务发起端和服务提供端。进一步的，如图4中步骤6所示，TbusppAgent会在收到名字服务服务器发送的实例变更通知时向该名字服务服务器回复收到了此次通知或TbusppAgent响应超时；如图4中步骤7所示，集群内名字服务服务器向发起实例变更通知的名字服务服务器回复此次通知的结果；如图4中步骤8所示，发起实例变更通知的名字服务服务器向发起实例变更通知的TbusppAgent转发此次通知的结果；如图4中步骤9所示，发起实例变更通知的TbusppAgent再将此次通知的结果转发给发起实例变更通知的服务提供端。

如果所述实例变更请求是实例上线请求，并且通知的结果为响应超时，那么会引起实例初始化失败，业务方应重新拉起进程尝试；如果所述实例变更请求是指标同步请求，并且通知的结果为响应超时，那么可以忽略本次请求，在下一周期重新上报即可。原则上，名字服务的相关错误和故障，不能影响正在运行的实例，所以设计上允许指标同步请求的失败。

步骤S307：各个所述服务发起端基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表；

在本申请实施例中，所述本地路由表中包括已有的实例信息和自定义指标信息，当各个服务发起端接收到所述实例变更通知后，利用所述实例变更通知中的实例信息和自定义指标信息更新所述本地路由表中已有的实例信息和自定义指标信息。

在实际应用中，如图4所示，在步骤5之后，所有所述服务发起端和所述服务提供端均可以更新本地路由表中的实例信息和自定义指标信息。

步骤S309：当任一所述服务发起端接收到来自客户端的访问请求后，所述服务发起端基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

在本申请实施例中，可以通过随机、轮询等选路算法确定目标实例，也可以基于各个实例的自定义指标信息进行加权随机、加权轮询等，还可以根据各个实例的自定义指标信息计算各个实例的权重，并直接选择权重最大的实例作为目标实例。也即，业务方可以根据其业务逻辑选择其需要的选路算法确定目标实例，本申请实施例对此不作限制。

在本申请实施例中，服务发起端接收集群中与之对应的名字服务服务器发送的实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息，所述实例变更通知为服务提供端响应于实例变更请求而向对应的名字服务服务器发送、并由对应的名字服务服务器转发至集群内的其余的名字服务服务器，并基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表，以及当接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。如此，可以平衡服务提供端的实例的负载，对服务提供端进行过载保护，以及完成期望的业务逻辑，例如，副本活动开启时将请求发送到在线玩家数量最多且没有过载的服务提供端，而普通登录时则将请求发送到在线玩家数量最多且没有过载的服务提供端；另外，对原本以接入且实现业务调度服务的业务而言，可以将业务模块中的调度服务的功能集成到基础组件中去，减少业务层的服务个数，同时，也不需要考虑调度服务的高可用、容灾方案，可以降低开发、机器和运维成本。

并且，对原本以服务提供端广播自定义指标信息给服务发起端的服务实现业务而言，可以提供服务发起端被发现时就含有初始指标的功能，同时减少服务提供端广播导致的性能损耗。此外，还可以为业务提供更为通用的框架。

本申请实施例可用于如下应用场景：

a)服务提供端的各个实例所在服务器硬件差异较大，且无法进行明确分类，不能以元数据等通用方式设置路由权重；

b)服务提供端在容量不足时需要扩容，由于扩容前后的实例实际负载差异较大，业务希望能够将新的业务请求发送至新启动的服务提供端的实例上；

c)业务逻辑中，服务提供端中各个实例需要及时上报自身的运行状况(包含业务数据)，以便服务发起端每次都能选择一个合适的目标实例发送业务数据。

特别的，本申请实施例至少可用于如下游戏场景中：

a)对战服务节点的负载均衡，避免部分对战服务节点负载过高导致工作异常；

b)副本活动开启时，将玩家分配至在线玩家数量最多且没有过载的节点；

c)普通登录时，将玩家分配至玩家较少的节点，避免服务提供端负载高影响玩家体验；

d)相关联的业务请求聚集至同一节点，在其负载达到上限后再尝试分发至同服务下其他节点；

e)根据游戏内业务资源(道具等)的数量进行分发消息。

本申请实施例还提供了一种负载均衡方法，所述方法以任一服务发起端为执行主体，如图5所示，所述方法可以包括：

步骤S501：接收集群中对应的名字服务服务器发送的实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息，所述实例变更通知为服务提供端响应于实例变更请求而向对应的名字服务服务器发送、并由对应的名字服务服务器转发至集群内的其余的名字服务服务器，各个所述名字服务服务器能够分别向与其连接的服务发起端转发所述实例变更通知；

步骤S503：基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表；

步骤S505：当接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

本申请实施例中的技术细节，可参见本申请上一实施例所提供的方法。

在一些实施例中，如图6和图7所示，所述当接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例可以包括：

步骤S601：当接收到来自客户端的访问请求后，确定所述本地路由表中与所述访问请求对应的目标实例组；

在本申请实施例中，所述访问请求为来自客户端的业务请求，例如，来自客户端的游戏普通登录请求或副本活动开启请求。所述本地路由表中可以包括多个实例组，每个实例组可以对应一种特定服务类型的访问请求，例如，本地路由表中包括实例组A和实例组B，其中，实例组A对应游戏普通登录请求，实例组B对应副本活动开启请求，当访问请求为游戏普通登录请求时，将实例组A确定为目标实例组，当访问请求为副本活动开启请求时，将实例组B确定为目标实例组。

每个实例组中的实例可以为所述服务发起端基于服务类型或名称和路由规则描述的元数据信息筛选出的实例。例如，所述服务发起端基于副本活动开启请求和对应的路由规则描述的元数据信息(如当前负载需要小于等于预设负载、玩家数量需要大于等于预设玩家数量)对各个实例进行筛选，并将符合条件的实例添加至与副本活动添加请求对应的实例组中。

所述服务发起端可以在更新本地路由表时进行实例组中实例的筛选，从而可以在接收到来自客户端的访问请求后，确定本地路由表中与所述访问请求对应的目标实例组。

步骤S603：判断所述目标实例组是否需要更新；

在本申请实施例中，判断所述目标实例组是否需要更新即判断所述目标实例组中的实例信息或者与实例对应的自定义指标信息是否更新，例如，目标实例组中是否新增实例或者某一实例的自定义指标是否更新。

步骤S605：在所述目标实例组需要更新时，遍历所述目标实例组中的实例，并基于所述目标实例组中各个实例的自定义指标信息计算各个实例在所述目标实例组中的位置或权重；

在本申请实施例中，所述目标实例组中的位置或权重用于表征所述目标实例组中的实例被确定为目标实例的概率，实例在所述目标实例组中的位置越靠前，说明该实例被确定为目标实例的概率越大，或者，实例在所述目标实例组中的权重越大，说明该实例被确定为目标实例的概率越大。

例如，对于副本活动开启请求，可以基于目标实例组中各个实例的自定义指标信息如当前负载信息和玩家数量计算各个实例在所述目标实例组中的位置或权重，各个实例在所述目标实例组中的位置或权重与所述当前负载信息成反比，与玩家数量成正比。

本申请实施例对具体计算公式不作限制，只要能够体现上述正反比关系即可。需要说明的是，对于同一目标实例组中的实例，需要基于同一计算公式计算其在目标实例组中的位置或权重。

步骤S607：基于各个实例在所述目标实例组中的位置或权重确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

在本申请实施例中，将所述目标实例组中位置最靠前或者权重最大的实例确定为处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

在本申请实施例中，通过对本地路由表中的实例进行分组，可以在接收到访问请求时，能够快速地确定出对应的目标实例组；并且，通过判断目标实例组是否更新，以及在目标实例组需要更新时对目标实例组中的各个实例的位置或权重进行更新，并基于更新后的位置或权重确定出目标实例，从而可以增加确定出的目标实例的可靠性。也即，通过本申请实施例，可以提高服务的响应速度，并可以保证对服务提供端进行过载保护的可靠性。

在一些实施例中，如图6和图7所示，所述方法还可以包括：

步骤S604：在所述目标实例组不需要更新时，从与所述目标实例组对应的缓存中获取自平衡二叉查找树，所述自平衡二叉查找树为根据最近一次更新的所述目标实例组中各个实例的位置或权重构建、并保存在缓存中的数据结构；

步骤S606：根据所述自平衡二叉查找树确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

在本申请实施例中，所述自平衡二叉查找树为根据最近一次更新的目标实例组中各个实例的位置或权重而构建并保存在与所述目标实例组对应的缓存中的数据结构。

例如，在当前访问请求之前的上一次访问请求时，如果所述目标实例组需要更新，那么在对所述目标实例组中各个实例的位置或权重进行更新后，需要根据更新后的所述目标实例组中各个实例的位置或权重构建自平衡二叉树查找树，并将构建完的自平衡二叉查找树保存在与所述目标实例组对应的缓存中，据此，当接收到当前访问请求且所述目标实例组不需要更新时，能够直接基于缓存中的平衡二叉查找树确定处理当前访问请求的目标实例。

所述自平衡二叉查找树可以为红黑树，在构建红黑树时，可以将所述目标实例组中的各个实例依次插入，红黑树根据各个实例的位置或权重自平衡，在构建完红黑树后，红黑树的最左节点为位置最靠前或权重最小的节点，红黑树的最右节点为位置最靠后或权重最大的节点，在构建完红黑树后，将红黑树保存在与所述目标实例组对应的缓存中。据此，当接收到访问请求且所述目标实例组不需要更新时，可以将所述红黑树的最右节点直接确定为目标实例，以将请求转发至权重最大的节点；或将所述红黑树的最左节点直接确定为目标实例，以将请求转发至位置最靠前的节点。

在本申请实施例中，通过在目标实例组不需要更新时，直接从缓存中获取自平衡二叉查找树，并基于自平衡二叉查找树确定目标实例，可以减少从目标实例组中查找目标实例的时间，从而可以提高服务的响应速度。

在一些实施例中，如图8所示，所述在所述目标实例组需要更新时，遍历所述目标实例组中的实例，并基于所述目标实例组中各个实例的自定义指标信息计算各个实例在所述目标实例组中的位置或权重可以包括：

步骤S801：在所述目标实例组具有实例组更新标签时，确定所述目标实例组需要更新，所述实例组更新标签在所述目标实例组中的任一实例发生变更时设置；

步骤S803：遍历所述目标实例组中的实例，将所述目标实例组中具有实例更新标签的实例确定为待调整实例，所述实例更新标签用于表征具有该标签的实例发生了变更；

步骤S805：基于所述目标实例组中各个所述待调整实例的自定义指标信息更新各个所述待调整实例在所述目标实例组中的权重。

在本申请实施例中，在所述服务发起端更新本地路由表中的实例信息和自定义指标信息时，对变更的实例设置实例更新标签，以能快速检查实例组中的哪些实例需要更新，并对该变更的实例所在的实例组设置实例组更新标签，以能快速检查某一实例组是否需要更新。

例如，实例组A中最初包括实例a、实例b以及与各个实例对应的自定义指标信息，当实例a的自定义指标信息发生变更时，对实例a设置用于表征实例的自定义指标发生了变更的实例更新标签，并对实例组A设置实例组更新标签。如此，当接收到来自客户端的访问请求且实例组A为与该访问请求对应的目标实例组时，可以快速基于实例组A的标签判断出实例组A需要进行更新，在对实例组A中的实例进行遍历时，可以基于实例的标签判断实例a在实例组A中的位置或权重需要更新。

在实例b下线时，对实例b设置用于表征实例b已被删除的实例更新标签，并对实例组A设置实例组更新标签。如此，当接收到来自客户端的访问请求且实例组A为与该访问请求对应的目标实例组时，可以快速基于实例组A的标签判断出实例组A需要进行更新，在对实例组A中的实例进行遍历时，可以基于实例的标签判断实例b已从实例组A中移除。

在实例c上线时，实例组A中将会包括实例a、实例b和实例c，对实例c设置用于表征实例c为新上线实例的实例更新标签，并对实例组A设置实例组更新标签。如此，当接收到来自客户端的访问请求且实例组A为与该访问请求对应的目标实例组时，可以快速基于实例组A的标签判断出实例组A需要进行更新，在对实例组A中的实例进行遍历时，可以基于实例的标签判断实例c在实例组A中的位置或权重需要更新。

在本申请实施例中，通过对目标实例组设置实例组更新标签，可以快速地基于实例组更新标签确定目标实例组是否需要更新，并且，在所述目标实例组中的某一实例设置实例更新标签时，只需要重新根据该实例的自定义指标信息计算该实例的权重即可，无需对所述目标实例组中的所有实例均进行权重计算，从而可以减少确定目标实例所需的时间，即能够更加高效的确定目标实例，进而提高服务的响应速度。

在一些实施例中，如图9所示，在所述当接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例的步骤之后，所述方法还可以包括：

步骤S901：对所述本地路由表中目标实例的自定义指标信息进行临时调整；

步骤S903：在接收到来自客户端的下一次访问请求时，基于临时调整后的所述本地路由表确定处理所述下一次访问请求的目标实例；

步骤S905：在所述目标实例所在的目标服务提供端发送实例变更通知时，利用所述实例变更通知中包括的变更的实例信息和自定义指标信息覆盖临时调整后的所述本地路由表。

在本申请实施例中，在服务发起端接收到访问请求并将所述访问请求转发至所述目标实例后，所述服务发起端对本地路由表中目标实例的自定义指标信息进行临时调整，从而使得所述服务发起端在再次接收到访问请求时，可以基于临时调整的本地路由表确定处理下一次访问请求的目标实例。而在目标实例所在的目标服务提供端重新上报实例变更通知时，再利用所述实例变更通知中包括的变更的实例信息和自定义指标信息覆盖临时调整后的所述本地路由表。

例如，业务需要根据最小负载进行选路，目标实例组中包括实例a(load＝10)，实例b(load＝20)，实例c(load＝30)，则对业务请求分发时，会优先选择实例a，但是，持续选中实例a会引起实例a的负载(即load)剧增，因此，在实例a重新上报其自定义指标信息之前，可以在服务发起端每次选中实例a时对实例a的负载进行临时调整，当实例a的负载调整达到20后，后续再接收到业务请求时，将选中实例a和实例b中负载较小的实例(负载达到30之前)，并对选中实例的负载进行临时调整，避免了持续选中实例a引起实例a的负载剧增。

需要说明的是，服务发起端对服务提供端的调整只在本地生效，只要服务提供端主动发起变更，则所有节点会以此次同步的服务提供端的最新指标为准。也即，调整原则为：各节点只能主动同步自己的自定义指标信息，各节点对其他节点指标信息的调整均为基于本地的临时调整。

在本申请实施例中，避免了某一实例持续被选中引起的负载剧增，从而可以平衡服务提供端的实例的负载，对服务提供端进行过载保护。

未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的方法。

本申请实施例还提供了一种负载均衡装置1000，请参见图10，所述装置1000可以包括：

通知接收模块1010，用于接收集群中对应的名字服务服务器发送的实例变更通知，所述实例变更通知包括变更的实例信息和自定义指标信息，所述实例变更通知为服务提供端响应于实例变更请求而向对应的名字服务服务器发送、并由对应的名字服务服务器转发至集群内的其余的名字服务服务器，各个所述名字服务服务器能够分别向与其连接的服务发起端转发所述实例变更通知；

本地路由表更新模块1020，用于基于所述实例变更通知中的所述实例信息和所述自定义指标信息更新本地路由表；

访问请求处理模块1030，用于在任一所述服务发起端接收到来自客户端的访问请求后，基于更新后的本地路由表确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

在一些实施例中，所述访问请求处理模块可以包括：

目标实例组确定子模块，用于当接收到来自客户端的访问请求后，确定所述本地路由表中与所述访问请求对应的目标实例组；

实例组更新判断子模块，用于判断所述目标实例组是否需要更新；

计算子模块，用于在所述目标实例组需要更新时，遍历所述目标实例组中的实例，并基于所述目标实例组中各个实例的自定义指标信息计算各个实例在所述目标实例组中的位置或权重；

访问请求处理子模块，用于基于各个实例在所述目标实例组中的位置或权重确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

在一些实施例中，所述访问请求处理模块还可以包括：

自平衡二叉查找树获取子模块，用于在所述目标实例组不需要更新时，从与所述目标实例组对应的缓存中获取自平衡二叉查找树，所述自平衡二叉查找树为根据最近一次更新的所述目标实例组中各个实例的位置或权重构建、并保存在缓存中的数据结构；

所述访问请求处理子模块还用于根据所述自平衡二叉查找树确定处理所述访问请求的目标实例，并转发所述访问请求至所述目标实例。

在一些实施例中，所述计算子模块包括：

第一更新确定单元，用于在所述目标实例组具有实例组更新标签时，确定所述目标实例组需要更新，所述实例组更新标签在所述目标实例组中的实例发生变更时设置；

待调整实例确定单元，用于遍历所述目标实例组中的实例，将所述目标实例组中具有实例更新标签的实例确定为待调整实例，所述实例更新标签在所述实例为所述目标实例组中的新增实例或所述实例的自定义指标信息发生变更时设置；

权重更新单元，用于基于所述目标实例组中各个所述待调整实例的自定义指标信息更新各个所述待调整实例在所述目标实例组中的权重。

在一些实施例中，所述装置还可以包括：

自定义指标信息临时调整模块，用于对所述本地路由表中目标实例的自定义指标信息进行临时调整；

所述访问请求处理模块还用于在接收到来自客户端的下一次访问请求时，基于临时调整后的所述本地路由表确定处理所述下一次访问请求的目标实例；

自定义指标信息覆盖模块，用于在所述目标实例所在的目标服务提供端发送实例变更通知时，利用所述实例变更通知中包括的变更的实例信息和自定义指标信息覆盖临时调整后的所述本地路由表。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行如本实施例上述任一方法。

本申请实施例还提供了一种电子设备，其结构图请参见图11，该设备1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing units，CPU)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对设备中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在设备1100上执行存储介质1130中的一系列指令操作。设备1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作系统1141，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。本实施例上述的任一方法均可基于图11所示的设备进行实施。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤和顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或中断产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本实施例中所示出的结构，仅仅是与本申请方案相关的部分结构，并不构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比示出的更多或更少的部件，或者组合某些部件，或者具有不同的部件的布置。应当理解到，本实施例中所揭露的方法、装置等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分仅仅为一种逻辑功能的划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元模块的间接耦合或通信连接。

基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实施方式中提供的方法。

本领域技术人员还可以进一步意识到，结合本说明书所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但这种实现不应认为超出本申请的范围。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。