服务
关于
CloudProse博客
无服务器

步骤功能:控制无服务器逻辑

简化对控制无服务器逻辑的理解
卢卡斯·皮尔森(Lucas Pearson)Trek10
卢卡斯·皮尔森(Lucas Pearson) | 2019年9月4日

步进功能非常适合控制长时间运行的无服务器工作流中的流程,但也有局限性。在本文中,我们将探讨使项目更适合Step Functions的原因。

我对Step Functions的最初经验之一是在一个灵活的IoT平台的初稿设计中,该平台具有在AWS 物联网 之上构建的可重用组件。创建成本模型电子表格后,很快就决定将设计更改为仅使用AWS 物联网 核心规则操作。对于此特定用例,将数据流决策保留在AWS 物联网 Core中才有意义。在更轻松的控制与将数据流的成本减少一半之间,这很有意义。那么什么时候才是使用步进功能的合适时间呢?首先,让我们谈谈如何定义阶梯函数。

警告:如果您已经有亚马逊州立语言的经验,那么可以在此处跳过此位

步骤功能使用定义 亚马逊州立语言,它由三个主要状态组成。 亚马逊州立语言的主要三种状态是Task,Choice和Fail。从表面上看,这些很简单,但是可以组成大型工作流,​​并且仍然易于推理。

这是亚马逊州立语言的示例,本质上是JSON。

{ "Comment": "An example of the Amazon States Language using a choice state.", "StartAt": "FirstState", "States": { "FirstState": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FUNCTION_NAME", "Next": "ChoiceState" }, "ChoiceState": { "Type" : "Choice", "Choices": [ { "Variable": "$.foo", "NumericEquals": 1, "Next": "FirstMatchState" }, { "Variable": "$.foo", "NumericEquals": 2, "Next": "SecondMatchState" } ], "Default": "DefaultState" }, "FirstMatchState": { "Type" : "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:OnFirstMatch", "Next": "NextState" }, "SecondMatchState": { "Type" : "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:OnSecondMatch", "Next": "NextState" }, "DefaultState": { "Type": "Fail", "Error": "DefaultStateError", "Cause": "No Matches!" }, "NextState": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FUNCTION_NAME", "End": true } }}

亚马逊州语言概念

步骤功能的用例

这里有一些 用于步骤功能的AWS用例

AWS此处提供的示例很棒,但非常具体。它们有什么共同点?我为“步进功能”发现的一些模式是:

  • 数据流控制
  • 控制失败
  • 需要手动交互的长期工作

给定一个仅适合这些模式之一的用例,您可能能够找到一种成本较低的设计方法,而无需使用“步进功能”。一旦在设计中使用了多个模式,就很有可能使Step功能成为您的最佳选择。让我们更深入地研究这些模式是什么,以便我们在您的用例中识别它们。

数据流控制

这种模式是关于在状态机的控制下进行决策的。让我们看一下由 AWS Step Function用例.

在此示例中,我们看到将照片上传到S3时,会触发Lambda以开始执行步进功能。进入“步骤功能”后,该作业将工作负载分为一个lambda(用于从S3对象提取元数据)和另一个(用于使用Amazon Rekognition用于对象,场景和活动识别)运行。所有这些的结果都存储在DynamoDB中。为什么将工作负载分成可组合的部分如此重要?我们难道不能像将所有这些步骤放到一个函数中一样轻松地将所有这些都放到一个函数中吗?是的,但是我们将失去对代码/功能的流程和可重用性的控制。

提取元数据的Lambda可以在其他项目中使用。我们可以将这种元数据提取视为一种微服务,可以被许多应用程序使用。当我们拥有被视为服务的功能时,那么我们需要胶水将这些服务绑定在一起,该胶水可以是步骤功能。这些服务将失败,我们需要能够从该失败中恢复,从而使我们进入下一个模式。

控制失败

当我们将可重用服务组合在一起以用于多个应用程序时,必然会发生故障。借助AWS Lambda,我们可以在15分钟的运行时间中执行单个函数。我们提供了重试选项,例如“死信队列”,但是如果您的lambda失败或超时时需要根本不同的东西怎么办?如果您知道由于Lambda超时而导致失败,但仍在处理中,则可以继续在AWS Batch上进行处理。这些动作需要编排,而Step Functions非常擅长。它具有用于简单重试和退避重试以及针对发生的故障类型进行分支决策的功能。由于决策确实是力量的来源,因此我建议更深入地研究该语言的功能。

链接到有关处理亚马逊州立语言中的错误的更多详细信息 这里 .

长期运行的工作(尤其是那些需要手动交互的工作)

这种模式很难定义,因为长期运行对不同组织意味着不同的事情。在这种情况下,我真正专注于长时间运行的含义,而不是在单个Lambda(15分钟超时)中可以运行的含义,而且还可能需要人工交互。某些重要的流程只是不能由软件来决定(或至少尚未决定)。我为此找到的一个例子是 员工晋升流程。我们仍然希望这种过程能够由人类完成。给出的示例可以在最终决定之前通过自动化流程给出。该过程可能有许多自动化步骤,这些步骤会使员工走上晋升道路。对于使用AWS的人员,可以通过一项新的认证来启动此认证,并且可以自动对其进行检查,但最终由经理决定。该经理的互动可能看起来像上面链接中给出的手动批准过程。请记住,Step Function调用最多可以持续1年。其他限制请看 这里 .

提示

  • 对于较大的有效负载,请对资源使用ARN,而不要对资源本身使用ARN。一个示例是使用S3对象(文件)的ARN而不是文件中的数据。
  • 使用重试进行错误处理时,您可以具体说明错误并以不同的方式处理不同的类型。
  • 在价格来自的阶梯函数中,注意通过状态机进行的转换数量。不允许过多的重试或不必要的过渡,否则步进功能将很快变得非常昂贵。

现在我知道

下次当您为无服务器项目寻找编排工具时,请考虑“步骤功能”。您可以问问自己:

  1. 我是否在尝试通过功能或流程系统来控制数据流?
  2. 我是否需要通过重试甚至开始一个完全不同的过程来控制故障?
  3. 最后,我要长时间运行的整个过程吗? (不仅是15分钟以上)是否需要长达几个月或长达一年的运行时间,并且在此期间需要手动交互?

如果您对以上多个AWS Step Functions中的一个以上的回答为“是”,则可能是该项目所需的工具。

作者
卢卡斯·皮尔森(Lucas Pearson)Trek10
卢卡斯·皮尔森(Lucas Pearson)