用于对分布式存储系统进行读写的方法和装置

技术领域

本申请涉及互联网大数据技术领域，特别涉及一种用于对分布式存储系统进行读写的方法和装置。

背景技术

随着大数据技术的高速发展，越来越多的企业采用基于Hbase的NoSQL数据服务作为结构化数据与半结构数据的分布式存储系统。企业内部通常会出现多个应用需要接入存储服务的需求，而如果各应用独自搭建一套Hbase集群，将面临着运维困难、集群利用率低、数据共享难等压力。因此，搭建一套运维简单，高可用，架构灵活，让应用容易接入的多租户存储系统就成为了必然选择。而传统单体架构由于服务间没有解耦，在数据量和用户量较小的时候可以胜任，但当数据量和用户量暴增之后，往往会出现运维成本高，可扩展性和容错性差等问题，且不能通过简单的增加机器解决。为了满足服务间的解耦，存储系统通常采用微服务架构。在搭建微服务架构的存储系统时，需考虑大流量、高并发、低成本等要求，既需要保障各应用的资源隔离，也要考虑服务的可扩展性。

为了防止各应用互相挤占并发资源，存储系统需要做到对各应用进行资源隔离以达到总体服务稳定的目的，而传统资源隔离通常是在集群侧进行，操作不够灵活且较难控制。同时，为了保证服务的高可用性，传统的微服务架构一般是将应用服务实例注册到服务注册中心。然而，各应用服务实例接收到的请求不同，节点压力也不同，而服务注册中心返回的实例信息无法控制，无法达到多实例负载均衡的理想效果。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种用于对分布式存储系统进行读写的方法和装置，以提供一种实现资源分离和负载均衡的分布式存储系统读写方法。

本申请实施例提供了一种用于对分布式存储系统进行读写的方法，包括：目标应用服务向协调服务端发送第一请求，其中，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例；响应于第一请求，协调服务端获取目标应用服务对应的多个可用应用服务实例的标识信息，并根据预设规则从多个可用应用服务实例中确定出目标应用服务实例；协调服务端将目标应用服务实例的标识信息发送至目标应用服务；目标应用服务基于目标应用服务实例的标识信息向目标应用服务实例发送读写请求；响应于读写请求，目标应用服务实例对分布式存储系统执行读写操作。

本申请实施例提供了一种用于对分布式存储系统进行读写的方法，应用于协调服务端，包括：接收目标应用服务发送的第一请求，其中，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例；响应于第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息；根据预设规则从多个可用应用服务实例中确定出目标应用服务实例；将目标应用服务实例的标识信息发送至目标应用服务，使得目标应用服务通过目标应用服务实例对分布式存储系统执行读写操作。

本申请实施例提供了一种用于对分布式存储系统进行读写的方法，应用于目标应用服务，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例，该方法包括：向协调服务端发送第一请求；接收协调服务端响应于第一请求返回的目标应用服务对应的目标应用服务实例的标识信息；基于目标应用服务实例的标识信息，向目标应用服务实例发送读写请求，以使得目标应用服务实例响应于读写请求对分布式存储系统执行读写操作。

本申请实施例提供了一种用于对分布式存储系统进行读写的方法，应用于服务注册中心，服务注册中心注册有协调服务端对应的多个协调服务实例以及有权限对分布式存储系统进行读写的多个应用服务中各应用服务对应的多个应用服务实例，该方法包括：接收目标应用服务发送的第三请求，其中，目标应用服务为多个应用服务中的一个；响应于第三请求，将可用协调服务实例的标识信息返回给目标应用服务，使得目标应用服务向可用协调服务实例的标识信息对应的目标协调服务实例发送第一请求；接收目标协调服务实例响应于第一请求发送的第二请求；响应于第二请求，向目标协调服务实例返回目标应用服务对应的多个可用应用服务实例的标识信息，协调服务实例用于根据预设规则从多个可用应用服务实例中确定出目标应用服务实例，使得目标应用服务通过目标应用服务实例对分布式存储系统执行读写操作。

本申请实施例提供了一种用于对分布式存储系统进行读写的装置，位于协调服务端，包括：接收模块，用于接收目标应用服务发送的第一请求，其中，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例；获取模块，用于响应于第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息；确定模块，用于根据预设规则从多个可用应用服务实例中确定出目标应用服务实例；发送模块，用于将目标应用服务实例的标识信息发送至目标应用服务，使得目标应用服务通过目标应用服务实例对分布式存储系统执行读写操作。

