CN110086881A - 业务处理方法、装置及设备 - Google Patents

业务处理方法、装置及设备 Download PDF

Info

Publication number
CN110086881A
CN110086881A CN201910377183.1A CN201910377183A CN110086881A CN 110086881 A CN110086881 A CN 110086881A CN 201910377183 A CN201910377183 A CN 201910377183A CN 110086881 A CN110086881 A CN 110086881A
Authority
CN
China
Prior art keywords
business
processing
docker
processed
waiting task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201910377183.1A
Other languages
English (en)
Inventor
汪文星
周彩冬
陆炯炯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Netease Hangzhou Network Co Ltd
Original Assignee
Netease Hangzhou Network Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Netease Hangzhou Network Co Ltd filed Critical Netease Hangzhou Network Co Ltd
Priority to CN201910377183.1A priority Critical patent/CN110086881A/zh
Publication of CN110086881A publication Critical patent/CN110086881A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明实施例提供一种业务处理方法、装置及设备，所述方法包括：接收客户端发送的第一业务处理请求，所述第一业务处理请求中包括待处理业务的标识；根据所述待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，所述至少两个Docker处理的业务不同；根据所述第一业务处理请求生成第二业务处理请求，并向所述目标Docker发送第二业务处理请求，以使所述目标Docker处理所述待处理业务。用于提高对待处理业务的处理效率。

Description

