求大牛分析下批量框架的想法和设计什么建议或觉得不妥的地方写下来

dulei123321 2011-08-24 02:43:57

中国农业银行

批量框架
设计方案

文档信息：
版本：V1.0.0
项目：
密级：内部
状态：受控
模板版本：V1.0.0

修订记录：
日期版本修订描述作者
2011/8/1 V1.0.0 创建曹文浩
2011/8/12 V1.0.1 修改曹文浩
2011/8/19 V1.0.2 修改曹文浩

修订内容：
版本修订内容
V1.0.1 增加应用场景
V1.0.2 修改交易流程、增加内部结构和消息订阅机制的实现部分

文档审批信息
序号审批人角色审批日期签字备注
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

目录
1.前言 2
2.名词解释 2
3.概述 2
3.1批量框架的应用场景 2
3.2批量框架的组成部分 2
3.3批量框架的部署结构 2
4.架构设计 2
4.1整体架构 2
4.2总控服务器 2
4.3应用服务器 2
4.4交易流程 2
5.内部结构和处理机制 2
5.1异步总控 2
5.1.1通讯模块 2
5.1.2配置管理模块 2
5.1.3调度模块 2
5.1.4其他模块 2
5.2消息队列 2
5.3消息订阅 2
5.4异常处理 2

1.前言
批量任务的定义一般定义为联机批量和日终批量，在此基础上结合电子渠道的批量交易特点分为3个种类：一般的联机批量交易、定时的批量交易、周期性发起的批量服务。具体的应用场景分为5个，对于这5个应用场景批量框架给予了不同的处理方式，能够将大任务拆分为小任务并以异步的通讯方式完成交易数据的传递，同时还提供了定时调度的能力。

2.名词解释
异步总控服务器：接受批量请求并拆分批量任务到一组无序的消息中，并将它们发送到对应的消息队列中。同时根据配置的定时调度任务发起调度消息到指定的应用。
消息服务器：由一组消息队列组成的消息中间层，在总控服务器与应用服务器之间传递消息。
应用服务器:批量任务的真正执行者，以集群的方式部署。
MSMQ：微软消息队列。

3.概述
批量框架属于一种轻量级的调度框架，能够将较大的批量任务拆分成粒度合适的子任务再发送至消息服务器中缓存并等待应用服务集群的处理。批量框架只专注于批量任务的拆分和调度，并不涉及任何业务逻辑、中间状态等。
批量框架采用消息驱动的模式，利用消息队列存储转发交易信息，同时实现了整体通讯的异步化，避免某些环节因为通讯流量过大出现访问超时和拥堵。消息服务中间件除了能够实现任务的拆解和分发以外，还能够提供数据持久化和应用高速访问的能力以及任务的恢复能力。
根据批量交易的特点，分为以下3种处理模式：
A.一般联机批量交易：
1. 渠道端发起批量交易告知异步总控服务器并提交批量文件。
2. 异步总控服务器给渠道段一个响应之后拆分这个批量文件中的交易信息到一组无序的子任务块当中。
3. 异步总控服务器为这些任务块定义主题并发送到消息服务器上。
4. 每个应用根据主题取得自己的任务块后开始处理任务。

B.定时的批量交易：
1. 渠道端发起批量交易告知异步总控服务器并提交批量文件。
2. 异步总控服务器给渠道段一个响应之后任务则延迟一段时间。
3. 异步总控服务器启动任务拆分这个批量文件中的交易信息到一组无序的子任务块当中。
4. 异步总控服务器为这些任务块定义主题并发送到消息服务器上。
5. 每个应用根据主题取得自己的任务块后开始处理任务。

C.定时服务：
1. 通过手动配置的方式向异步总控服务器内添加一个周期任务。
2. 异步总控服务器在规定的时间根据配置的参数产生一个调度消息。
3. 异步总控服务器将这个调度消息发送至应用服务器。

框架解决的问题：
1. 统筹电子渠道批量交易，简化批量业务开发
2. 将大批量拆分成小任务块并行处理
3. 以异步通信和消息中间件缓存任务的方式防止应用服务器拥堵
4. 应用集群处理批量业务，易于扩展处理能力
5. 拥有定时能力

3.1批量框架的应用场景
批量框架共包含5个应用场景的批量交易模式，其中联机批量的场景有2个，定时交易的场景有2个，定时服务的场景有1个。

