您现在的位置是：首页 > 文章详情

Linkis架构解析系列---Job执行流程源码解析

日期：2020-11-02点击：544收藏

Linlis 0.X版本架构解析系列

--Job执行流程架构源码解析

作业执行服务在Linkis 中承担了计算的作用，Job作为作业执行服务中的最小单元，为Job定义了通用的接口和执行优化，来提升Job的通用性和能力。从Job封装到运行，涉及到Linkis中的多个服务，本文将介绍linkis 0.X版本中的Job从提交到执行的整个过程。

1. Job执行在Linkis处在什么位置

Job执行在Linkis的架构中处于统一作业执行服务（Unified Job Execution Services）中，如下图所示：

从图中可以看到UJES在Linkis中占据核心部分，一个Job从封装、运行、结果推送的执行流程从前端入口，到底层计算引擎，涉及到统一作业服务、资源管理服务、统一存储服务、统一上下文服务涉及到Linkis的多个服务。

2. Job处理流程

Linkis UJES（Unified Job Execution Services）作为Job的执行服务，对外提供了REST/WebSocket的通用接口，用于接收上层系统提交的各种访问请求，并提供给底层计算存储引擎执行。支持Job的高并发、高可用、多租户、资源隔离，上下文统一。Job的执行处理流程如下图：

从图我们可以了解到一个Job的执行可以分为15个步骤，可以把这15个步骤规划到三个大步骤中：Job封装，Job执行，Job信息推送；

2.1 Job封装

1. Clinet(如前端)发起请求执行Job，Job请求信息如下：

2. GateWay收到Job后将Job通过executeApplicationName和requestApplicationName转发给对应的Entrance。

3. Entrance接受到对应的Job后，会调用JobHistory的RPC对Job的元信息进行持久化，并对前端的请求进行解析对自定义变量和参数进行封装，封装为可以执行的Job。

2.2 Job的执行

1. 拿到解析后的Job后，Entrance会先为用户去请求一个计算引擎，在请求前先去ResourceManager找到负载最低的EngineManager(引擎管理器)；
2. 接着会向负载低的EM请求启动Engine，如果是JDBC和MLSQL没有EM的服务，这步会在Entrance里面进行；
3. EM接收到启动新的Engine后，会先向RM(资源管理器)为这个用户申请资源启动Engine，如果资源足够则准备启动引擎；
4. EM根据申请到的资源启动新的Engine，引擎启动成功后会向EM推送信息，EM接着推送给Entrance，至此引擎的申请流程结束；
5. Entrance请求到Engine后，首先为该Job申请锁定该Engine以防止其他Entrance和Job提交到该Engine；
6. Entrance锁定Engine成功后，会将Job发送给Engine执行，至此Job开始实际执行

这里需要说明的是如果用户存在一个可用空闲的引擎，则会跳过1，2，3，4 四个步骤；

2.3 Job信息推送

1. Job执行过程中为了客户端的用户可以实时看到job的运行状况，Engine会将Job的状态/进度/日志通过RPC实时推送给Entrance；
2. Entrance收到Job信息进行持久化处理，如果是websocket则将信息直接推送给用户；
3. Job执行完成后，Engine会将最终状态和结果集推送给Entrance，Entrance收到后将结果保存到结果集路径，接着更新JobHistory中的状态信息和结果集信息；
4. 客户端通过状态接口判断Job的成功与否，如果成功则可以通过调用接口请求JobHistory拿到结果集信息。至此整个Job则执行完成。

3 Linkis的Job执行源码解读

第三章对Job的处理流程进行了一个简单讲解，本章主要讲解在这一流程中Entrance，EngineManager，Engine的代码调用流程。

3.1.Entrance处理流程

Entrance是Job执行的入口，当Job从GateWay转发后会先到EntranceRestfulApi或者EntranceWebSocketService分别对应Rest和WebSocket请求的逻辑处理。下面我们从WebSocket请求进行讲解，Rest请求类似；