业务处理方法、装置及设备
技术领域
本发明实施例涉及任务调度领域，尤其涉及一种业务处理方法、装置及设备。
背景技术
大数据系统中涉及多种数据处理业务，目前，通常采用调度系统Airflow对大数据系统中不同数据处理业务进行调度、或者监督。
在实际应用中，多个数据处理业务的程序或者脚本设置在同一台物理机中，在Airflow对大数据系统中不同数据处理业务进行调度、或者监督，以使物理机根据数据处理业务的程序或者脚本对多个数据处理业务进行处理时，同一台物理机需要同时运行多个运行环境，其中，一个运行环境对应一种数据处理业务的程序或者脚本。在上述过程中，同一台物理机运行多个运行环境，可能导致不同数据处理业务相互影响，进而导致物理机无法同时处理多个数据处理业务，降低对数据处理业务的处理效率低。
发明内容
本发明实施例提供一种业务处理方法、装置及设备，提高对待处理业务的处理效率。
第一方面，本发明实施例提供一种业务处理方法，应用于调度设备，所述方法包括：
接收客户端发送的第一业务处理请求，所述第一业务处理请求中包括待处理业务的标识；
根据所述待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，所述至少两个Docker处理的业务不同；
根据所述第一业务处理请求生成第二业务处理请求，并向所述目标Docker发送第二业务处理请求，以使所述目标Docker处理所述待处理业务。
在一种可能的实施方式中，所述根据所述第一业务处理请求生成第二业务处理请求，包括：
在所述第一业务处理请求中获取所述待处理业务的标识；
获取所述业务处理系统的地址信息和所述目标Docker的标识；
根据所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识，生成所述第二业务处理请求。
在另一种可能的实施方式中，根据所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识，生成所述第二业务处理请求，包括：
根据预设算法，将所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识分别赋值给预设参数，得到所述第二业务处理请求。
在另一种可能的实施方式中，所述调度设备和所述业务处理系统部署在不同的物理机中。
第二方面，本发明实施例提供一种业务处理方法，所述方法包括：
Docker接收调度设备发送的业务处理请求，所述业务处理请求中包括待处理业务的标识，所述Docker为业务处理系统中的至少两个Docker中与所述待处理业务对应的Docker，所述至少两个Docker处理的业务不同；
所述目标Docker根据所述业务处理请求，处理所述待处理业务。
在一种可能的实施方式中，所述Docker根据所述业务处理请求，处理所述待处理业务，包括：
获取所述待处理业务中包括的至少一个待处理任务；
获取每个待处理任务对应的参数信息；
根据所述每个待处理任务对应的参数信息，对所述待处理业务进行处理。
在另一种可能的实施方式中，所述Docker根据所述业务处理请求，处理所述待处理业务之后，还包括：
获取每个待处理任务对应的执行结果；
根据每个待处理任务对应的执行结果，确定每个待处理任务对应的处理状态，所述处理状态用于指示是否对所述待处理任务处理成功；
向所述调度设备发送每个待处理任务对应的处理状态。
在另一种可能的实施方式中，针对所述至少一个待处理任务中的任意一个第一待处理任务；获取所述第一待处理任务对应的处理状态，包括：
获取所述第一待处理任务对应的预设判断条件；
根据所述第一待处理任务对应的预设判断条件和所述第一待处理任务的执行结果，确定所述第一待处理任务对应的处理状态。
在另一种可能的实施方式中，所述Docker根据所述业务处理请求，处理所述待处理业务之后，还包括：
获取每个待处理任务对应日志信息；
发送所述每个待处理任务对应日志信息。
第三方面，本发明实施例提供一种业务处理装置，应用于调度设备，所述装置包括：接收模块、确定模块和发送模块，其中，
所述接收模块用于，接收客户端发送的第一业务处理请求，所述第一业务处理请求中包括待处理业务的标识；
所述确定模块用于，根据所述待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，所述至少两个Docker处理的业务不同；
所述发送模块用于，根据所述第一业务处理请求生成第二业务处理请求，并向所述目标Docker发送第二业务处理请求，以使所述目标Docker处理所述待处理业务。
在一种可能的实施方式中，所述发送模块具体用于：
在所述第一业务处理请求中获取所述待处理业务的标识；
获取所述业务处理系统的地址信息和所述目标Docker的标识；
根据所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识，生成所述第二业务处理请求。
在另一种可能的实施方式中，所述发送模块具体用于：
根据预设算法，将所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识分别赋值给预设参数，得到所述第二业务处理请求。
在另一种可能的实施方式中，所述调度设备和所述业务处理系统部署在不同的物理机中。
第四方面，本发明实施例提供一种业务处理装置，应用于Docker，所述装置包括：接收模块和处理模块，其中，
所述接收模块接收调度设备发送的业务处理请求，所述业务处理请求中包括待处理业务的标识，所述接收模块为业务处理系统中的至少两个Docker中与所述待处理业务对应的Docker中的接收模块，所述至少两个Docker处理的业务不同；
所述处理模块根据所述接收模块接收的所述业务处理请求，处理所述待处理业务。
在一种可能的实施方式中，所述处理模块具体用于：
获取所述待处理业务中包括的至少一个待处理任务；
获取每个待处理任务对应的参数信息；
根据所述每个待处理任务对应的参数信息，对所述待处理业务进行处理。
在另一种可能的实施方式中，
所述处理模块用于，所述处理模块根据所述接收模块接收的所述业务处理请求，处理所述待处理业务之后，获取每个待处理任务对应的执行结果；
所述处理模块用于，根据每个待处理任务对应的执行结果，确定每个待处理任务对应的处理状态，所述处理状态用于指示是否对所述待处理任务处理成功；
所述装置还包括发送模块，所述发送模块用于：
向所述调度设备发送每个待处理任务对应的处理状态。
在另一种可能的实施方式中，针对所述至少一个待处理任务中的任意一个第一待处理任务；所述处理模块还用于：获取所述第一待处理任务对应的预设判断条件；
根据所述第一待处理任务对应的预设判断条件和所述第一待处理任务的执行结果，确定所述第一待处理任务对应的处理状态。
在另一种可能的实施方式中，所述装置还包括发送模块，
所述处理模块用于，在所述处理模块根据所述业务处理请求处理所述待处理业务之后，获取每个待处理任务对应日志信息；
所述发送模块用于，发送所述每个待处理任务对应日志信息。
第五方面，本发明实施例提供一种业务处理装置，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第一方面所述的业务处理处理方法。
第六方面，本发明实施例提供一种业务处理装置，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上第二方面所述的业务处理方法。
第七方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至4任一项所述的业务处理处理方法。
第八方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求5至8任一项所述的业务处理处理方法。
在本发明实施例提供的业务处理方法、装置及设备中，所述方法接收客户端发送的第一业务处理请求，第一业务处理请求中包括待处理业务的标识，根据待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，至少两个Docker处理的业务不同，根据第一业务处理请求生成第二业务处理请求，并向目标Docker发送第二业务处理请求，以使目标Docker处理待处理业务。在上述过程中，通过目标Docker处理待处理业务，可以实现在同一个服务上同时处理多个不同待处理业务，且的避免了同一个服务器同时处理不同业务时，相互影响的问题，从而提高对待处理业务的处理效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的业务处理方法的应用场景图；
图2为本发明实施例提供的业务处理方法的流程示意图一；
图3为本发明实施例提供的业务处理方法的流程示意图二；
图4为本发明实施例提供的一种业务处理装置的结构示意图；
图5为本发明实施例提供另一种业务处理装置的结构示意图；
图6为本发明实施例提供的又一种业务处理装置的结构示意图；
图7为本发明实施例提供的一种业务处理装置的硬件结构示意图；
图8为本发明实施例提供的另一种业务处理装置的硬件结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1为本发明实施例提供的业务处理方法的应用场景图。请参见图1，调度系统包括多个客户端(例如，客户端101、客户端102、客户端103)、调度设备104和服务器105，其中，服务器105中设置有多个Docker。在实际应用中，多个客户端可以同时向调度设备104发送业务处理请求，业务处理请求中包括待处理业务的标识(不同的业务请求中的待处理业务的标识不同)，调度设备104可以根据业务处理请求中的待处理业务的标识，将不同的业务处理请求发送至服务器105中不同的Docker中(不同的Docker处理的业务不同)，以使Docker根据业务处理请求处理对应的待处理业务。
在上述过程中，服务器中设置有多个Docker，不同的Docker处理的待处理业务不同，使得在同一个服务器(物理机)中可以同时处理多个不同的待处理业务，避免了同一个服务器同时处理多个不同的待处理业务时相互影响的问题，从而提高对待处理业务的处理效率。
下面，通过具体实施例对本申请所示的技术方案进行详细说明。需要说明的是，下面几个具体实施例可以相互结合，对于相同或相似的内容，在不同的实施例中不再进行重复说明。
图2为本发明实施例提供的业务处理方法的流程示意图一。请参见图2，业务处理方法包括：
S201：客户端发送第一业务处理请求。
可选的，客户端可以为智能终端设备(例如，手机、平板电脑)、也可以为非智能终端设备(例如，台式电脑)。
可选的，一个客户端、或者多个客户端可以发送多个第一业务处理请求。其中，多个第一业务处理请求可以相同，也可以为不同。
S202：调度设备接收客户端发送的第一业务处理请求，第一业务处理请求中包括待处理业务的标识。
可选的，调度设备可以接收一个客户端、或者多个客户端发送的多个第一业务处理请求。
可选的，一个第一业务处理请求中包括一项待处理业务、以及该项待处理业务的标识。
需要说明的是，相同的第一业务处理请求中的待处理业务的标识相同，不同的第一业务处理请求中的待处理业务的标识不相同。
S203：调度设备根据第一业务处理请求中的待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，至少两个Docker处理的业务不同。
可选的，待处理业务的标识用于指示待处理业务的类型。
例如，待处理业务的标识为“0”，指示该待处理业务为购物，待处理业务的标识为“1”，指示待处理业务为音乐。
可选的，业务处理系统可以为一个、或者多个服务器(物理机)中设置的Docker构成的系统。
可选的，一个服务器中可以设置一个、或者多个Docker。
在实际应用中，目标Docker处理的业务的类型与待处理业务的类型相同。
S204：调度设备根据第一业务处理请求生成第二业务处理请求。
可选的，第一业务处理请求中还包括待处理业务的待处理任务、待处理任务对应的脚本、待处理任务对应的参数信息和待处理任务对应的预设判断条件。
可选的，调度设备根据第一业务处理请求生成的第二业务处理请求中也包括待处理任务、待处理任务对应的脚本、待处理任务对应的参数信息和待处理任务对应的预设判断条件。
S205：调度设备向目标Docker发送第二业务处理请求。
需要说明的是，服务器具有预设的IP地址和多个预设端口，服务器中的每个Docker对应其所在服务器的一个预设端口，因此，在确定出目标Docker后，可以获取目标Docker所在的服务器的IP地址和目标Docker对应的预设端口。
可选的，在获取到目标Docker所在的服务器的IP地址和目标Docker对应的预设端口，根据服务器的IP地址和预设端口，向目标Docker发送第二业务处理请求。
S206：Docker接收调度设备发送的业务处理请求。
需要说明的是，业务处理请求中包括待处理业务的标识，所述Docker为业务处理系统中的至少两个Docker中与所述待处理业务对应的Docker，所述至少两个Docker处理的业务不同。
可选的，S204中的Docker可以为S203中的目标Docker，所述业务处理请求可以为S203中的第二业务处理请求。
需要说明的是，每个Docker中设置有Web Agent，所述Web Agent可以接收调度设备发送的业务处理请求。
可选的，Web Agent具有三个属性，所述三个属性分别为名称、接口名称、接口的方法。在实际应用中，示调度设备根据名称、接口名称、接口的方法向对应的Web Agent发送业务处理请求。
可选的，调度设备发送的业务处理请求还包括接收业务处理请求的Docker中WebAgent的名称、接口名称、接口的方法。
在实际应用中，由于业务处理请求中包括Web Agent的名称、接口名称、接口的方法，因此，对应的Web Agent可以接收到该业务处理请求。
可选的，本发明实施例提供一个业务处理请求(包括一个待处理任务)的执行代码，如下：
SimpleHttpOperator{
http_conn_id＝remote_flow”；
endpoint＝“execute_task”；
method＝“POST”；
data＝{"task_name":"hive_beeline","params":"1 2 3","file_type":"shell"}；
response_check＝lambda response:True if'msg'in response.json()andresponse.json()['msg']＝＝0else False}。
在上述代码中，SimpleHttpOperator为远程调度算子。
需要说明的是，上述业务处理请求的执行代码中，各个参数的含义如下表1。
表1
在表1中，参数信息data的执行代码为json格式，data中的"task_name"用于标识待处理任务的脚本的名称，"params"用于指示向待处理任务的脚本传递的参数，"file_type"用于标识待处理任务的脚本的类型。预设判断条件response_check为自定义的一段辑逻代码。
S207：Docker根据业务处理请求，处理待处理业务。
在实际应用中，Web Agent设置有一个接口名称为"execute_task"的接口，该"execute_task"接口接收三个参数，包括"task_name"、"params"和"file_type"。其中，"task_name"标识待处理任务的脚本的名称，"params"标识给待处理任务的脚本传递的参数，"file_type"标识待处理任务的脚本的类型(例如,“python”、或者“shell”)。
可选的，Docker中的Web Agent接收到业务处理请求后，"execute_task"可以根据业务处理请求中的参数信息data，确定三个参数的取值。
例如，根据业务处理请求中的参数信息data，确定execute_task中的三个参数分别为"task_name":"hive_beeline"、"params":"1 2 3"、"file_type":"shell"。
可选的，"params"中的多个参数可以用空格、顿号等分开。
在实际应用中，Web Agent根据"task_name"，查找对应的脚本，根据"params"向对应的脚本传递参数，根据"file_type"使用对应的执行命令(“shell”类型的脚本使用“bash”执行命令，“python”类型的脚本使用“python”执行命令)对待处理业务的脚本进行处理，从而实现处理待处理业务。
可选的，完成处理待处理业务后，向调度设备发送执行结果。
需要说明的是，由于对待处理业务的脚本进行处理，才能实现处理待处理业务，且不同的待处理业务的脚本的运行环境不同，因此，因此，需要在Docker中预先部署与待处理业务的脚本的运行环境对应的Web Agent，才能使得Web Agent执行S204至S205中的方法。
可选的，在Docker中部署Web Agent包括：
首先，通过Flask+Gunicorn为基础框架。使得Web Agent可以接收调度设备发送的业务处理请求，确定待处理任务对应的脚本与向脚本传递的参数，在完成处理待处理业务的后，向调度设备发送执行结果。
其次，定制化编写Dockerfile。实现Web Agent镜像的定制、封装。
最后，通过Docker的重要组件Docker-compose将Web Agent镜像加载到Docker容器中。实现在在Docker中的部署Web Agent。
可选的，在定制化编写Dockerfile的过程中，可以定制执行待处理任务的脚本时需要依赖的环境和工具包。其中，执行不同待处理业务中的待处理任务脚本时，需要依赖的环境和工具包不同。
在实际应用中，定制化编写Dockerfile的过程中，需要一个基础镜像，由于本申请中使用的Flask框架是基于python的，因此，使用的基础镜像是“python:3.6”。
可选的，定制化编写Dockerfile的过程中，还可以对重要的脚本、或者文件进行持久化处理，防止将镜像被删除后数据丢失。
例如，待处理业务中的待处理任务的脚本为“hive”类型，因此，需要在Dockerfile中封装好“hadoop”、“hive”、“java”等运行环境，以及用于权限认证的“kerberos”运行环境。
可选的，Docker-compose将Web Agent镜像加载到Docker容器的过程还包括：编写yml文件，在yml文件中指定在镜像中需要执行的启动Web Agent的命令，并且指定镜像需要开放的端口，以提供给外界访问接口。
可选的，还可以在Web Agent镜像中加自定义的脚本(例如，python脚本和shell脚本)。
可选的，自定义的脚本可以放在Web Agent的接口指定的路径下，例如：接口指定的路径为“/home/task”。
在上述过程中，定制化编写Dockerfile，实现Web Agent镜像的定制和封装，可以将不同待处理业务的分离，使得对不同待处理业务进行给处理时，各个待处理业务中待处理任务的脚本、或者程序互不影响。
在本发明实施例提供的业务处理方法中，接收客户端发送的第一业务处理请求，第一业务处理请求中包括待处理业务的标识，根据待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，至少两个Docker处理的业务不同，根据第一业务处理请求生成第二业务处理请求，并向目标Docker发送第二业务处理请求，以使目标Docker处理待处理业务。在上述过程中，通过目标Docker处理待处理业务，可以实现在同一个服务上同时处理多个不同待处理业务，且的避免了同一个服务器同时处理不同业务时，相互影响的问题，从而提高对待处理业务的处理效率。
在上述实施例的基础上，下面，结合图3，对本发明实施例提供的业务处理方法作进一步的详细说明，具体的，请参见图3。
图3为本发明实施例提供的业务处理方法的流程示意图二。请参见图3，包括：
S301：客户端发送第一业务处理请求。
需要说明的是，S301的执行方法与S201的执行方法相同，此处，不再赘述S301的执行过程。
S302：调度设备接收客户端发送的第一业务处理请求，第一业务处理请求中包括待处理业务的标识。
需要说明的是，S302的执行方法与S202的执行方法相同，此处，不再赘述S302的执行过程。
S303：调度设备在第一业务处理请求中获取待处理业务的标识。
可选的，调度设置在接收到第一业务处理请求后，可以对第一业务处理请求进行解析处理，获取待处理业务的标识。
S304：调度设备根据待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，至少两个Docker处理的业务不同。
需要说明的是，S304的执行方法与S203的执行方法相同，此处，不再赘述S304的执行过程。
在一种可能的实施方式中，所述调度设备和所述业务处理系统部署在不同的物理机中。
在本发明实施中，调度设备和业务处理系统部署在不同的物理机中，使得待处理业务中待处理任务的脚本与调度设备隔离，从而降低调度设备和所述脚本之间的耦合。
可选的，调度设备和业务处理系统还可以部署在不同网络中的不同的物理机中。
S305：调度设备获取业务处理系统的地址信息和目标Docker的标识。
可选的，业务处理系统的地址信息可以为业务处理系统中一个服务器的IP地址，目标Docker的标识可以为目标Docker对应的预设端口。
S306：调度设备根据预设算法，将待处理业务的标识、业务处理系统的地址信息和目标Docker的标识分别赋值给预设参数，得到第二业务处理请求。
可选的，预设算法可以为S206中的远程调度算子SimpleHttpOperator。
可选的，可以在远程调度算子SimpleHttpOperator中增加预设参数，例如，增加预设参数“Sign”用于指示待处理业务的标识，增加预设参数“adr”用于指示业务处理系统的地址信息，增加预设参数“num”目标Docker的标识。
可选的，在远程调度算子SimpleHttpOperator中增加预设参数后，将待处理业务的标识(“Sign”)、业务处理系统的地址信息(“adr”)和目标Docker的标识(“num”)分别赋值给预设参数，得到第二业务处理请求。
S207：调度设备向目标Docker发送第二业务处理请求。
需要说明的是，S307的执行方法与S205的执行方法相同，此处，不再赘述S307的执行过程。
S308：Docker接收调度设备发送的业务处理请求。
其中，业务处理请求中包括待处理业务的标识，Docker为业务处理系统中的至少两个Docker中与待处理业务对应的Docker，至少两个Docker处理的业务不同。
需要说明的是，S308的执行方法与S206的执行方法相同，此处，不再赘述S308的执行过程。
S309：Docker获取待处理业务中包括的至少一个待处理任务。
可选的，业务处理请求中包括至少一个待处理任务，在Docker中的WebAgent获取待处理业务后，可以获取至少一个待处理任务。
S310：Docker获取每个待处理任务对应的参数信息。
可选的，根据表1可知，由于业务处理请求中包括待处理任务的参数信息data、因此，在Web Agent获取待处理业务后获取每个待处理任务对应的参数信息data。
S311：Docker根据每个待处理任务对应的参数信息，对待处理业务进行处理。
可选的，根据每个待处理任务对应的参数信息，对待处理业务进行处理包括：WebAgent根据参数信息data中的"task_name"，查找待处理业务对应的脚本，根据参数信息data中的"params"向脚本对应的传递参数，根据参数信息data中的"file_type"使用脚本对应的执行命令对待处理业务的脚本进行处理。
S312：Docker获取每个待处理任务对应的执行结果。
需要说明的是，所述执行结果为使用执行命令执行完待处理任务对应的脚本后生成的。
可选的，对待处理业务的脚本进行处理后，Docker中的Web Agent可以获取待处理任务对应的执行结果。
S313：Docker针对至少一个待处理任务中的第一待处理任务，获取第一待处理任务对应的预设判断条件。
需要说明是，Web Agent接收的待处理业务请求中还包括预设判断条件，如表1中的“response_check”。
可选的，Web Agent可以从接收到的待处理业务请求中获取第一待处理任务对应的预设判断条件。
S314：Docker根据第一待处理任务对应的预设判断条件和第一待处理任务的执行结果，确定第一待处理任务对应的处理状态。
可选的，处理状态用于指示是否成功执行第一待处理任务的脚本。
可选的，处理状态可以为“1”或者“0”，其中，“1”用于指示成功执行第一待处理任务的脚本，“0”用于指示无法成功执行第一待处理任务的脚本。
可选的，第一待处理任务的执行结果使得第一待处理任务对应的预设判断条件成立时，确定处理状态“1”，第一待处理任务的执行结果使得第一待处理任务对应的预设判断条件不成立时，确定处理状态“0”。
例如，执行结果X＝4，预设判断条件X>5，则处理状态为“0”。
S315：Docker向调度设备发送每个待处理任务对应的处理状态。
在一种可能的实施方式中，所述Docker根据所述业务处理请求，处理所述待处理业务之后，还包括：
获取每个待处理任务对应日志信息；
发送所述每个待处理任务对应日志信息。
在上述实施方式中，根据与待处理任务对应的执行命令执行完所述待处理任务后，还可以生成日志信息，Docker获取每个待处理任务对应日志信息，并将待处理任务对应日志信息发送至调度设备。
可选的，调度设备可以根据日志信息中的特殊字样判断是否成功执行待处理任务对应的脚本。
可选的，特殊字样可以为“error”、“warning”等。
在本发明实施例中，调度设备可以HTTP请求的方式，通过远程调度算子SimpleHttpOperator对待处理任务对应的脚本传递参数信息，使得Docker可以根据参数信息待处理任务对应的脚本，从而实现调度设备的远程调度。
图4为本发明实施例提供的一种业务处理装置的结构示意图。请参见图4，业务处理装置应用于调度设备中，所述业务处理装置10包括：接收模块11、确定模块12和发送模块13，其中，
所述接收模块11用于，接收客户端发送的第一业务处理请求，所述第一业务处理请求中包括待处理业务的标识；
所述确定模块12用于，根据所述待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，所述至少两个Docker处理的业务不同；
所述发送模块13用于，根据所述第一业务处理请求生成第二业务处理请求，并向所述目标Docker发送第二业务处理请求，以使所述目标Docker处理所述待处理业务。
本发明实施例提供的业务处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
在一种可能的实施方式中，所述发送模块13具体用于：
在所述第一业务处理请求中获取所述待处理业务的标识；
获取所述业务处理系统的地址信息和所述目标Docker的标识；
根据所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识，生成所述第二业务处理请求。
在一种可能的实施方式中，所述发送模块13具体用于：
根据预设算法，将所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识分别赋值给预设参数，得到所述第二业务处理请求。
在一种可能的实施方式中，所述调度设备和所述业务处理系统部署在不同的物理机中。
本发明实施例提供的业务处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
图5为本发明实施例提供另一种业务处理装置的结构示意图。请参见图5，业务处理装置应用于Docker，所述业务处理装置20包括：接收模块21和处理模块22，其中，
所述接收模块21接收调度设备发送的业务处理请求，所述业务处理请求中包括待处理业务的标识，所述接收模块为业务处理系统中的至少两个Docker中与所述待处理业务对应的Docker中的接收模块，所述至少两个Docker处理的业务不同；
所述处理模块22根据所述接收模块21接收的所述业务处理请求，处理所述待处理业务。
本发明实施例提供的业务处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
在一种可能的实施方式中，所述处理模块22具体用于：
获取所述待处理业务中包括的至少一个待处理任务；
获取每个待处理任务对应的参数信息；
根据所述每个待处理任务对应的参数信息，对所述待处理业务进行处理。
在一种可能的实施方式中，针对所述至少一个待处理任务中的任意一个第一待处理任务；所述处理模块还用于：获取所述第一待处理任务对应的预设判断条件；
根据所述第一待处理任务对应的预设判断条件和所述第一待处理任务的执行结果，确定所述第一待处理任务对应的处理状态。
本发明实施例提供的业务处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
图6为本发明实施例提供的又一种业务处理装置的结构示意图。在图5的基础上，请参见图6，业务处理装置20还包括发送模块23，其中，
所述处理模块22用于，所述处理模块根据所述接收模块接收的所述业务处理请求，处理所述待处理业务之后，获取每个待处理任务对应的执行结果；
所述处理模块22用于，根据每个待处理任务对应的执行结果，确定每个待处理任务对应的处理状态，所述处理状态用于指示是否对所述待处理任务处理成功；
所述发送模块23用于，向所述调度设备发送每个待处理任务对应的处理状态。
在一种可能的实施方式中，
所述处理模块22用于，在所述处理模块根据所述业务处理请求处理所述待处理业务之后，获取每个待处理任务对应日志信息；
所述发送模块23用于，发送所述每个待处理任务对应日志信息。
本发明实施例提供的业务处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
图7为本发明实施例提供的一种业务处理装置的硬件结构示意图，如图7所示，该业务处理装置30包括：至少一个处理器31、存储器32、发送器33和接收器34。其中，处理器31、存储器32、发送器33和接收器34通过总线35连接。
在具体实现过程中，至少一个处理器31执行所述存储器32存储的计算机执行指令，使得至少一个处理器31执行如上的业务处理方法。
处理器31的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。
图8为本发明实施例提供的另一种业务处理装置的硬件结构示意图，如图8所示，该业务处理装置40包括：至少一个处理器41、存储器42、发送器43和接收器44。其中，处理器41、存储器42、发送器43和接收器44通过总线35连接。
在具体实现过程中，至少一个处理器41执行所述存储器42存储的计算机执行指令，使得至少一个处理器41执行如上的业务处理方法。
处理器41的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。
在上述图7-图8所示的实施例中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application SpecificIntegrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器。
总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。
本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上所述的业务处理方法。
上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。
一种示例性的可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，简称：ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。
所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (21)

