CN117420956A - 一种信息处理方法、装置、设备和计算机存储介质 - Google Patents

Abstract

本申请实施例公开了一种信息处理方法，所述方法包括：接收客户端发送的用于请求第一资源信息的获取请求；基于所述获取请求从中心分布式存储系统中获取第一目标路由信息；基于所述第一资源信息的类型和所述第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统；发送所述获取请求至所述第一目标分布式存储系统。本申请实施例还公开了一种信息处理装置、设备和计算机可读存储介质。

Description

一种信息处理方法、装置、设备和计算机存储介质

技术领域

本申请涉及计算机技术领域的信息处理技术，尤其涉及一种信息处理方法、装置、设备和计算机存储介质。

背景技术

目前，业界最常见的数据存储优化方案为基于kube-apiserver的数据拆分方案；该数据拆分方案的核心思路是进行集群拆分，将不同类型的资源数据存储到不同的etcd集群中，这样每个etcd集群只需要存储一部分数据，压力随之下降，从而可以支持大规模场景。这种方案实现较简单，只需要在kube-apiserver的启动参数中配置etcd-servers和etcd-servers-overrides参数即可。其中，etcd-servers是默认的etcd集群地址；如果需要拆分资源存储到其他etcd集群，则配置etcd-servers-overrides进行覆盖即可。kube-apiserver启动后会根据配置，将不同类型的资源数据存储到相应的etcd集群上。但是，当etcd节点数或者拆分的资源类型较多时，需要在kube-apiserver的启动参数中进行冗长的配置，且在变更etcd节点或者资源数据拆分时，需要修改kube-apiserver的启动参数并重启全部kube-apiserver，导致维护效率较低。

发明内容

为解决上述技术问题，本申请实施例期望提供一种信息处理方法、装置、设备和计算机存储介质，解决了相关技术中etcd节点数或者拆分的资源类型较多时存在kube-apiserver的启动参数的配置冗长的问题，实现了在修改kube-apiserver启动参数时不需要重启kube-apiserve，提高了维护效率。

本申请的技术方案是这样实现的：

一种信息处理方法，所述方法包括：

接收客户端发送的用于请求第一资源信息的获取请求；

基于所述获取请求从中心分布式存储系统中获取第一目标路由信息；

基于所述第一资源信息的类型和所述第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统；

发送所述获取请求至所述第一目标分布式存储系统。

上述方案中，所述基于所述获取请求从中心分布式存储系统中获取目标路由信息，包括：

构建针对所述中心分布式存储系统中的路由信息的目标树结构；

基于所述获取请求的目标字符信息遍历所述目标树结构，得到所述第一目标路由信息。

上述方案中，所述方法还包括：

接收多个第一客户端发送的针对第二资源信息的监控请求；

基于所述监控请求从所述中心分布式存储系统中确定第二目标路由信息；

基于所述第二资源信息的类型和所述第二目标路由信息，确定第二目标分布式存储系统；

将多个所述监控请求合并为目标监控请求，并发送至所述第二目标分布式存储系统；

相应的，所述方法还包括：

通过所述第二目标分布式存储系统获取针对所述第二资源信息的监控事件，并发送所述监控事件至每一第一客户端；其中，所述监控事件是所述第二目标分布式存储系统基于所述目标监控请求产生的。

上述方案中，所述方法还包括：

接收多个第二客户端发送的用于确定通信连接的信息流；

从所述中心分布式存储系统中确定与所述信息流对应的第三目标路由信息；

基于所述第三目标路由信息确定与所述信息流对应的第三目标分布式存储系统；

将多个所述信息流合并为目标信息流，并发送所述目标信息流至所述第三目标分布式存储系统；

相应的，所述方法还包括：

接收所述第三目标分布式存储系统发送的针对所述目标信息流的响应信息，并发送所述响应信息至每一第二客户端。

上述方案中，所述方法还包括：

在监测到所述中心分布式存储系统中的路由信息发生变化的情况下，在所述中心分布式存储系统中设置代理服务器对应的目标迁移标识；

采用目标迁移方式，获取发生变化的路由信息对应的源分布式存储系统中的目标资源信息，并将所述目标资源信息存储至所述发生变化的路由信息对应的目的分布式存储系统；

删除所述源分布式存储系统中的所述目标资源信息，并控制所述发生变化的路由信息处于生效状态；

删除所述目标迁移标识。

上述方案中，所述方法还包括：

接收所述客户端发送的针对所述发生变化的路由信息对应的所述目标资源信息的第一查询请求；

基于所述第一查询请求从所述源分布式存储系统中获取第一子资源信息，并从所述目的分布式存储系统中获取第二子资源信息；

基于所述第一子资源信息和所述第二子资源信息，确定所述目标资源信息。

上述方案中，所述方法还包括：

接收所述客户端发送的针对所述发生变化的路由信息对应的所述目标资源信息中的目标子资源信息的第二查询请求；

在所述源分布式存储系统中具有所述目标子资源信息的情况下，基于所述第二查询请求从所述源分布式存储系统中获取所述目标子资源信息；

在所述源分布式存储系统中不具有所述目标子资源信息的情况下，基于所述第二查询请求从所述目的分布式存储系统中获取所述目标子资源信息。

上述方案中，所述接收客户端发送的用于请求资源信息的获取请求，包括：