场景1：

 场景描述
渠道将批量文件上传至某一个地方并告知批量框架，或者直接传递交易数据给批量框架，批量框架接到任务后会立即启动拆分并将拆分的结果经由消息服务器发送给应用处理。
 提交数据
交易数据以批量文件或DataTable的方式提供给批量框架。
 返回数据
对于上传文件的形式消息中的交易数据以字符串（数组）的形式存在，对于DataTable的方式消息中的交易数据仍以DataTable的方式存在。
 场景举例
批量对公转账、批量撤单

场景2：

 场景描述
渠道端提供批量文件以及相关的讯息，框架将不同的任务拆分入不同类型的消息块中。
 提交数据
包含不同后台类型的同类交易信息的批量文件。
 消息数据
与场景2中消息相同，但是对应不同的后台。
 场景举例
批量对私转账

场景3:

 场景描述
渠道传递批量文件和时间描述给框架，框架按时间条件发起批量任务取得批量文件并拆分。
 提交数据
批量文件和时间参数
 返回数据
消息中的交易数据以字符串（数组）的形式存在。
 场景举例
预约批量转账

场景4:

 场景描述
渠道传递批量文件和日期描述符给框架，框架按在日终结时段发起批量任务。
 提交数据
批量文件和日期参数
 返回数据
消息中的交易数据以字符串（数组）的形式存在。
 场景举例
通知存款自动支取

场景5:

 场景描述
渠道配置或传递任务参数和时间规则给，框架按时间条件调起渠道应用。
 提交数据
任务参数和时间规则。
 返回消息
调度消息
 场景举例
电子对账单信息上传、证书到期提醒、退款文件下载

3.2批量框架的组成部分
批量框架的应用组成如下图：

各个部分的说明：
 渠道应用：渠道应用通过框架的接口发起联机批量交易。
 手动配置批量：对于需要长期运行的周期任务，需要使用手动配置的方式定义。
 任务持久化：手动配置的定时批量任务需要长期运行，因此作业本身需要被持久化。
 服务访问层：提供发起批量交易的通讯接口。
 定时器：完成定时任务的触发操作。
 策略库：定义了一组与拆分和调度相关的策略参数，供应用选择和配置。
 调度器实体：执行批量任务的拆分和发送的线程。
 消息服务：框架提供的消息服务中间件，用于存储和转发任务。
 应用服务器集群：任务的真正执行者。

3.3批量框架的部署结构
批量框架的部署结构：

各个部分的说明：
 渠道应用：批量任务的发起者。发起批量的方式是通过调用一个远程接口实现的，仅通过接口通知异步总控服务器有批量交易并告知批量文件存放地址和批量类型。
 手动配置批量：对于周期性的批量调度任务，以手动配置的方式添加到异步总控服务器中。这部分交易被持久化在框架库中，以定时器触发的方式运行。
 总控服务器：包含了框架的调度核心，集成接受批量请求、调度和拆解批量任务以及分发任务等服务。调度器实体依据任务信息和调度策略拆分任务并发送至相应的消息队列，依据配置的调度参数启动即时和定时任务。
 消息服务器：提供消息服务的中间件，物理上可以是分布的。消息队列部署在windows server 域上，消息支持事务特性并具有优先级。包括任务队列和日志队列。
 应用服务集群：部署批量应用的服务器集群。以集群的方式扩展应用处理批量的能力。
 框架库：框架库中记录交易的批次信息和辅助框架运行的一些参数数据以及调度策略参数等。

4.架构设计
4.1整体架构
整体应用架构图：

上图表示框架的在整个应用流程中的位置和整体架构，图示框架的主要职责是拆分交易和定时调度服务。
批量请求来自于各个应用系统联机提交，定时的任务需要通过控制台配置进入框架，通过框架的定时机制发送调度消息给配置好的应用。普通的批量交易被拆分后进入消息服务器，以订阅的方式被相关应用取走并处理。

4.2总控服务器
总控服务结构图：