本申请实施例还提供一种计算机设备，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现上述任意实施例中所述的用于对分布式存储系统进行读写的方法的步骤。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现上述任意实施例中所述的用于对分布式存储系统进行读写的方法的步骤。

在本申请实施例中，提供了一种用于对分布式存储系统进行读写的方法，有权限对分布式存储系统进行读写的多个应用服务中各应用服务具有对应的多个应用服务实例，多个应用服务中的目标应用服务可以向协调服务端发送第一请求，协调服务端响应于第一请求获取目标应用服务对应的多个可用应用服务实例的标识信息，并根据预设规则从多个可用应用服务实例中确定出目标应用服务实例，协调服务端将目标应用服务实例的标识信息发送至目标应用服务，目标应用服务基于目标应用服务实例的标识信息向目标应用服务实例发送读写请求，目标应用服务实例响应于读写请求对分布式存储系统执行读写操作。上述方案中，可以将对分布式存储系统进行读写的功能封装成服务组件，目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写，通过为有权限对分布式存储系统进行读写的多个应用服务中的每个应用服务提供一组独立的应用服务实例，使得各应用服务可以通过将请求提交到自己的应用服务实例上面进行数据的读写，从而在应用服务实例侧实现资源隔离，相较于传统的在集群侧进行资源隔离而言，在应用服务实例侧实现资源隔离，操作更加灵活且容易控制。此外，通过协调服务端确定执行读写操作的目标应用服务对应的目标应用服务实例，可以对执行读写操作的服务实例进行控制，从而实现多实例负载均衡的效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，并不构成对本申请的限定。在附图中：

图1示出了本申请一实施例中用于对分布式存储系统进行读写的方法的应用场景的示意图；

图2示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图；

图3示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图；

图4示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图；

图5示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图；

图6示出了本申请一实施例中用于对分布式存储系统进行读写的方法的交互示意图；

图7示出了本申请一实施例中Coordinate服务执行原理的流程图；

图8示出了图7中步骤S706工作原理流程图；

图9示出了本申请一实施例中的用于对分布式存储系统进行读写的装置的示意图；

图10示出了本申请一实施例中的计算机设备的示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本申请公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

图1本领域的技术人员知道，本申请的实施方式可以实现为一种系统、装置设备、方法或计算机程序产品。因此，本申请公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

考虑到企业等各种机构内部通常会出现多个应用需要接入存储服务的需求，而如果各应用独自搭建一套Hbase集群，将面临着运维困难、集群利用率低、数据共享难等压力，可以搭建一套运维简单，高可用，架构灵活，让应用容易接入的多租户存储系统。基于此，本申请实施例提供了一种用于对分布式存储系统进行读写的方法。图1示出了本申请一实施例中用于对分布式存储系统进行读写的方法的应用场景的示意图。

请参考图1，应用A、应用B、……应用X为需要接入存储服务的多个应用服务，即有权限对分布式存储系统进行读写的多个应用服务。可以为每个应用服务提供一组独立的应用服务实例。如图1中所示，A-server服务为应用A对应的一组应用服务实例，B-server服务为应用B对应的一组应用服务实例，X-server服务为应用X对应的一组应用服务实例，并且A-server服务、B-server服务和X-server服务为相互独立的应用服务实例组。如图1所示，各应用服务可以通过将读写请求提交到自己的应用服务实例，并通过应用服务实例对分布式存储系统(例如，Hbase集群)进行数据读写操作，从而可以实现在应用服务实例侧实现资源隔离的目的。

请继续参考图1，可以将应用服务实例部署到Docker容器中，可以通过Kubernetes容器编排引擎进行管理。Kubernetes简称K8S，为容器编排引擎，能够对容器进行管理，提供快速的容器调度、弹性伸缩等诸多功能。每个应用服务实例能接收到的读写请求是有并发数限制的，当应用读写业务量增大时，可以通过Kubernetes容器编排引擎方便及时地为应用服务扩容服务实例个数，提升并发资源，满足业务需求；在业务量缩减时，以通过Kubernetes容器编排引擎方便及时地为应用服务减少服务实例个数，节省资源，从而达到动态分配联机并发资源的目的。

图2示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例描述及附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至分布式处理环境)。

具体地，如图2所示，本申请一种实施例提供的用于对分布式存储系统进行读写的方法可以包括以下步骤。

步骤S201，目标应用服务向协调服务端发送第一请求，其中，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例。