接收经由域名服务器转发的所述客户端发送的所述获取请求；其中，所述域名服务器用于基于目标均衡策略转发所述获取请求。

一种信息处理装置，所述装置包括：

接收单元，用于接收客户端发送的用于请求第一资源信息的获取请求；

获取单元，用于基于所述获取请求从中心分布式存储系统中获取第一目标路由信息；

确定单元，用于基于所述第一资源信息的类型和所述第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统；

发送单元，用于发送所述获取请求至所述第一目标分布式存储系统。

一种代理服务器，所述代理服务器包括：处理器、存储器和通信总线；

所述通信总线用于实现所述处理器和所述存储器之间的通信连接；

所述处理器用于执行所述存储器中的信息处理程序，以实现上述的信息处理方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现上述的信息处理方法的步骤。

本申请的实施例所提供的信息处理方法、装置、设备和计算机存储介质，可以接收客户端发送的用于请求第一资源信息的获取请求，并基于获取请求从中心分布式存储系统中获取第一目标路由信息，之后基于第一资源信息的类型和第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统，最后发送获取请求至第一目标分布式存储系统，这样，可以通过代理服务器基于中心分布式存储系统中配置的路由信息将客户端的用于获取资源数据的获取请求转发至对应的分布式存储系统，即不需要依赖于kube-apiserver进行资源数据的获取，也就不需要在kube-apiserver的启动参数中来配置相应的参数，从而解决了相关技术中etcd节点数或者拆分的资源类型较多时存在kube-apiserver的启动参数的配置冗长的问题，实现了在修改kube-apiserver启动参数时不需要重启kube-apiserve，且提高了维护效率。

附图说明

图1为本申请实施例提供的一种信息处理方法的流程示意图；

图2为本申请实施例提供的另一种信息处理方法的流程示意图；

图3为本申请实施例提供的一种信息处理方法中转发获取请求至后端etcd集群的示意图；

图4为本申请的实施例提供的一种信息处理方法中的目标Trie树的结构示意图；

图5为本申请实施例提供的又一种信息处理方法的流程示意图；

图6为本申请实施例提供的一种信息处理方法中处理监视程序的示意图；

图7为本申请另一实施例提供的一种信息处理方法的流程示意图；

图8为本申请实施例提供的一种信息处理方法中处理心跳信息流的示意图；

图9为本申请实施例提供的一种信息处理装置的结构示意图；

图10为本申请实施例提供的一种代理服务器的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

应理解，说明书通篇中提到的“本申请实施例”或“前述实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“本申请实施例中”或“在前述实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在未做特殊说明的情况下，执行本申请实施例中的任一步骤，可以是设备的处理器执行该步骤。还值得注意的是，本申请实施例并不限定设备执行下述步骤的先后顺序。另外，不同实施例中对数据进行处理所采用的方式可以是相同的方法或不同的方法。还需说明的是，本申请实施例中的任一步骤是设备可以独立执行的，即设备执行下述实施例中的任一步骤时，可以不依赖于其它步骤的执行。

应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

本申请实施例提供一种信息处理方法，该方法可以应用于代理服务器，参照图1所示，该方法可以包括以下步骤：

步骤101、接收客户端发送的用于请求第一资源信息的获取请求。

其中，客户端指的是加载有Kubernetes应用的终端；代理服务器可以指的是etcd-gRPC-proxy服务器；在本申请实施例中，获取请求可以是通过客户端中的Kubernetes应用对应的kube-apiserver来发送至代理服务器的。并且，该获取请求可以是用于获取分布式存储系统中的资源数据的请求。

步骤102、基于获取请求从中心分布式存储系统中获取第一目标路由信息。

其中，中心分布式存储系统可以指的是分布式存储系统中作为配置中心的分布式存储系统；并且，该中心分布式存储系统中可以进行后端的分布式存储系统的变更和对应的路由信息的配置。在一种可行的实现方式中，分布式存储系统可以指的是etcd集群，那中心分布式存储系统就可以指的是从etcd集群中确定出来的中心etcd集群。需要说明的是，中心etcd集群可以是Etcd-gRPC-proxy服务器从etcd集群中选出来的。

在本申请实施例中，etcd-gRPC-proxy服务器在接收到获取请求后，可以根据获取请求的目标字符信息从中心etcd集群中配置有的路由信息中，确定与第一资源信息对应的第一目标路由信息。

步骤103、基于第一资源信息的类型和第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统。

其中，第一资源信息的类型可以指的是需要获取的资源数据的类型。在本申请实施例中，etcd-gRPC-proxy服务器可以根据需要获取的第一资源数据的类型和第一目标路由信息，从中所有的etcd集群中确定需要路由至的第一目标etcd集群的标识。

步骤104、发送获取请求至第一目标分布式存储系统。

在本申请实施例中，etcd-gRPC-proxy服务器根据确定出来的第一目标etcd集群的标识，将接收到的获取请求发送至第一目标etcd集群；这样，第一目标etcd集群可以在接收到获取请求后，响应该获取请求获取第一资源数据。

需要说明的是，本申请实施例中的Etcd-gRPC-proxy服务器可以复用后端的一个etcd集群作为配置中心，以节省资源；并且，Etcd-gRPC-proxy服务器是无状态的，可以进行无限制的水平扩展；也就是说，在当前的Etcd-gRPC-proxy服务器的所能提供的数据处理能力不足时，可以增加新的Etcd-gRPC-proxy服务器来增强对数据的处理能力，并且各自Etcd-gRPC-proxy服务器对请求的处理是独立的，不受影响的。

