CN117278562A - 负载均衡方法、装置、系统、电子设备及存储介质 - Google Patents

Abstract

本公开提供一种负载均衡方法、装置、系统、电子设备及存储介质。所述负载均衡方法包括：接收第一客户端发送的第一服务请求，并从第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；基于七层负载均衡策略对第一请求任务进行处理以确定第一请求任务对应的目标服务器，并根据第一请求任务及其对应的目标服务器获得第二请求任务；基于第二客户端的身份认证信息对第二请求任务进行加密，基于加密结果及第一用户信息获得第二服务请求；将第二服务请求发送至目标服务器，使目标服务器基于第二服务请求获得第一用户信息及第二请求任务。本公开能够在Kubernetes平台实现七层负载均衡策略，提高负载均衡策略的灵活性，提高服务请求的负载均衡。

Description

负载均衡方法、装置、系统、电子设备及存储介质

技术领域

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

背景技术

在计算机领域，通常会使用负载均衡装置来平衡多个关键服务器之间的流量，以达到优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。

Kubernetes是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务。Kubernetes通常采用四层负载均衡策略，负载均衡装置并不知道请求中的内容，只是将来自用户的请求均匀的发送给集群服务器的各个节点上，这种负载均衡模式并不均衡；但若采用七层负载均衡策略，负载均衡装置虽可以基于请求内容进行更加均衡的负载均衡，但是无法保证负载均衡装置与集群服务器的各个节点之间的通信安全。

发明内容

有鉴于此，本公开的目的在于提出一种负载均衡方法、装置、系统、电子设备及存储介质。

基于上述目的，本公开提供了一种负载均衡方法，包括：

接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；

基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；

基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得第二服务请求；

将所述第二服务请求发送至所述目标服务器，使所述目标服务器基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

可选的，所述从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务，包括：

基于所述第一客户端的身份认证证书对所述第一服务请求进行身份认证；

响应于所述身份认证成功，卸载所述第一客户端的身份认证证书，获得所述第一用户信息及所述第一请求任务。

可选的，所述基于加密结果及所述第一用户信息获得第二服务请求，包括：

将所述第一用户信息存储于所述第二服务请求的消息头中，将所述加密结果存储于所述第二服务请求的消息体中。

可选的，所述基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务，包括：

获取所述第一请求任务中的请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个，并基于请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个以及预设的路由规则进行路由匹配，基于路由匹配结果获得子请求任务；

获取所述子请求任务的读写类型、资源类型、用户请求限速中的至少一个，基于读写类型、资源类型、用户请求限速中的至少一个确定所述子请求任务对应的所述目标服务器，并根据所述子请求任务及其对应的目标服务器获得所述第二请求任务。

可选的，基于读写类型对所述子请求任务进行负载均衡处理，获得所述第二请求任务，包括：

响应于所述子请求任务的读写类型为读请求，将所述第二请求任务转发至所述目标服务器中的第一目标服务器；

响应于所述子请求任务的读写类型为写请求，将所述第二请求任务转发至所述目标服务器中的第二目标服务器。

可选的，基于资源类型对所述子请求任务进行负载均衡处理，获得所述第二请求任务，包括：

响应于所述子请求任务的资源类型为容器组请求，将所述第二请求任务转发至所述目标服务器中的第三目标服务器；

响应于所述子请求任务的资源类型为副本应用管理请求，将所述第二请求任务转发至所述目标服务器中的第四目标服务器。

可选的，还包括：

接收第三客户端发送的第三服务请求，从所述第三服务请求中解析得到所述第三客户端的第三用户信息及第三请求任务；

基于七层负载均衡策略对所述第三请求任务进行处理以确定所述第三请求任务对应的目标服务器，并根据所述第三请求任务及其对应的目标服务器获得第四请求任务；

基于第二客户端的身份认证信息对所述第四请求任务进行加密，基于加密结果及所述第三用户信息获得第四服务请求；

基于HTTP2协议将所述第二服务请求和所述第四服务请求通过一条传输控制协议连接发送至所述目标服务器。

本公开还提供了一种负载均衡装置，包括：

第一认证模块，用于接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；

负载均衡模块，用于基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；

第二认证模块，用于基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得第二服务请求；

发送模块，用于将所述第二服务请求发送至目标服务器，使所述目标服务器基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

本公开还提供了一种负载均衡系统，包括：

第一客户端，用于生成并发送第一服务请求；

负载均衡装置，用于接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得并发送第二服务请求；以及，

至少一个目标服务器，用于接收负载均衡装置发送的所述第二服务请求，基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

本公开还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任意一项所述的方法。

本公开还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行上述任意一项所述的方法。

