任务系统和业务系统集成的流程

这是学习笔记的第 1918 篇文章

  任务系统毫无疑问是一个平台建设中的重点内容，我们大多数人在建设的过程中其实会犯一个基础的错误，那就是反正系统都是我在做，那么流程我就简化一点。开始接入还好，一旦接入第三方流程，发现简单的流程都跑不通了。 

   为了能够平滑的对接业务系统的任务，我们需要用解耦合的态度来看待这件事情，即你的是你的，我的是我的，不要纠缠在一起，但流程上可以集成起来。

  假设我们有一个数据库备份的任务，通过第三方的平台（即下图中的业务系统）来触发，备份任务的基础工作是运维系统来提供API,因为备份的时间较长，不能让前端长时间等待，所以我们引入了任务系统来支撑，即备份这个动作是即时触发，异步执行，在需要查看任务状态和结果的时候，可以通过业务系统去发起请求，将任务执行结果通过任务系统的API推送反馈。整个路程就是这样。

听起来流程也蛮简单，但是如何将这三个系统整合起来，让整个流程完整的运行起来呢。我梳理了如下的7个流程，从任务注册开始到任务查询结束。

整个流程中的难点就是整个流程中存在两个UUID,第一个UUID是任务触发的一个闭环，即任务从业务系统触发，任务系统会即时响应，生成一个UUID号，这个任务是通过调度器下发，因为不想让调度器也处于阻塞状态，所以调度器是即时返回的，从调度器的角度来说，它的作用就是提供一个任务调用的平台。任务的执行到了运维系统之后，其实运维系统是无法得到这个UUID的，所以它要反馈问题的进度就会是一个问题。我们不能模糊的处理这件事，如何不能够定位到执行的任务明细，那么我们的任务系统就是一个无法控制的黑盒子。

所以在这里我们要指定一个规则，既然运维系统执行任务时是不知道任务系统返回的UUID，那么我们需要任务系统生成一个UUID到运维系统去，任务系统触发的逻辑是类似如下的方式：

UUID1 = taskops.invoke_task.delay(xxxxxx,UUID2);

因为任务的触发机制，UUID1是无法推送到运维系统，那么我们就需要对这种异步任务统一设置一个规则，需要推送一个任务的UUID，即上图中的UUID2.

这样任务执行结束之后推送结果到任务系统，整个任务的执行就结束了。

还有一个问题，那就是对于业务系统来说，它只知道UUID1,而运维系统返回的是UUID2,那么这两个UUID是如何衔接在一起呢，答案是运维系统会来做这个事情，他在任务触发的时候，需要把任务的UUID对应关系写入一个模型里面去维护。 

即这种关系是如下的方式存放的。

UUID1, UUID2

即UUID1和UUID2是可以互相映射的。

任务执行的结果表类似于：

UUID1,UUID1_starttime,UUID2,UUID2_finish_time,UUID2_args

对于异步任务的执行来说，整个过程是一个完全可控而且可以追溯的方式。 

对于定时任务而言，思路也是类似的，而对于大多数的API来说，比如执行一个简单的任务，一个命令或者查询一个API数据等，操作时间极短，其实是可以折中的，这种任务的执行其实只需要维护一个UUID，待任务返回之后才返回到业务系统。

从系统的设计和完整度来说，这是两种互补的场景。 

相关链接：