本申请的实施例所提供的信息处理方法，可以通过代理服务器基于中心分布式存储系统中配置的路由信息将客户端的用于获取资源数据的获取请求转发至对应的分布式存储系统，即不需要依赖于kube-apiserver进行资源数据的获取，也就不需要在kube-apiserver的启动参数中来配置相应的参数，从而解决了相关技术中etcd节点数或者拆分的资源类型较多时存在kube-apiserver的启动参数的配置冗长的问题，实现了在修改kube-apiserver启动参数时不需要重启kube-apiserve，且提高了维护效率。

基于前述实施例，本申请实施例提供一种信息处理方法，参照图2所示，该方法可以包括以下步骤：

步骤201、代理服务器接收经由域名服务器转发的客户端发送的用于请求第一资源信息的获取请求。

其中，域名服务器用于基于目标均衡策略转发获取请求。

在本申请实施例中，域名服务器可以指的是(Domain Name Server，DNS)。其中，如图3所示，通过客户端的kube-apiserver发送获取请求后，该获取请求会被发送至DNS，且DNS可以根据预先设定的目标均衡策略从多个etcd-gRPC-proxy服务器中确定当前可以处理获取请求的etcd-gRPC-proxy服务器，并转发该获取请求至对应的etcd-gRPC-proxy服务器。具体的，kube-apiserver配置的etcd-servers为etcd-gRPC-proxy服务器的域名，在访问etcd时，kube-apiserver会先进行DNS解析从而获取到对应的etcd-gRPC-proxy服务器的IP地址，然后访问对应的etcd-gRPC-proxy服务器，即将获取请求发送至对应的etcd-gRPC-proxy服务器。在一种可行的实现方式中，如图3所示可以包括有etcd-gRPC-proxy1和etcd-gRPC-proxy2等多个etcd-gRPC-proxy服务器，DNS确定出来的获取请求对应的etcd-gRPC-proxy服务器可以是etcd-gRPC-proxy1。

需要说明的是，在整个系统中可以包括有多个客户端，也即如图3所示可以包括有多个终端的多个kube-apiserver(即kube-apiserver1、kube-apiserver2和kube-apiserver3等)。其中，DNS需要在上面配置etcd-gRPC-proxy服务器的域名解析，为etcd-gRPC-proxy服务器的域名添加相应的多条Ipv4/Ipv6记录，每条Ipv4/Ipv6记录对应一个etcd-gRPC-proxy实例的IP地址；每次进行域名解析时，随机返回一个实例的IP地址即可，用于实现多个etcd-gRPC-proxy实例的负载均衡和高可用。

步骤202、代理服务器构建针对中心分布式存储系统中的路由信息的目标树结构。

在本申请实施例中，etcd-gRPC-proxy服务器对应的在中心etcd集群中的配置主要包括：后端etcd集群的配置和路由信息的配置。在一种可行的实现方式中，后端etcd集群的配置可以为：/etcd-grpc-proxy/clusters/<name>:<endpoints>，路由信息的配置可以为/etcd-grpc-proxy/routers/<prefix>:<cluster-name>。

需要说明的是，etcd-gRPC-proxy提供了简单易用的应用程序接口(ApplicationProgramming Interface，API)和命令行工具etcd-grpc-proxyctl来用于动态更新配置，而不需要用户去直接访问中心etcd集群；具体，可以如下表所示：

在本申请其他实施例中，目标树结构可以指的是目标Trie树，可以将中心etcd集群中的路由信息插入到Trie树中得到目标Trie树。在一种可行的实现方式中，以路由信息包括/:default；/events:etcd1；/pods:etcd2和/crd/clusters:etcd3为例进行说明，生成的目标Trie树可以如图4所示的Trie结构。

需要说明的是，中心etcd可以是从图3中所示的后端etcd集群中选出来的；后端etcd集群可以包括如图3中所示的etcd1和etcd2等多个etcd集群。本申请实施例中的etcd-gRPC-proxy支持基于前缀(prefix)的路由策略，可以把不同prefix的key路由到相应的后端etcd集群。

步骤203、代理服务器基于获取请求的目标字符信息遍历目标树结构，得到第一目标路由信息。

其中，代理服务器可以根据获取请求的目标字符信息对中心etcd集群中的目标Trie树进行遍历，得到该获取请求对应的第一目标路由信息。

在一种可行的实现方式中，基于图4所示的目标Trie结构，若获取请求的key为/crd/clusters/test，那执行的查找操作为：先将key值按照路径分割为crd、clusters和test；从Trie根路径开始查找，首先判断根路径是否有crd子节点，根路径有crd子节点；然后查找crd节点是否有clusters子节点，crd节点有clusters子节点；最后查找clusters节点是否有test子节点，查找到确定没有test子节点，那么/crd/clusters这条路径就是匹配到的最长前缀，即为第一目标路由信息。

需要说明的是，本申请实施例中关于目标树结构(即目标Trie树)的路由算法的伪代码可以如下所示：

步骤204、代理服务器基于第一资源信息的类型和第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统。