从上面所述可以看出，本公开提供的负载均衡方法、装置、系统、电子设备及存储介质，采用七层负载均衡策略对第一服务请求中的第一请求任务进行负载均衡，可获得第一请求任务中的具体内容，并基于第一请求任务中的具体内容实现负载均衡，保证各第一服务请求中的第一请求任务可以均衡地分发至各个目标服务器；同时，由于是负载均衡装置主动进行负载均衡，而不是被动的要求客户端重连，因此不受服务升级影响，即使配置变更也无需重启服务；利用第二客户端的第二客户端的身份认证信息对第二请求任务进行加密，保证数据传输时的安全；采用用户模拟技术利用第二客户端模拟第一客户端，使得即使第一客户端的身份认证证书已被卸载在负载均衡侧，目标服务器也可获得第二请求任务所属的第一客户端的第一用户信息，避免重要用户信息丢失。

附图说明

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

图1为基于Kubernetes平台的负载均衡系统的结构框图；

图2为基于Kubernetes平台的七层负载均衡策略的系统的结构示意图；

图3为基于Kubernetes平台的七层负载均衡策略的系统的另一结构示意图；

图4为基于Kubernetes平台的四层负载均衡策略的系统的结构示意图；

图5为四层负载均衡策略示意图；

图6为本公开实施例所述负载均衡方法的流程示意图；

图7为本公开实施例所述基于Kubernetes平台的七层负载均衡策略的系统结构示意图；

图8为本公开实施例所述负载均衡装置的内置认证模块示意图；

图9为本公开实施例所述负载均衡装置的结构示意图；

图10为本公开实施例电子设备的结构示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本公开实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

为了帮助对本发明的理解，下面首先对本发明涉及的一些名词进行解释性描述：

Kubernetes：简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes提供了应用部署、规划、更新、维护的一种机制。

Pod是可以在Kubernetes中创建和管理的、最小的可部署的计算单元，例如可以为容器；Pods为容器组。

Deployment是一个定义及管理多副本应用(即多个副本Pod)的对象。

etcd是兼具一致性和高可用性的键值数据库，可以作为保存Kubernetes所有集群数据的后台数据库。

Upstream Cluster，上游集群，由相同的几个目标服务器(APIServer)组成的Group称为Upstream Cluster。

kube-apiserver(kube-应用程序编程接口服务器，即API服务器)是Kubernetes重要组件之一，它作为整个集群的中枢，对外提供了整个集群所有资源的HTTP REST接口，让集群内所有其他组件，包含kube-scheduler，kube-controller-manager，kubelet等都可以通过它来与其他组件进行交互。

kube-scheduler是一种控制平面组件，负责监视新创建的、未指定运行节点(node)的Pods，选择节点让Pod在上面运行。

kube-controller-manager运行管理控制器是一种运行控制器进程的控制平面组件，是集群中处理常规任务的后台线程。

Kubelet是一个在集群中每个节点(node)上运行的代理，它保证容器(containers)都运行在Pod中。

X509证书即数字证书，因其内容为第三方可信机构CA对公钥实施数字签名，故也叫公钥证书；数字证书在PKI体系中是一个表明身份的载体，除了用户的公钥，还包含用户公开的基本信息，如用户名、组织、邮箱等。

图1示出了一种基于Kubernetes平台的负载均衡系统及其实现方法的结构示意图。

如图1所示，基于Kubernetes平台的负载均衡系统包括至少一个客户端(client)、负载均衡装置以及上游集群(Upstream Cluster)。其中，上游集群可包括一个或多个目标服务器(API Server)。

在本系统中，第一客户端A发起服务请求，负载均衡装置基于服务请求进行负载均衡以将服务请求中的任务分发至上游集群(Upstream Cluster)中的不同API服务器，以基于各API服务器对各任务进行相应的处理。

在这个过程中，第一客户端A的第一用户通常使用身份认证证书例如x509证书作为认证(Authentication)方式来访问API服务器。而API服务器对证书认证时需要解析x509证书中通用名称(CommonName)和颁发机构(Organization)的信息作为用户名(user name)和组(group)。

如图2所示，若在负载均衡装置使用基于七层负载均衡的策略时，第一客户端A所使用的第一客户端的身份认证证书(即图2中的第一证书)会被卸载在负载均衡装置的负载均衡侧，即来自第一客户端A的第一用户的第一用户信息被卸载；之后，负载均衡装置利用七层负载均衡策略对服务请求中的请求任务进行处理，并将处理后的请求任务直接分发至上游集群中相应的API服务器。在这个系统中，负载均衡装置与上游集群之间的通信是不加密的，因此可能是不安全的。