1.一种业务处理方法，其特征在于，应用于调度设备，所述方法包括：
接收客户端发送的第一业务处理请求，所述第一业务处理请求中包括待处理业务的标识；
根据所述待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，所述至少两个Docker处理的业务不同；
根据所述第一业务处理请求生成第二业务处理请求，并向所述目标Docker发送第二业务处理请求，以使所述目标Docker处理所述待处理业务。
2.根据权利要求1所述的方法，其特征在于，所述根据所述第一业务处理请求生成第二业务处理请求，包括：
在所述第一业务处理请求中获取所述待处理业务的标识；
获取所述业务处理系统的地址信息和所述目标Docker的标识；
根据所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识，生成所述第二业务处理请求。
3.根据权利要求2所述的方法，其特征在于，根据所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识，生成所述第二业务处理请求，包括：
根据预设算法，将所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识分别赋值给预设参数，得到所述第二业务处理请求。
4.根据权利要求1-3任一项所述的方法，其特征在于，所述调度设备和所述业务处理系统部署在不同的物理机中。
5.一种业务处理方法，其特征在于，所述方法包括：
Docker接收调度设备发送的业务处理请求，所述业务处理请求中包括待处理业务的标识，所述Docker为业务处理系统中的至少两个Docker中与所述待处理业务对应的Docker，所述至少两个Docker处理的业务不同；
所述Docker根据所述业务处理请求，处理所述待处理业务。
6.根据权利要求5所述的方法，其特征在于，所述Docker根据所述业务处理请求，处理所述待处理业务，包括：
获取所述待处理业务中包括的至少一个待处理任务；
获取每个待处理任务对应的参数信息；
根据所述每个待处理任务对应的参数信息，对所述待处理业务进行处理。
7.根据权利要求5所述的方法，其特征在于，所述Docker根据所述业务处理请求，处理所述待处理业务之后，还包括：
获取每个待处理任务对应的执行结果；
根据每个待处理任务对应的执行结果，确定每个待处理任务对应的处理状态，所述处理状态用于指示是否对所述待处理任务处理成功；
向所述调度设备发送每个待处理任务对应的处理状态。
8.根据权利要求7所述的方法，其特征在于，针对所述至少一个待处理任务中的任意一个第一待处理任务；获取所述第一待处理任务对应的处理状态，包括：
获取所述第一待处理任务对应的预设判断条件；
根据所述第一待处理任务对应的预设判断条件和所述第一待处理任务的执行结果，确定所述第一待处理任务对应的处理状态。
9.根据权利要求5所述的方法，其特征在于，所述Docker根据所述业务处理请求，处理所述待处理业务之后，还包括：
获取每个待处理任务对应日志信息；
发送所述每个待处理任务对应日志信息。
10.一种业务处理装置，其特征在于，应用于调度设备，所述装置包括：接收模块、确定模块和发送模块，其中，
所述接收模块用于，接收客户端发送的第一业务处理请求，所述第一业务处理请求中包括待处理业务的标识；
所述确定模块用于，根据所述待处理业务的标识，在业务处理系统中的至少两个Docker中确定目标Docker，所述至少两个Docker处理的业务不同；
所述发送模块用于，根据所述第一业务处理请求生成第二业务处理请求，并向所述目标Docker发送第二业务处理请求，以使所述目标Docker处理所述待处理业务。
11.根据权利要求10所述的装置，其特征在于，所述发送模块具体用于：
在所述第一业务处理请求中获取所述待处理业务的标识；
获取所述业务处理系统的地址信息和所述目标Docker的标识；
根据所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识，生成所述第二业务处理请求。
12.根据权利要求11所述的装置，其特征在于，所述发送模块具体用于：
根据预设算法，将所述待处理业务的标识、所述业务处理系统的地址信息和所述目标Docker的标识分别赋值给预设参数，得到所述第二业务处理请求。
13.根据权利要求10-12任一项所述的装置，其特征在于，所述调度设备和所述业务处理系统部署在不同的物理机中。
14.一种业务处理装置，其特征在于，应用于Docker，所述装置包括：接收模块和处理模块，其中，
所述接收模块接收调度设备发送的业务处理请求，所述业务处理请求中包括待处理业务的标识，所述接收模块为业务处理系统中的至少两个Docker中与所述待处理业务对应的Docker中的接收模块，所述至少两个Docker处理的业务不同；
所述处理模块根据所述接收模块接收的所述业务处理请求，处理所述待处理业务。
15.根据权利要求14所述的装置，其特征在于，所述处理模块具体用于：
获取所述待处理业务中包括的至少一个待处理任务；
获取每个待处理任务对应的参数信息；
根据所述每个待处理任务对应的参数信息，对所述待处理业务进行处理。
16.根据权利要求14所述的装置，其特征在于，
所述处理模块用于，所述处理模块根据所述接收模块接收的所述业务处理请求，处理所述待处理业务之后，获取每个待处理任务对应的执行结果；
所述处理模块用于，根据每个待处理任务对应的执行结果，确定每个待处理任务对应的处理状态，所述处理状态用于指示是否对所述待处理任务处理成功；
所述装置还包括发送模块，所述发送模块用于，向所述调度设备发送每个待处理任务对应的处理状态。
17.根据权利要求16所述的装置，其特征在于，针对所述至少一个待处理任务中的任意一个第一待处理任务；所述处理模块还用于：获取所述第一待处理任务对应的预设判断条件；
根据所述第一待处理任务对应的预设判断条件和所述第一待处理任务的执行结果，确定所述第一待处理任务对应的处理状态。
18.根据权利要求14所述的装置，其特征在于，所述装置还包括发送模块，
所述处理模块用于，在所述处理模块根据所述业务处理请求处理所述待处理业务之后，获取每个待处理任务对应日志信息；
所述发送模块用于，发送所述每个待处理任务对应日志信息。
19.一种业务处理装置，其特征在于，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求1至4任一项所述的业务处理处理方法。
20.一种业务处理装置，其特征在于，包括：至少一个处理器和存储器；
所述存储器存储计算机执行指令；
所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如权利要求5至8任一项所述的业务处理方法。
21.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如权利要求1至8任一项所述的业务处理处理方法。
CN201910377183.1A 2019-05-07 2019-05-07 业务处理方法、装置及设备 Pending CN110086881A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910377183.1A CN110086881A (zh) 2019-05-07 2019-05-07 业务处理方法、装置及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910377183.1A CN110086881A (zh) 2019-05-07 2019-05-07 业务处理方法、装置及设备