其中，以中心etcd集群中存储的路由信息为图4所示的路由为例，若资源信息的类型为events，那确定出来的分布式存储系统就是etcd1；若资源信息的类型为pods，那确定出来的分布式存储系统就是etcd2。在本申请实施例中，基于上述确定出来的第一目标路由信息，第一资源信息的类型为clusters，确定出来的第一目标分布式存储系统为etcd3。相应的，etcd-gRPC-proxyl服务器可以发送至获取请求至etcd3集群，以便获取对应的第一资源数据。

步骤205、代理服务器发送获取请求至第一目标分布式存储系统。

步骤206、在监测到中心分布式存储系统中的路由信息发生变化的情况下，代理服务器在中心分布式存储系统中设置代理服务器对应的目标迁移标识。

在本申请实施例中，若中心etcd集群中存储的路由信息被修改，可能会导致资源数据所属的etcd集群发生变化，因此在修改后的路由正式生效之前，etcd-gRPC-proxy服务器需要先进行数据迁移。此时，若获取请求的为etcd-gRPC-proxy1服务器，那么etcd-gRPC-proxy1可以在中心etcd集群中设置迁移锁，并由etcd-gRPC-proxy1来进行数据的迁移。其中，目标迁移标识可以指的是具有该目标迁移标识的etcd-gRPC-proxy具有唯一迁移数据的权限，其他etcd-gRPC-proxy不具有数据迁移的权限。目标迁移标识可以为迁移锁。

步骤207、代理服务器采用目标迁移方式，获取发生变化的路由信息对应的源分布式存储系统中的目标资源信息，并将目标资源信息存储至发生变化的路由信息对应的目的分布式存储系统。

在本申请实施例中，目标迁移方式可以指的是分页迁移方式。

步骤208、代理服务器删除源分布式存储系统中的目标资源信息，并控制发生变化的路由信息处于生效状态。

在本申请实施例中，可以使用分页迁移方式每次从发生变化的路由信息对应的源etcd集群中查询获取目标数量的资源数据，并将查询到的目标数量的资源数据迁移至发生变化的路由信息对应的目的etcd集群，之后将源etcd集群中的已经迁移至目的etcd集群的目标数量的资源数据删除；接着判断刚刚迁移完成的资源数据的数量是否等于目标数量，如果刚刚迁移完成的资源数据的数量等于目标数量，说明源etcd集群中还存在未迁移的资源数据，那就继续从源etcd集群中查询获取资源数据，将其迁移至目的etcd集群，并删除当前迁移至目的etcd集群的资源数据，如此继续循环直到源etcd集群中的数据都迁移至目的etcd集群。如果刚刚迁移完成的资源数据的数量小于目标数量，说明源etcd集群中的资源数据均已迁移完成。在一种可行的实现方式中，目标数量可以为100。

需要说明的是，在资源数据迁移完成之前，路由相关的写请求在所有etcd-gRPC-proxy服务器上都会被阻塞，只有读请求依旧是正常处理的；当资源数据迁移完成后，执行资源数据迁移的etcd-gRPC-proxy服务器会设置路由为生效状态。在一种可行的实现方式中，若在中心etcd集群中新增一条路由，且新增的路由为/leases:etcd4，那写入中心etcd集群的路由信息为/etcd-grpc-proxy/routers/leases？:etcd4；其中，“？”就表示该路由还未正式生效。并且，当路由正式生效时会删除路由key后面的问号，以使得路由处于生效状态。

在一种可行的实现方式中，若资源数据类型为/leases的资源数据之前存储在default集群上，那就需要将default集群(源分布式存储系统)中的数据迁移至新增的etcd4集群(目的分布式存储系统)。

步骤209、代理服务器删除代理服务器对应的目标迁移标识。

在本申请实施例中，在资源数据迁移完成后就删除迁移锁即释放迁移锁，此时之前阻塞的写请就会得到处理。

需要说明的是，步骤209之后若查询发生迁移的所有资源数据可以选择执行步骤210～步骤212，或者若查询发生迁移的资源数据中的某一资源数据可以选择执行步骤213～步骤215。

步骤210、代理服务器接收客户端发送的针对发生变化的路由信息对应的目标资源信息的第一查询请求。

在本申请实施例中，目标资源信息可以指的是前述发生迁移的所有资源数据；当然，该第一查询请求可以是客户端通过Kubernetes应用的kube-apiserver发送给DNS，之后由DNS选择合适的etcd-gRPC-proxy服务器后转发至该合适的etcd-gRPC-proxy服务器的。

步骤211、代理服务器基于第一查询请求从源分布式存储系统中获取第一子资源信息，并从目的分布式存储系统中获取第二子资源信息。

其中，第一子资源信息可以是从发生变化的路由信息对应的源etcd集群中查询获取到的资源数据；第二子资源信息可以是从发生变化的路由信息对应的目的etcd集群中查询获取到的资源数据；也就是说，需要从源etcd集群和目的etcd集群中共同来查询获取资源数据。

步骤212、代理服务器基于第一子资源信息和第二子资源信息，确定目标资源信息。

在本申请实施例中，可以将查询获取到的第一子资源信息和第二子资源信息合起来得到目标资源信息。

步骤213、代理服务器接收客户端发送的针对发生变化的路由信息对应的目标资源信息中的目标子资源信息的第二查询请求。

在本申请实施例中，目标子资源信息可以指的是前述发生迁移的资源数据中的任一资源数据；当然，该第二查询请求可以是客户端通过Kubernetes应用的kube-apiserver发送给DNS，之后由DNS选择适配的etcd-gRPC-proxy服务器后转发至该适配的etcd-gRPC-proxy服务器的。