本实施例中，可以将对分布式存储系统进行读写的功能封装成服务组件。目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写。多个应用服务中的各应用服务可以具有对应的多个应用服务实例。目标应用服务可以向协调服务端发送第一请求。

步骤S202，响应于第一请求，协调服务端获取目标应用服务对应的多个可用应用服务实例的标识信息，并根据预设规则从多个可用应用服务实例中确定出目标应用服务实例。

步骤S203，协调服务端将目标应用服务实例的标识信息发送至目标应用服务。

协调服务端响应于接收到的第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息。其中，第一请求中可以携带有目标应用服务的应用标识。在一个实施例中，协调服务端中可以缓存有各应用服务对应的多个可用应用服务实例的标识信息。在另一个实施例中，协调服务端可以向服务注册中心发送第二请求。其中，第二请求中可以携带有目标应用服务的应用标识。服务注册中心可以注册有多个应用服务中各应用服务对应的多个应用服务实例。服务注册中心可以响应于第二请求向协调服务端返回目标应用服务对应的多个可用应用服务实例的标识信息。

协调服务端可以根据预设规则从多个可用应用服务实例中确定出目标应用服务实例。例如，协调服务端可以从多个可用应用服务实例中随机确定出目标应用服务实例。又例如，协调服务端可以依次确定出目标应用服务实例，即，随着接收到的第二请求，按预设顺序给出目标应用服务实例。在确定出目标应用服务实例中，协调服务端可以将目标应用服务实例的标识信息发送至目标应用服务。

步骤S204，目标应用服务基于目标应用服务实例的标识信息向目标应用服务实例发送读写请求。

步骤S205，响应于读写请求，目标应用服务实例对分布式存储系统执行读写操作。

在接收到目标应用服务实例的标识信息之后，目标应用服务可以基于接收到的标识信息，向目标应用服务实例发送读写请求。目标应用服务实例可以响应于读写请求对分布式存储系统执行读写操作。

上述实施例中，可以将对分布式存储系统进行读写的功能封装成服务组件，目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写，通过为有权限对分布式存储系统进行读写的多个应用服务中的每个应用服务提供一组独立的应用服务实例，使得各应用服务可以通过将请求提交到自己的应用服务实例上面进行数据的读写，从而在应用服务实例侧实现资源隔离，相较于传统的在集群侧进行资源隔离而言，在应用服务实例侧实现资源隔离，操作更加灵活且容易控制。此外，通过协调服务端确定执行读写操作的目标应用服务对应的目标应用服务实例，可以对执行读写操作的服务实例进行控制，从而实现多实例负载均衡的效果。

请参考图3，示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图。本实施例中的方法可以应用于协调服务端。如图3所示，本申请一种实施例提供的用于对分布式存储系统进行读写的方法可以包括以下步骤。

步骤S301，接收目标应用服务发送的第一请求，其中，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例。

步骤S302，响应于第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息。

协调服务端可以接收目标应用服务发送的第一请求。其中，目标应用服务作为分布式存储系统的多个接入应用服务中一个，可以对分布式存储系统进行读写。可以将对分布式存储系统进行读写的功能封装成服务组件。多个应用服务中的各应用服务可以具有一组应用服务实例。其中，第一请求中可以携带有目标应用服务的应用标识。协调服务端可以响应于接收到的第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息。

步骤S303，根据预设规则从多个可用应用服务实例中确定出目标应用服务实例。

步骤S304，将目标应用服务实例的标识信息发送至目标应用服务，使得目标应用服务通过目标应用服务实例对分布式存储系统执行读写操作。

协调服务端可以根据预设规则从多个可用应用服务实例中确定出目标应用服务实例。例如，协调服务端可以从多个可用应用服务实例中随机确定出目标应用服务实例。又例如，协调服务端可以依次确定出目标应用服务实例，即，随着接收到的第二请求，按预设顺序给出目标应用服务实例。在确定出目标应用服务实例中，协调服务端可以将目标应用服务实例的标识信息发送至目标应用服务。在接收到目标应用服务实例的标识信息之后，目标应用服务可以基于接收到的标识信息，向目标应用服务实例发送读写请求。目标应用服务实例可以响应于读写请求对分布式存储系统执行读写操作。

