CN112631738A - 一种基于库容器实现的分布式任务处理的系统及方法 - Google Patents

Abstract

本发明公开了一种基于库容器实现的分布式任务处理的系统及方法，包括至少一个中心服务器组件、至少一个Work组件和至少一个Consul注册中心模块，所述中心服务器组件用于监控客户上传或指定的库文件，并将中心服务器组件地址端口注册到consul注册中心模块，如果有多个中心服务器组件启动，将首先依次注册到注册中心。本发明的有益效果是：本发明提供的库包上传和发布，管理方便，自动维护工作组件和容器的启停，不用人力检查是否正常和问题，自动管理容器中任务的处理，运维成本降低；本发明通过不改变现有开发模式的情况下，简单对用户透明的方式提供服务，客户不改变原有开发包库的方式，简单上传指定即可，操作方便，技术门槛降低。

Description

一种基于库容器实现的分布式任务处理的系统及方法

技术领域

本发明涉及一种分布式任务处理的系统，具体为一种基于库容器实现的分布式任务处理的系统及方法，属于大数据分布式多任务处理应用技术领域。

背景技术

随着信息化技术的不断推进，大数据分布式多任务的处理越来越常见；但是基于集群和单服务器实现的并行处理和分发框架，要么要求资源和硬件、软件越来越高，要么难以部署和实现，其技术门槛越来越高，维护和运作成本也越来越高。

如何实现现有开发环境下，在不需要介入复杂硬件和软件的情况下实现分布处理和并行任务部署，是现在大家一致的期待。

现有环境下，特别复杂的有kubernets（又名k8s）的集群部署，有对硬件要求颇高的hadoop并行操作系统；但是技术门槛太高，需要耗费很多人力和学习成本，维护成本也越来越高。

也有基于xxljob和powerjob的开源分布任务平台，但是他们都无法直接上传库包使用，需要客户按平台的要求修改代码，改变原有的代码和开发方式，造成学习和部署的困难；需要改变开发模式，成本太高。

当然还有云上的serverless，这个虽然方便易用，但是费用颇高；如何实现一个方法，在现有集群环境下，简单搭建一套并行分布任务平台，是一个非常迫切的要求。

发明内容

本发明的目的就在于为了解决上述的问题，而提出一种基于库容器实现的分布式任务处理的系统及方法。

本发明的目的可以通过以下技术方案实现：一种基于库容器实现的分布式任务处理的系统，包括至少一个中心服务器组件、至少一个Work组件和至少一个Consul注册中心模块；

其中，所述中心服务器组件用于监控客户上传或指定的库文件，并将中心服务器组件地址端口注册到consul注册中心模块，如果有多个中心服务器组件启动，将首先依次注册到注册中心；然后注册中心采取选举算法，选举出master主节点对外发布服务，中心服务器组件和work组件进行通信和对外提供库包日志服务；

所述Work组件为各个实际执行任务的工作站守护进程，负责执行具体的任务和中心服务器组件通信交流，并执行中心服务器组件的命令，work组件还用于各个分布服务器上的代理；

同样work组件启动后，首先将自身资源（cpu、内存、可用硬盘空间等信息）和地址端口注册到consul注册中心，同时检查注册work机器情况，防止重复注册（根据机器硬件信息生成唯一识别码识别）；同时向注册中心查询master服务组件信息，向其报告信息和听从指令命令；每次执行时候都需要根据consul实时情况汇报，当收到consul发出的重新选举master服务组件信息时候，需等待和查询新的master服务组件，向新服务组件负责和汇报通信；

每个机器上的工作组件启动后，首要的事情便是查询对方服务的master服务组件信息，同时请求服务组件的公钥，将公钥加入到本机的.ssh目录中的授权服务文件中，同时剔除旧的过时或被选举下去的辅助备份服务组件；此步骤的作用是，保证服务组件对work组件享有绝对的免密码登录和控制的权利(依托linux的公私钥ssh登录机制实现)，完成这些步骤后，可以保证服务组件可以作为root用户直接控制工作组件，在特别情况下，如果工作work组件发生错误，或无法执行指令的情况下，服务组件可以直接免密登录work机器，直接控制work机器；保证系统的绝对指挥权和稳定，必要时候，甚至可以代替work组件进行登录启动等操作。