步骤214、在源分布式存储系统中具有目标子资源信息的情况下，代理服务器基于第二查询请求从源分布式存储系统中获取目标子资源信息。

在本申请实施例中，etcd-gRPC-proxy服务器在接收到第二查询请求后，可以先从源etcd集群中查找该目标子资源信息；若查找到了说明源etcd集群具有该目标子资源信息，就确定获取到了目标子资源信息。

步骤215、在源分布式存储系统中不具有目标子资源信息的情况下，代理服务器基于第二查询请求从目的分布式存储系统中获取目标子资源信息。

在本申请实施例中，若未查找到说明源etcd集群中不具有该目标子资源信息，那就从目的etcd集群中查找该目标子资源信息，并确定查找到的目标子资源信息为最终查询的子资源数据。

在本申请其他实施例中，参照图5所示，该信息方法还可以包括以下步骤：

步骤216、代理服务器接收多个第一客户端发送的针对第二资源信息的监控请求。

在本申请实施例中，多个第一客户端可以是与前述发送获取请求和查询请求的客户端不同；第二资源信息可以指的是多个第一客户端所监控的资源数据；需要说明的是，该第二资源信息可以指的是一个资源数据，或者某一特定范围内的多个资源数据。监控请求可以是用于监控第二资源数据的请求。

需要说明的是，该监控请求可以是客户端通过Kubernetes应用的kube-apiserver发送给DNS，之后由DNS选择etcd-gRPC-proxy服务器后转发至该etcd-gRPC-proxy服务器的。

步骤217、代理服务器基于监控请求从中心分布式存储系统中确定第二目标路由信息。

在本申请实施例中，确定第二目标路由信息的具体实现过程与前述确定第一目标路由信息的实现过程是相同的，此处不作赘述，具体可以参照前述实施例中确定第一目标路由信息的描述。

步骤218、代理服务器基于第二资源信息的类型和第二目标路由信息，确定第二目标分布式存储系统。

其中，第二目标分布式存储系统可以指的是第二目标etcd集群；该第二目标etcd集群可以指的是多个监控请求需要发送至的etcd集群。需要说明的是，etcd-gRPC-proxy服务器可以根据第二资源数据的类型在第二目标路由信息中确定需要路由至的第二目标etcd集群。

步骤219、代理服务器将多个监控请求合并为目标监控请求，并发送至第二目标分布式存储系统。

在本申请实施例中，etcd-gRPC-proxy服务器可以将接收到的多个监控请求合并为一个目标监控请求，并将该目标监控请求转发至第二目标etcd集群。监控请求可以指的是对应的监视程序c-watcher；在一种可行的实现方式中，以具有三个第一客户端为例，如图6所示，每个第一客户端通过自己的kube-apiserver1、kube-apiserver2和kube-apiserver3分别发送各自的c-watcher给etcd-gRPC-proxy服务器，之后etcd-gRPC-proxy服务器可以将三个c-watcher合并为单个监视程序s-watcher，并将该单个监视程序s-watcher发送至确定出来的后端的etcd集群(即第二目标etcd集群)。

步骤220、代理服务器通过第二目标分布式存储系统获取针对第二资源信息的监控事件，并发送监控事件至每一第一客户端。

其中，监控事件是第二目标分布式存储系统基于目标监控请求产生的。

在本申请实施例中，第二目标etcd集群在接收到单个监视程序s-watcher后，可以根据该监视程序s-watcher进行相应的监视(watch)事件；并且，在watch事件发生时，etcd-gRPC-proxy服务器可以将所有事件从s-watcher广播到其对应的c-watcher，以便将监控事件广播至每一个第一客户端。

需要说明的是，本申请实施例中的每个后端etcd集群之间是相互独立的，且可以按需新增或者删除后端etc集群，只需要修改etcd-gRPC-proxy对应的中心etc集群中的后端集群和路由信息的配置即可。

在本申请其他实施例中，参照图7所示，该信息方法还可以包括以下步骤：

步骤221、代理服务器接收多个第二客户端发送的用于确定通信连接的信息流。

在本申请实施例中，多个第二客户端可以是与前述发送获取请求和查询请求的客户端，以及第一客户端不同；其中，信息流可以是用于为了保持客户端申请租约的有效性而定期发送的心跳信号信息流。

需要说明的是，信息流可以是客户端通过Kubernetes应用的kube-apiserver发送给DNS，之后由DNS选择etcd-gRPC-proxy服务器后转发至该etcd-gRPC-proxy服务器的。

步骤222、代理服务器从中心分布式存储系统中确定与信息流对应的第三目标路由信息。

在本申请实施例中，确定第三目标路由信息的具体实现过程与前述确定第一目标路由信息的实现过程是相同的，此处不作赘述，具体可以参照前述实施例中确定第一目标路由信息的描述。

步骤223、代理服务器基于第三目标路由信息确定与信息流对应的第三目标分布式存储系统。

其中，第三目标分布式存储系统可以指的是第三目标etcd集群；该第三目标etcd集群可以指的是多个信息流需要发送至的etcd集群。需要说明的是，etcd-gRPC-proxy服务器可以根据信息流的信息在第三目标路由信息中确定需要路由至的第三目标etcd集群。

步骤224、代理服务器将多个信息流合并为目标信息流，并发送目标信息流至第三目标分布式存储系统。