上述实施例中，可以将对分布式存储系统进行读写的功能封装成服务组件，目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写，通过为有权限对分布式存储系统进行读写的多个应用服务中的每个应用服务提供一组独立的应用服务实例，使得各应用服务可以通过将请求提交到自己的应用服务实例上面进行数据的读写，从而在应用服务实例侧实现资源隔离，相较于传统的在集群侧进行资源隔离而言，在应用服务实例侧实现资源隔离，操作更加灵活且容易控制。此外，通过协调服务端确定执行读写操作的目标应用服务对应的目标应用服务实例，可以对执行读写操作的服务实例进行控制，从而实现多实例负载均衡的效果。

在本申请一些实施例中，响应于第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息，可以包括：响应于第一请求，向服务注册中心发送第二请求，其中，服务注册中心注册有多个应用服务中各应用服务对应的多个应用服务实例；接收服务注册中心响应于第二请求返回的目标应用服务对应的多个可用应用服务实例的标识信息。

响应于第一请求，协调服务端可以向服务注册中心发送第二请求。其中，第二请求中可以携带有目标应用服务的应用标识。服务注册中心可以注册有多个应用服务中各应用服务对应的多个应用服务实例。响应于第二请求，服务注册中心可以确定目标应用服务对应的多个可用应用服务的标识信息，并向协调服务端返回目标应用服务对应的多个可用应用服务实例的标识信息。通过将多个应用服务中各应用服务对应的应用服务实例注册到注册中心，可以从注册中心获取目标应用服务对应的多个可用应用服务实例的标识信息。

在本申请一些实施例中，该方法还可以包括：定时向服务注册中心发送第四请求；接收服务注册中心响应于第四请求返回的多个应用服务中各应用服务对应的多个可用应用服务实例的标识信息；将多个应用服务中各应用服务对应的多个可用应用服务实例的标识信息缓存到本地。

协调服务端在启动后进行初始化，可以从服务注册中心获取多个应用服务中各应用服务对应的多个应用服务实例的信息，并缓存到本地，之后可以每隔预设时间(例如，1分钟、5分钟)更新一次，如果更新失败，则仍缓存上一次的应用服务实例的标识信息。具体地，协调服务端可以定时向服务注册中心发送第四请求。服务注册中心响应于第四请求向协调服务端返回多个应用服务中各应用服务对应的多个可用应用服务实例的标识信息。协调服务端接收到服务注册中心返回的多个应用服务中各应用服务对应的多个可用应用服务实例的标识信息之后，将其缓存到本地，实现定时更新。相应的，在协调服务端向服务注册中心发送第二请求失败的情况下，可以从本地缓存中获取目标应用对应的多个可用应用服务的标识信息。通过上述方式，使得在协调服务端与服务注册中心之间连接失败的情况下仍然可以获取目标应用对应的多个可用应用服务实例的标识信息。

在本申请一些实施例中，根据预设规则从多个可用应用服务实例中确定出目标应用服务实例，可以包括：获取目标应用对应的多个可用应用服务实例中各可用应用服务实例的监控指标信息；根据各可用应用服务实例的监控指标信息，从多个可用应用服务实例中确定出目标应用服务实例。

具体地，协调服务端可以获取目标应用服务对应的多个可用应用服务实例中各服务实例的监控指标信息。在一个实施例中，多个应用服务实例以容器化方式进行部署，由容器编排引擎进行管理，容器编排引擎可以用于监控多个应用服务实例中各应用服务实例的监控指标信息。协调服务端可以从容器编排引擎获取目标应用服务对应的多个可用应用服务实例中各实例的监控指标信息。

在一个实施例中，监控指标信息可以包括以下至少之一：CPU利用率、内存以及IO等指标信息。例如，协调服务端可以根据自定义规则进行测算返回最符合要求的服务器信息。例如，对监控指标中的CPU利用率、内存、IO等指标按照自定义的比例进行计算相加，返回值最大或最小的服务实例的IP和端口。又例如，协调服务端可以根据服务实例的单一指标进行排序，比如返回CPU使用率最低的服务实例的标识信息或者返回可用内存最大的服务实例的标识信息。通过上述方式，可以返回最佳性能的服务实例执行分布式存储系统的读写操作，可以达到多实例负载均衡的目的。

请参考图4，示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图。本实施例中的方法应用于目标应用服务，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例。如图4所示，本申请一种实施例提供的用于对分布式存储系统进行读写的方法可以包括以下步骤。

步骤S401，向协调服务端发送第一请求。

本实施例中，可以将对分布式存储系统进行读写的功能封装成服务组件。目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写。多个应用服务中的各应用服务可以具有对应的多个应用服务实例。目标应用服务可以向协调服务端发送第一请求。其中，第一请求中可以携带有目标应用服务的应用标识。

