上文中，我们对shield-job要实现的功能和主要流程做了简单的分析。本文，我将带着大家进行技术选型、模块划分及对应的数据库表结构设计。

核心思路还是简洁、易理解、突出原理。

技术选型

技术选型如下表

组件名	作用
MySQL	保存服务注册信息、任务元数据、记录日志等信息。是整个调度框架的核心存储设施
RocketMQ	任务发布介质，注册中心与后台管理直接的沟通媒介。任务调度过程中用于任务的下发
SpringBoot	核心开发框架
JDK8	基于JDK8，向后兼容
Tomcat8	基于Tomcat8，向后兼容

PS: 之所以选择了RocketMQ，一方面是笔者偏爱这款MQ中间件，另一方面也是想帮助大家更多的了解主流的分布式开发组件，提升个人技术素养。

模块划分

上文中，我贴出了整个任务调度框架的流程图，如下：

从图中我们可以看出，核心分为三大部分，分别为

1. 任务管理后台
2. 任务调度器
3. 任务注册中心

因此建立工程目录如下图所示

项目	描述	功能
shield-job-api	项目核心api定义	定义了各模块需要实现的业务核心api
shield-job-register	任务注册中心	用于服务注册，上下线监控，服务心跳保持等
shield-job-scheduler-core	shield-job调度核心	核心jar包，具体的项目依赖该jar包
shield-job-server	任务管理后台	对任务进行统一管理，发布等
shield-job-demo-spring（图中未体现）	Spring版本的样例工程	提供一个基于spring的样例工程

数据表结构设计

基于上述的目标：简洁、易理解、突出原理。我主要设计了四张核心数据表，表名如下，具体的字段在开发过程中会陆续进行说明。

简单概述一下，shield_schedule_log 为任务调度日志表，对任务调度过程中的核心的步骤和执行过程进行记录，便于错误排查及任务的重执行。

这里简单对重执行进行一下描述，对于重复执行的任务，shield-job不保证幂等性，幂等操作需要业务层自己控制，这样对于框架本身的简洁性和任务执行的可控性都是有好处的。

shield_schedule_app_group 为应用分组表，用于对一类型的服务进行集中的管理，主要用来支持业务线的概念。

shield_schedule_service_registry 为服务注册信息表。之所以使用数据库表进行服务注册信息管理，主要是从实现的难易程度和学习理解的难度考量的，因此放弃了使用zookeeper作为注册中心。

shield_schedule_task_info 为任务信息定义表，该表主要用于后台对任务进行发布和对注册中心的同步操作，全局上对任务进行统一的管理和状态维护。

小结

本文，我们对shield-job的技术选型、模块划分及数据库表设计等方面进行了概述，具体的细节将在后续的开发中逐步展开。

PS: 最近开了两个新坑，虽说flag立的挺高，但还是有信心填好坑的，就让我们拭目以待吧。