所述Consul注册中心模块用于接收中心服务器组件和Work组件的注册信息。由于consul组件是开源共享的，其注册发现中心保证CAP原理中的CA（CAP的核心理论是：一个分布式系统不可能同时满足CAP三个条件，可用和分区容错性三个需求；备注： C 、Consistency（强一致性），A、Availability (可用性)，P、Partitiontolerance（分区容错性），consul注册中心的CA可以满足高可用和高一致性，牺牲部分分区容错；对于非巨型网络（例如大于1000台机器的集群），完全足够使用。

优选的，所述Work组件执行中心服务器组件的命令为docker命令、上传下载命令、执行启停命令、获取jar库包命令、汇报监控命令和健康状态反馈命令等，这样中心服务组件就可以将具体任务库包等下发给具体的work组件。

优选的，所述work组件和中心服务组件均采用java编写，核心实现http协议通信和work组件的自注册和work组件的system内部调用命令。

优选的，通过work组件将健康信息和进程任务信息注册写入consul注册中心组件中，以便服务组件展示和统计。

优选的，所述中心服务器组件包括库包管理组件（日志组件），库包管理组件用于对外提供库包日志服务。

一种基于库容器实现的分布式任务处理的系统的分布式任务处理方法，该系统的工作方法具体包括以下步骤：

步骤一：中心服务器组件监控客户上传或指定的库文件，将库文件发布到相应服务器的Docker容器中，而后启动、停止、和操作容器即可；将中心服务器组件地址端口注册到Consul注册中心，若有多个中心服务器组件启动，则首先依次注册到Consul注册中心，然后Consul注册中心采取选举算法，选举出master主节点对外发布服务，同时通过库包管理组件收集实时日志展现给用户，服务组件启动后向Consul注册中心注册，注册成功后启动各个具体工作服务器上的任务工作组件，服务组件随后调用库包管理组件，对外提供库包管理的界面和接口，至此，部署完毕，等待客户上传或指定启动具体库文件，进行服务操作；

步骤二：启动work组件，首先将work组件资源和地址端口注册到consul注册中心组件，同时检查注册work机器情况，防止重复注册（根据机器硬件信息生成唯一识别码识别）；同时向consul注册中心组件查询master服务组件信息，向其报告信息和听从指令命令；每次执行时都根据consul实时情况汇报，当收到consul注册中心组件发出的重新选举master服务组件信息时，需等待和查询新的master服务组件，向新的中心服务器组件负责和汇报通信；

步骤三：当master服务组件和work组件双向通信后,按照协议执行命令和交互（交互中首先接收master服务组件的公钥,接收服务组件的绝对控制权）；

步骤四：当consul组件重新选举出新的中心服务器组件作为master时,所有组件刷新新的服务组件地址,重新交互和剔除旧服务组件信息,接收新的master指挥。

与现有技术相比，本发明的有益效果是：

(1) 本发明提供的库包上传和发布，管理方便，自动维护工作组件和容器的启停，不用人力检查是否正常和问题，自动管理容器中任务的处理，运维成本降低。

(2) 本发明通过不改变现有开发模式的情况下，简单对用户透明的方式提供服务，客户不改变原有开发包库的方式，简单上传指定即可，操作方便，技术门槛降低，本发明可以广泛的应用在并行计算、并行任务、多机部署和操作等复杂和高性能要求的场合。

附图说明

为了便于本领域技术人员理解，下面结合附图对本发明作进一步的说明。

图1为本发明一种基于库容器实现的分布式任务处理的系统及方法的整体工作流程框图。

具体实施方式

下面将结合实施例对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1所示，一种基于库容器实现的分布式任务处理的系统，至少一个中心服务器组件、至少一个Work组件和至少一个Consul注册中心模块；

其中，所述中心服务器组件用于监控客户上传或指定的库文件，并将中心服务器组件地址端口注册到consul注册中心模块，如果有多个中心服务器组件启动，将首先依次注册到注册中心；然后注册中心采取选举算法，选举出master主节点对外发布服务，中心服务器组件和work组件进行通信和对外提供库包日志服务；

所述Work组件为各个实际执行任务的工作站守护进程，负责执行具体的任务和中心服务器组件通信交流，并执行中心服务器组件的命令，work组件还用于各个分布服务器上的代理；

同样work组件启动后，首先将自身资源（cpu、内存、可用硬盘空间等信息）和地址端口注册到consul注册中心，同时检查注册work机器情况，防止重复注册（根据机器硬件信息生成唯一识别码识别）；同时向注册中心查询master服务组件信息，向其报告信息和听从指令命令；每次执行时候都需要根据consul实时情况汇报，当收到consul发出的重新选举master服务组件信息时候，需等待和查询新的master服务组件，向新服务组件负责和汇报通信；