步骤S402，接收协调服务端响应于第一请求返回的目标应用服务对应的目标应用服务实例的标识信息。

协调服务端响应于接收到的第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息。其中，第一请求中可以携带有目标应用服务的应用标识。在一个实施例中，协调服务端中可以缓存有各应用服务对应的多个可用应用服务实例的标识信息。在另一个实施例中，协调服务端可以向服务注册中心发送第二请求。其中，第二请求中可以携带有目标应用服务的应用标识。服务注册中心可以注册有多个应用服务中各应用服务对应的多个应用服务实例。服务注册中心可以响应于第二请求向协调服务端返回目标应用服务对应的多个可用应用服务实例的标识信息。

协调服务端可以根据预设规则从多个可用应用服务实例中确定出目标应用服务实例。例如，协调服务端可以从多个可用应用服务实例中随机确定出目标应用服务实例。又例如，协调服务端可以依次确定出目标应用服务实例，即，随着接收到的第二请求，按预设顺序给出目标应用服务实例。又例如，协调服务端可以获取多个可用应用服务实例中各可用应用服务实例的监控指标信息，并根据各可用应用服务实例的监控指标信息，从多个可用应用服务实例中确定出目标应用服务实例。目标应用服务可以接收协调服务端响应于第一请求返回的目标应用服务对应的目标应用服务实例的标识信息。

步骤S403，基于目标应用服务实例的标识信息，向目标应用服务实例发送读写请求，以使得目标应用服务实例响应于读写请求对分布式存储系统执行读写操作。

在接收到目标应用服务实例的标识信息之后，目标应用服务可以基于接收到的标识信息，向目标应用服务实例发送读写请求。目标应用服务实例可以响应于读写请求对分布式存储系统执行读写操作。

上述实施例中，可以将对分布式存储系统进行读写的功能封装成服务组件，目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写，通过为有权限对分布式存储系统进行读写的多个应用服务中的每个应用服务提供一组独立的应用服务实例，使得各应用服务可以通过将请求提交到自己的应用服务实例上面进行数据的读写，从而在应用服务实例侧实现资源隔离，相较于传统的在集群侧进行资源隔离而言，在应用服务实例侧实现资源隔离，操作更加灵活且容易控制。此外，通过协调服务端确定执行读写操作的目标应用服务对应的目标应用服务实例，可以对执行读写操作的服务实例进行控制，从而实现多实例负载均衡的效果。

在本申请一些实施例中，协调服务端具有多个协调服务实例；相应的，向协调服务端发送第一请求，可以包括：向服务注册中心发送第三请求，其中，服务注册中心注册有多个协调服务实例；接收服务注册中心响应于第三请求返回的可用协调服务实例的标识信息；向可用协调服务实例的标识信息对应的目标协调服务实例发送第一请求。

具体地，可以将协调服务端设置为多实例部署，即协调服务端具有多个协调服务实例。多个协调服务实例可以注册在服务注册中心中。目标应用服务可以向服务注册中心发送第三请求。服务注册中心可以响应于第三请求，确定可用的或者说存活的协调服务实例，并将可用协调服务实例的标识信息返回给目标应用服务。在存货的协调服务实例为多个的情况下，服务注册中心可以将其中一个的标识信息返回给目标应用服务。目标应用服务可以向接收到的可用协调服务实例的标识信息对应的目标协调服务实例发送第一请求，以获取对应的目标应用服务实例的标识信息。上述实施例中，通过将协调服务端设置为多实例部署，可以防止单节点故障。

在本申请一些实施例中，多个应用服务实例以容器化方式进行部署，由容器编排引擎进行管理，容器编排引擎用于监控多个应用服务实例中各应用服务实例的监控指标信息，并根据监控指标信息对多个应用服务实例中各应用服务实例进行扩容或缩容。

具体地，可以将多个应用服务实例部署到容器中，通过容器编排引擎进行管理。每个应用服务实例能接收到的读写请求是有并发数限制的，当应用读写业务量增大时，通过容器编排引擎方便及时的为应用扩容服务实例个数，提升并发资源，满足业务需求；业务量缩减时，及时减少服务实例个数，节省资源，从而达到动态分配联机并发资源的目的。

请参考图5，示出了本申请一实施例中用于对分布式存储系统进行读写的方法的流程图。如图5所示，本申请一种实施例提供的用于对分布式存储系统进行读写的方法可以包括以下步骤。