总控服务器的服务访问层提供一组访问框架的接口：提交批量文件的接口、提交DataTable数据的接口、配置调度策略的接扣和配置定时任务的接口，一共四个接口。
当任务进入到异步总控服务器里面的时候，Scheduler(调度程序)意识到有任务到达马上生成一个Instance，这个Instance里包含了任务的上下文Context，任务数据DataMap，任务策略Strategy和任务处理器Processor以及消息发送器Sender。
任务生成完毕以后放入到调度容器Container中，然后检视线程池ThreadPool中是否有空闲的线程如果有则启动这个实例去拆分任务。
Instance启动以后会按照策略执行拆分任务，将任务拆分以后放入消息体中，然后填写好消息头，然后按照策略去发送消息到消息服务器。
线程池ThreadPool中预先定义了一组work线程，当有实时批量任务到达时会按照任务到达的先后顺序为他们分配处理线程。而当定时任务到达时依旧按照实时任务的步骤处理，不过在发起调度应用时会根据定时任务发起的时间选择是否执行还是先sleep到执行时刻到达时再发送任务调度信息。对于定时调度任务需要通过手动配置让它们进入框架的调度容器。
调度策略Strategy：对于异步总控服务器而且，联机批量任务的到达是不断的，而且就数据形式而言是一条条交易数据的堆积，因此拆分任务实际上只是将这些无序的交易拆分到一些小块当中。但是，由于各个渠道应用的具体情况不同，这些交易数据发往的后台也不同等等，拆分这些任务不能选择单一的策略。因此提供了一组影响调度器行为的参数，来灵活控制调度器的拆分以及发送。

4.3应用服务器
应用服务器结构图

应用服务器由一个处理消息的组件和应用处理程序两部分组成。对于每一个消息框架视为一个最小事物单元，通过接收确认消息Acknowledge来确保应用对消息的处理是完整的，而且框架也只确保消息的处理是完整的并不会涉及具体的交易明细。应用的开发仅开发Application部分，其余的消息接收工作由框架来完成。
4.4交易流程
框架的交易流程针对不同的数据类型分为了3种，分别针对提交批量文件的情况，提交DataTable的情况和定时调度的情况。
1.对于提交批量文件的情况（包含定时批量）：
批量文件可以是定时的交易也可以是即时发起的交易，对于即时的交易框架会及时响应拆分并发送；对于定时的交易需要用到定时延迟服务，系统先记录下交易信息，到达时间点后延迟服务会发起批量交易事件，此时再启动批量任务去处理批量文件。

2.对于提交DataTable的情况：
以DataTable方式提交的批量交易不支持将任务延迟到某个时间点的定时方式，即来即处理。

3.对于定时调度的情况
对于周期类的调度任务，框架只负责调起这个任务，这类任务需要再系统初始化的时候预先配置好并持久化到文件系统中，也可以在系统运行的过程中动态的添加或删除。

5.内部结构和处理机制
批量框架的模块划分从功能层次上分为：异步总控、消息服务、消息订阅三大组成部分。一个完整的批量交易的处理模型如下图所示：

交易流程：
1．当批量框架收到来自应用的批量请求后，将批次信息录入数据库。
2．检测这个请求是否是定时批量任务，如果是定时批量任务将为这个任务定义触发器并灌入时间参数。
3．读取策略参数并初始化任务，然后将任务加入到调度容器中。
4．任务满足执行条件且被调度器选中获得执行线程后，建立与文件服务器的通讯并读取批量文件（或直接读取内存中的DataTable）中的交易信息并拆分和封装到消息中。
5．将这个任务的全部消息发送至消息服务器。
6．产生订阅事件并发送至订阅该事件的应用。
7．应用获取消息并启动处理过程解析数据后发送交易。
8．交易处理完成后返回一条确认消息至消息服务器。
9．异步总控服务器从消息服务器上取回影响消息并更新至数据库。

5.1异步总控
异步总控主要包含以下几个模块：
通讯模块：负责框架与外界的通讯。
配置管理模块：管理配置调度参数和定时任务。
调度模块：调度任务。包括拆解批量文件或DataTable、向消息服务器发送消息、发送订阅事件等一系列功能。
数据访问模块：访问框架数据库。
确认消息处理模块：侦听并处理确认消息。