在本申请实施例中，etcd-gRPC-proxy服务器可以将接收到的多个信息流合并为一个目标信息流，并将该目标信息流转发至第三目标etcd集群。在一种可行的实现方式中，以具有三个第二客户端为例，如图8所示，每个第二客户端通过自己的kube-apiserver1、kube-apiserver2和kube-apiserver3分别发送各自的L1心跳信息流(c-stream)、L1心跳信息流(c-stream)和L3心跳信息流(c-stream)给etcd-gRPC-proxy服务器，之后etcd-gRPC-proxy服务器可以将三个c-stream合并为一个s-stream，并将该一个s-stream发送至确定出来的后端的etcd集群(即第三目标etcd集群)，以实现将s-stream注册到后端etcd集群。

需要说明的是，在etcd工作负载涉及很多的客户端租约活动时，本申请中将多个信息流合并为一个信息流可以避免出现中央处理器(Central Processing Unit，CPU)使用率过高的问题。

步骤225、代理服务器接收第三目标分布式存储系统发送的针对目标信息流的响应信息，并发送响应信息至每一第二客户端。

其中，etcd-gRPC-proxy服务器可以将各自c-stream对应的心跳信息流的响应信息发送至对应的每一个第二客户端，以便完成租约的有效性。

在本申请其他实施例中，本申请实施例中的方案可以支持动态配置，可以动态增删etcd集群和修改路由配置，而无需重启任何服务，进而大幅提升了大规模K8s的可扩展性和可运维性；同时，支持请求合并，可以减小etcd集群的负载，提升系统整体性能。而且，支持任意资源，包括定制资源定义(Custom Resource Definition，CRD)定义的资源或从外部服务器接入的资源。此外，使用本申请提供的方案对K8s的etcd数据存储进行优化后，可以较为容易的实现1万节点以上规模的K8s集群。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

本申请的实施例所提供的信息处理方法，可以通过代理服务器基于中心分布式存储系统中配置的路由信息将客户端的用于获取资源数据的获取请求转发至对应的分布式存储系统，即不需要依赖于kube-apiserver进行资源数据的获取，也就不需要在kube-apiserver的启动参数中来配置相应的参数，从而解决了相关技术中etcd节点数或者拆分的资源类型较多时存在kube-apiserver的启动参数的配置冗长的问题，实现了在修改kube-apiserver启动参数时不需要重启kube-apiserve，且提高了维护效率。

基于前述实施例，本申请实施例提供一种信息处理装置，该信息处理装置可以应用于图1、2、5和7对应的实施例提供的信息处理方法中，参照图9所示，该信息处理装置3可以包括：接收单元31、获取单元32、确定单元33和发送单元34，其中：

接收单元31，用于接收客户端发送的用于请求第一资源信息的获取请求；

获取单元32，用于基于获取请求从中心分布式存储系统中获取第一目标路由信息；

确定单元33，用于基于第一资源信息的类型和第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统；

发送单元34，用于发送获取请求至第一目标分布式存储系统。

在本申请的其他实施例中，获取单元32还用于执行以下步骤：

构建针对中心分布式存储系统中的路由信息的目标树结构；

基于获取请求的目标字符信息遍历目标树结构，得到第一目标路由信息。

在本申请的其他实施例中，接收单元31，还用于接收多个第一客户端发送的针对第二资源信息的监控请求；

确定单元33，还用于基于监控请求从中心分布式存储系统中确定第二目标路由信息；

确定单元33，还用于基于第二资源信息的类型和第二目标路由信息，确定第二目标分布式存储系统；

发送单元34，还用于将多个监控请求合并为目标监控请求，并发送至第二目标分布式存储系统；

相应的，发送单元34，还用于通过第二目标分布式存储系统获取针对第二资源信息的监控事件，并发送监控事件至每一第一客户端；其中，监控事件是第二目标分布式存储系统基于目标监控请求产生的。

在本申请的其他实施例中，接收单元31，还用于接收多个第二客户端发送的用于确定通信连接的信息流；

确定单元33，还用于从中心分布式存储系统中确定与信息流对应的第三目标路由信息；

确定单元33，还用于基于第三目标路由信息确定与信息流对应的第三目标分布式存储系统；

发送单元34，还用于将多个信息流合并为目标信息流，并发送目标信息流至第三目标分布式存储系统；

相应的，发送单元34，还用于接收第三目标分布式存储系统发送的针对目标信息流的响应信息，并发送响应信息至每一第二客户端。

在本申请的其他实施例中，参照图9所示，该信息处理装置还包括处理单元35，其中，处理单元35用于执行以下步骤：

在监测到中心分布式存储系统中的路由信息发生变化的情况下，在中心分布式存储系统中设置代理服务器对应的目标迁移标识；

采用目标迁移方式，获取发生变化的路由信息对应的源分布式存储系统中的目标资源信息，并将目标资源信息存储至发生变化的路由信息对应的目的分布式存储系统；

删除源分布式存储系统中的目标资源信息，并控制发生变化的路由信息处于生效状态；

删除代理服务器对应的目标迁移标识。

在本申请的其他实施例中，接收单元31，还用于接收客户端发送的针对发生变化的路由信息对应的目标资源信息的第一查询请求；

获取单元32，还用于基于第一查询请求从源分布式存储系统中获取第一子资源信息，并从目的分布式存储系统中获取第二子资源信息；

