引言

在 【性能优化】：探索系统瓶颈的根源（一）文章中，我们已经分析了手动结算的弊端和瓶颈，本文来分析下怎么优化系统性能。

需求分析

既然手动结算耗时费力易出错，那么能不能开发一个**程序自动化处理**呢？如果要开发一个自动化跑批的程序，核心功能点是什么呢？

第一：需要能正常运行；
第二：出错了之后也得能重跑；
第三：既然是自动化处理了，步骤结果信息能通知到我们；
第四：系统能够自动生成财务报表并下载；
第五：能看到每次步骤的执行详情；
第六：需要数据库表记录每次执行步骤的参数，供下次使用。

通过上述分析，我们已经能够得出，一个自动化跑批的程序，核心功能点如下

1. 正常运行
2. 出错重试
3. 节点报警
4. 步骤详情
5. 一个可视化的界面

所以，我们的自动化跑批模型大概类似于这种

表结构设计

通过需求分析，我们已经大概知道了自动化跑批的功能点，现在来设计下表结构。

CREATE TABLE ` dispatch ` (
  ` id ` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '数据库表主键',
  ` dispatch_time ` timestamp NOT NULL COMMENT '调度日期',
  ` status ` varchar(10) NOT NULL COMMENT '调度状态（failed、success、running、pause、human）',
  ` remarks ` varchar(50) DEFAULT NULL COMMENT '备注',
  ` create_time ` timestamp NULL DEFAULT NULL COMMENT '创建时间',
  ` update_time ` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  PRIMARY KEY (` id `)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_bin COMMENT = '调度表'

CREATE TABLE ` dispatch_detail ` (
  ` id ` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '数据库表主键',
  ` dispatch_id ` bigint(20) NOT NULL COMMENT '调度表主键',
  ` step ` varchar(20) NOT NULL COMMENT '步骤',
  ` start_time ` timestamp NULL DEFAULT NULL COMMENT '开始日期',
  ` end_time ` timestamp NULL DEFAULT NULL COMMENT '结束日期',
  ` status ` varchar(10) NOT NULL COMMENT '调度状态（failed、success、running、pause、human）',
  ` remarks ` varchar(50) DEFAULT NULL COMMENT '备注',
  ` create_time ` timestamp NULL DEFAULT NULL COMMENT '创建时间',
  ` update_time ` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  ` execution_time ` varchar(50) DEFAULT NULL COMMENT 'DAG调度时间',
  ` serial_number ` int(10) DEFAULT NULL COMMENT '步骤序号',
  ` result ` varchar(1000) DEFAULT NULL COMMENT '返回结果',
  ` params ` varchar(1000) DEFAULT NULL COMMENT '请求参数',
  PRIMARY KEY (` id `),
  KEY ` idx_step ` (` step `),
  KEY ` idx_dispatch_id ` (` dispatch_id `)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_bin COMMENT = '调度明细表'

CREATE TABLE ` back_record ` (
  ` id ` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '数据库表主键',
  ` back_pt ` varchar(20) NOT NULL COMMENT '备份日期',
  ` create_time ` timestamp NULL DEFAULT NULL COMMENT '创建时间',
  ` update_time ` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  ` dispatch_id ` bigint(20) NOT NULL COMMENT '调度表主键',
  PRIMARY KEY (` id `)
  /*T![clustered_index] CLUSTERED */
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_bin COMMENT = '备份记录表'

CREATE TABLE ` netting_record ` (
  ` id ` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '数据库表主键',
  ` back_pt ` varchar(20) NOT NULL COMMENT '备份日期',
  ` version ` varchar(20) NOT NULL COMMENT '备份版本号',
  ` create_time ` timestamp NULL DEFAULT NULL COMMENT '创建时间',
  ` update_time ` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  ` dispatch_id ` bigint(20) NOT NULL COMMENT '调度表主键',
  PRIMARY KEY (` id `)
  /*T![clustered_index] CLUSTERED */
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_bin COMMENT = '轧差记录表'

CREATE TABLE ` sap_record ` (
  ` id ` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '数据库表主键',
  ` product_version ` varchar(20) NOT NULL COMMENT '发送sap日期',
  ` create_time ` timestamp NULL DEFAULT NULL COMMENT '创建时间',
  ` update_time ` timestamp NULL DEFAULT NULL COMMENT '更新时间',
  ` dispatch_id ` bigint(20) NOT NULL COMMENT '调度表主键',
  PRIMARY KEY (` id `)
  /*T![clustered_index] CLUSTERED */
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_bin COMMENT = 'sap发送记录表'

代码设计

通过需求分析和表结构设计，我们已经大致有一个模型了，为了让程序扩展性更好，所以还需要对代码结构设计下。

步骤配置化

步骤列表信息不能写死，如果之后有变动，还需要改动代码发布，所以我们可以把它放到公司的配置中心动态配置，在调度运行的时候加载到表中，并以接口形式返回给前端。

钉钉通知

如果要监控每一步骤的执行信息，如输入参数、返回参数、执行状态、运行时长等信息，我们可以引入钉钉通知。
具体可参考 高效实时监控：异步计算任务的挑战与解决方案（一）

设计模式

为了使代码的扩展性更好、可读性更强，我们可以引入设计模式来设计。通过跑批模型图，可以得到以下信息

• 各个步骤的执行特别符合一条“责任链”，从起始节点依次向下执行，直到尾节点；
• 各个步骤在执行时，都必需满足上一个节点执行成功且自己没有执行过，如果把这个流程代码放到一个抽象的父类，各个步骤子类去实现自己的业务逻辑，这就是“模板方法”。

可参考：
【职责链】设计模式：构建灵活的请求处理系统
【模板方法】设计模式：构建可扩展软件的基石

总结

通过以上简单分析，我们已经可以大概能想象出自动化跑批系统的雏型了，在下一篇我们就要实际编码来实现了。
以上分析肯定存在漏洞不完善的地方，欢迎大家批评指正。