屡试不爽的架构三架马车

定时任务的需求有那么几类：

1. 如之前所说，跨服务调用，MQ通知难免会有不可达的问题，我们需要有一定的机制进行补偿。
2. 有一些业务是基于任务表进行驱动的，有关任务表的设计下面会详细说明。
3. 有一些业务是定时定期来进行处理的，根本不需要实时进行处理(比如通知用户红包即将过期，和银行进行日终对账，给用户出账单等)。和2的区别在于，这里的任务的执行时间和频次是五花八门的，2的话一般而言是固定频次的。

详细说明一下任务驱动是怎么一回事。其实在数据库中做一些任务表，以这些表驱动作为整个数据处理的核心体系，这套被动的运作方式是最最可靠的，比MQ驱动或服务驱动两种形态可靠多，天生必然是可负载均衡的+幂等处理+补偿到底的，任务表可以设计下面的字段：

• 自增ID
• 任务类型：表明具体的任务类型，当然也可以不同的任务类型直接做多个任务表。
• 外部订单号：和外部业务逻辑的唯一单号关联起来。
• 执行状态：未处理(等待处理)，处理中(防止被其它Job抢占)，成功(最终成功了)，失败(暂时失败，会继续进行重试)，人工介入(永远不会再变了，一定需要人工处理，需要报警通知)
• 重试次数：处理过太多次还是失败的可以归类为死信，由专门的死信队列任务单独再进行若干次的重试不行的话就报警人工干预
• 处理历史：每一次的处理结果，Json的List保存在这里供参考
• 上次处理时间：最近一次执行时间
• 上次处理结果：最近一次执行结果
• 创建时间：数据库维护
• 最后修改时间：数据库维护

除了这些字段之外，还可能会加一些业务自己的字段，比如订单状态，用户ID等等信息作为冗余。任务表可以进行归档减少数据量，任务表扮演了消息队列的性质，我们需要有监控可以对数据积压，出入队不平衡处理不过来，死信数据发生等等情况进行报警。如果我们的流程处理是任务ABCD顺序来处理的话，每一个任务因为有自己的检查间隔，这套体系可能会浪费一点时间，没有通过MQ实时串联这么高效，但是我们要考虑到的是，任务的处理往往是批量数据获取+并行执行的，和MQ基于单条数据的处理是不一样的，总体上来说吞吐上不会有太多的差异，差的只是单条数据的执行时间，考虑到任务表驱动执行的被动稳定性，对于有的业务来说，这不失为一种选择。

这里再说明一下Job的几个设计原则：

1. Job可以由各种调度框架来驱动，比如ElasticJob、Quartz等等，需要独立项目处理，不能和服务混在一起，部署启动多份往往会有问题。当然，自己实现一个任务调度框架也不是很麻烦的事情，在执行的时候来决定Job在哪台机器来跑，让整个集群的资源使用更合理。说白了就是两种形态，一种是Job部署在那里由框架来触发，还有就是只是代码在那里，由框架来起进程。
2. Job项目只是一层皮，最多有一些配置的整合，不应该有实际的业务逻辑，不会触碰数据库，大部分情况就是在调用具体服务的API接口。Job项目就负责配置和频次的控制。
3. 补偿类的Job注意补偿次数，避免整个任务被死信数据卡住的问题。

三马车都说完了，那么，最后我们来梳理一下这么一套架构下整个项目的模块划分：

Site：

• front
• console
• app-gateway

Façade Service：

• partnerinvestservice-api
• partnerinvestservice-server
• partnerinvestservice-listener
• normalinvestservice-api
• normalinvestservice-server
• normalinvestservice-listener
• reserveinvestservice-api
• reserveinvestservice-server
• reserveinvestservice-listener
• autoinvestservice-api
• autoinvestservice-server
• autoinvestservice-listener

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!