确定单元33，还用于基于第一子资源信息和第二子资源信息，确定目标资源信息。

在本申请的其他实施例中，接收单元31，还用于接收客户端发送的针对发生变化的路由信息对应的目标资源信息中的目标子资源信息的第二查询请求；

获取单元32，还用于在源分布式存储系统中具有目标子资源信息的情况下，基于第二查询请求从源分布式存储系统中获取目标子资源信息；

获取单元32，还用于在源分布式存储系统中不具有目标子资源信息的情况下，基于第二查询请求从目的分布式存储系统中获取目标子资源信息。

在本申请的其他实施例中，接收单元31，还用于接收经由域名服务器转发的客户端发送的获取请求；其中，域名服务器用于基于目标均衡策略转发获取请求。

需要说明的是，各个单元所执行的步骤的具体说明可以参照图1、2、5和7对应的实施例提供的信息处理方法中，此处不再赘述。

本申请的实施例所提供的信息处理装置，可以通过代理服务器基于中心分布式存储系统中配置的路由信息将客户端的用于获取资源数据的获取请求转发至对应的分布式存储系统，即不需要依赖于kube-apiserver进行资源数据的获取，也就不需要在kube-apiserver的启动参数中来配置相应的参数，从而解决了相关技术中etcd节点数或者拆分的资源类型较多时存在kube-apiserver的启动参数的配置冗长的问题，实现了在修改kube-apiserver启动参数时不需要重启kube-apiserve，且提高了维护效率。

基于前述实施例，本申请的实施例提供一种代理服务器，该代理服务器可以应用于图1、2、5和7对应的实施例提供的信息处理方法中，参照图10所示，该代理服务器4可以包括：处理器41、存储器42和通信总线43，其中：

通信总线43用于实现处理器41和存储器42之间的通信连接；

处理器41用于执行存储器42中的信息处理程序，以实现以下步骤：

接收客户端发送的用于请求第一资源信息的获取请求；

基于获取请求从中心分布式存储系统中获取第一目标路由信息；

基于第一资源信息的类型和第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统；

发送获取请求至第一目标分布式存储系统。

在本申请的其他实施例中，处理器41用于执行存储器42中的信息处理程序的基于获取请求从中心分布式存储系统中获取第一目标路由信息，以实现以下步骤：

构建针对中心分布式存储系统中的路由信息的目标树结构；

基于获取请求的目标字符信息遍历目标树结构，得到第一目标路由信息。

在本申请的其他实施例中，处理器41用于执行存储器42中的信息处理程序，还可以实现以下步骤：

接收多个第一客户端发送的针对第二资源信息的监控请求；

基于监控请求从中心分布式存储系统中确定第二目标路由信息；

基于第二资源信息的类型和第二目标路由信息，确定第二目标分布式存储系统；

将多个监控请求合并为目标监控请求，并发送至第二目标分布式存储系统；

相应的，处理器41用于执行存储器42中的信息处理程序，还可以实现以下步骤：

通过第二目标分布式存储系统获取针对第二资源信息的监控事件，并发送监控事件至每一第一客户端；其中，监控事件是第二目标分布式存储系统基于目标监控请求产生的。

在本申请的其他实施例中，处理器41用于执行存储器42中的信息处理程序，还可以实现以下步骤：

接收多个第二客户端发送的用于确定通信连接的信息流；

从中心分布式存储系统中确定与信息流对应的第三目标路由信息；

基于第三目标路由信息确定与信息流对应的第三目标分布式存储系统；

将多个信息流合并为目标信息流，并发送目标信息流至第三目标分布式存储系统；

相应的，处理器41用于执行存储器42中的信息处理程序，还可以实现以下步骤：

接收第三目标分布式存储系统发送的针对目标信息流的响应信息，并发送响应信息至每一第二客户端。

在本申请的其他实施例中，处理器41用于执行存储器42中的信息处理程序，还可以实现以下步骤：

在监测到中心分布式存储系统中的路由信息发生变化的情况下，在中心分布式存储系统中设置代理服务器对应的目标迁移标识；

采用目标迁移方式，获取发生变化的路由信息对应的源分布式存储系统中的目标资源信息，并将目标资源信息存储至发生变化的路由信息对应的目的分布式存储系统；

删除源分布式存储系统中的目标资源信息，并控制发生变化的路由信息处于生效状态；

删除代理服务器对应的目标迁移标识。

在本申请的其他实施例中，处理器41用于执行存储器42中的信息处理程序，还可以实现以下步骤：

接收客户端发送的针对发生变化的路由信息对应的目标资源信息的第一查询请求；

基于第一查询请求从源分布式存储系统中获取第一子资源信息，并从目的分布式存储系统中获取第二子资源信息；

基于第一子资源信息和第二子资源信息，确定目标资源信息。

在本申请的其他实施例中，处理器41用于执行存储器42中的信息处理程序，还可以实现以下步骤：

接收客户端发送的针对发生变化的路由信息对应的目标资源信息中的目标子资源信息的第二查询请求；

在源分布式存储系统中具有目标子资源信息的情况下，基于第二查询请求从源分布式存储系统中获取目标子资源信息；

在源分布式存储系统中不具有目标子资源信息的情况下，基于第二查询请求从目的分布式存储系统中获取目标子资源信息。

在本申请的其他实施例中，处理器41用于执行存储器42中的信息处理程序的接收客户端发送的用于请求第一资源信息的获取请求，以实现以下步骤：

