DataShops数据工厂，系统架构（二）

系统架构

DataShops系统有四个角色组成，分别是Master、Worker、API、UI，他们独立部署，不同角色间使用gRPC框架通信，Protocol Buffer对消息序列化

设计目标

1. 支持多种类型任务
2. 工作流配置、依赖、执行等可视化操作
3. 支持最小单元添加依赖
4. 支持日志实时滚动
5. 支持任务失败重试
6. 支持任务失败告警
7. 支持多种任务分发机制，随机、负载、指定主机
8. 动态中心化设计，多台Master可实现负载均衡
9. 支持docker与k8s部署
10. 对外API服务，开放查询任务相关元数据，方便对接外部系统
11. 支持任务历史版本查看及恢复
12. 支持历史任务状态可视化查看
13. 支持系统运行状态可视化
14. 支持资源文件管理
15. 支持实时查看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持续工作造成单节点故障