每个机器上的工作组件启动后，首要的事情便是查询对方服务的master服务组件信息，同时请求服务组件的公钥，将公钥加入到本机的.ssh目录中的授权服务文件中，同时剔除旧的过时或被选举下去的辅助备份服务组件；此步骤的作用是，保证服务组件对work组件享有绝对的免密码登录和控制的权利(依托linux的公私钥ssh登录机制实现)，完成这些步骤后，可以保证服务组件可以作为root用户直接控制工作组件，在特别情况下，如果工作work组件发生错误，或无法执行指令的情况下，服务组件可以直接免密登录work机器，直接控制work机器；保证系统的绝对指挥权和稳定，必要时候，甚至可以代替work组件进行登录启动等操作。

所述Consul注册中心模块用于接收中心服务器组件和Work组件的注册信息。由于consul组件是开源共享的，其注册发现中心保证CAP原理中的CA（CAP的核心理论是：一个分布式系统不可能同时满足CAP三个条件，可用和分区容错性三个需求；备注： C 、Consistency（强一致性），A、Availability (可用性)，P、Partitiontolerance（分区容错性），consul注册中心的CA可以满足高可用和高一致性，牺牲部分分区容错；对于非巨型网络（例如大于1000台机器的集群），完全足够使用。

优选的，所述Work组件执行中心服务器组件的命令为docker命令、上传下载命令、执行启停命令、获取jar库包命令、汇报监控命令和健康状态反馈命令等，这样中心服务组件就可以将具体任务库包等下发给具体的work组件。

优选的，所述work组件和中心服务组件均采用java编写，核心实现http协议通信和work组件的自注册和work组件的system内部调用命令。

优选的，通过work组件将健康信息和进程任务信息注册写入consul注册中心组件中，以便服务组件展示和统计。

优选的，所述中心服务器组件包括库包管理组件（日志组件），库包管理组件用于对外提供库包日志服务。

优选的，该系统的工作方法具体包括以下步骤：

步骤一：中心服务器组件监控客户上传或指定的库文件，将库文件发布到相应服务器的Docker容器中，而后启动、停止、和操作容器即可；将中心服务器组件地址端口注册到Consul注册中心，若有多个中心服务器组件启动，则首先依次注册到Consul注册中心，然后Consul注册中心采取选举算法，选举出master主节点对外发布服务，同时通过库包管理组件收集实时日志展现给用户，服务组件启动后向Consul注册中心注册，注册成功后启动各个具体工作服务器上的任务工作组件，服务组件随后调用库包管理组件，对外提供库包管理的界面和接口，至此，部署完毕，等待客户上传或指定启动具体库文件，进行服务操作；所需要的设备或装置或构件： Docker容器工具、Linux标准服务器、Consul注册中心、库包管理组件、服务监控组件、任务工作组件。

步骤二：启动work组件，首先将work组件资源和地址端口注册到consul注册中心组件，同时检查注册work机器情况，防止重复注册（根据机器硬件信息生成唯一识别码识别）；同时向consul注册中心组件查询master服务组件信息，向其报告信息和听从指令命令；每次执行时都根据consul实时情况汇报，当收到consul注册中心组件发出的重新选举master服务组件信息时，需等待和查询新的master服务组件，向新的中心服务器组件负责和汇报通信；

步骤三：当master服务组件和work组件双向通信后,按照协议执行命令和交互（交互中首先接收master服务组件的公钥,接收服务组件的绝对控制权）；

步骤四：当consul组件重新选举出新的中心服务器组件作为master时,所有组件刷新新的服务组件地址,重新交互和剔除旧服务组件信息,接收新的master指挥。

服务监控组件部署在中心服务器或具有负载均衡的后端，可以以负载均衡冗余方式或者主备方式保持高可用性；

服务组件启动后向注册中心注册，注册成功后启动各个具体工作服务器上的任务工作组件；

服务组件随后调用库包管理组件，对外提供库包管理的界面和接口。

至此，部署完毕，等待客户上传或指定启动具体库文件，进行服务操作。

整个方法使用自己开发的组件有三个： 服务组件、库包日志管理组件、work组件。

需要用到的装置是linux系统、docker系统、consul系统。

本发明核心在服务组件和work组件的通信和反馈机制；服务组件和work组件都自动在consul注册中心注册，以便双方自动发现彼此。

通信机制是双向的，通信类型分为：

1执行命令

启动、停止、重启、热部署；

2接收文件

库包文件流、版本信息；