1. 前端的WebSocket请求通过Gateway转发到ServerSocket类，继承了WebSocketAdapter，ServerSocket会调用ControllerServer的onMessage的方法将消息投递到serverListenerEventBus消息总线，serverListenerEventBus接着会将消息给到EntranceWebSocketService进行处理处理部分代码如下：

2. 执行请求处理逻辑：EntranceWebSocketService的dealExecute方法会调用entranceServer.execute去执行Job，entranceServer接着会对job进行解析封装然后提交给调度器。

3. Job执行流程：调度拿到Job后会为这个Job生成一个groupName，然后通过groupName去ConsumerManager获取一个Consumer(分组消费器)，并将该Job传递给这个FIFOUserConsumer ，FIFOUserConsumer 接着会循环去BlockingLoopQueue里面取Job进行消费，拿到Job后FIFOUserConsumer 会请求一个引擎，接着将该Job提交给线程池运行。

Job线程运行起来后首先会将该Job请求提交给远程Engine进行执行，并拿到响应，为了提升Job的性能，这里一般会返回AsynReturnExecuteResponse(异步返回的请求响应) 用于将Job的状态和信息都异步返回回来，该线程可以直接执行完降低线程开销

4. Job信息推送：Job信息推送为Engine通过RPC推送给Entrance，Entrance再通过WebSocket推送给用户，或者用户通过Rest请求。

3.2 EngineManager

引擎管理器EngineManager是用来管理引擎的，用于对引擎的生命周期进行管理，当Entrance中的Consumer发起askExecutor时会将PRC请求发送给EngineManagerReceiver,

EM接收到消息会先向RM判断该用户和Creator是否还有足够的资源启动引擎，资源判断通过后才会发起引擎启动

Engine的正常退出流程分为两种1、用户发起kill命令,通过EM 杀掉Engine 2、Engine空闲时间过长自行kill，默认一个小时
用户调用kill后会EM会调用：engineManager.getEngineManagerContext.getOrCreateEngineFactory.delete

3.3.Engine处理流程

Engine启动成功后就可以接受Entrance的job请求，执行并推送Job信息给到Entrance，Entrance的job请求会发送到EngineReceiver

engine的Job执行调度流程和Entrance的相同，除了实现类不一样都是通过Scheduler--Consumer--Executor--Executor执行Job，这里需要说明的是Executor对应的是相应Engine的具体执行代码的实现类不是Engnie，这是与Entrance有区别的地方，执行流程也主要在Executor进行实现的:

Job信息通过JobDemo定时进行推送：

3.4 Linkis的Job架构概括

上面从入口、引擎管理器、引擎介绍了一个Job的整体执行流程，Job执行的整体的调用链可以总结为下图：

4. 总结

本文从Job在Linkis 0.X版本中所处的位置进行引入，介绍了一个Job从提交到封装、运行、信息推送的整个流程和源码解析。在Linkis1.0版本中我们对Job执行做了多个优化：
1. 任务标签化：灵活的通过标签做租户隔离，智能路由对应的引擎服务，并支持通过标签指定提交的Hadoop集群等；
2. 任务全栈化：支持在交互作业的基础上，支持流式、一次性批量等作业类型；
3. 任务解析策略化：借鉴Calcite思想，对任务进行编排优化，支持更多的计算策略，智能调度执行；
4. 服务简化：统一Entrance和EngineManager服务，底层计算存储引擎只需要实现引擎插件（EngineConnPlugin）就可以完成新引擎的实现，不在需要实现Entrance和EngineManager服务。

Linkis1.0 新的架构对多个模块进行了架构调整和优化，敬请期待，同时Linkis1.0有多个模块正在开发实现当中，欢迎社区各位大佬的加入。

本文从Job在Linkis中所处的位置进行引入，介绍了一个Job从提交到封装、运行、信息推送的整个流程和源码解析。后续将为大家带来Linkis更多模块的代码解析，敬请期待。