SOA专题

在亚马逊云计算平台上使用Camel开发分布式工作流

  工作流从当初单机可视化开发发展到今天云计算时代,流程可定制性和运行时的可伸缩拓展性得到了高度统一与协调。本文演示如何基于Amazon的云平台开发一个工作流系统。

  一个工作流由很多独立任务组成,由动态条件决定的特定顺序执行的任务。经常一个工作流表示一个业务流程,例如一个电子商务商店的订单处理流程。

  亚马逊Web服务提供了各种工具,用于构建分布式和可扩展的工作流应用程序。构建这样的应用程序的方法是使用主题Topic和队列Queue两种不同的连接。然后我们能使用发布/订阅模式这一竞争性消费者或其他机制来扩展我们的应用程序,最简单的应用程的一个类似的快照:

 

  管道中每个步骤中都被队列连接到下一步,每个步骤执行某些动作和需要决定下一个步骤是什么。

  另外使用的SNS/ SQS涉及到一些其他低级别的任务: -

  • 序列化/反序列化的数据
  • 为SQSmessages确保了一致性(FIFO先进先出顺序)
  • 保证消息大小不超过最大值 -
  • 创造某种审计支持 -
  • 订阅者订阅主题,分配权限
  • 在DLQs工作结束时管理它。

   通过使用云计算这些功能可以轻易克服这些技术挑战,留下尽可能多的时间编写提供商业价值的实际代码。

简单的工作流服务SWF

   SWF在另一方面提供了更高级别的API,用于编写分布式的、异步的工作流应用。它可以自动序列化/反序列化数据,管理应用程序状态,提供可审计性,保证强一致性,支持多个版本。最重要的是,它确保了工作流的业务流程和业务逻辑执行分离。任何典型的SWF应用程序有以下组成部分:

   对于SWF而言,工作流其实是一种的模板,描述应该遵循实际流程不同的步骤。工作流的执行也是在这模板中运行。

启动器Starter -流程能够启动,停止和与工作流执行进行交互。

判定器Decider - 即编排orchestrates 和并决定什么是工作流执行的下一步骤。

工人Worker - 一个流程用于执行特定类型的任务。

SWF控制台 - 提供完整的可见性和程序执行的控制。

  一个工作流例子执行可以通过以下步骤:首先启动开始工作流的执行, SWF接收它,询问判定器下一步是什么,然后根据决定将任务传递到一个适当的活动Worker。一旦SWF接受到Worker处理结果,就又询问判定器判断下一个步骤,并根据其响应执行或不执行另一个Worker。这个流程持续到判定器回答工作流完成。

为什么使用Camel?

   亚马逊提供了一个Java客户端访问其SWF服务的,这个客户端是使用元注解标注一个代理类实现的。整个流程都是使用代理类绑定起动器Starter和判定器Decider,但是从Decider到Worker的过程比较麻烦。使用为编排设计的Camel骆驼路由能够为Worker设计一个路由,Camel SWF组件提供这个功能,有两种类型的端点:工作流和活动。

   一个工作流生产者允许使我们能够启动,终止,撤销,取样整个工作流执行历史。下面是生产者如何启动一个工作流执行的例子:

from("direct:start")
      .setHeader(SWFConstants.OPERATION, constant("START"))
      .log("Starting a workflow task ${body}")
      .to("aws-swf://workflow?domainName=demo&workflowList=demo-flow&version=1.0
&eventName=processWorkflows");

  工作流消费者是一个判定器Decider。它接收SWF服务的决策任务,无论这个任务是定期计划执行的活动任务或执行完成的工作流。它是一个无状态的确定性路,其唯一职责就是协调任务:

from("aws-swf://workflow?domainName=demo&workflowList=demo-flow&version=1.0
      &eventName=processWorkflows")
      .log("Received a workflow task ${body}")
      .filter(header(SWFConstants.ACTION).isEqualTo(SWFConstants.EXECUTE_ACTION))
          .to("aws-swf://activity?domainName=demo&activityList=demo-activity
         &version=1.0&eventName=processActivities");

 

   活动端点使我们能够与活动任务进行交互。一个活动生产者用于调度活动任务的,它只能被一个判定器路由(实际上是决定器线程)使用。这是因为只能有一个判定器可以安排活动任务。

  最后,我们还必须提供活动Worker的实现,可以使用活动的消费者创建它。此端点将获得活动任务的SWF文件,执行它们,并返回到SWF的结果。这是实际执行业务逻辑:

from("aws-swf://activity?domainName=demo&activityList=demo-activity&version=1.0
         &eventName=processActivities")
      .log("Received Activity task ${body}")
      .setBody(constant("1"));

  总结,任何SWF应用程序包含一个启动器Stater(流程的生产者)启动执行,判定器(worfklow的消费者)接收决策任务和计划调度安排活动任务Task(这是活动生产者),活动Worker(这是活动的消费者)则是执行的任务的。SWF服务管理这些端点之间的通信是异步,一致性。

 

 

EDA