5.1.1通讯模块
框架使用Web Server的方式对外提供服务，2个对外通讯接口（传递批量文件和传递DataTable）均已Http Request的方式响应外部请求。接口的具体内容和批量文件以及DataTable的格式在接口规范文档中有具体描述。
传递批量文件的接口通讯采用web service方式，批量文件的传输采用socket方式进行。渠道端通过建立http连接的方式与框架取得联系并发起批量交易，框架在建立批量任务后通过socket连接以文件流的方式取得批量文件的内容。应用与框架的通讯在框架响应渠道端的http请求后关闭连接，框架与文件服务器的通讯在取得完整文件信息后关闭连接。

传递DataTable的接口以web service的通讯方式进行DataTable的传输需要对DataTable进行序列化和反序列化。应用与批量框架直接的通讯通过建立http连接的方式，当批量框架响应应用的http请求并完成数据的传输后关闭http连接。

5.1.2配置管理模块
除去框架本身的运行配置管理部分，框架还具有一个单独的配置管理模块。这个配置管理模块主要负责两部分的配置工作：批量调度参数的配置和定时调度任务的配置。配置管理以web app的方式提供配置管理界面，通过可视化的参数配置动态的改变框架运行参数和添加删除定时调度任务。

5.1.3调度模块
任务调度模块是框架的主要功能体现，他的实现包含了几个具体的组成部分：任务调度容器、定时器、任务定义、策略分析、拆分批量任务、消息发送、事件发布等。
调度的模型图如下：

调度容器的结构

框架中的任务定义分为3种，分别对以第一章提到的3种类型的批量交易。对于每一种任务的启动首先要进行任务的定义，在定义任务的过程中会启动调度策略分析为批量任务制定调度参数之后生成批量任务。任务生成以后会进入调度容器并驻留在容器中直到它被调度选中获得执行。
任务获得执行需要具备的条件有2个，1是任务本身没有定时条件或定时时间到达。2是线程池中有空闲的线程。不满足上述2个条件的任务会驻留在容器中等待被调度选中。
当任务开始执行的时候首先取得批量交易数据（通过Socket接口读书数据文件或已经在内存中的DataTable），取得数据以后会按照调度参数中关于批量文件的拆分粒度描述参数进行批量数据的拆分和消息的封装。当批量文件被拆分完毕以后，启动一个发送连接将这组消息发送至消息服务器上。当消息发送完成并全部成功以后，启动订阅事件发送他将应用订阅的事件发送到对应的应用服务器上。
调度参数可以影响任务的拆分和消息的发送俩个环节。当批量任务被受理的时候框架需要从参数表里读出对应的策略，然后按照策略里的参数描述进行任务的拆分和任务的发送。调度参数在策略表中和批量文件中的策略标号是关联调度参数的方式，对于提交DataTable的方式在调用相关接口时需要指定使用的策略标号。

调度参数：
参数名说明
策略标号调度策略的ID
策略描述说明文字
拆分粒度每条消息中至多包含的交易笔数
子任务粒度不同数据段中的任务拆分粒度
消息数量此批次交易需要被拆分为几个消息
消息有效时间超过有效时间的消息将被丢弃
播送方式注册订阅事件
推送目标订阅者的列表
段分隔符自定义批量文件段分隔符
段结束符自定义批量文件段结束符
目标队列消息会被送入指定的队列
事物性此批次的消息是否为一个事物
回调参数调度消息失败时的回调选项
回调延迟延迟n毫秒进行重新调起
回调次数至多进行n此回调
回调超时回调的超时时间

批量任务从触发时间上分为4种：
1. 联机任务
与时间无关的任务，即到达即处理。
2. 定时联机任务
需要延迟一段时间再做的联机任务，即时到达延迟处理。
3. 日终任务
需要延迟到日终时段处理的任务。
4. 周期任务
以一个固定的周期发起的任务。

对于1的情况，当有任务到达以后会立即拆分处理。
对于2的情况当任务到达以后需要延迟到任务时机再处理，因此2的情况不能发送内存数据，仅支持以文件的方式提交数据。
对于3的情况与2类似，但是并没有任务执行的具体时间，而是在日终时段再依次处理。
对于4的情况任务不是通过调用框架接口发起，而是需要配置到框架中，框架按照任务的周期去调起任务。在配置这个任务的时候需要指定任务的周期规则以corn表达是的方式提供给，如果有需要也可以指定调度参数。

5.1.4其他模块
除了以上主要模块以为，异步总控服务器还包含了一些辅助模块：数据访问模块是在整个的交易处理过程中提供框架数据库的访问服务；确认消息侦听模块是侦听并接受来自应用返回的确认消息以确保发送到消息服务器上的消息都被正常的处理。