步骤S501，接收目标应用服务发送的第三请求，其中，目标应用服务为多个应用服务中的一个。

本实施例中的方法应用于服务注册中心，服务注册中心注册有协调服务端对应的多个协调服务实例以及有权限对分布式存储系统进行读写的多个应用服务中各应用服务对应的多个应用服务实例。每个应用服务实例和协调服务实例在启动后可以在服务注册中心进行注册，这样服务注册中心的服务注册表中将会存储所有应用服务实例和协调服务实例的信息。如果一个服务实例超过默认时间不向服务注册中心发送心跳，则注册服务中心就会将该服务实例从应用注册服务列表中删除，仅保留可用的服务实例。服务注册中心可以接收多个应用服务中的目标应用服务发送的第三请求。

步骤S502，响应于第三请求，将可用协调服务实例的标识信息返回给目标应用服务，使得目标应用服务向可用协调服务实例的标识信息对应的目标协调服务实例发送第一请求。

服务注册中心可以响应于第三请求，将可用协调服务实例的标识信息返回给目标应用服务。目标应用服务基于接收到的可用协调服务实例的标识信息向对应的目标协调服务实例发送第一请求。

步骤S503，接收目标协调服务实例响应于第一请求发送的第二请求。

步骤S504，响应于第二请求，向目标协调服务实例返回目标应用服务对应的多个可用应用服务实例的标识信息，目标协调服务实例用于根据预设规则从多个可用应用服务实例中确定出目标应用服务实例，使得目标应用服务通过目标应用服务实例对分布式存储系统执行读写操作。

目标协调服务实例接收到第一请求之后，向服务注册中心发送第二请求。服务注册中心可以响应于第二请求，从服务注册列表中获取目标应用服务对应的多个可用应用服务实例的标识信息，并将其返回给目标协调服务实例。目标协调服务实例接收到多个可用应用服务实例的标识信息之后，可以根据预设规则从多个可用应用服务实例中确定出目标应用服务实例。例如，目标协调服务实例可以从多个可用应用服务实例中随机确定出目标应用服务实例。又例如，目标协调服务实例可以依次确定出目标应用服务实例，即，随着接收到的第二请求，按预设顺序给出目标应用服务实例。又例如，目标协调服务实例可以获取多个可用应用服务实例中各可用应用服务实例的监控指标信息，并根据各可用应用服务实例的监控指标信息，从多个可用应用服务实例中确定出目标应用服务实例。在确定出目标应用服务实例中，目标协调服务实例可以将目标应用服务实例的标识信息发送至目标应用服务。

在接收到目标应用服务实例的标识信息之后，目标应用服务可以基于接收到的标识信息，向目标应用服务实例发送读写请求。目标应用服务实例可以响应于读写请求对分布式存储系统执行读写操作。

上述实施例中，可以将对分布式存储系统进行读写的功能封装成服务组件，目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写，通过为有权限对分布式存储系统进行读写的多个应用服务中的每个应用服务提供一组独立的应用服务实例，使得各应用服务可以通过将请求提交到自己的应用服务实例上面进行数据的读写，从而在应用服务实例侧实现资源隔离，相较于传统的在集群侧进行资源隔离而言，在应用服务实例侧实现资源隔离，操作更加灵活且容易控制。此外，通过将多个应用服务实例和多个协调服务实例注册到服务注册中心，可以维护可用应用服务实例和可用协调服务实例的信息以便于获取。进一步地，将协调服务端设置为多实例部署，可以防止单节点故障。

下面参考图6至图8结合一个具体实施例对上述方法进行说明，然而，值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

本具体实施例中的方法可以应用以下技术：

1)Kubernetes容器编排服务。Kubernetes能够对容器进行管理，提供快速的容器调度、弹性伸缩等诸多功能。本实施例主要使用了Kubernetes的Pod横向自动扩容功能(Horizontal Pod Autoscaling)，通过将Server服务部署到容器中，在Kubernetes中根据容器CPU利用率和监控的交易量等指标信息自动化对Server实例进行扩容和缩容。

2)Eureka注册中心。Eureka是一种开源框架，主要用于定位运行在流程管理平台中的中间服务，以达到负载均衡和中间层服务故障转移的目的。本实施例主要使用Eureka的注册和服务发现能力，每个Server服务实例启动后会在Eureka中进行注册，这样Eureka中的服务注册表中将会存储所有可用应用服务节点的信息。如果一个Server服务实例超过默认时间不向Eureka发送心跳，Eureka就会将该服务实例从应用注册服务列表中删除。

