Cloud Design Pattern - Scheduler Agent Supervisor (调度代理主管模式)

1.前言

上一篇我们讨论了云计算设计模式之运行时配置模式,了解了如何设计一个支持运行时修改系统配置的系统架构,从而提升系统高可用性.这一篇我们讨论下分布式任务处理系统中的任务调度,监测,异常处理等问题。

2.概念

调度主管模式需要处理的事项包括:

1）协调分布式环境中的服务（Service）或者资源（Resource）协同工作;

2）能够独立处理任务（Job）执行过程中的异常;

3）当某个任务执行失败时,能够执行回滚措施让系统恢复到一致性的状态;

实现这三个目标就能够通过内部非正常执行时的事务回滚和重做机制来为系统增加弹性机制,提升系统的可靠性,对调用者来说,就是提高了高可用性。

3.问题域

一个应用包含多个步骤的任务,其中的某些任务会调用远程服务或者资源,每一个步骤都是可以单独运行的,但是这些任务只有按照应用既定的顺序执行才能得到正确的结果.正常情况下应用应该可以侦测到一系列任务执行的状态,尤其是任务执行失败的状态,这时候应用应该可以采取相应的恢复机制-重做或者回滚.

4.解决方案

调度代理模式定义了如下角色:

1）调度者（ Scheduler）.调度者安排各个步骤的执行顺序,总体工作是协调任务的工作。这些任务可以被组织成管道（pipeline）或者工作流（workflow）,调度者的职责就是确保管道或者工作流中的任务按照既定的顺序正确的执行。调度者需要记录每个任务在管道中执行的状态信息。状态信息应该包括任务执行的时间的上限阀值及任务执行的起止时间.当任务需要与远程服务及资源交互时,调度者需要调用合适的代理（下面会介绍）,并把需要执行的动作交给代理,代理负责与远程资源交互,然后把返回的结果交给调度者,调度者把结果返回给具体的任务.通常调度者和代理的通信是采用异步的request\response message方式进行。

提醒:与此模式非常类似的一种模式:Process Manager,实际的工作流定义在独立的工作流引擎中,工作流引擎可以被调度者调用.这种方式将工作流中的业务逻辑解耦出来,这种方式更加灵活。

2）代理（Agent）.代理封装了访问一个步骤涉及到的远程服务和远程资源的逻辑,并且实现了异常处理机制及Timeout机制.如果工作流中的多个步骤需要调用多个远程服务或者资源,那么每个步骤会调用自己对应的代理。

3）监管者（Supervisor）监测调度者所调度的任务（JOB）的状态.监管者监测运行过程中的问题,并且调用何时的代理去重试或者做事务回滚.注意:通常由调度程序和代理来执行恢复或补救操作.

下图展示了该模式的机制:

在实际运行过程中,可能会有很多的调度者在并行运行,系统可以运行多个代理的实例,即使是多个监管者。这时候就必须要考虑这些实例之间的协调问题了.可以参考我们之前讨论的领导选拔模式.值得注意的是,监管者需要建立一种机制来防止错误的Task被不停地retry,这时候可以设定一个retry count,当超过retry conunt之后或者timeout，就不再执行retry操作,并别给相应的人发送通知.管理者可以给调度者发送一个消息来实现整个事务回滚,回滚的方式就是我们之前讨论的事务回滚模式。回滚要求每个步骤都必须包含回滚的命令操作。

5.值得考虑的方面

1）测试复杂性。由于对于每一种情形都提供测试case会非常繁琐,所以测试机制必须健全;

2）重试或者事务回滚机制的实现会很复杂.

3）监管者角色执行的频率需要考量.

4）管道中的JOB是幂等性的,允许多次执行对结果无影响.

6.相关阅读

The following patterns and guidance may also be relevant when implementing this pattern:
1）Retry Pattern. An Agent can use this pattern to transparently retry an operation that accesses a remote service or resource, and that has previously failed, in the expectation that the cause of the failure is transient and may be corrected.
2）Circuit Breaker Pattern. An Agent can use this pattern to handle faults that may take a variable amount of time to rectify when connecting to a remote service or resource.
3）Compensating Transaction Pattern. If the workflow being performed by a Scheduler cannot be completed successfully, it may be necessary to undo any work it has previously performed. The Compensating Transaction pattern describes how this can be achieved for operations that follow the eventual consistency model. These are the types of operations that are commonly implemented by a Scheduler that performs complex business processes and workflows.
4）Asynchronous Messaging Primer. The components in the Scheduler Agent Supervisor pattern typically run decoupled from each other and communicate asynchronously. The Asynchronous Messaging primer describes some of the approaches that can be used to implement asynchronous communication based on message queues.
3）Leader Election Pattern. It may be necessary to coordinate the actions of multiple instances of a Supervisor to prevent them from attempting to recover the same failed process. The Leader Election pattern describes how this coordination can be achieved.

The post Cloud Architecture: The Scheduler-Agent-Supervisor Pattern on Clemens Vasters' blog.
The Process Manager pattern on the Enterprise Integration Patterns website.
An example showing how the CQRS pattern uses a process manager is available in Reference 6:A Saga on Sagas (part of the CQRS Journey guidance) on the MSDN website.
The Scheduler page on the Azure website.