接收经由域名服务器转发的客户端发送的获取请求；其中，域名服务器用于基于目标均衡策略转发获取请求。

需要说明的是，处理器所执行的步骤的具体说明可以参照图1、2、5和7对应的实施例提供的信息处理方法中，此处不再赘述。

本申请的实施例所提供的代理服务器备，可以通过代理服务器基于中心分布式存储系统中配置的路由信息将客户端的用于获取资源数据的获取请求转发至对应的分布式存储系统，即不需要依赖于kube-apiserver进行资源数据的获取，也就不需要在kube-apiserver的启动参数中来配置相应的参数，从而解决了相关技术中etcd节点数或者拆分的资源类型较多时存在kube-apiserver的启动参数的配置冗长的问题，实现了在修改kube-apiserver启动参数时不需要重启kube-apiserve，且提高了维护效率。

基于前述实施例，本申请的实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有一个或者多个程序，该一个或者多个程序可被一个或者多个处理器执行，以实现图1、2、5和7对应的实施例提供的信息处理方法的步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据传输设备的处理器以产生一个机器，使得通过计算机或其他可编程数据传输设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据传输设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据传输设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims (11)

1.一种信息处理方法，其特征在于，所述方法包括：

接收客户端发送的用于请求第一资源信息的获取请求；

基于所述获取请求从中心分布式存储系统中获取第一目标路由信息；

基于所述第一资源信息的类型和所述第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统；

发送所述获取请求至所述第一目标分布式存储系统。

2.根据权利要求1所述的方法，其特征在于，所述基于所述获取请求从中心分布式存储系统中获取目标路由信息，包括：

构建针对所述中心分布式存储系统中的路由信息的目标树结构；

基于所述获取请求的目标字符信息遍历所述目标树结构，得到所述第一目标路由信息。

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

接收多个第一客户端发送的针对第二资源信息的监控请求；

基于所述监控请求从所述中心分布式存储系统中确定第二目标路由信息；

基于所述第二资源信息的类型和所述第二目标路由信息，确定第二目标分布式存储系统；

将多个所述监控请求合并为目标监控请求，并发送至所述第二目标分布式存储系统；

相应的，所述方法还包括：

通过所述第二目标分布式存储系统获取针对所述第二资源信息的监控事件，并发送所述监控事件至每一第一客户端；其中，所述监控事件是所述第二目标分布式存储系统基于所述目标监控请求产生的。

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

接收多个第二客户端发送的用于确定通信连接的信息流；

从所述中心分布式存储系统中确定与所述信息流对应的第三目标路由信息；

基于所述第三目标路由信息确定与所述信息流对应的第三目标分布式存储系统；

将多个所述信息流合并为目标信息流，并发送所述目标信息流至所述第三目标分布式存储系统；

相应的，所述方法还包括：

接收所述第三目标分布式存储系统发送的针对所述目标信息流的响应信息，并发送所述响应信息至每一第二客户端。

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

在监测到所述中心分布式存储系统中的路由信息发生变化的情况下，在所述中心分布式存储系统中设置代理服务器对应的目标迁移标识；

采用目标迁移方式，获取发生变化的路由信息对应的源分布式存储系统中的目标资源信息，并将所述目标资源信息存储至所述发生变化的路由信息对应的目的分布式存储系统；

删除所述源分布式存储系统中的所述目标资源信息，并控制所述发生变化的路由信息处于生效状态；

删除所述目标迁移标识。

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

接收所述客户端发送的针对所述发生变化的路由信息对应的所述目标资源信息的第一查询请求；

基于所述第一查询请求从所述源分布式存储系统中获取第一子资源信息，并从所述目的分布式存储系统中获取第二子资源信息；

基于所述第一子资源信息和所述第二子资源信息，确定所述目标资源信息。

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

接收所述客户端发送的针对所述发生变化的路由信息对应的所述目标资源信息中的目标子资源信息的第二查询请求；

在所述源分布式存储系统中具有所述目标子资源信息的情况下，基于所述第二查询请求从所述源分布式存储系统中获取所述目标子资源信息；

在所述源分布式存储系统中不具有所述目标子资源信息的情况下，基于所述第二查询请求从所述目的分布式存储系统中获取所述目标子资源信息。

8.根据权利要求1所述的方法，其特征在于，所述接收客户端发送的用于请求资源信息的获取请求，包括：

接收经由域名服务器转发的所述客户端发送的所述获取请求；其中，所述域名服务器用于基于目标均衡策略转发所述获取请求。

9.一种信息处理装置，其特征在于，所述装置包括：

接收单元，用于接收客户端发送的用于请求第一资源信息的获取请求；

获取单元，用于基于所述获取请求从中心分布式存储系统中获取第一目标路由信息；

确定单元，用于基于所述第一资源信息的类型和所述第一目标路由信息，从分布式存储系统中确定第一目标分布式存储系统；

发送单元，用于发送所述获取请求至所述第一目标分布式存储系统。

10.一种代理服务器，其特征在于，所述代理服务器包括：处理器、存储器和通信总线；

所述通信总线用于实现所述处理器和所述存储器之间的通信连接；

所述处理器用于执行所述存储器中的信息处理程序，以实现如权利要求1～8中任一项所述的信息处理方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现如权利要求1～8中任一项所述的信息处理方法的步骤。