系统架构
DataShops系统有四个角色组成,分别是Master、Worker、API、UI,他们独立部署,不同角色间使用gRPC框架通信,Protocol Buffer对消息序列化
设计目标
- 支持多种类型任务
- 工作流配置、依赖、执行等可视化操作
- 支持最小单元添加依赖
- 支持日志实时滚动
- 支持任务失败重试
- 支持任务失败告警
- 支持多种任务分发机制,随机、负载、指定主机
- 动态中心化设计,多台Master可实现负载均衡
- 支持docker与k8s部署
- 对外API服务,开放查询任务相关元数据,方便对接外部系统
- 支持任务历史版本查看及恢复
- 支持历史任务状态可视化查看
- 支持系统运行状态可视化
- 支持资源文件管理
- 支持实时查看DAG状态图
架构设计图
模块说明
- datashops-api 接口模块
- datashops-common 工具类模块
- datashops-dao 数据库操作模块
- datashops-model 实体模块
- datashops-server 核心服务模块
- datashops-service 接口服务模块
- datashops-protocol gRPC通信模块
架构说明
Master
master主要负责任务的调度、分发,多个master可提供负载均衡,保证服务的稳定性,任务调度默认只在一个master上运行,防止任务重复调度。对启动的任务会定时检查依赖及资源状态,并按指定策略分发给对应的worker节点运行。
Worker
worker负责任务的具体执行,如果对应任务需要特殊的环境变量,则需要相应的配置环境
Zookeeper
zookeeper提供分布式锁、任务队列、服务心跳服务
API
API是一个接口服务,负责对外提供统一的服务入口,包括UI的请求,其他服务调用
UI
使用Vue和element-ui提供可视化界面
分布式锁
使用curator中的InterProcessMutex
实现分布式锁,从元数据库中定时获取需要执行的任务
DAG
任务被执行时,会生成对应DAG工作流,检查有无环,上游依赖任务状态,系统资源等
容错
- 任务执行状态在元数据库中保存,当master节点整体故障,重启后能保证对应任务自动拉起,且同一DAG中已成功任务不再重复执行
- 单个任务因worker节点故障导致长时间不更新状态,会通过超时发现异常,并重新拉起执行
网络通信
- 系统使用
gRPC
进行master与worker间心跳、任务下发、结果返回等通信 - 使用
Protocol Buffer
对消息进行序列化,更加高效的简化网络请求
元数据
所有元数据信息存入MySQL数据库中
负载均衡
多个master节点能保证同时提供服务,所有任务分发及worker节点请求通过随机的方式与不同master通信,达到负载均衡的效果,防止一个master持续工作造成单节点故障