在先前的文章中，对于变更风险观测的流程逻辑设计，有浅谈一小部分。但从宏观来讲，一个变更观测平台，需要对大量的观测任务做统一调度，这样才能把整个观测平台给支撑起来。因此，本文就简单分享一下，变更风险观测的任务调度可能怎样设计。

这个问题可以拆分为几个子问题：多任务并发需要如何处理，任务调度的消息协议需要如何设计，以及怎么去保证整个调度系统的稳定性。

首先第一个问题是，多任务并发的整个系统设计。主要是两个路子，一种方式是有一个任务驱动服务去不断地向一个MQ去生产和消费任务调度信息，好比说创建任务的过程，HTTP接口逻辑先让任务记录落库，然后produce一条任务执行的消息，之后consumer消费了任务执行消息后，就initialize整个观测任务，开始执行，执行过程中不断生产消费poll的消息，如果用RMQ的话也可以借助延迟队列机制去定时推进任务进程，直到任务结束。另外一种方式是通过一个外部的cronjob去查询近期的非终止态任务，然后一个个去推进执行，不走消息队列。

两种方式各有利弊，后者因为有定时的查询过程，对DB的压力会稍微大一些，因此如果任务量非常多的话，查询时延会比较高，导致任务推进缓慢，而前者主要依赖MQ的稳定性，如果消费逻辑不稳定，容易造成消息积压或者任务推进过程中断。整体来看前者的架构会更加灵活一些，用mq分担一些任务推进工作，在这个基础上，再去附加一个外部的cronjob做兜底。对于MQ的生产消费，如果任务量有预估，可以用定容的服务去处理produce/consume逻辑，当然如果有计费要求，用faas会更加合理。

第二块是消息协议设计。这块会主要关注创建任务需要包括哪些信息，可以大致做这样的分门别类：

• 任务创建的元信息：哪个job、创建人、创建来源以及任务的调度参数
• 工单（阶段）的上下文信息：工单所属渠道、工单ID、变更类型、阶段唯一key以及放量比例等信息
• DevOps的上下文信息：需求/发布信息、流水线ID等信息
• 风险观测参数：上下游服务、观测时长、通知webhook等信息

这样，一个观测任务就能够精准对应到一次发布、一次特定节点以及一组特定的执行策略，就能够确定整个任务的运行方式和观测内容。

第三个问题是稳定性保障。除了一些必要的中间件/服务监控告警之外，影响整个系统稳定性的，还是producer/consumer和mq这个搭配。这里有几个点需要考虑的：

• 代码：producer/consumer的panic需要recover+ack，防止任务进程中断；channel/singleflight/waitgroup阻塞之类问题需要有重试机制、死信队列兜底，先保证进度信息不丢失再做修复。
• 容量：观测任务的处理延时主要在任务推进，一次任务推进的时间可能很长，兜底需要1～2min的timeout，所以除了对服务有一个合理的定容之外，整个任务推进的逻辑当中，需要把能够开goroutine异步执行的步骤尽可能单独拿出来，优先保证消费延时不要太高。如果遇到一个观测项又有多个子任务需要调度的场景，一个好的方法是把多个子任务调度放到单独的服务中进行，这样不影响主流程；如果是在消费不过来了，也可以通过一些兜底机制，根据任务执行时间或任务重要性，自主适配延长下次consume的间隔，从而减轻自己压力。

总体来看变更风险观测的任务调度，大体设计思路方面不需要做的非常复杂，重要还是去有一套稳定性兜底机制，保证整个生产消费链路能够持续稳定运转。后续有什么额外的经验，再在这里补充～