Publications (1)

Publication Number Publication Date
CN110086881A true CN110086881A (zh) 2019-08-02

Family

ID=67419010

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910377183.1A Pending CN110086881A (zh) 2019-05-07 2019-05-07 业务处理方法、装置及设备

Country Status (1)

Country Link
CN (1) CN110086881A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110889108A (zh) * 2019-11-26 2020-03-17 网易（杭州）网络有限公司 spark任务的提交方法、装置和服务器
CN113568658A (zh) * 2021-08-13 2021-10-29 中国科学院西北生态环境资源研究院 多语言地学在线服务方法、装置、存储介质及电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1662004A (zh) * 2004-02-27 2005-08-31 华为技术有限公司 一种实现会话发起协议应用服务器多业务处理的方法
CN104615651A (zh) * 2014-12-26 2015-05-13 北京奇虎科技有限公司 业务信息处理方法和浏览器客户端
CN106060127A (zh) * 2016-05-24 2016-10-26 中国联合网络通信集团有限公司 服务器调用方法及装置
CN106790291A (zh) * 2017-03-09 2017-05-31 腾讯科技（深圳）有限公司 一种入侵检测提示方法及装置
CN108829507A (zh) * 2018-03-30 2018-11-16 北京百度网讯科技有限公司 分布式数据库系统的资源隔离方法、装置和服务器
CN108881368A (zh) * 2018-04-22 2018-11-23 平安科技（深圳）有限公司 高并发业务请求处理方法、装置、计算机设备和存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1662004A (zh) * 2004-02-27 2005-08-31 华为技术有限公司 一种实现会话发起协议应用服务器多业务处理的方法
CN104615651A (zh) * 2014-12-26 2015-05-13 北京奇虎科技有限公司 业务信息处理方法和浏览器客户端
CN106060127A (zh) * 2016-05-24 2016-10-26 中国联合网络通信集团有限公司 服务器调用方法及装置
CN106790291A (zh) * 2017-03-09 2017-05-31 腾讯科技（深圳）有限公司 一种入侵检测提示方法及装置
CN108829507A (zh) * 2018-03-30 2018-11-16 北京百度网讯科技有限公司 分布式数据库系统的资源隔离方法、装置和服务器
CN108881368A (zh) * 2018-04-22 2018-11-23 平安科技（深圳）有限公司 高并发业务请求处理方法、装置、计算机设备和存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110889108A (zh) * 2019-11-26 2020-03-17 网易（杭州）网络有限公司 spark任务的提交方法、装置和服务器
CN110889108B (zh) * 2019-11-26 2022-02-08 网易（杭州）网络有限公司 spark任务的提交方法、装置和服务器
CN113568658A (zh) * 2021-08-13 2021-10-29 中国科学院西北生态环境资源研究院 多语言地学在线服务方法、装置、存储介质及电子设备
CN113568658B (zh) * 2021-08-13 2023-09-19 中国科学院西北生态环境资源研究院 多语言地学在线服务方法、装置、存储介质及电子设备