为了提高负载均衡装置与上游集群之间的通信安全性，如图3所示，负载均衡装置利用七层负载均衡策略对服务请求中的请求任务进行处理之后，负载均衡装置使用新的客户端(例如第二客户端B)的证书(例如第二客户端的身份认证证书，即图3中的第二证书)对请求任务进行加密后，再访问API服务器。在这种情况下，虽然通过对负载均衡装置与上游集群之间的通信进行加密保证了二者之间通信的安全性，但是由于API服务器基于第二客户端的身份认证证书对第二客户端B进行的身份认证，在身份认证成功后获得的是来自第二客户端B的的第二用户信息，且由于在前次身份认证时第一用户信息已被卸载，API服务器无法获得第一用户信息；即API服务器仅知道该请求任务来自于第二客户端B，而不知该请求任务来自于第一客户端A，这导致API服务器丢失了重要的用户信息，对API服务器后续的任务处理造成巨大影响。

因而，目前在负载均衡装置中仅能使用基于四层负载均衡的策略，如图4所示。四层负载均衡使用的是网络地址转换(Network Address Translation，NAT)技术。如图5所示，当服务请求进来的时候，负载均衡装置修改数据包里面的目标和源IP和端口，然后把数据包发向目标API服务器，API服务器处理完成后，服务器再做一次修改，返回给请求的客户端。在这个过程中，负载均衡装置并不能知道请求中的内容。这使得通过配置四层负载均衡的规则使得传输层的连接请求能够均匀地分布在多个相同的APIServer副本之间。

然而，使用基于四层负载均衡的策略代理kube-apiserver流量的方案中，有以下的不足：

(1)请求负载不均衡：四层的负载均衡在用户和API服务器创建传输控制协议(Transmission Control Protocol，TCP)链接后，后续的请求都会通过相同的TCP链接发送到相同的API服务器，而每个用户的请求量是不均衡的，所以从请求(request)的角度来看是不均衡的，尤其是在API服务器滚动更新之后，不均衡的情况尤其严重。

(2)负载策略不灵活：基于四层负载均衡的策略不能获取到请求的具体内容，所以只能提供hash、轮询、最小连接数之类的负载策略，并进一步加剧请求负载的不均衡。

有鉴于此，本公开实施例提供一种负载均衡方法，能够有效解决上述问题。如图6所示，本公开实施例所述负载均衡方法，应用于负载均衡装置，包括：

步骤S101，接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务。

步骤S103，基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务。

步骤S105，基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得第二服务请求。

步骤S107，将所述第二服务请求发送至目标服务器，使所述目标服务器基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

本实施例中，采用七层负载均衡策略对第一服务请求中的第一请求任务进行负载均衡，可获得第一请求任务中的具体内容，并基于第一请求任务中的具体内容实现负载均衡，保证各第一服务请求中的第一请求任务可以均衡地分发至各个目标服务器；同时，由于是负载均衡装置主动进行负载均衡，而不是被动的要求客户端重连，因此不受服务升级影响，即使配置变更也无需重启服务；利用第二客户端的第二客户端的身份认证信息对第一用户信息、第二请求任务进行加密，保证数据传输时的安全；采用用户模拟技术用第二客户端来模拟第一客户端，使得即使第一客户端的身份认证证书已被卸载在负载均衡侧，目标服务器也可获得第二请求任务所属的第一客户端的第一用户信息，避免重要用户信息丢失。

下面结合图7所示的基于Kubernetes平台的负载均衡系统详细阐述本申请的技术方案。

本公开中负载均衡系统包括第一客户端、负载均衡装置以及至少一个目标服务器。其中，第一客户端用于生成并发送第一服务请求；负载均衡装置，用于接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得并发送第二服务请求；至少一个目标服务器，用于接收负载均衡装置发送的所述第二服务请求，基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

首先，第一客户端生成第一服务请求并将第一服务请求发送至负载均衡装置。其中，第一客户端可以是移动设备或固定设备。第一服务请求可以为超文本传输协议(HyperText Transfer Protocol，HTTP)消息，第一服务请求中包括用于实现发起第一服务请求的第一客户端的身份认证的第一客户端的身份认证证书。

负载均衡装置接收该第一服务请求之后，卸载所述第一服务请求中的第一客户端的身份认证证书并获得第一客户端的第一用户信息，同时获得第一请求任务。具体的，负载均衡装置可基于该第一客户端的身份认证证书对第一服务请求的发起客户端(即第一客户端)进行身份认证，当身份认证成功，将该第一客户端的身份认证证书卸载并获得第一客户端的第一用户信息以及第一请求任务。其中，负载均衡装置可以是kube-gateway组件。

