AWS Serverless应用模型添加对Step Functions状态机的支持

by

• Steffen Opel

摘要：

AWS Serverless应用模型（AWS SAM）最近获得了对AWS Step Functions状态机的支持。新的AWS::Serverless::StateMachine资源类型能够让开发人员在一个SAM模板或单独的文件中定义状态机，这样的话，他们就能够以serverless应用中集成部件的形式提供工作流编排。

AWS Serverless应用模型（AWS Serverless Application Model，AWS SAM）最近获得了对AWS Step Functions状态机的支持。新的AWS::Serverless::StateMachine资源类型能够让开发人员在一个SAM模板或单独的文件中定义状态机，这样的话，他们就能够以serverless应用中集成部件的形式提供工作流编排。

AWS Serverless应用模型是一个开源框架，它提供了一个“简单整洁”的速记语法来扩展AWS的基础设施即代码服务CloudFormation，从而简化serverless应用的构建（我们此前曾经介绍过）。它是伴随AWS SAM CLI一起使用的，该工具最近刚刚正式发布，提供了“一个本地的工具来创建、开发、调试和部署serverless应用”。

AWS Step Functions是一个serverless工作流编排服务，它允许“序列化AWS Lambda函数和多个AWS服务到业务关键型应用中”。Step Functions状态机的执行能够最多运行一年的时间，同时会自动管理状态、错误处理和重试逻辑（我们此前曾经介绍过）。

正如Rob Sutter在他的概述博客文章中所描述的，AWS SAM为Step Functions所提供的支持借助AWS::Serverless::StateMachine资源类型简化了serverless应用中工作流的定义。除了为工作流执行的日志记录或基于事件的触发配置选项提供速写语法之外，它还允许使用SAM策略模板将工作流的权限缩小到仅限于当前应用所使用到的资源。反过来，这能够在通过AWS Serverless Application Repository（我们此前曾经介绍过）部署应用的时候，放弃客户对未限定作用域的IAM权限的确认。

他的样例模板供应了一个DynamoDB表，随后该表被Step Functions状态机通过服务集成引用到PutItem API操作，以便于存储工作流执行的信息，并且会被一个策略模板所引用，这样的话，所有的资源就能以单个应用的形式一起进行供应：

Resources:
  SAMTable:
    Type: AWS::Serverless::SimpleTable
  SimpleStateMachine:
    Type: AWS::Serverless::StateMachine
    Properties:
      Definition:
        StartAt: FirstState
        States:
          FirstState:
            Type: Pass
            Next: Write to DynamoDB
          Write to DynamoDB:
            Type: Task
            Resource: arn:aws:states:::dynamodb:putItem
            Parameters:
              TableName: !Ref SAMTable
              Item:
                id:
                  S.$: $$.Execution.Id
            ResultPath: $.DynamoDB
            End: true
      Policies:
        - DynamoDBWritePolicy: 
            TableName: !Ref SAMTable

注意，状态机可以像上面的样例那样，通过Definition属性在基于SAM的模板的JSON或YAML文件中内联定义，也可以通过DefinitionUri属性，由Amazon S3 URI或本地文件路径来进行定义，如下面的样例所示。DefinitionSubstitutions属性允许声明一个键-值对的map，能够在状态机内用${dollar_sign_brace}符号替换匹配的变量定义：

StockTraderStateMachine:
  Type: AWS::Serverless::StateMachine
  Properties:
    DefinitionUri: statemachine/stockTrader.asl.json
    DefinitionSubstitutions:
      StockCheckerFunctionArn: !GetAtt StockCheckerFunction.Arn
      StockSellerFunctionArn: !GetAtt StockSellerFunction.Arn
      StockBuyerFunctionArn: !GetAtt StockBuyerFunction.Arn
      DDBPutItem: !Sub arn:${AWS::Partition}:states:::dynamodb:putItem
      DDBTable: !Ref TransactionTable

AWS社区英雄Ben Kehoe在tweet上推荐了这种架构选择：

各位，认真听好了，这是一个DSL部署API（CodeBuild、CodePipeline、SSM Automation docs……）应有的运行方式，你在自己的文件中定义内容，然后使用替换功能从模板注入引用。我对这个版本发布超级感兴趣！

AWS::Serverless::StateMachine提供的额外简化就是可以启动工作流执行的事件源的配置以及用于捕获工作执行历史的日志目的地的配置。两者的运行方式在概念上都类似于这些属性如何在其他资源类型中是如何实现的。

在相关的新闻中，AWS团队最近添加了对通过Visual Studio Code“定义、可视化和创建”Step Functions工作流的支持。针对Visual Studio Code的AWS Toolkit最近刚刚具备了通过启动配置调试SAM应用的能力。AWS Step Functions本身最近具备了新的通过AWS CodeBuild进行服务集成的功能，AWS CodePipeline补充了一个新的操作类型以支持通过Step Functions实现复杂的发布流程。这些更新组合在一起，能够让开发人员自动化和定制化他们的软件开发工作流并支持细粒度的持续交付能力，但是这与微软的GitHub Actions有所差异。

相对于AWS SAM，更喜欢Serverless框架的开发人员可以使用Serverless Step Functions插件。微软的Azure也提供了一个设计者优先的声明式开发体验，用来创建和管理Visual Studio Code中的Azure Logic Apps工作流定义。与之不同的是，Azure Durable Functions为有状态工作流提供了一个代码优先的声明式编排。Google Cloud平台的工作流编排服务Cloud Composer构建在开源的Apache Airflow引擎之上，通过基于Python的配置即代码实现命令式的工作流定义。

AWS Serverless应用模型文档提供了一个开发人员指南，包括AWS SAM规范的参考、SAM CLI命令参考和SAM策略模板。它们通过GitHub仓库和Slack频道提供支持。除了供应AWS服务的常规使用定价之外，AWS SAM不收取任何额外费用。

查看英文原文：AWS Serverless Application Model Supports Step Functions State Machines