Similar Documents

Publication Publication Date Title
US11637889B2 (en) Configuration recommendation for a microservice architecture
CN103248684B (zh) 一种互联网中资源获取方法和装置
CN108683720A (zh) 一种容器集群服务配置方法及装置
CN108322325B (zh) 一种虚拟机管理方法及装置
CN107872402A (zh) 全局流量调度的方法、装置及电子设备
CN108933829A (zh) 一种负载均衡方法及装置
CN108418874A (zh) 跨广域网数据回导方法、装置、计算机设备及存储介质
CN110764688B (zh) 对数据进行处理的方法和装置
CN113014611B (zh) 一种负载均衡方法及相关设备
CN110457078A (zh) 智能服务方法、装置及设备
US10986172B2 (en) Configurable connection reset for customized load balancing
CN109561054A (zh) 一种数据传输方法、控制器及接入设备
CN108933695A (zh) 用于处理信息的方法和装置
CN110086881A (zh) 业务处理方法、装置及设备
CN108289086A (zh) 请求处理方法及装置、服务器
CN111431730A (zh) 一种业务处理方法、系统、计算机设备及可读介质
CN108366098A (zh) 一种网络节点的数据交互方法及装置
CN112953993A (zh) 资源调度方法、设备、网络系统及存储介质
CN107332703B (zh) 一种多应用日志的查看方法及装置
CN108667750B (zh) 虚拟资源管理方法及装置
CN115454576B (zh) 一种虚拟机进程管理方法、系统及电子设备
CN113835789A (zh) 渲染方法、装置、电子设备及计算机存储介质
US9628401B2 (en) Software product instance placement
CN110245027A (zh) 一种进程间通信的方法和设备
CN110719303B (zh) 一种容器化nrf的方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20190802

RJ01 Rejection of invention patent application after publication