本实施例中，kube-gateway组件中可设置多个认证模块。如图8所示，例如，kube-gateway组件中可包括身份认证代理(Authenticating proxy)模块、X509认证(X509 Auth)模块以及令牌审核(TokenReview)模块。相应的，负载均衡装置对第一客户端的认证可采用身份认证代理认证(Authenticating proxy)、X509证书(X509 Cert)、令牌(Bearer Token)等认证方式；即第一客户端的身份认证证书可以包括身份验证代理、X509证书以及令牌等。

当采用身份认证代理认证方式时，可将第一客户端的第一用户信息直接存储于第一服务请求的消息头(herder)中，也可在服务器中额外配置证书；当负载均衡装置接收到第一服务请求时，可通过身份认证代理模块从第一服务请求的消息头中获取到第一用户信息。

当采用X509证书认证时，第一服务请求包括X509证书；当负载均衡装置接收到第一服务请求时，可通过X509认证模块解析X509证书中的通用名称(CommonName)和颁发机构(Organization)的信息作为用户名(user name)和组(group)信息。本实施例中，可为不同的上游集群域名配置不同的用户CA证书。

当采用令牌(Bearer Token)认证时，第一服务请求包括令牌；当负载均衡装置接收到第一服务请求时，向API服务器发送特殊的令牌审核(TokenReview)请求，要求上游集群中的API服务器对令牌进行认证，从而得到对应的用户信息(UserInfo)。由于令牌认证时信息很少变化，因此当认证成功后，可对认证结果进行较长时间的缓存，从而可以避免重复认证造成的额外开销。

在另一些实施例中，对第一客户端的身份认证也可采用用户模拟(Userimpersonation)、匿名认证(Anonymous)、基本认证(Basic Auth，即用户名密码认证)等方式。本实施例中，通过在负载均衡装置中内置上述多个认证模块，从而可以对第一客户端进行认证，并在认证成功后获得第一服务请求中的第一用户信息以及第一请求任务。

负载均衡装置基于第一客户端的身份认证证书例如X509证书对第一客户端的身份认证成功后，负载均衡装置获得第一客户端的第一用户信息以及第一请求任务。其中，该第一请求任务即为第一服务请求的具体内容，其可包括对资源、流量等内容的请求，可以为URL、Cookie等。同时，负载均衡装置会将该第一客户端的身份认证证书卸载，这样第一请求任务中不会包含其所属的第一客户端的第一用户信息，即API服务器无法基于第一请求任务获得生成该任务的用户。

可选的，在有需要的情况下，身份认证结束后，还会做授权验证。

在一些实施例中，身份认证完成后，负载均衡装置基于七层负载均衡策略对第一请求任务进行处理，包括对第一请求任务进行路由匹配、限流以及负载均衡从而确定第一请求任务对应的目标服务器，从而根据第一请求任务及其对应的目标服务器获得第二请求任务。其中，目标服务器可以为应用程序编程接口服务器apiserver(即API服务器)；一条第一请求任务可以对应一个目标服务器，也可以对应多个目标服务器，本实施例对此不作限制。

具体的，负载均衡装置对第一请求任务进行解析，获取所述第一请求任务中的请求操作(verb)信息、应用程序编程接口组信息(apiGroup)、资源类型信息(resource)、资源名称(resourceName)、发起请求的用户信息(user)、发起请求的用户组信息(userGroup)、请求路径信息(nonResourceURL)中的至少一个具体内容。这样，负载均衡装置即可基于第一请求任务的上述具体内容，来区分不同类型的请求，并实现差异化的路由匹配，从而可以为各个第一请求任务匹配合适的API服务器，保证请求负载的均衡；同时，后续还可以基于不同的服务请求实现限流、降级、熔断等流量治理能力。

其中，当针对的是非资源请求时，其请求操作信息与HTTP的请求操作信息一一对应，包括get、post、put和delete；当针对的是资源请求时，其请求操作信息包括get、list、create、update、patch、watch、delete和deletecollection。

如果第一请求任务是资源请求，应用程序编程接口组信息(apiGroup)用于表示第一请求任务所请求的资源所在的应用程序编程接口组(api group)，资源类型信息表示第一请求任务所请求的资源类型，资源名称表示第一请求任务所请求的资源的资源名称，发起请求的第一客户端的第一用户信息表示发起第一请求任务的用户信息，发起请求的用户组信息表示发起第一请求任务的用户组的第一用户信息。如果第一请求任务不是资源请求，则请求路径信息表示第一请求任务的请求路径。

当负载均衡装置获得第一请求任务中的上述信息后，基于请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个以及预设的路由规则进行路由匹配，并基于路由匹配结果获得子请求任务。

其中，预设的路由规则包括多个路由匹配规则字段，所述路由匹配规则字段包括：与请求操作信息对应的请求操作字段(verbs)、与应用程序编程接口组信息对应的应用程序编程接口组字段(apiGroups)、与资源类型信息对应的资源类型字段(resources)、与发起请求的用户信息对应的用户字段(users)、与发起请求的用户组信息对应的用户组字段(userGroups)、与发起请求的用户信息及用户组信息对应的服务账户字段(ServiceAccounts)、与请求路径信息所对应的请求路径字段(nonResourceURLs)。