3)coordinate服务自定义规则算法，用于从Eureka获得所有可用服务实例列表后，对采集到的每个服务实例监控指标信息，根据自定义规则进行测算返回最符合要求的服务器信息。例如，对监控指标中的CPU利用率、内存、IO等指标按照自定义的比例进行计算相加，返回值最大或最小的服务实例的IP和端口。

本具体实施例中，用于对分布式存储系统系统进行读写的方法涉及客户端服务(即，上文中的应用服务)、Coordinate服务(即，上文中的协调服务端)以及Server服务(即，上文中的应用服务实例)。客户端服务负责发起读写Hbase数据库(分布式存储系统)的请求，包括从Eureka获取可用Coordinate服务，从Coordinate服务获取可用的Server服务IP和端口，向Server服务端发出读写请求等工作。Coordinate服务负责从Eureka获取应用的可用Server服务列表，并根据自定义规则返回一个性能最佳的Server服务的地址。Server服务负责连接Hbase集群，并对Hbase数据库进行在线读写。

请参考图6，示出了本申请一实施例中用于对分布式存储系统进行读写的方法的交互示意图。如图6所示，该方法可以包括以下步骤。

步骤S601：Server服务实例和Coordinate服务实例启动后将自己注册到Eureka。

步骤S602：客户端发送请求到Eureka获取可用Coordinate服务实例，Coordinate服务实例为多实例部署，以防止单节点故障。

步骤S603：Eureka返回客户端可用Coordinate服务实例信息，如IP和端口。

步骤S604：客户端向可用Coordinate服务实例发送请求，获取可用的Server实例信息，如Server实例的IP和端口。

步骤S605：Coordinate服务接到客户端请求后，向Eureka获取应用名下所有Server实例信息。

步骤S606：Eureka向Coordinate服务返回应用服务名注册列表中所有存活的Server实例。

步骤S607：Coordinate根据自定义规则计算后返回值最优的Server服务实例信息。

步骤S608：客户端向获取到的Server服务实例发送http读写请求。

步骤S609：接到读写请求的Server服务实例根据请求中的命令对Hbase数据库进行读写操作。

步骤S610：Server服务实例将读写操作的执行结果返回给客户端。

请参考图7，示出了本申请一实施例中的Coordinate服务执行原理的流程图。

步骤S701：Coordinate服务启动后进行初始化，从Eureka获取所有应用的Server实例信息缓存到本地，之后每隔1分钟更新一次，如果更新失败，则仍缓存上一次的实例信息。

步骤S702：接到客户端请求后，Coordinate服务向Eureka发送http请求获取应用所属Server实例信息。

步骤S703：判断请求是否发送成功，如果发送成功则执行步骤S704，发送失败则执行步骤S705。

步骤S704：判断Eureka中是否存在Server服务实例信息，若存在则执行步骤S706，否则执行步骤S707。

步骤S705：判断缓存中是否存在该应用服务下Server服务实例信息，若存在，则执行步骤S706，否则执行步骤S707。

步骤S706：Coordinate返回根据自定义规则计算后得出的Server服务实例的IP和端口。

步骤S707：Coordinate返回相关报错信息。

请参考图8，示出了图7中步骤S706工作原理流程图。

步骤S801：Coordinate获取所属应用的Server服务实例列表，如果列表中有多个Server服务实例信息则进行后续步骤，否则直接返回。

步骤S802：从监控模块获取每个Server的指标信息，如CPU使用率、剩余内存大小、网络情况。

步骤S803：根据自定义函数对每个Server服务实例的指标信息进行计算，首先将每项指标的值换算成[0,1]之间进行归一化，归一化后的值为：(该项指标原始值-该项最小值)/(该项指标最大值-该项最小值)，再将各项指标乘以自定义比例后相加，例如，如果读写请求中每条信息数据量较大，对内存需求比较高，对时效性要求较低，则可设置可用CPU指标比重为30％，可用内存比重为50％，其余指标比重为20％，得到的为最符合应用需求的负载最低的Server实例信息。

步骤S804：将步骤S803计算得出的值最优的Server服务实例的IP和端口号返回给客户端。

