基于Amazon Serverless 构建零售创新应用
本次 Build On 将教会您如何使用亚马逊云科技各项服务的运用最终实现 Serverless 搭建零售创新应用。
通过实验用户能了解到 Amazon Step Functions 是如何非常便利的编排业务逻辑的,也能了解到 Amazon EventBridge 的整体发布和管理事件的过程,并最终如何通过 Amazon DynamoDB 与Amazon Cognito 来实现零售创新应用场景的完整业务流构建。
零售创新应用2小时内开门!祝你好运!(本实验整体流程预计80分钟-120分钟)
零售创新应用流程如下:
1、头顶显示器显示一个 QR 码,每 5 分钟更改一次。客户扫描此 QR 码以使用他们的移动设备下订单。二维码适用于 5 分钟内的 10 杯饮品,一旦没有更多饮品,二维码就会从屏幕上消失。这有助于防止商家被订单淹没!
2、客户在二维码加载的网络应用程序上下订单。后端验证订单,创建订单号,并将其提供给商家。
3、商家看到订单出现在他们自己的应用程序上。他们可以更改订单的状态,以指示订单的制作时间、完成时间或是否需要取消订单。
4、客户在其移动设备上看到所有商家更新。头顶上的监视器还显示即将到来和已完成的饮料的状态。
接下来您将创建将现有前端与后端无服务器应用程序集成的各种微服务。您将使用 亚马逊云科技 Step Functions
处理编排,使用 Amazon EventBridge
处理编排。
前端已经部署。构建后端后,您将向前端提供环境变量以使它们能够连接。三个前端是:
后端应用程序架构使用Amazon Step Functions、Amazon EventBridge、Amazon Lambda、Amazon API Gateway、Amazon S3、Amazon DynamoDB和Amazon Cognito。
JavaScript
在前端浏览器应用程序中执行,向使用 API Gateway
构建的后端 API
发送和接收数据。DynamoDB
提供 API
使用的持久性数据存储层。使用 Amazon IoT Core
和 Lambda
将事件路由回前端应用程序。
有关完整架构,请参见下图。
模块 | 特征 | 描述 |
---|---|---|
设置 | 设置环境 | 先决条件和要求以及设置 Amazon CloudShell。 |
1a | 构建工作流程 第1部分 | 开始构建 Step Functions 工作流程。 |
1b | 构建工作流程 第2部分 | 完成并测试工作流程。 |
2 | 使用 EventBridge 路由事件 | 使用事件在不同的微服务之间进行通信。 |
3 | 配置前端 | 构建一个服务,通过打开的 websocket 连接将消息发送回前端。 |
本部分介绍如何为研讨会使用或创建 亚马逊云科技
账户、您可以使用哪些 亚马逊云科技
海外区域以及如何设置用于完成模块的操作。
本实验可以在您自己的 亚马逊云科技
账户中运行。为了让您能够参加研讨会,我们需要设置和配置一些 亚马逊云科技
服务。我们已尽可能简单地提供这些服务。
我们将利用 Amazon CloudFormation
,它使我们能够构建我们的基础设施。选择要将模板部署到的首选区域。只需单击启动链接即可在您的帐户中创建堆栈。
点击上面的链接直接生成堆栈
1、输入堆栈名称(或仅保留默认名称)
2、选中功能部分中的框
3、单击创建堆栈
创建完成后,我们就可以正式开始构建工作流程了。
注意:CloudFormation创建后不是立马成功的,需要等到状态为CREATE_COMPLETE才成功,大概3-5分钟
本节介绍如何构建通过生产管理饮料订单的工作流。您将使用 Amazon Step Functions Workflow Studio 以可视方式构建工作流。本部分大约需要 30~45 分钟。
在零售订购应用程序中,每个客户订购都遵循一系列步骤:
每个饮料订单都将在此工作流程的一个单独点中。传统上,在代码中嵌入这种类型的逻辑会导致许多嵌套的逻辑分支,并依赖中央数据库来跟踪状态。处理超时还需要一个单独的过程来对超过其允许时间的工作流采取行动。
这种类型的工作流逻辑是状态机的一个例子。本研讨会使用Amazon Step Functions构建一个状态机,该状态机可以处理给定饮料订单的所有这些不同步骤。每个饮料订单都是状态机的单独执行。无论是每小时喝一杯还是每分钟喝一百杯,Step Functions
都能独立且可靠地维护所有单独的执行,无需复杂的自定义代码。
在本模块中,您将构建 Step Functions
工作流,以跟踪零售店的每个单独订单。
Step Functions
工作流程使用 Amazon
状态语言 (ASL) 定义。ASL
是一种基于 JSON
的结构化语言,用于定义状态机、工作状态的集合(任务状态)、确定要转换到下一个状态的状态(选择状态)、因错误停止执行(失败状态)、等等。工作流是基于 JSON
的文档,您可以将其签入 GitHub
,并使用基础设施作为代码工具(如 Amazon SAM 或 CDK)进行部署。
亚马逊云科技
管理控制台提供了一个名为 Workflow Studio
的可视化构建器工具,它可以帮助简化构建工作流。可视化构建工具后,您可以将其保存在亚马逊云科技的云中以供立即使用,或在 ASL 中导出定义。此模块使用 Workflow Studio
构建工作流。
有关本节中使用的此服务的更多信息:
Amazon Step Functions
中创建一个新工作流。在本节之后,您将拥有一个用于构建应用程序功能的工作流。
步骤说明:
1、转到 Step Functions
控制台。在 亚马逊云科技
管理控制台中,选择Services
,然后选择 应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
2、选择创建状态机。
3、在创建状态机页面上,步骤 1:
4、在步骤 2 中,您使用 Workflow Studio 设计工作流。以下是用户界面的主要区域:
(1) 在此选项卡上,您可以在操作和流程之间进行选择。操作代表您可以对亚马逊云科技服务采取的步骤,例如调用 Amazon Lambda 函数。Flow 显示了管理控制流逻辑的选项,例如选择状态或并行逻辑。
(2) 顶部的工具栏使您可以撤消或重做更改或更改工作流可视化的布局。
(3) 工作流可视化显示当前工作流的流程图。您可以单击此流程中的元素并拖放以进行更改。
(4) 右侧面板显示当前选定元素的选项。在这样的新工作流程中,您可以为整个工作流程设置注释或超时值。
5、选择流
选项卡,然后将Pass状态从左侧菜单拖到工作流可视化中显示将第一个状态拖至此处
的框。选择下一个
6、在检查生成的代码
页面上,这显示了您迄今为止构建的工作流的定义。左侧面板以 JSON 格式显示 Amazon 状态语言 (ASL) 语言定义;右侧显示了工作流的可视化流程图。选择下一步。
7、在指定状态机设置页面上,这显示了新工作流的设置。您也可以稍后编辑这些内容。
(A) 对于Name,输入OrderProcessorWorkflow
。
(B) 对于权限,选择选择现有角色。选择包含-01OrderProcessorRole-
的角色。此角色已为您创建。
检查下,确定您选择了“ 01OrderProcessorRole ”。
(C) 对于Logging
,在下拉菜单中保持OFF。如果您启用此功能,Step Functions
会将执行历史记录记录到 CloudWatch Logs
。
(D) 对于Tracing
,请保持禁用状态。当您启用此选项时,Step Functions
会向 Amazon X-Ray
发送跟踪信息,以帮助在您的工作负载中提供可观察性。
添加名称并设置这些选项后,选择Create state machine
。
恭喜,您已使用 Workflow Studio
设计器创建了您的第一个 Step Functions
工作流!
在本节中,您将测试新的工作流程。
1、在上一部分中,在显示新工作流的页面上,选择启动执行。
2、在启动执行
弹出窗口中,编辑输入 JSON
,使注释值显示为“Hello, world!”
。每次执行都以输入有效负载开始,您将在其中传递有关请求的参数。选择开始执行。
3、执行完成后,控制台显示结果页面。
(1)执行状态显示成功。此面板还有执行的开始和结束时间以及 Amazon 资源名称 (ARN) 参考。
(2)图表检查器显示此执行的流程,流程路径以绿色突出显示,任何错误状态以红色突出显示。您可以选择每个元素并查看输入和输出。
(3)执行事件历史显示执行期间的每个事件和累计经过时间。每个工作流都有一个 ExecutionStarted
事件。这个具有一个通过状态的简单工作流具有 PassStateEntered
和 PassStateExited
事件。单击每个事件旁边的三角形以显示每个事件的输入和输出负载。
在本节之后,您将拥有一个基于商店是否营业的工作流程。
1、转到 Step Functions
控制台。在 亚马逊云科技
管理控制台中,选择Services
,然后选择 应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
2、从左侧菜单中,选择 状态机
并从列表中选择OrderProcessorWorkflow
。选择编辑。
3、在下一页上,选择Workflow Studio
以在设计器中打开工作流。
4、删除上一节添加的通过状态。单击设计器窗口中的状态,然后在工具栏中选择删除。
在本部分中,您将使用 Step Functions
中的直接服务集成从 DynamoDB
表中查询项目。
1、在左侧选中 操作
选项卡后,搜索框中输入DynamoDB
。将 DynamoDB GetItem
操作从列表拖到设计器中的空状态。
2、选中状态后,右侧的属性面板会显示该状态的配置。在配置
选项卡中:
DynamoDB Get Shop status
。DynamoDB
查询:{
"TableName": "serverlesspresso-config-table",
"Key": {
"PK": {
"S": "config"
}
}
}
3、选择输出选项卡。在这里,您将修改状态的输出以包含来自 DynamoDB 查询的结果:
ResultPath
将原始输入添加到输出框。$.GetStore
,然后在值文本框中输入。工作流必须根据从 DynamoDB
表中读取的值来分支逻辑。在本节中,您将添加分支逻辑。
1、从流
选项卡中,将 Choice
状态拖到 DynamoDB GetItem
状态下。
2、在操作
选项卡中,在搜索框中输入EventBridge以过滤 EventBridge 操作。找到 PutEvents 操作并拖动到选择状态下的空规则 #1框。
3、在流
选项卡中,将 Pass
状态拖到选择状态下的 Default
空框。
4、您现在已经定义了一个逻辑分支,其中一个结果路由到 EventBridge
,另一个路由到通过状态。接下来,定义选择状态下的决策逻辑。单击选择状态以在右侧面板中打开其属性。对于 Rule #1
,单击编辑图标。
5、选择添加条件。
6、在规则 #1 的条件面板中,指定将确定商店是否关闭的规则:
$.GetStore.Item.storeOpen.BOOL
。此 JSONPath
语法指定来自 DynamoDB
查询响应的 storeOpen
布尔属性。is equal to
。Boolean constant
,然后选择true作为值。7、对于状态名,添加Shop Open?
8、通过选择设计器上方的定义切换按钮来检查亚马逊状态语言 (ASL) 定义。ASL 显示为:
{
"Comment": "A description of my state machine",
"StartAt": "DynamoDB Get Shop Status",
"States": {
"DynamoDB Get Shop Status": {
"Type": "Task",
"Resource": "arn:aws:states:::dynamodb:getItem",
"Parameters": {
"TableName": "serverlesspresso-config-table",
"Key": {
"PK": {
"S": "config"
}
}
},
"ResultPath": "$.GetStore",
"Next": "Shop Open?"
},
"Shop Open?": {
"Type": "Choice",
"Choices": [
{
"Not": {
"Variable": "$.GetStore.Item.storeOpen.BOOL",
"BooleanEquals": true
},
"Next": "PutEvents"
}
],
"Default": "Pass"
},
"PutEvents": {
"Type": "Task",
"End": true,
"Parameters": {
"Entries": [
{}
]
},
"Resource": "arn:aws:states:::aws-sdk:eventbridge:putEvents"
},
"Pass": {
"Type": "Pass",
"End": true
}
}
}
9、选择应用并退出。
10、在 编辑
页面中,选择 保存
。
11、在 IAM
角色弹出窗口中,选择 仍然保存
。您正在使用的 IAM
角色已部署在设置模块中并具有必要的权限。
在本节中,您将测试新的工作流程。
1、在上一部分中,在显示新工作流的页面上,选择 启动执行。在 启动执行 弹出窗口中,选择 启动执行。
2、执行完成后,控制台显示结果页面。左侧显示执行流程,绿色状态显示实际路径。选择Shop Open?
状态以在右侧显示详细信息。
3、选择右侧的 步骤输入
以查看选择状态的输入路径。在这种情况下,该 storeOpen 属性为 TRUE,导致选择状态选择 Pass 状态。
接下来,您将在允许订单继续之前检查商店容量。
在本节之后,如果有可用容量,您将拥有一个运行的工作流。
在本部分中,您将使用 Step Functions 中的亚马逊云科技开发工具包集成来查询服务。
1、转到 Step Functions
控制台。在 亚马逊云科技 管理控制台中,选择Services
,然后选择应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
2、从左侧菜单中,选择State machine并从列表中选择OrderProcessorWorkflow 。将 ARN 值复制出来- 稍后您将需要此值。选择编辑。
3、在下一页上,选择Workflow Studio
以在设计器中打开工作流。
4、在左侧选择操作
选项卡后,在搜索栏中输入listexecutions
。将 ListExecutions
从列表拖到 Shop Open?
和Pass
中间。
5、选中ListExecutions
后,右侧的属性面板会显示该状态的配置。在配置选项卡中:
ListExecutions
。API Parameters
,粘贴以下 JSON
,替换YOUR_STATE_MACHINE_ARN
为您之前复制的 ARN
。{
"StateMachineArn": "YOUR_STATE_MACHINE_ARN",
"MaxResults": 100,
"StatusFilter": "RUNNING"
}
检查您将YOUR_STATE_MACHINE_ARN替换为正确的 ARN。
6、选择输出选项卡。在这里,您将修改状态的输出以包含 SDK 调用的结果:
ResultPath
将原始输入添加到输出框。$.isCapacityAvailable
。工作流必须根据 ListExecutions SDK 调用返回的值分支逻辑。在本节中,您将添加分支逻辑。
1、从 流
选项卡中,将 Choice
状态拖到 ListExecutions
状态下。
2、您现在已经定义了一个逻辑分支。接下来,定义选择状态下的决策逻辑。单击选择状态以在右侧面板中打开其属性。对于Rule #1,单击编辑图标。选择Add conditions。
3、在规则 #1 的条件面板中,指定将确定商店是否有容量的规则:
$.isCapacityAvailable.Executions[20]
is present
。在继续之前仔细检查 NOT 下拉菜单是否为空白
4、Then next state is
下拉选择EventBridge PutEvents。然后点击关闭
。
5、对于状态名称,输入 Is capacity available?
。
6、通过选择设计器上方的定义切换按钮来检查亚马逊状态语言 (ASL) 定义。ASL 显示为:
{
"Comment": "A description of my state machine",
"StartAt": "DynamoDB Get Shop Status",
"States": {
"DynamoDB Get Shop Status": {
"Type": "Task",
"Resource": "arn:aws:states:::dynamodb:getItem",
"Parameters": {
"TableName": "serverlesspresso-config-table",
"Key": {
"PK": {
"S": "config"
}
}
},
"ResultPath": "$.GetStore",
"Next": "Shop Open?"
},
"Shop Open?": {
"Type": "Choice",
"Choices": [
{
"Not": {
"Variable": "$.GetStore.Item.storeOpen.BOOL",
"BooleanEquals": true
},
"Next": "PutEvents"
}
],
"Default": "ListExecutions"
},
"ListExecutions": {
"Type": "Task",
"Next": "Is capacity available?",
"Parameters": {
"StateMachineArn": "YOUR_STATE_MACHINE_ARN",
"MaxResults": 100,
"StatusFilter": "RUNNING"
},
"Resource": "arn:aws:states:::aws-sdk:sfn:listExecutions",
"ResultPath": "$.isCapacityAvailable"
},
"Is capacity available?": {
"Type": "Choice",
"Choices": [
{
"Variable": "$.isCapacityAvailable.Executions[20]",
"IsPresent": true,
"Next": "PutEvents"
}
],
"Default": "Pass"
},
"PutEvents": {
"Type": "Task",
"End": true,
"Parameters": {
"Entries": [
{}
]
},
"Resource": "arn:aws:states:::aws-sdk:eventbridge:putEvents"
},
"Pass": {
"Type": "Pass",
"End": true
}
}
}
7、选择应用并退出。
8、在 编辑 OrderProcessorWorkflow
页面中,选择 保存
。
9、在 IAM
角色弹出窗口中,选择 仍然保存
。您正在使用的 IAM
角色已部署在设置模块中并具有必要的权限。
在本节中,您将测试对工作流的更改。
1、在上一部分中,在显示新工作流的页面上,选择 启动执行
。在 启动执行
弹出窗口中,选择 启动执行
。
2、执行完成后,控制台显示结果页面。左侧显示执行流程,绿色状态显示实际路径。选择容量可用吗?状态以在右侧显示详细信息。
3、选择右侧的步骤输出以查看选择状态的输出路径。在这种情况下,isCapacityAvailable 属性中的 Executions 数组显示一项。这意味着有一个活动执行,因此有可用容量,导致工作流进入通过状态。
接下来,您将为每次执行添加一个人类可读的订单号。
在本模块中,您:
DynamoDB
和 EventBridge
交互,而无需 Lambda
函数中的自定义代码。在下一个模块中,您将完成工作流程的构建。
在本节中,您将完成工作流程的构建。最后,您将测试工作流程。本部分大约需要 30~45 分钟。
在本节之后,您将拥有一个为订单分配订单号的工作流。
在本部分中,您使用 Step Functions
中的 DynamoDB
集成来增加原子计数器并将该值用作订单号。
转到 Step Functions
控制台。在 亚马逊云科技 管理控制台中,选择Services
,然后选择应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
从左侧菜单中,选择状态机
并从列表中选择OrderProcessorWorkflow 。选择编辑。
3、在下一页上,选择 Workflow Studio
以在设计器中打开工作流。
4、在左侧选择操作
选项卡后,在搜索栏中输入updateitem
。将 Amazon DynamoDB UpdateItem
操作从列表拖到 容量可用吗?
下面,并在设计器中选中该状态。
5、选中后,右侧的属性面板会显示该状态的配置。在配置选项卡中对应配置下面参数:
对于状态名,输入 Generate Order Number
。
对于API 参数,粘贴以下 JSON
:
{
"TableName": "serverlesspresso-counting-table",
"Key": {
"PK": {
"S": "orderID"
}
},
"UpdateExpression": "set IDvalue = IDvalue + :val",
"ExpressionAttributeValues": {
":val": {
"N": "1"
}
},
"ReturnValues": "UPDATED_NEW"
}
6、选择输出
选项卡。在这里,您将修改状态的输出以包含来自 DynamoDB 查询的结果:
ResultSelector
选中转换结果框。{
"orderNumber.$": "$.Attributes.IDvalue.N"
}
ResultPath
将原始输入添加到输出框。$.Order.Payload
7、通过选择设计器上方的定义切换按钮来检查亚马逊状态语言 (ASL) 定义。ASL 显示为:
{
"Comment": "A description of my state machine",
"StartAt": "DynamoDB Get Shop status",
"States": {
"DynamoDB Get Shop status": {
"Type": "Task",
"Resource": "arn:aws:states:::dynamodb:getItem",
"Parameters": {
"TableName": "serverlesspresso-config-table",
"Key": {
"PK": {
"S": "config"
}
}
},
"ResultPath": "$.GetStore",
"Next": "Shop Open?"
},
"Shop Open?": {
"Type": "Choice",
"Choices": [
{
"Not": {
"Variable": "$.GetStore.Item.storeOpen.BOOL",
"BooleanEquals": true
},
"Next": "EventBridge PutEvents"
}
],
"Default": "ListExecutions"
},
"ListExecutions": {
"Type": "Task",
"Next": "Is capacity available?",
"Parameters": {
"StateMachineArn": "YOUR_STATE_MACHINE_ARN",
"MaxResults": 100,
"StatusFilter": "RUNNING"
},
"Resource": "arn:aws:states:::aws-sdk:sfn:listExecutions",
"ResultPath": "$.isCapacityAvailable"
},
"Is capacity available?": {
"Type": "Choice",
"Choices": [
{
"Variable": "$.isCapacityAvailable[20]",
"IsPresent": true,
"Next": "EventBridge PutEvents"
}
],
"Default": "Generate Order Number"
},
"Generate Order Number": {
"Type": "Task",
"Resource": "arn:aws:states:::dynamodb:updateItem",
"Parameters": {
"TableName": "serverlesspresso-counting-table",
"Key": {
"PK": {
"S": "orderID"
}
},
"UpdateExpression": "set IDvalue = IDvalue + :val",
"ExpressionAttributeValues": {
":val": {
"N": "1"
}
},
"ReturnValues": "UPDATED_NEW"
},
"Next": "Pass",
"ResultPath": "$.Order.Payload",
"ResultSelector": {
"orderNumber.$": "$.Attributes.IDvalue.N"
}
},
"EventBridge PutEvents": {
"Type": "Task",
"Resource": "arn:aws:states:::events:putEvents.waitForTaskToken",
"Parameters": {
"Entries": [
{
"Detail": {
"Message": "Hello from Step Functions!",
"TaskToken.$": "$$.Task.Token"
},
"DetailType": "MyDetailType",
"EventBusName": "MyEventBusName",
"Source": "MySource"
}
]
},
"End": true
},
"Pass": {
"Type": "Pass",
"End": true
}
}
}
8、选择应用并退出。在编辑页面中,选择保存。
9、在 编辑 OrderProcessorWorkflow
页面中,选择 保存
。
10、在 IAM
弹出窗口中选择仍然保存。
在本节中,您将测试对工作流的更改。
1、在上一部分中,在显示新工作流的页面上,选择 启动执行
。在启动执行
弹出窗口中,选择 启动执行
。
2、执行完成后,控制台显示结果页面。左侧显示执行流程,绿色状态显示实际路径。选择 Generate Order Number
状态以在右侧显示详细信息。
3、选择右侧的Step 输出以查看选择状态的输出路径。JSON 输出显示了一个 Order 属性,其 Payload 中的 orderNumber 为 1。
4、选择 新执行
并重复步骤 2 和 3。orderNumber 现在为 2。每次运行开始另一个执行时,订单号都会增加。
接下来,您将向工作流添加等待条件,以等待客户提交订单。
在本节之后,您将有一个工作流程,等待客户提供其零售订单的详细信息,然后等待商家下订单。
1、转到 Step Functions
控制台。在 亚马逊云科技 管理控制台中,选择Services
,然后选择应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
2、从左侧菜单中,选择State machine并从列表中选择OrderProcessorWorkflow 。选择编辑。
3、在下一页上,选择 Workflow Studio
以在设计器中打开工作流。
4、在左侧选择操作
选项卡后,在搜索栏中输入putevents
。将 Amazon EventBridge PutEvents
操作从列表拖到容量可用吗?
下方,并在设计器中选中该状态。
5、选中状态后,右侧的属性面板会显示该状态的配置。在配置选项卡中:
Emit - Workflow Started TT
。API
参数,粘贴以下 JSON
:{
"Entries": [
{
"Detail": {
"Message": "The workflow waits for your order to be submitted. It emits an event with a unique 'task token'. The token is stored in an Amazon DynamoDB table, along with your order ID.",
"TaskToken.$": "$$.Task.Token",
"orderId.$": "$.detail.orderId",
"userId.$": "$.detail.userId"
},
"DetailType": "OrderProcessor.WorkflowStarted",
"EventBusName": "Serverlesspresso",
"Source": "awsserverlessda.serverlesspresso"
}
]
}
6、选择输出选项卡。在这里,您将修改状态的输出以包含来自 DynamoDB
查询的结果:
ResultPath
将原始输入添加到输出框。Discard result and keep original input
。7、选择正在处理错误
选项卡。在这里,您添加一个捕获状态来处理任何错误。在捕获错误
中,选择 添加新的捕获器
。
备注
,输入 Customer timed out
。错误
,选择 States.Timeout
。回退状态
,选择添加新状态。8、在错误处理选项卡上,对于心跳,输入300
秒。这意味着如果在 5 分钟内未收到回调,则工作流将超时。
9、选择左侧的 流
选项卡后,将 Pass
状态操作从列表拖到设计器中的空 将状态拖至此处
占位符。
10、选中状态后,右侧的属性面板会显示该状态的配置。
配置
选项卡中,对于 状态名称
,输入 Customer timedout
。输出
选项卡中,对于 结果
,输入"Customer timedout"
(包括引号)。ResultPath
将原始输入添加到输出$.cause
。在本节中,您将添加一个 EventBridge PutEvents
状态,该状态会在回调完成时发出一个事件。工作流在此处等待,直到收到回调。这发生在商家点饮料时。
1、在左侧选择操作
选项卡后,在搜索栏中输入putevents
。将 Amazon EventBridge PutEvents
操作从列表拖到设计器中的 Generate Order Number
和 Pass
状态之间。
2、选中状态后,右侧的属性面板会显示该状态的配置。在配置选项卡中:
Emit-Awaiting Completion TT
。API
参数,粘贴以下 JSON
:{
"Entries": [
{
"Detail": {
"Message": "You pressed 'submit order'. The workflow resumes using the stored 'task token', it generates your order number. It then pauses again, emitting an event with a new 'task token'.",
"TaskToken.$": "$$.Task.Token",
"orderId.$": "$.detail.orderId",
"orderNumber.$": "$.Order.Payload.orderNumber",
"userId.$": "$.detail.userId"
},
"DetailType": "OrderProcessor.WaitingCompletion",
"EventBusName": "Serverlesspresso",
"Source": "awsserverlessda.serverlesspresso"
}
]
}
3、选择输出选项卡。在这里,您将修改状态的输出以包含重新启动工作流的过程(订单)的结果:
ResultPath
将原始输入添加到输出框。$.order
。4、选择错误处理选项卡。在这里,您添加一个捕获状态来处理任何错误。在 捕获错误
中,选择 添加新的捕获器
。
Comment
,输入 Barista timed out
。Errors
,选择 States.Timeout
。Fallback state
,选择添加新状态。ResultPath
,输入 $.comment
。5、在错误处理选项卡上,对于心跳,输入900
秒。这意味着如果在 15 分钟内未收到回调,则工作流将超时。
6、选择左侧的 流
选项卡后,将 Pass
状态操作从列表拖到设计器中的空 将状态拖至此处
占位符。
7、选中状态后,右侧的属性面板会显示该状态的配置。
在 配置
选项卡中,对于 状态名称
,输入 Barista timedout
。
在 Output
选项卡中,对于 结果
,输入 "Barista timedout"
(包括引号)。
选择使用 ResultPath
将原始输入添加到输出
在输入字段中输入 $.cause
。
8、选择应用并退出。在编辑页面中,选择保存。
9、在 IAM角色
弹出窗口中选择仍然保存。
在本节中,您将测试对工作流的更改。
1、在上一部分中,在显示新工作流的页面上,选择 启动执行
。
2、在 启动执行
弹出窗口中,输入以下 JSON
有效负载:
{
"detail": {
"orderId": "1",
"userId": "testuser"
}
}
3、选择启动执行
4、控制台显示 Running
的执行状态。左侧显示执行流程,绿色状态显示实际路径。蓝色状态显示何时暂停执行,等待回调。
5、在执行事件历史记录
面板中,打开 Emit - Workflow Started TT
的 TaskScheduled
事件。这将显示此事件的有效负载。将 TaskToken
的值复制出来,下一步需要使用。
您将使用名为 Amazon CloudShell 的服务,这是一个基于浏览器的 shell
终端,可以轻松安全地管理、探索 亚马逊云科技 资源并与之交互以运行 API 命令。
1、在 亚马逊云科技 管理控制台的搜索栏中输入 CloudShell
,然后从搜索选项中选择 CloudShell
:
2、选择Close
,以超越欢迎警报:
3、在 CloudShell
终端中,输入以下命令,注意替换 YOUR_TASK_TOKEN
令牌值:
aws stepfunctions send-task-success --task-output '{"orderId":1}' --task-token YOUR_TASK_TOKEN
执行继续到等待回调的下一个状态。
4、在 Execution event history
面板中,打开 Emit - Awaiting completion TT
的 TaskScheduled
事件。这将显示此事件的有效负载。将 TaskToken 值复制到便笺簿。
5、使用带有任务令牌的工作流的 SendTaskSuccess API
回调并继续执行。在 CloudShell
终端中,输入以下命令,替换 YOUR_TASK_TOKEN
为令牌值:
aws stepfunctions send-task-success --task-output '{"orderId":1}' --task-token YOUR_TASK_TOKEN
控制台显示工作流的执行现已完成。
heartbeat
属性为每个等待条件设置超时值。接下来,您将修改工作流以在发生重要事件时处理事件。
在本节之后,您将拥有一个发出几个新事件的工作流。
在本节中,您将添加一个 EventBridge PutEvents
状态,该状态在客户或商家订单超时时发出事件。您已经创建了处理超时的逻辑,因此只需要使用 EventBridge
来发出事件。
1、转到 Step Functions
控制台。在 亚马逊云科技 管理控制台中,选择Services
,然后选择 应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
2、从左侧菜单中,选择 状态机
并从列表中选择OrderProcessorWorkflow
。选择编辑。
3、在下一页上,选择Workflow Studio以在设计器中打开工作流。
4、在左侧选择操作
选项卡后,在搜索栏中输入putevents
。将 Amazon EventBridge PutEvents
操作从列表拖到设计器中的客户超时和结束状态之间。
5、选中状态后,右侧的属性面板会显示该状态的配置。在配置选项卡中:
Emit - error timeout
。API
参数,粘贴以下 JSON
:{
"Entries": [
{
"Detail": {
"Message": "The order timed out. Step Functions waits a set amount of time (5 minutes for a customer, 15 minutes for a barista), no action was taken and so the order is ended.",
"userId.$": "$.detail.userId",
"orderId.$": "$.detail.orderId",
"cause.$": "$.cause"
},
"DetailType": "OrderProcessor.OrderTimeOut",
"EventBusName": "Serverlesspresso",
"Source": "awsserverlessda.serverlesspresso"
}
]
}
6、将 Barista
超时传递状态连接到 Emit - error timeout
。选择Barista
超时状态以打开右侧的属性面板。在 Configuration
选项卡中,将 下一个状态
更改为 Emit - error timeout
。
在本部分中,您将添加一个 EventBridge PutEvents
状态,该状态会在订单完成且工作流完成时发出最终事件。
1、在左侧选择操作
选项卡后,在搜索栏中输入putevents
。将 Amazon EventBridge PutEvents
操作从列表拖到设计器中的 Pass
和 End
状态之间。
2、选中状态后,右侧的属性面板会显示该状态的配置。在配置选项卡中:
状态名称
,输入 Emit-order finished
。API
参数,粘贴以下 JSON
:{
"Entries": [
{
"Detail": {
"Message": "The order has reached the end of the workflow, and so a final event is emitted to alert other services to this.",
"userId.$": "$.detail.userId",
"orderId.$": "$.detail.orderId"
},
"DetailType": "OrderProcessor.orderFinished",
"EventBusName": "Serverlesspresso",
"Source": "awsserverlessda.serverlesspresso"
}
]
}
在本节中,您将更新之前创建的 EventBridge PutEvents 状态,以在商店关闭或无法接受新订单时发出事件。
1、选择 Shop open?
和 结束状态之间的 PutEvents
。
2、选中状态后,右侧的属性面板会显示该状态的配置。在配置选项卡中:
状态名称
,输入Emit-Shop not ready
。API
参数,粘贴以下 JSON
:{
"Entries": [
{
"Detail": {
"Message": "The Step functions workflow checks if the shop is open and has capacity to serve a new order by invoking a Lambda function that queries the Shop config service. The shop was not ready, and so a 'not ready' event is emitted to cancel the current order.",
"userId.$": "$.detail.userId"
},
"DetailType": "OrderProcessor.ShopUnavailable",
"EventBusName": "Serverlesspresso",
"Source": "awsserverlessda.serverlesspresso"
}
]
}
选择应用并退出。在编辑页面中,选择保存。
在 IAM 角色
弹出窗口中,选择 仍然保存
。
在本部分中,您将工作流配置为在超时、订单完成或商店因关闭而未准备好接收订单时发出事件。
接下来,您将测试工作流程以查看执行路径如何根据商店状态和商家容量而变化。
在本节之后,您将拥有一个准备好支持饮料订购应用程序的工作流。
首先,在商店打开的情况下测试工作流程,这是运行设置模块时的默认状态。
1、转到 Step Functions
控制台。在 亚马逊云科技 管理控制台中,选择Services
,然后选择 应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
2、在状态机下,选择 OrderProcessorWorkflow
。在显示工作流的页面上,选择 启动执行
。
3、在 启动执行
弹出窗口中,输入以下 JSON
有效负载,然后选择 启动执行
:
{
"detail": {
"orderId": "1",
"userId": "testuser"
}
}
4、图表检查器显示了由于商店打开而采用的工作流路径。
商店的状态存储在应用程序的 DynamoDB
配置表中。店铺开门了吗?transition
检查此值并使用 Step Functions
选择状态来确定流程。在这里,您将切换此状态并运行执行以测试结果。
1、转到 DynamoDB
控制台。在 亚马逊云科技 管理控制台中(新开一个页面),搜索里面输入DynamoDB
,然后选择 DynamoDB
。确保您的地区是弗吉尼亚北部。
2、从左侧菜单中,选择 Tables
菜单中的 Explore items
。在 Tables
列表中选择 serverlesspresso-config-table
。
3、在“返回的项目”面板中选择config
项。这将打开项目编辑器。选择JSON
并禁用 View DynamoDB JSON
。
4、设置商店打开。粘贴以下 JSON
,该 JSON
设置 storeOpen
为false
.
{
"PK": "config",
"storeOpen": false,
"maxOrdersPerUser": 1,
"maxOrdersInQueue": 10
}
5、选择保存更改
以更新表。
6、转到 Step Functions
控制台。在 亚马逊云科技 管理控制台中,选择Services
,然后选择 应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
7、在状态机下,选择 OrderProcessorWorkflow
。在显示工作流的页面上,选择 启动执行
。
8、在 启动执行
弹出窗口中,输入以下 JSON
有效负载,然后选择 启动执行
:
{
"detail": {
"orderId": "1",
"userId": "testuser"
}
}
9、图表检查器显示由于商店关闭而采用的工作流路径。
10、执行已经结束。在执行事件历史记录面板中,为步骤 EventBridge PutEvents
展开类型为 TaskScheduled
的事件。
工作流已发出一个事件,指示商店不可用。这可以由应用程序中的其他微服务使用以采取适当的操作。
11、在 DynamoDB
表中将存储重新设置为“打开”。1. 转到 DynamoDB
控制台。在 亚马逊云科技 管理控制台中,选择 Services
,然后在 数据库
下选择 DynamoDB
。确保您的地区是弗吉尼亚北部。
12、从左侧菜单中,选择 Tables
菜单中的 Explore items
。在Tables
列表中选择 serverlesspresso-config-table
。
13、在返回的项目
面板中选择config
项。这将打开项目编辑器。
14、将商店重新设置为打开状态。粘贴以下 JSON
,该 JSON
设置storeOpen
为 true
.
{
"PK": "config",
"storeOpen": true,
"maxOrdersPerUser": 1,
"maxOrdersInQueue": 10
}
15、选择保存更改以更新表。
您测试了工作流如何响应,具体取决于商店是打开还是关闭。恭喜,您现在已经为应用程序配置了工作流!
接下来,您将设置和配置允许其他微服务对此工作流程中的更改做出反应的事件。
在本模块中:
在下一个模块中,您将使用事件来编排后端的不同部分。
本部分介绍如何使用 Amazon Step Functions
将事件发送到无服务器事件总线。您将了解如何创建事件规则以将事件负载路由到相关的下游服务。这些事件使您的应用程序能够在微服务之间进行通信。
用最简单的术语来说,事件是系统状态发生变化的信号。在亚马逊云科技中,它表示为 JSON 消息,包含一些关于发生了什么变化以及系统当前状态可能是什么的事实。
事件是:
Observable
:微服务可以订阅他们关心的事件。事件是 JSON 消息,其中包含包裹在信封中的消息:
最大消息大小为 256 KB。要了解更多信息,请阅读EventBridge 配额。
在模块 1 中创建的工作流程从头到尾协调各个订单。一些工作流程步骤需要人工交互(例如客户提交他们的饮料订单,或商家接受并完成订单)。
工作流在这些步骤中发出一个事件,然后在继续之前等待响应。事件被发送到无服务器事件总线,并被路由到相关服务。
路由由Amazon EventBridge执行。您将事件发布到总线,订阅者使用规则过滤他们关心的事件。在本模块中,您将在 EventBridge 中创建规则以捕获这些事件并将其路由到相关服务。
EventBridge
让您可以路由来自 亚马逊云科技 服务、自定义应用程序、软件即服务应用程序和微服务的事件。事件被发送到总线,包括您可以专门为您的工作负载设置的自定义总线。然后,亚马逊云科技
服务或微服务等消费者使用规则来过滤他们想要接收的消息。
这是事件驱动架构背后的消息传递。它允许您将事件的生产者和消费者解耦——生产者不知道谁(如果有的话)正在监听他们发布的事件。同样,订阅者不知道是否有其他人在收听,并且他们可能不知道事件的发布者。
这可以更快地开发软件中的新功能,增加可扩展性,并减少开发团队之间的摩擦。
Amazon EventBridge
中创建一个新规则。Amazon CloudWatch Logs
。每个 Serverlesspresso
事件都会发送到名为“Serverlesspresso”
的自定义事件总线。
事件是状态的更改或更新,例如在客户网站上下的订单。事件可以携带状态(订购的物品、其修饰符和用户 ID)或事件可以是标识符(订单已完成的通知)。
事件驱动架构具有三个关键组件:事件生产者、事件路由器和事件消费者。生产者向路由器发布事件,路由器过滤并将事件推送给消费者。生产者服务和消费者服务是解耦的,这使得它们可以独立扩展、更新和部署。
事件本质上是短暂的,这意味着它们在接收时不会被存储。记录事件及其状态以供以后检查和回放通常很有用。
创建一个规则,通过应用程序的自定义总线将每个事件记录到 CloudWatch Logs
。
1、转到 EventBridge
控制台。从 亚马逊云科技 管理控制台中,选择Services
,然后选择应用程序集成
, 在选择Amazon EventBridge
。确保您的地区是弗吉尼亚北部。
2、选择规则。选择创建规则。
3、在步骤的第 1 步中:
logAll
。Serverlesspresso
。4、在步骤的第 2 步中:
{
"source": ["awsserverlessda.serverlesspresso"]
}
5、在步骤的第 3 步中:
Target 1
面板中,选择如下图所示。CloudWatch 日志组
serverlesspressoEventBus
。6、在步骤的第 4 步中,选择 下一步
。
7、在步骤的第 5 步中,检查定义规则详细信息
面板所在的事件总线为Serverlesspresso
。然后选择创建规则
。
在本节中,您将测试该规则是否将所有 Serverlesspresso
事件记录到正确的日志组。您使用模块 1 中的 Step Functions
工作流来生成事件。
2、在 启动执行
弹出窗口中,在 输入
文本框中输入以下 JSON
有效负载,然后选择 启动执行
:
{
"detail": {
"orderId": "2",
"userId": "testuser2"
}
}
3、控制台显示 Running
的执行状态。左侧显示执行流程,绿色状态显示实际路径。蓝色状态显示何时暂停执行,等待回调。
4、在执行事件历史记录
面板中,打开Emit - Workflow Started TT的TaskScheduled事件。这将显示此事件的有效负载。事件详细信息也显示在此处。它包含:
serverlesspresso
awsserverlessda.serverlesspresso
)。DetailType( OrderProcessor.WorkflowStarted)
。由于此事件被发送到 Serverlesspresso
事件总线并包含源awsserverlessda.serverlesspresso
,因此它通过您创建的规则路由到 CloudWatch Logs
。
5、转到 CloudWatch
控制台。在 亚马逊云科技 管理控制台中,选择Services
,然后在管理与监管
中选择 CloudWatch
。确保您的地区是弗吉尼亚北部。
6、从左侧菜单中,选择日志组。选择名为 的日志组/aws/events/serverlesspressoEventBus
。
8、每个事件都记录到单独的日志流中。选择第一个日志流。
9、从 Target(s)
部分中,选择名为 severlesspressoEventBus
的目标,然后选择 Log Stream
部分中的第一行。展开时间戳旁边的箭头。
这会显示所有事件信息,包括 TaskTokenStep Functions
生成的事件detail-type
、事件和事件 source
。
从现在开始,任何 Serverlesspresso
发送到自定义事件总线的事件都将发送到 CloudWatch Logs
并可供检查。
CloudWatch Logs
的包罗万象的规则。CloudWatch Logs
中看到了记录的事件。接下来,您将创建一个将事件从验证器服务路由到订单工作流的规则。
到目前为止,您已经从 Step Functions
控制台 OrderProcessor
手动启动了工作流程。
在生产中,工作流由 Validator
服务生成的事件启动。每次客户扫描二维码时都会发出该事件。
Amazon EventBridge
中创建一个新规则,将 Validator
事件传递到您的 OrderProcessor
工作流程。在本节中,您将构建侦听Validator.NewOrder事件并将其传递给订单工作流目标的规则。
1、转到 EventBridge
控制台。从 亚马逊云科技管理控制台中,选择Services
,然后选择应用程序集成
,再选择 Amazon EventBridge
。确保您的地区是弗吉尼亚北部。
2、选择规则。选择创建规则。
3、在步骤的第 1 步中:
NewOrder
。Serverlesspresso
。4、在步骤的第 2 步中:
{
"detail-type": ["Validator.NewOrder"],
"source": ["awsserverlessda.serverlesspresso"]
}
5、在步骤的第 3 步中:
目标 1
面板中,选择如下图所示Step Functions
状态机OrderProcessorWorkflow
。提示:您可以开始 OrderProcessor
在搜索框中输入内容以查找工作流程。执行角色
,确保选中 为此特定资源创建新角色
。6、在步骤的第 4 步中,选择下一步。
7、在步骤的第 5 步中,检查定义规则详细信息
面板所在的事件总线为Serverlesspresso
。然后选择创建规则
。
在本节中,您将测试在发出 NewOrder
事件时启动 OrderProcessor
工作流的规则。
在 Amazon EventBridge
控制台下,选择事件总线。
选择 Serverlesspresso
事件总线
3、选择发送事件
4、检查是否选择了 serverlesspresso
事件总线
5、将以下内容复制到事件源
中:
awsserverlessda.serverlesspresso
6、将以下内容复制到详细信息类型
中:
Validator.NewOrder
7、将以下内容复制到事件详细信息
中:
{"userId":"1","orderId":"1"}
8、选择发送
这应该创建一个带有确认摘要的事件 ID:
这将在工作流中开始新的执行 OrderProcessor
。
3、从 Amazon Step Functions
控制台中,选择您之前创建的OrderProcessorWorkflow
。您将看到状态为Running的最新执行。
4、从名称列中选择最新的执行。控制台显示Running的执行状态。左侧显示执行流程,绿色状态显示实际路径。蓝色状态显示何时暂停执行,等待回调。
新规则已成功将 NewOrder
事件路由到 OrderProcessor
工作流。在下一步中,您将创建一个将 WorkflowStarted
事件路由到 Amazon Lambda
函数的规则。
QR
码但没有订阅这些事件时向自定义总线发布事件。您创建了一个订阅验证器事件并将流量路由到订单工作流的规则。QR
码来触发 Validator
服务,而是模拟了一个示例事件并使用 CLI
将其发布到自定义事件总线。Validator
事件触发了规则并启动了工作流。接下来,您将创建一个事件,Order Manager
微服务使用该事件来保存订单的详细信息。
内置模块的订单处理器工作流发出 WorkflowStarted
事件。在订单的这一点上,工作流程已检查商店是否营业以及商家是否有能力接受新订单。现在,工作流程最多等待 15 分钟,让客户选择并提交他们的零售订单。这是订单等待人工交互的过程中的第一次。
Step Functions
通过实施等待回调任务令牌模式来做到这一点。它将任务令牌传递给集成服务 ( Amazon EventBridge
)。任务暂停,直到工作流通过SendTaskSuccessorSendTaskFailure
调用接收到该任务令牌。
在下一步中,您将创建接收 WorkflowStarted
包含任务令牌的事件的规则。您将此事件路由到 Amazon Lambda
函数,该函数将令牌与唯一订单 ID 一起保存到 Amazon DynamoDB
表中。
Order Manager
服务跟踪所有单独的饮料订单(例如“Double espresso
”)及其完成状态。商家和客户应用程序使用该服务来获取未结或已完成订单的列表。此服务通过侦听工作流中的事件来保持同步。
在这个部分:
Amazon EventBridge
中创建一个新规则。Amazon Lambda
函数。Lambda
函数输入负载和响应。1、转到 EventBridge
控制台。从 亚马逊云科技 管理控制台中,选择Services
,然后选择应用程序集成
,再选择 Amazon EventBridge
。确保您的地区是弗吉尼亚北部。
2、选择规则。选择创建规则。
3、在步骤的第 1 步中:
WorkflowStarted
。Serverlesspresso
。4、在步骤的第 2 步中:
{
"detail-type": ["OrderProcessor.WorkflowStarted"],
"source": ["awsserverlessda.serverlesspresso"]
}
5、在步骤的第 3 步中:
目标 1
面板中,选择 如下所示Lambda函数
Lambda
函数。这是由设置模块中的核心堆栈部署的。提示:您可以开始在字段中输入“WorkflowStarted
”来查找功能。6、在步骤的第 4 步中,选择下一步。
7、在步骤的第 5 步中,检查定义规则详细信息
面板所在的事件总线为Serverlesspresso
。然后选择创建规则
。
在本部分中,您将测试该规则是否调用 WorkflowStarted Lambda
函数,并检查事件负载和结果。
在 Amazon EventBridge
控制台下,选择事件总线。
选择 Serverlesspresso
事件总线
3、选择发送事件
4、检查是否选择了 serverlesspresso
事件总线
5、将以下内容复制到事件源
中:
awsserverlessda.serverlesspresso
6、将以下内容复制到详细信息类型
中:
Validator.NewOrder
7、将以下内容复制到事件详细信息
中:
{"userId":"1","orderId":"1"}
8、选择发送
您创建的名为 NewOrder
的规则会触发 OrderProcessor
工作流。这反过来将一个 WorkflowStarted
事件发送到 Serverlesspresso
事件总线。
2、转到 CloudWatch
控制台。在 亚马逊云科技 管理控制台中,选择 Services
,然后在 管理与监管
中选择 CloudWatch
。确保您的地区是弗吉尼亚北部。
3、从左侧菜单中,选择日志组。选择名为 的日志组 /aws/events/serverlesspressoEventBus
。
4、显示的两个最新日志流包含两个事件。
5、选择最新的日志流以显示详细信息并展开 Timestamp
列旁边的箭头。这显示了 OrderProcessor.WorkflowStarted
由事件总线处理的事件。
这会显示所有事件信息,包括 TaskTokenStep Functions
生成的事件detail-type
、事件和事件的 source
.
6、新的 WorkflowStarted
规则已将此事件路由到 WorkflowStarted Lambda
函数。此 Lambda
函数将任务令牌写入名为 serverlesspresso -order-table
的 DynamoDB
表。
7、转到 DynamoDB
控制台。在 亚马逊云科技 管理控制台中,选择 Services
,然后在 数据库
中选择 DynamoDB
。确保您的地区是弗吉尼亚北部。
8、在左侧的表格菜单中选择探索项目。选择表。serverlesspresso-order-table
9、在返回的项目
面板中,选择第一个项目以查看其内容。该订单由 Lambda
函数写入 DynamoDB
表。该项目包含 Step Functions TaskToken
、订单 ID (“SK”) 和“ORDERSTATE
”:
当客户从 Customer App
提交饮料订单时,Order Manager
微服务将从 DynamoDB
获取此任务令牌并将其返回给 Step Functions
服务。然后,这将用于恢复该订单的工作流程。
在下一节中,您将看到订单是如何通过名为 OrderManager
的单独工作流程取消、更新和完成的
DynamoDB
表的 Lambda
函数。CLI
中的事件、观察自定义事件总线处理的事件以及验证订单信息是否已写入 DynamoDB
表来进行测试。恭喜!您已配置规则来处理事件并将选定的事件传送到不同的目标。当整个工作负载发生事件时,这会将后端微服务连接在一起。在下一节中,您将使用三个前端应用程序来测试后端。
该 WaitingCompletion
事件由模块 1 中内置的工作流发出OrderProcessor
。此时在订单中,用户已经提交了他们的饮料请求,OrderProcessor
工作流已经生成了一个订单号,并且现在暂停,直到商家完成订单。工作流已发出一个 WaitingCompletion
事件,以及一个TaskToken
用于恢复工作流的新事件。
您现在将创建一个新规则,将此事件路由到 Lambda
函数,该函数将serverlesspresso-order-table
使用新的 TaskToken
、订单号和订单状态更新 。
1、转到 EventBridge
控制台。从 亚马逊云科技 管理控制台中,选择 Services
,然后选择 应用程序集成
下的Amazon EventBridge
。确保您的地区是弗吉尼亚北部。
2、选择规则。选择创建规则。
3、在步骤的第 1 步中:
对于名称,输入 WaitingCompletion
。
对于事件总线,输入 Serverlesspresso
。
选择下一步。
4、在步骤的第 2 步中:
{
"detail-type": ["OrderProcessor.WaitingCompletion"],
"source": ["awsserverlessda.serverlesspresso"]
}
5、在步骤的第 3 步中:
目标 1
面板中,选择如下图所示Lambda函数
函数
下拉列表中,选择名字包含WaitingCompletion
的 Serverlesspresso
函数 。提示:您可以开始在字段中输入“WaitingCompletion”
来查找函数。6、在步骤的第 4 步中,选择下一步。
7、在步骤的第 5 步中,检查定义规则详细信息
面板所在的事件总线为Serverlesspresso
。然后选择创建规则
。
在本节中,您在 Serverlesspresso
事件总线上创建了 4 个 EventBridge
规则。在“规则”页面上,将“事件总线”下拉列表更改为Serverlesspresso
并确认您看到列出的所有 4 条新规则(除了在设置过程中创建的 4 条规则)。
在本节中,您将测试这两个工作流程。OrderProcessor
工作流管理单个饮料订单的整体路径。OrderManager
工作流程处理饮料更新和状态更改。通过与两者进行交互,您可以从头到尾完成订单。
有3个步骤:
本部分在不同的工作流和服务之间移动。要准备,请在浏览器中打开多个选项卡:
Step Functions
控制台并打开OrderProcessorWorkflow
。这是您在模块 1 中构建的工作流程。Step Functions
控制台并打开OrderManagerStateMachine
。此工作流部署在设置模块中。EventBridge
控制台。DynamoDB
控制台。以下说明将使用所有这些选项卡,因此在本节期间将这些选项卡保持打开状态。
首先,创建一个新的工作流执行来模拟由客户扫描二维码引起的订单。
要从 Amazon EventBridge
控制台的 Events
下启动新的工作流程:
1、选择事件总线。
2、选择 Serverlesspresso
事件总线
3、选择发送事件
4、检查是否选择了 serverlesspresso
事件总线
5、将以下内容复制到事件源
中:
awsserverlessda.serverlesspresso
6、将以下内容复制到详细信息类型
中:
Validator.NewOrder
7、将以下内容复制到事件详细信息
中:
{"userId":"1","orderId":"2"}
8、选择发送
9、转到 OrderProcessorWorkflow
选项卡。在 执行
面板中,打开处于 正在运行
状态的最新执行。
3、Workflow
在 WorkflowStarted
状态下暂停。第一个 TaskToken
已保存到 DynamoDB
.
4、转到 serverlesspresso-order-table
。
5、查找SK为“2”的条目。从PK列中选择 Orders
以打开项目详细信息。
6、与唯一的 TaskToken
订单 ID 一起存储在这里。应用程序使用它来稍后恢复工作流程。
在上一节中,您了解了如何使用 OrderManager
工作流来清理、更新、取消订单,并通过返回正确的 TaskToken
.
在这里,您将向饮料订单添加详细信息,模拟客户在客户应用程序中配置他们的订单。为此,您可以运行 OrderManager
工作流来更新 OrderProcessor
状态机。
1、转到 OrderManager
工作流选项卡。
2、选择开始执行。在输入文本区域中输入以下内容并选择 Start execution
:
{"action":"","body":{"userId":"1","drink":"Cappuccino","modifiers":[],"icon":"barista-icons_cappuccino-alternative"},"orderId":"2","baristaUserId":"3"}
3、在此执行的 OrderManager
工作流中,此执行现已完成。
4、在 OrderProcessor
选项卡中,工作流已恢复,允许其进入 TaskToken
下一步。
5、WaitingCompletion
事件被发送到 Serverlesspresso
事件总线。该事件被路由到 WaitingCompletion Lambda
函数,该函数使用新生成的orderNumber
和更新 serverlesspresso -order-table
。TaskToken
6、要验证这一点,请转到 serverlesspresso-order-table
。您可以看到一个新列 orderNumber
,其中包含人类可读的订单号。
7、在 OrderProcessor
选项卡中,工作流在此步骤暂停,直到商家通知应用程序订单已完成。
1、接下来,使用 OrderManager
工作流来模拟商家领取订单。
2、转到 OrderManager
工作流选项卡。
选择开始执行。在输入文本区域中输入以下内容并选择 Start execution
:
{
"action": "make",
"body": {},
"orderId": "2",
"baristaUserId": "3"
}
3、OrderManager
工作流使用商家的订单 ID 更新 DynamoDB
表并发出一个新事件。
最后,使用 OrderManager 工作流程来模拟商家完成订单。
1、转到 OrderManager
工作流选项卡。
2、选择开始执行。在输入文本区域中输入以下内容,然后选择 Start execution
。请注意,输入有效负载包含 action:complete
.
{"action":"complete","body":{"userId":"1","drink":"Cappuccino","modifiers":[],"icon":"barista-icons_cappuccino-alternative"},"orderId":"2","baristaUserId":"3"}
3、OrderManager
工作流更新 DynamoDB
表并恢复 OrderProcessor
工作流:
在 OrderProcessor
选项卡中,执行也完成:
4、在 serverlesspresso-order-table
中,饮料订单已更新,状态为Completed
:
CLI
启动了 OrderProcessor
工作流来模拟新订单的到达。OrderManager
工作流程来模拟客户订单输入和完成订单的商家。DynamoDB
表中看到了持久状态的影响。您已完成工作流的端到端后端测试。在下一个模块中,您将配置一个新规则以将事件路由回前端应用程序。您将能够从前端应用程序运行完整的测试。
这家零售店使用三种不同的前端应用程序来协调商家和顾客之间的订单。在本节中,您将配置前端应用程序以连接到您目前构建的后端,并发送一些测试订单。
前端使客户和商家能够与后端应用程序进行交互。有3个前端应用程序:
在本模块中,您将设置每个前端,以便您可以对后端应用程序执行端到端测试。
现代 Web 应用程序通常使用发布-订阅模式在数据更改时接收通知。从在新电子邮件到达时接收警报到提供仪表板分析,此方法允许来自后端系统的更丰富的事件流。
Serverlesspresso 前端在侦听订单状态的变化时使用此模式。前端通过 Amazon SDK 订阅,然后等待后端发布的消息。SDK 自动管理 WebSocket 连接并处理 Web 应用程序中的许多常见连接问题。消息使用主题进行分类,主题是定义消息通道的字符串。
Amazon IoT Core 服务管理后端发布者和前端订阅者之间的广播。这启用了扇出功能,当多个订阅者正在收听同一主题时会发生这种情况。您可以使用此机制将消息广播到数千个前端设备。对于 Web 应用程序集成,这是实现发布-订阅的首选方式,而不是使用 Amazon SNS。
要了解有关前端和后端之间通信的不同方式的更多信息,请阅读在无服务器 Web 应用程序中管理后端请求和前端通知。
前端是为您托管的,需要配置才能连接到您在本研讨会中部署的后端。所有三个应用程序的设置都是相同的,但您必须单独配置每个应用程序。
您将使用 Amazon CloudShell
运行一些 Amazon CLI 命令,Amazon CloudShell
是一个基于浏览器的 shell 终端,可以轻松安全地管理、探索 Amazon 资源并与之交互。
1、在 亚马逊云科技
管理控制台的搜索栏中输入 CloudShell
,然后从搜索选项中选择 CloudShell
:
2、选择Close,以超越欢迎警报:
3、在 CloudShell
终端中,输入以下命令以检索该 poolId
值:
aws cognito-identity list-identity-pools --max-results 10
4、运行此命令以检索host值:
aws iot describe-endpoint --endpoint-type iot:Data-ATS
将这两个值复制到便笺簿,您将在“显示应用程序”部分中需要它们。
Publisher
微服务通过 EventBridge
规则接收事件,并将这些事件转发到 Amazon IoT Core
中的主题。前端被配置为收听适当的主题。
共有三个主题:
有三个 Lambda
函数和三个 EventBridge
规则,每个都发布到一个单独的主题,并且这些已在设置过程中部署。
Display App
在零售机显示器上运行。它提供了即将到来的和已完成的饮料列表。它还显示客户扫描以开始订单的二维码。这是您将设置的三个前端中的第一个。
此前端已部署并在
https://workshop-display.serverlesscoffee.com/
上以托管 UI 的形式呈现。
大多数前端配置已经为您输入,您必须通过从 Cloud Formation
模板输出中选择显示应用程序 URL 来加载这些配置:
1、在 亚马逊云科技
管理控制台中,搜索“Cloud Formation
”,然后从结果列表中选择“Cloud Formation
”。
2、从堆栈列表中,选择应该命名为serverless-workshop
的核心堆栈。
3、选择输出选项卡。
4、找到名为 DisplayAppURI
的输出并选择预先创建的 URL
,在新选项卡中打开此链接。
5、这将打开显示应用程序 UI,其中预填充了除 2 个之外的所有配置。
CloudShell
中查找设置poolId中的值..CloudShell
中查找设置host中的值。6、选择保存并重新加载。
Serverlesspresso
应用程序支持用户和管理员帐户。管理员帐户可以登录 Display
和 Barista
应用程序,而用户只能登录 Customer
应用程序。在本节中,您将创建一个管理员用户来登录所有应用程序。
1、选择创建帐户选项卡。输入您在研讨会期间可以访问的有效电子邮件以及密码。选择创建帐户
2、输入电子邮件中的验证码,然后选择Confirm
。
3、在单独的浏览器选项卡中,搜索 Cognito
控制台。点击进入
然后选择新界面
选择ServerlesspressoUserPool
。
4、选择 组
选项卡,然后选择 创建组
。
5、在 创建组
页面中,组名
输入 admin
并选择 创建组
。
6、选择用户选项卡,然后选择您已创建的用户。
7、在 组成员资格
中,选择 将用户添加到组
。选择admin
并选择添加。
8、返回显示显示应用程序的浏览器选项卡。使用您创建的用户登录,现在显示显示应用程序。
请注意右上角提供的 4 个管理按钮:
Cognito
用户并返回登录页面。显示的二维码将每五分钟更改一次,并将订单总数限制为屏幕上显示的值(默认为 10)。稍后,在端到端测试中,您将扫描此二维码以开始订购流程。
在浏览器选项卡中保持显示应用程序打开。
接下来,您将设置 Barista 应用程序。
商家应用程序在零售机旁边的平板电脑上运行,由商家操作。它提供了即将到来的订单列表,并使商家能够将收到的订单标记为已完成或已取消。
此前端已部署并在
https://workshop-barista.serverlesscoffee.com/
上以托管 UI 的形式呈现。
1、您可以从 Display App
传输配置,以避免手动输入设置。如果您已配置 Display App
,请在浏览器中切换到该选项卡,或导航至https://workshop-display.serverlesscoffee.com/。选择工具栏中的配置 Barista
应用程序按钮。
2、这将在新窗口中打开 Barista
应用程序配置页面,并将后端设置嵌入到 URL 查询字符串中。
3、选择保存并重新加载。
4、选择登录选项卡。输入您在上一节中配置的帐户的电子邮件和密码。选择登录
5、显示商家应用程序
请注意工具栏上提供的三个管理按钮:
Cognito
用户并返回登录页面。保持 Barista App
在浏览器选项卡中打开。
接下来,您将设置订单应用程序。
客户应用程序在客户的智能手机上运行。当他们第一次使用智能手机扫描二维码时,URL 会将浏览器重定向到此 Web 应用程序。
此前端已部署并在
https://workshop-order.serverlesscoffee.com/
上以托管 UI 的形式呈现。
1、您可以从 Display App
传输配置,以避免在智能手机上手动输入设置。如果您已配置 Display App
,请在浏览器中切换到该选项卡,或导航至https://workshop-display.serverlesscoffee.com/。选择工具栏中的**配置订单应用程序**按钮。
2、这将打开一个包含 QR 码的弹出窗口,它将后端设置嵌入到查询字符串中。
3、在您的智能手机上,使用条形码扫描仪应用程序扫描此 QR 码。这将打开配置设置页面并使用后端设置填充字段。
4、选择保存并重新加载。暂时关闭此选项卡。
您现在已经配置了所有三个 Web 应用程序,并且可以从端到端测试您的工作负载。
是时候使用智能手机使用前端应用程序完成完整的端到端测试了——这一步需要使用 iPhone
或 Android
设备。
1、确保 Display App
和 Barista App
在两个单独的浏览器选项卡中打开。
Display App
为零售机上方的显示器供电。2、打开智能手机上的条形码扫描仪。某些手机型号可能需要使用免费的 QR 扫描仪应用程序,而不是默认的条形码扫描仪。扫描显示应用程序上的二维码。如果由于屏幕处于超时期间而当前未显示条码,请等到计时器结束并且条码重新出现。
3、使用您在上一节中创建的帐户登录应用程序。
4、令牌验证后,选择要订购的饮品,然后选择 Order Now
。
5、验证 Display
和 Barista
应用程序以查看新订单到达。
6、与 Barista
应用程序交互以制作或取消饮料,并注意 Display
和 Customers
应用程序是如何更新的。
7、重复步骤 2-6 下订单并试验应用程序的功能。您还可以导航到 Step Functions
控制台以查看每种零售饮品的工作流程。
到了这里。恭喜! 您已完成 Serverlesspresso
应用程序的端到端后端测试。如果您还有时间参加研讨会,请完成可选模块以将新的微服务添加到为每位客户创建零售旅程报告的应用程序中。
此页面提供了有关清理在前面的模块中创建的资源的说明。在免费套餐下,许多资源不会花费您任何费用,但建议您删除它们。
本次分别需要删除4个规则:NewOrder
、logAll
、WaitingCompletion
、WorkflowStarted
。
NewOrder
1、从 CloudShell
获取本次实验中使用的 NewOrder
规则列表id,并将ID记录下来需要在下个命令使用:
aws events list-targets-by-rule --rule "NewOrder" --event-bus-name Serverlesspresso
2、删除 NewOrder
规则列表id,替换your-id
为上一个命令得到的id值
aws events remove-targets --rule "NewOrder" --ids "your-id" --event-bus-name Serverlesspresso
3、删除规则NewOrder
:
aws events delete-rule --name "NewOrder" --event-bus-name Serverlesspresso
logAll
1、从 CloudShell
获取本次实验中使用的 logAll
规则列表id,并将ID记录下来需要在下个命令使用:
aws events list-targets-by-rule --rule "logAll" --event-bus-name Serverlesspresso
2、删除 logAll
规则列表id,替换your-id
为上一个命令得到的id值
aws events remove-targets --rule "logAll" --ids "your-id" --event-bus-name Serverlesspresso
3、删除规则logAll
:
aws events delete-rule --name "logAll" --event-bus-name Serverlesspresso
WaitingCompletion
1、从 CloudShell
获取本次实验中使用的 WaitingCompletion
规则列表id,并将ID记录下来需要在下个命令使用:
aws events list-targets-by-rule --rule "WaitingCompletion" --event-bus-name Serverlesspresso
2、删除 WaitingCompletion
规则列表id,替换your-id
为上一个命令得到的id值
aws events remove-targets --rule "WaitingCompletion" --ids "your-id" --event-bus-name Serverlesspresso
3、删除规则WaitingCompletion
:
aws events delete-rule --name "WaitingCompletion" --event-bus-name Serverlesspresso
WorkflowStarted
1、从 CloudShell
获取本次实验中使用的 WorkflowStarted
规则列表id,并将ID记录下来需要在下个命令使用:
aws events list-targets-by-rule --rule "WorkflowStarted" --event-bus-name Serverlesspresso
2、删除 WorkflowStarted
规则列表id,替换your-id
为上一个命令得到的id值
aws events remove-targets --rule "WorkflowStarted" --ids "your-id" --event-bus-name Serverlesspresso
3、删除规则WorkflowStarted
:
aws events delete-rule --name "WorkflowStarted" --event-bus-name Serverlesspresso
1、从 CloudShell
获取本次研讨会中使用的堆栈列表:
aws cloudformation list-stacks | grep serverless
2、删除以 开头的每个堆栈serverlesspresso
,替换your-stack-name
为每个堆栈名称:
aws cloudformation delete-stack --stack-name your-stack-name
1、转到 Step Functions
控制台。在 亚马逊云科技
管理控制台中,选择Services
,然后选择 应用程序集成
下的 Step Functions
。确保您的地区是弗吉尼亚北部。
2、选择OrderProcessorWorkflow
,点击删除