预设的路由规则可以由上述字段中的一个或多个组合，且每个字段之间的关系是『与&&』；同时，一次路由匹配可以由多条路由规则组成，且多条路由规则之间的关系是『或||』。如下表所示，每个路由匹配规则字段的基本规则如下：

其中，可利用通配符"*"来匹配所有。即当存在匹配所有的通配符时，其他任何单独匹配都会被忽略，例如可以利用通配符"*"来匹配对pods的所有操作。可选的，在请求路径字段(nonResourceURLs)中，通配符"*"可以用来匹配后缀(suffix)。

可选的，在上述路由匹配规则字段中，除了服务账户字段(ServiceAccounts)和请求路径字段(nonResourceURLs)以外，其他的字段都可以在字符串前面加入"-"来表示反选。一旦使用了反选"-"，则里面所有的元素都应该是反选的，即正选和反选不能同时存在。例如，通过resources:["-pods"，"-deployments"]来匹配非pods和非deployments的请求，而resources:["-pods"，"deployments"]在实际流程中"-pods"会被忽略，这条规则会变为匹配所有deployments的请求。

负载均衡装置获得获取请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个之后，即可基于请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个以及预设的路由规则进行路由匹配，基于路由匹配结果获得子请求任务，从而实现对第一请求任务的路由匹配。

本实施例中，负载均衡装置能做到通用负载均衡装置无法做到的针对API服务器的流量特征的路由匹配方式，它能够解析出与API服务器一致的请求属性(requestattribute)，从而通过这些请求属性的组合构建特殊的路由匹配规则，实现差异化的路由匹配；同时，如user、userGroup、serviceAccount等信息是通用负载均衡装置无法获取到的。

之后，负载均衡装置可基于内置的流量治理模块对子请求任务进行流量治理，包括：基于最大并发数、令牌桶算法等预设的限流算法来判断是否需要对子请求任务进行限制；以及，通过轮询负载均衡算法来选取一个合适的目标服务器进行转发。

具体的，负载均衡装置获取所述子请求任务的读写类型、资源类型、用户请求限速等信息中的至少一个，并基于读写类型、资源类型、用户请求限速等信息中的至少一个确定所述子请求任务对应的所述目标服务器，并根据所述子请求任务及其对应的目标服务器获得所述第二请求任务。

具体的，负载均衡装置可判断子请求任务的读写类型：当子请求任务的读写类型为读请求时，例如子请求任务为get、list、watch请求时，将所述第二请求任务转发至所述目标服务器中的第一目标服务器kube-apiserver-A进行处理；当子请求任务的读写类型为写请求，例如子请求任务为create、update、patch、delete、deletecollection请求时，将所述第二请求任务转发至所述目标服务器中的第二目标服务器kube-apiserver-B进行处理，且第一目标服务器kube-apiserver-A与第二目标服务器kube-apiserver-B不同。

本实施例中，基于读写类型将不同的子请求任务转发至不同的目标服务器，即应用程序编程接口服务器，从而实现读写分离。在一些具体的实施例中，可在第一目标服务器kube-apiserver-A中定制缓存所有资源，当子请求任务为读请求时，使其均命中第一目标服务器kube-apiserver-A所对应的缓存(cache)，这样读请求就不会到穿透到后端的存储中，当有一些较大的读请求(例如list请求)时，通过该第一目标服务器kube-apiserver-A中的缓存来为该list请求提供资源，避免过大的list请求打爆后端的缓存。

在一些实施例中，负载均衡装置可判断子请求任务的资源类型，且当子请求任务的资源类型为容器组(pods)请求时，负载均衡装置将所述第二请求任务转发至所述目标服务器中的第三目标服务器kube-apiserver-C；以及，当所述子请求任务的资源类型为副本应用管理(deployments)请求时，负载均衡装置将所述第二请求任务转发至所述目标服务器中的第四目标服务器kube-apiserver-D，第三目标服务器kube-apiserver-C与第四目标服务器kube-apiserver-D不同。

其中，第三目标服务器kube-apiserver-C可以与第一目标服务器kube-apiserver-A、第二目标服务器kube-apiserver-B中的一个为同一目标服务器，也可以为不同的目标服务器；第四目标服务器kube-apiserver-D可以与第一目标服务器kube-apiserver-A、第二目标服务器kube-apiserver-B中的另一个为同一目标服务器，也可以为不同的目标服务器，本实施例对此不作限制。