5.2消息队列
框架的消息服务中间件以集成在Windows环境下的MSMQ组件的方式提供服务。框架使用的队列分为三种：任务数据队列、错误消息队列、确认消息队列。任务数据队列接受来自总控服务器的任务消息并发送给订阅了相关事件的应用。错误消息队列是异步总控想应用发送在对批量文件进行处理的过程中出现的错误信息。确认消息队列是应用返回给异步总控的确认消息，异步总控收集这些确认消息以确保框架中的消息被正常处理。

5.3消息订阅
应用取得消息服务器中的消息是通过订阅的方式获得的。当一组属于某个应用的消息被放置到消息服务器上的时候会触发一个订阅事件，这个订阅事件告知对应的应用去取的消息。消息被取得以后通过识别消息头中的交易类型信息调起不同的应用处理流程。
基于MSMQ的发布/订阅系统实现：

由于MSMQ的定于机制是基于广播实现的，因此要实现能够传递交易数据的消息订阅使用了远程方法来实现订阅事件的传递。
订阅者首先需要注册一个自己订阅的主题Topic，这个Topic是订阅者Sub和发布者Pub都需要知道的一个标签，这个标签被标记在消息上。当具有某一个主题的消息被发送到消息消息服务器上的时候在Pub内产生一个事件，这个事件包含了这个主题的内容，根据这个主题的内容产生事件的Job会启动基于事件远程调用过程，它将通知在Sub内的订阅事件处理器有他订阅的消息到达服务器了。此后订阅者会启动消息接收线程，按照事件通知的内容去取得相应的消息完成订阅消息的接收过程。

5.4异常处理
框架中可能产生的异常有2种：一种异常会导致交易失败而无法发送消息，这种异常通过框架的异常处理机制将错误消息发送给应用，其余的错误处理交给应用去做。
部分框架处理流程中产生的异常：
异常处理
批量文件丢失发送错误消息给应用，丢弃请求
批量文件格式不正确发送错误消息给应用，丢弃请求
部分批量文件格式不正确发送错误消息给应用，丢弃错误交易
批量文件头中交易笔数与实际不符发送错误消息给应用，丢弃请求
交易类型不正确发送错误消息给应用，丢弃请求
请求通讯异常中断请求
文件服务器通讯异常保存已生效消息，有限次尝试续读
消息发送通讯异常有限次尝试失败后发送备用队列
订阅事件发送异常超时重发，失败后均衡至其他应用

另一种异常会影响到批量任务在交易端的状态，例如运行过程中消息服务器突然崩溃，当消息服务器崩溃以后应用将得不到消息服务器上的消息，而在应用端这笔交易将是已提交的状态。
1．异步总控服务器宕机器
异步总控服务器采取双机热备的方式：当异步总控服务器出现故障的时候，全部的批量请求将因为得不到响应而被阻塞到总控服务器恢复。此时存在交易风险的是已经被响应请求的批次交易中有部分还没被发送到消息服务器上。这笔交易在响应请求的时候已经将批次信息录入数据库，异步总控服务器的热备机起动后会去扫描数据库中的未发送任务，扫描完成再次扫描消息服务器中的消息并获取消息头中关于批次的信息再进行一次筛选，然后将已经提交批量文件的未发送任务重启起动，向提交DataTable的批量应用发送交易失败消息。由于任务消息的发送属于一个事物，因此不会出现一个批次的部分任务被发送的情形。
2．消息服务器宕机
消息服务器出现故障的时候，异步总控服务器会无法发送消息至消息队列，同时正在接受消息的应用将被阻塞。此时异步总控服务器能够检测到消息服务器的故障，立即重启消息服务器。由于消息服务器上的消息是持久化在文件系统当中的，因此当消息服务器重启后不用担心丢失消息的问题。
3．应用服务器宕机
应用服务器宕机后，已经在应用中处理的消息将得不到确认消息。在订阅事件被响应后的长时间内得不到来自应用的确认消息，框架则认为这段消息中的任务失踪，并发送包含失踪交易数据的错误消息到消息服务器上。应用重启后，获取消息服务器上的错误消息，按照错误消息中的记录去查询相应的交易状态并决定是否重做交易。

...全文