3报告状态

健康状态、任务状态、实时最后n条日志；

4容器管理

容器启停、容器构建、容器情况报告；

5日志回报

日志流收集；

通信协议：

http json格式

服务器发送报文

{“通信类型”：“”，

“通信内容”：“”，

}

服务器接收客户报文

{“通信类型”：“”，

“通信内容”：“”，

“状态码”：“”

}

本发明的系统具体工作流程如下：

S1、Server组件--发送信息到consul注册自身；

S2、Server组件--请求consul选举出master(即leader),遵循CAP原理；

S3、Consul--广播告诉所有work组件新master(新leader)；

S4、Work组件--发送信息到consul查询是否重复--没有重复就发送正式注册信息；

S5、Consul组件--告知master信息或master变动信息--同时告知注册结果；

S6、Work组件--获得master信息后直接和master通信--与master接收和通信。

本发明的系统支持对work组件中运行的任务、日志、状态的修改和查看；修改包括资源参数的配置和修改，任务的启动停止和暂停，也包括任务的优雅停止操作（所谓优雅停止，就是收到命令后不是马上停止，而是完成手头工作后停止，避免对客户来说服务意外中断的不友好性质）；

日志动态查看，支持实时日志的查看和滚动操作；且work组件和服务组件间的调度和执行解耦，提高了整体系统的稳定性；另外基于注册发现机制，可以保障work组件和机器加入集群的动态性质，由于work组件和进程可以优雅停止，因此可以随时增加或缩减work组件数量，保障了系统的动态可扩展性质。

以上公开的本发明优选实施例只是用于帮助阐述本发明。优选实施例并没有详尽叙述所有的细节，也不限制该发明仅为的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本发明的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本发明。本发明仅受权利要求书及其全部范围和等效物的限制。

Claims (6)

1.一种基于库容器实现的分布式任务处理的系统，其特征在于：包括至少一个中心服务器组件、至少一个Work组件和至少一个Consul注册中心模块；

其中，所述中心服务器组件用于监控客户上传或指定的库文件，并将中心服务器组件地址端口注册到consul注册中心模块，中心服务器组件和work组件进行通信和对外提供库包日志服务；

所述Work组件为各个实际执行任务的工作站守护进程，负责执行具体的任务和中心服务器组件通信交流，并执行中心服务器组件的命令，work组件还用于各个分布服务器上的代理；

所述Consul注册中心模块用于接收中心服务器组件和Work组件的注册信息。

2.根据权利要求1所述的一种基于库容器实现的分布式任务处理的系统，其特征在于，所述Work组件执行中心服务器组件的命令为docker命令、上传下载命令、执行启停命令、获取jar库包命令、汇报监控命令和健康状态反馈命令。

3.根据权利要求2所述的一种基于库容器实现的分布式任务处理的系统，其特征在于，所述work组件和中心服务器组件均采用java编写，核心实现http协议通信和work组件的自注册和work组件的system内部调用命令。

4.根据权利要求1所述的一种基于库容器实现的分布式任务处理的系统，其特征在于，通过work组件将健康信息和进程任务信息注册写入consul注册中心组件中。

5.根据权利要求3所述的一种基于库容器实现的分布式任务处理的系统，其特征在于，所述中心服务器组件包括库包管理组件，库包管理组件用于对外提供库包日志服务。

6.根据权利要求1-5任一项所述的一种基于库容器实现的分布式任务处理的系统的分布式任务处理方法，其特征在于，该方法具体包括以下步骤：

步骤一：中心服务器组件监控客户上传或指定的库文件，将库文件发布到相应服务器的Docker容器中，将中心服务器组件地址端口注册到Consul注册中心，若有多个中心服务器组件启动，则首先依次注册到Consul注册中心，然后Consul注册中心采取选举算法，选举出master主节点对外发布服务；

步骤二：启动work组件，首先将work组件资源和地址端口注册到consul注册中心组件，同时检查注册work机器情况，同时向consul注册中心组件查询master服务组件信息，向其报告信息和听从指令命令，每次执行时都根据consul实时情况汇报，当收到consul注册中心组件发出的重新选举master服务组件信息时，需等待和查询新的master服务组件，向新的中心服务器组件负责和汇报通信；

步骤三：当master服务组件和work组件双向通信后,按照协议执行命令和交互；

步骤四：当consul组件重新选举出新的中心服务器组件作为master时,所有组件刷新新的服务组件地址,重新交互和剔除旧服务组件信息,接收新的master指挥。

Images