本实施例中，由于上游集群中的资源进行请求是不均衡的，或者不同资源的重要程度不同，例如事件(event)请求的请求量非常大，但是稍微丢失一些不重要，而其他请求却很重要，这样可基于子请求任务的不同的资源类型来提供不同的限流方式，提高限流以及负载均衡的效果。

在一些实施例中，负载均衡装置可为不同的用户设置不同的限速要求，例如对于第一子用户userA的请求，利用令牌桶预先配置其限流要求为token-bucket-qps-10，即限制其请求QPS为10；而对于第二子用户userB的请求，利用令牌桶预先配置其限流要求为token-bucket-qps-100，即限制其请求QPS为100。这样，即可基于不同用户的特征、需求等为不同用户提供不同的限流要求。

此外，由于基于七层负载均衡策略的设置，负载均衡装置可以获取第一请求任务中的具体内容，因此负载均衡装置还可基于其他任意具体内容中的信息对第一请求任务进行路由匹配以及流量治理，本说明书对此不作限制。

在一些实施例中，负载均衡装置获得第二请求任务之后，基于第二客户端的身份认证信息对所述第一用户信息、所述第二请求任务进行加密从而利用所述第二客户端模拟第一客户端，并根据加密结果获得第二服务请求。其中，所述第一用户信息存储于所述第二服务请求的消息头中，所述加密结果存储于所述第二服务请求的消息体中，从而根据所述加密结果及所述第一用户信息生成所述第二服务请求。

可选的，第二客户端的身份认证信息可以包括身份验证代理、X509证书以及令牌等。

本实施例中，负载均衡装置通过用户模拟技术利用第二客户端模拟第一客户端，并利用第二客户端访问后端的目标服务器。

首先，在目标服务器中预置用户模拟权限，基于该权限可确定一个用户是否可以模拟为另一个用户。在本实施例中，用户模拟权限可包括：第二客户端能够用于模拟第一客户端；或者，也可设置第二客户端能够用于模拟任何一个客户端。

当负载均衡装置接收到第一客户端发送的第一服务请求时，认证成功后获得第一客户端的第一用户信息及第一请求任务，并利用七层负载均衡策略对第一请求任务进行处理，从而获得第二请求任务。

之后，负载均衡装置基于第二客户端的身份认证信息对第二请求任务进行加密，并基于加密结果及第一用户信息获得第二服务请求。

在本实施例中，负载均衡装置将第一用户信息存放入第二服务请求的消息头中，并利用第二客户端的身份认证信息对第二请求任务进行加密获得加密结果，并将加密结果存放入第二服务请求的消息体中，从而利用第二客户端模拟第一客户端，之后将基于加密结果和第一用户信息生成的第二服务请求发送给目标服务器。

这样目标服务器基于第二客户端的身份认证证书对第二服务请求的发起客户端(即第二客户端)进行身份认证，认证成功后卸载所述第二客户端的身份认证证书，获得第二客户端的第二客户端信息和第二请求任务。

此时，虽然目标服务器认证后认为第二请求任务来自于第二客户端，但是目标服务器还可从第二服务请求的消息头中获取到第一用户信息，从而得知第二请求任务属于第一客户端，即第二客户端是用第一客户端模拟得到的。

之后，目标服务器利用预置的用户模拟权限，来判断第二客户端是否有足够的权限来模拟第一客户端。当第二客户端能够用于模拟第一客户端时，目标服务器可确定第二请求任务实际来自于第一客户端，即可基于第二请求任务以及第一客户端信息执行所述第二请求任务。

本实施例中，通过利用第二客户端模拟第一客户端，并将第一客户端的第一用户信息存储于第二服务请求的消息头中，即使第一客户端的身份认证证书被卸载，目标服务器也可获得第二请求任务实际的来源；同时，由于第二服务请求是利用第二客户端的身份认证信息进行加密的，从而提高了负载均衡装置与上游集群之间通信的安全性。

在一些实施例中，负载均衡装置与目标服务器之间的通信基于HTTP2协议，且代理服务利用HTTP2协议的多路复用能力，通过一条传输控制协议链接(即TCP链接)将多条基于不同客户端获得的服务请求发送至目标服务器。

具体的，当与第一客户端具有类似功能的第三客户端生成第三服务请求并发送至本公开实施例所述负载均衡装置时，负载均衡装置采用与处理第一客户端发送的第一服务请求同样的方法，接收第三客户端发送的第三服务请求，从所述第三服务请求中解析得到所述第三客户端的第三用户信息及第三请求任务；之后基于七层负载均衡策略对所述第三请求任务进行处理以确定所述第三请求任务对应的目标服务器，并根据所述第三请求任务及其对应的目标服务器获得第四请求任务；基于第二客户端的身份认证信息对所述第四请求任务进行加密，基于加密结果及所述第三用户信息获得第四服务请求；再基于HTTP2协议将所述第二服务请求和所述第四服务请求通过一条传输控制协议连接发送至所述目标服务器。即在本实施例中，当不同的客户端向负载均衡装置发出服务请求时，经过负载均衡装置处理后获得的服务请求通过一条传输控制协议链接发送至目标服务器。