上述实施例中，通过将读写Hbase的功能封装成Server服务组件，为每个接入应用提供一组独立的Server服务实例，应用通过将请求提交到自己的实例上面进行数据的读写，从而达到在Server实例侧实现资源隔离的目的。同时将Server实例部署到Docker容器中，通过Kubernetes容器编排引擎进行管理。每个Server服务实例能接收到的读写请求是有并发数限制的，当应用读写业务量增大时，通过Kubernetes容器编排引擎方便及时的为应用扩容服务实例个数，提升并发资源，满足业务需求；业务量缩减时，及时减少服务实例个数，节省资源，从而达到动态分配联机并发资源的目的。最后通过自研的Coordinate服务根据自定义规则返回最佳性能的服务器列表，达到多实例负载均衡的目的。

基于同一发明构思，本申请实施例中还提供了一种用于对分布式存储系统进行读写的装置，位于协调服务端，如下面的实施例所述。由于用于对分布式存储系统进行读写的装置解决问题的原理与用于对分布式存储系统进行读写的方法相似，因此用于对分布式存储系统进行读写的装置的实施可以参见用于对分布式存储系统进行读写的方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图9是本申请实施例的用于对分布式存储系统进行读写的装置的一种结构框图，如图9所示，包括：接收模块901、获取模块902、确定模块903和发送模块904，下面对该结构进行说明。

接收模块901用于接收目标应用服务发送的第一请求，其中，目标应用服务为有权限对分布式存储系统进行读写的多个应用服务中的一个，多个应用服务中各应用服务具有对应的多个应用服务实例。

获取模块902用于响应于第一请求，获取目标应用服务对应的多个可用应用服务实例的标识信息。

确定模块903用于根据预设规则从多个可用应用服务实例中确定出目标应用服务实例。

发送模块904用于将目标应用服务实例的标识信息发送至目标应用服务，使得目标应用服务通过目标应用服务实例对分布式存储系统执行读写操作。

从以上的描述中，可以看出，本申请实施例实现了如下技术效果：可以将对分布式存储系统进行读写的功能封装成服务组件，目标应用服务作为分布式存储系统的接入应用服务，可以对分布式存储系统进行读写，通过为有权限对分布式存储系统进行读写的多个应用服务中的每个应用服务提供一组独立的应用服务实例，使得各应用服务可以通过将请求提交到自己的应用服务实例上面进行数据的读写，从而在应用服务实例侧实现资源隔离，相较于传统的在集群侧进行资源隔离而言，在应用服务实例侧实现资源隔离，操作更加灵活且容易控制。此外，通过协调服务端确定执行读写操作的目标应用服务对应的目标应用服务实例，可以对执行读写操作的服务实例进行控制，从而实现多实例负载均衡的效果。

本申请实施方式还提供了一种计算机设备，具体可以参阅图10所示的基于本申请实施例提供的用于对分布式存储系统进行读写的方法的计算机设备组成结构示意图，所述计算机设备具体可以包括输入设备11、处理器12、存储器13。其中，所述存储器13用于存储处理器可执行指令。所述处理器12执行所述指令时实现上述任意实施例中所述的用于对分布式存储系统进行读写的方法的步骤。

在本实施方式中，所述输入设备具体可以是用户和计算机系统之间进行信息交换的主要装置之一。所述输入设备可以包括键盘、鼠标、摄像头、扫描仪、光笔、手写输入板、语音输入装置等；输入设备用于把原始数据和处理这些数的程序输入到计算机中。所述输入设备还可以获取接收其他模块、单元、设备传输过来的数据。所述处理器可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式等等。所述存储器具体可以是现代信息技术中用于保存信息的记忆设备。所述存储器可以包括多个层次，在数字系统中，只要能保存二进制数据的都可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也叫存储器，如RAM、FIFO等；在系统中，具有实物形式的存储设备也叫存储器，如内存条、TF卡等。

在本实施方式中，该计算机设备具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

本申请实施方式中还提供了一种基于用于对分布式存储系统进行读写的方法的计算机存储介质，所述计算机存储介质存储有计算机程序指令，在所述计算机程序指令被执行时实现上述任意实施例中所述用于对分布式存储系统进行读写的方法的步骤。

在本实施方式中，上述存储介质包括但不限于随机存取存储器(Random AccessMemory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(Hard DiskDrive,HDD)或者存储卡(Memory Card)。所述存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的，用于进行网络连接通信的接口。

在本实施方式中，该计算机存储介质存储的程序指令具体实现的功能和效果，可以与其它实施方式对照解释，在此不再赘述。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

应该理解，以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述，在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此，本申请的范围不应该参照上述描述来确定，而是应该参照前述权利要求以及这些权利要求所拥有的等价物的全部范围来确定。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请实施例可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。