本实施例中，由于在负载均衡装置处通过第二客户端来模拟其他用户，即使通过负载均衡装置访问目标服务器的用户不同，也可将不同的访问用户均模拟为第二客户端，从而使得负载均衡装置在访问目标服务器时使用了固定的客户端，即相应的负载均衡装置的代理转发请求即第二服务请求也通过该第二客户端来发送；当负载均衡装置与目标服务器之间采用HTTP2协议进行通信时，可利用HTTP2协议所具有的多路复用能力，将来自不同客户端的第二服务请求和第四服务请求在同一个TCP链接上发送，从而收敛单个目标服务器上的链接数，当上游集群具有一万个节点时，目标服务器所在节点的TCP连接数可从几千的数量级减少到几十。

可选的，负载均衡装置与目标服务器之间通信时，通过同一个TCP链接上发送的服务请求不限于第二服务请求、第四服务请求，可以为任意数量客户端发送至负载均衡装置并由负载均衡装置处理后获得的服务请求，本实施例对此不作限制。

在本公开中，负载均衡装置中还包括控制单元，该控制单元对外提供代理规则等控制面的API资源的增删改查操作，提供完整的认证授权能力，最终将请求存储到ETCD中，提供list/watch的能力。

在控制单元中使用异步的架构，配置通过API的形式对外提供，管理员随时通过API调用来修改配置，如：添加或删除需要代理的集群、修改代理集群的证书，clientCA等配置、修改代理集群的路由配置、修改代理集群的限流配置等，且以上的配置修改全部都会即刻生效，并不需要重启服务，也不会断开已有的链接。

在一些实施例中，上述负载均衡装置可采用Nginx服务器。

需要说明的是，本公开实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本公开实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

需要说明的是，上述对本公开的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种负载均衡装置。

参考图9，所述负载均衡装置，包括第一认证模块11、负载均衡模块12、第二认证模块13以及发送模块14。其中，第一认证模块11，用于接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；负载均衡模块12，用于基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；第二认证模块13，用于基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得第二服务请求；发送模块14，用于将所述第二服务请求发送至目标服务器，使所述目标服务器基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

可选的，所述第一认证模块还用于实现：基于所述第一客户端的身份认证证书对所述第一服务请求进行身份认证；响应于所述身份认证成功，卸载所述第一客户端的身份认证证书，获得所述第一用户信息及所述第一请求任务。

可选的，还包括：将所述第一用户信息存储于所述第二服务请求的消息头中，将所述加密结果存储于所述第二服务请求的消息体中。

可选的，所述负载均衡模块12还用于实现：获取所述第一请求任务中的请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个，并基于请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个以及预设的路由规则进行路由匹配，基于路由匹配结果获得子请求任务；获取所述子请求任务的读写类型、资源类型、用户请求限速中的至少一个，基于读写类型、资源类型、用户请求限速中的至少一个确定所述子请求任务对应的所述目标服务器，并根据所述子请求任务及其目标服务器获得所述第二请求任务。

可选的，所述负载均衡模块12还用于实现：响应于所述子请求任务的读写类型为读请求，将所述第二请求任务转发至所述目标服务器中的第一目标服务器；响应于所述子请求任务的读写类型为写请求，将所述第二请求任务转发至所述目标服务器中的第二目标服务器。

可选的，所述负载均衡模块12还用于实现：响应于所述子请求任务的资源类型为容器组请求，将所述第二请求任务转发至所述目标服务器中的第三目标服务器；响应于所述子请求任务的资源类型为副本应用管理请求，将所述第二请求任务转发至所述目标服务器中的第四目标服务器。

可选的，所述发送模块13还用于实现：接收第三客户端发送的第三服务请求，从所述第三服务请求中解析得到所述第三客户端的第三用户信息及第三请求任务；基于七层负载均衡策略对所述第三请求任务进行处理以确定所述第三请求任务对应的目标服务器，并根据所述第三请求任务及其对应的目标服务器获得第四请求任务；基于第二客户端的身份认证信息对所述第四请求任务进行加密，基于加密结果及所述第三用户信息获得第四服务请求；基于HTTP2协议将所述第二服务请求和所述第四服务请求通过一条传输控制协议连接发送至所述目标服务器。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述任一实施例中相应的服务编排方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种服务器，所述服务器包括：接收模块，用于接收负载均衡装置发送的第二服务请求；第三认证模块，用于基于所述第二客户端的身份认证信息对所述第二服务请求进行身份认证；获取模块，用于响应于所述身份认证成功，获取所述第一用户信息、所述第二用户信息及所述第二请求任务。

可选的，所述服务器还包括：权限验证模块，用于基于所述第一用户信息、所述第二用户信息及预置的用户模拟权限判断所述第二客户端是否具有模拟第一客户端的权限；响应于所述第二客户端具有模拟所述第一客户端的权限，执行所述第二请求任务。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本公开时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述任一实施例中相应的服务编排方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的方法。

图10示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本公开还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的方法。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本公开实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本公开实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本公开实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本公开实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本公开实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本公开实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本公开实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (11)

1.一种负载均衡方法，其特征在于，包括：

接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；

基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；

基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得第二服务请求；

将所述第二服务请求发送至所述目标服务器，使所述目标服务器基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

2.根据权利要求1所述的方法，其特征在于，所述从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务，包括：

基于所述第一客户端的身份认证证书对所述第一服务请求进行身份认证；

响应于所述身份认证成功，卸载所述第一客户端的身份认证证书，获得所述第一用户信息及所述第一请求任务。

3.根据权利要求1所述的方法，其特征在于，所述基于加密结果及所述第一用户信息获得第二服务请求，包括：

将所述第一用户信息存储于所述第二服务请求的消息头中，将所述加密结果存储于所述第二服务请求的消息体中。

4.根据权利要求1所述的方法，其特征在于，所述基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务，包括：

获取所述第一请求任务中的请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个，并基于请求操作信息、应用程序编程接口组信息、资源类型信息、资源名称、发起请求的用户信息、发起请求的用户组信息、请求路径信息中的至少一个以及预设的路由规则进行路由匹配，基于路由匹配结果获得子请求任务；

获取所述子请求任务的读写类型、资源类型、用户请求限速中的至少一个，基于读写类型、资源类型、用户请求限速中的至少一个确定所述子请求任务对应的所述目标服务器，并根据所述子请求任务及其对应的目标服务器获得所述第二请求任务。

5.根据权利要求4所述的方法，其特征在于，基于读写类型对所述子请求任务进行负载均衡处理，获得所述第二请求任务，包括：

响应于所述子请求任务的读写类型为读请求，将所述第二请求任务转发至所述目标服务器中的第一目标服务器；

响应于所述子请求任务的读写类型为写请求，将所述第二请求任务转发至所述目标服务器中的第二目标服务器。

6.根据权利要求4所述的方法，其特征在于，基于资源类型对所述子请求任务进行负载均衡处理，获得所述第二请求任务，包括：

响应于所述子请求任务的资源类型为容器组请求，将所述第二请求任务转发至所述目标服务器中的第三目标服务器；

响应于所述子请求任务的资源类型为副本应用管理请求，将所述第二请求任务转发至所述目标服务器中的第四目标服务器。

7.根据权利要求4所述的方法，其特征在于，还包括：

接收第三客户端发送的第三服务请求，从所述第三服务请求中解析得到所述第三客户端的第三用户信息及第三请求任务；

基于七层负载均衡策略对所述第三请求任务进行处理以确定所述第三请求任务对应的目标服务器，并根据所述第三请求任务及其对应的目标服务器获得第四请求任务；

基于第二客户端的身份认证信息对所述第四请求任务进行加密，基于加密结果及所述第三用户信息、获得第四服务请求；

基于HTTP2协议将所述第二服务请求和所述第四服务请求通过一条传输控制协议连接发送至所述目标服务器。

8.一种负载均衡装置，其特征在于，包括：

第一认证模块，用于接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；

负载均衡模块，用于基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；

第二认证模块，用于基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得第二服务请求；

发送模块，用于将所述第二服务请求发送至目标服务器，使所述目标服务器基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

9.一种负载均衡系统，其特征在于，包括：

第一客户端，用于生成并发送第一服务请求；

负载均衡装置，用于接收第一客户端发送的第一服务请求，并从所述第一服务请求中解析得到所述第一客户端的第一用户信息及第一请求任务；基于七层负载均衡策略对所述第一请求任务进行处理以确定所述第一请求任务对应的目标服务器，并根据所述第一请求任务及其对应的目标服务器获得第二请求任务；基于第二客户端的身份认证信息对所述第二请求任务进行加密，并基于加密结果及所述第一用户信息获得并发送第二服务请求；以及，

至少一个目标服务器，用于接收负载均衡装置发送的所述第二服务请求，基于所述第二服务请求获得所述第一用户信息及所述第二请求任务。

10.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至7任意一项所述的方法。

11.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，其特征在于，所述计算机指令用于使所述计算机执行权利要求1至7任意一项所述的方法。