亚马逊云科技 Build On - 2022年第三季主题：基于 Serverless 构建零售创新应用
亚马逊云科技 Build On - 2022年第三季主题：基于 Serverless 构建零售创新应用
- 一、Build On是什么?
- 二、2022年第三季主题-基于 Serverless 构建零售创新应用
- 三、使用事件驱动的架构（EDA）构建新应用程序
-
-
- 3.1. 有关耦合的方方面面
- 3.2. 事件驱动架构提供解决的方案
-
- 3.2.1 时间驱动架构的优点：
- 3.2.2 事件驱动型架构的三要素
- 3.2.3 事件驱动型架构的好处
- 3.2.4 传统架构
- 3.2.5 事件驱动型架构
- 3.3 Amazon支持的云原生事件生产者
- 3.4 事件收集
-
- 3.4.1 事件的收集需求分为两部分：
- 3.4.2 通过EventBridge 集成：接受、过滤、转换、路由和交付事件
- 3.5 事件消费者
-
- 3.5.1 Amazon EventBridge 目标
- 3.5.2 使用Amazon Serverless 构建事件消费者
- 3.6 总结：通过事件驱动架构解耦解决了应用可靠性和可扩展性问题
- 3.7 创建事件驱动的 Serverless 架构应用
- 3.8 利用 Amazon Serverless 开启EDA创新
-
- 四、实验介绍-Build On基于Serverless构建零售创新应用
-
-
- 4.1 本次实验将要使用的亚马逊云科技服务
- 4.2 本次实验的内容
-
- 4.2.1 设置-预先部署的核心资源
- 4.2.2 模块1：建立工作流程
- 4.2.3 模块2：路由事件
- 4.2.4 模块3：配置前端程序
-
- 五、实验过程及结果展示
-
- 5.1 应用实现流程
- 5.2 应用架构
-
- 5.2.1 前端
- 5.2.2 后端
- 5.3 设置实验环境
- 5.4 构建工作流程 - 第1部分
-
- 5.4.1 创建 Step Functions 工作流
- 5.4.2 商店开门了吗？
- 5.4.3 有容量吗？
- 5.4.4 第1部分总结
- 5.5 构建工作流 - 第2部分
-
- 5.5.1 添加订单号
- 5.5.2 等待订单
- 5.5.3 处理事件
- 5.5.4 测试
- 5.5.5 第2部分总结
- 5.6 路由事件
-
- 5.6.1 创建“全部记录”规则
- 5.6.2 新订单
- 5.6.3 工作流程开始
- 5.6.4 等待完成
- 5.6.5 端到端测试
- 5.7 配置前端
- 5.8 显示应用
- 5.9 商家应用程序
- 5.10 客户应用程序
- 5.11 端到端测试
- 5.12 清理资源
- 六、本次线上直播及实验收获
一、Build On是什么?
亚马逊云科技开发者 Build On 是由亚马逊团队策划、开发者社区联合打造的动手实操系列活动。它是以现实技术应用和需求场景为核心，结合时下重点技术领域与亚马逊云科技的前沿技术方案打造的，面向开发人员、IT技术人员、或技术领域决策者的必备云课程。
2022年亚马逊云科技 Build On 系列活动将围绕数据、软件、架构、运维和前沿技术领域的核心技术展开，旨在通过提供专业技术方向的动手实验、助教指导专家答疑等服务，帮助开发者了解相关领域的经曲技术框架以及经曲宰例最佳实践，并最终通过精心设计实验流程环境，由技术专家手把手带领开发者亲自设计、部署和操作。话题将涵盖云计算入门基础和专业级服务应用，如机器学习、loT技术、Serverless 等，覆盖从初创项目到成熟企业的全场景全生命周期的商业实战案例。无论您是刚接触到六的开发者，还是开发经验丰富的专家，您都将从 Build On 活动中获得实质性收获。
二、2022年第三季主题-基于 Serverless 构建零售创新应用
随着我国经济的快速发展，在技术创新的驱动下，传统快消服务业正在数字化转型升级。本季 Build On 将为您带来通过 Serverless 的事件驱动架构搭建快消行业场景应用，以满足小微企业的转型需求，创造弯道超车的可能。全新的 Serverless 解决方案基于现有的 Amazon Serverless 架构，使消费者能够在短短几秒钟内通过手机完成下单，而无需下载安装应用程序。
使用无服务器架构快速构建新零售行业解决方案，让开发者专注于业务代码的同时，能够实时构建应用，使项目快速推向市场降低试错成本，更好地适应用户需求。
三、使用事件驱动的架构（EDA）构建新应用程序
本部分主要讲解 Serverless的相关知识、整体实验内容和使用到的产品技术共三个板块。
3.1. 有关耦合的方方面面
（1）耦合：系统之间、模块与模块之间的相互关系
耦合很重要：没有耦合，模块与模块之间很难互动、很难产生调用的关系
耦合很复杂：耦合有各种各样的形态、耦合节点特别多
（2）耦合类型：
| 耦合类型 | 实例 |
|---|---|
| 技术依赖性 | Java vs. C++ |
| 地址依赖性 | IP地址、DNS |
| 数据格式依赖性 | 二进制、XML、JSON、ProtoBuf、Avro |
| 数据类型依赖性 | int16、int32、string、UTF-8、null、empty |
| 语义依赖性 | 名称、中间名、邮编 |
| 时序依赖性 | 同步、异步 |
| 交互方式依赖性 | 消息、RPC、查询风格（GraphQL） |
| 对话依赖性 | 分页、缓存、重试 |
| …… | …… |
关于更多耦合类型，请点击直链访问学习
3.2. 事件驱动架构提供解决的方案
3.2.1 时间驱动架构的优点：
- 解耦和分散应用程序组件
- 连接微服务
- 协调数据流
3.2.2 事件驱动型架构的三要素
- 事件的生产者：生产事件
- 事件的收集者：存储、过滤、路由（转发）事件
- 事件的消费者：处理事件
事件本身：概括总结为系统状态的一次改变或更新
下图举例：
3.2.3 事件驱动型架构的好处
- 解耦
- 削峰
- 异步
3.2.4 传统架构
上游服务直接调用下游服务
3.2.5 事件驱动型架构
通过事件触发服务
3.3 Amazon支持的云原生事件生产者
200多项Amazon 服务可以生产事件，同时支持自定义的事件
3.4 事件收集
3.4.1 事件的收集需求分为两部分：
- 事件路由：过滤和路由事件并将事件推送给订阅的消费者
- 事件存储：消费者可以从中提取事件的队列或事件流
3.4.2 通过EventBridge 集成：接受、过滤、转换、路由和交付事件
3.5 事件消费者
3.5.1 Amazon EventBridge 目标
3.5.2 使用Amazon Serverless 构建事件消费者
3.6 总结：通过事件驱动架构解耦解决了应用可靠性和可扩展性问题
- 事件获取：抽象生产者和消费者
- 异步事件：提高响应能力、减少依赖
- 事件存储：记录并缓冲消息，直到服务可用于处理
3.7 创建事件驱动的 Serverless 架构应用
优点：使您的应用程序能够无缝扩展以处理几乎任何需求
- 按点击量付费
- 最小的运营开销
3.8 利用 Amazon Serverless 开启EDA创新
Serverless针对事件驱动架构有哪些好处：
| 优点 | 具体说明 |
|---|---|
| 更高的敏捷性 | 无需管理基础架构、200+原生集成、Lambda 功能扩招、容器镜像支持 |
| 完美的扩展机制 | 自动扩展、高可用性、支持10GB /tmp存储、预置并发 |
| 最低的投入 | 以毫秒为最小计费单位、更低的TCO、可灵活使用Saving Plan，以进一步降低成本 |
| 端到端的Serverless服务堆栈组合 | 全面的服务套件 |
四、实验介绍-Build On基于Serverless构建零售创新应用
本部分主要介绍根据教程，构建一个无服务器架构的Serverless的网上咖啡店的应用
4.1 本次实验将要使用的亚马逊云科技服务
| 分类 | 组件 |
|---|---|
| 开发者工具 | Amazon Management Console、Amazon CloudShell |
| 本次研讨会的重点 | Amazon EventBridge、Amazon Step Functions |
| 部署核心模板 | Amazon Lambda、Amazon API Gateway、Amazon S3、Amazon Simple Notification Service（SNS）、Amazon IoT Core、Amazon DynamoDB |
| 组件 | 功能 |
|---|---|
| Amazon Management Console | |
| Amazon CloudShell | |
| Amazon EventBridge | 事件完成：驱动、接收、分发 |
| Amazon Step Functions | 流程编辑工具，图形化展示流程 |
| Amazon Lambda | Serverless的函数工具，将函数逻辑通过编码方式写在Lambda里面，通过事件触发执行 |
| Amazon API Gateway | 网关服务，暴露在互联网，用户通过http请求方式触发事件，API Gateway后端可以对接Lambda等无服务器服务、执行、并向web请求者返回结果 |
| Amazon S3 | 对象存储的服务 |
| Amazon Simple Notification Service（SNS） | 通知消息的引擎 |
| Amazon IoT Core | 与IoT设备对接服务 |
| Amazon DynamoDB | 无服务器架构的SQL数据库引擎，重要的持久化的信息（比如：订单）通过DynamoDB数据引擎向其他的服务进行传递 |
4.2 本次实验的内容
今天的实验内容
- 设置
登录到您的预配置的亚马逊云环境- 模块1：建立工作流程
建立订单处理工作流程，通过生产管理饮料订单- 模块2：路由事件
创建事件规则以在微服务间路由事件- 模块3：配置前端程序
配置前端应用程序，以连接到您到目前为止建立的后端，并发送些测试订单
4.2.1 设置-预先部署的核心资源
登录到您的预配置的亚马逊云环境
4.2.2 模块1：建立工作流程
建立订单处理工作流程，通过生产管理饮料订单
4.2.3 模块2：路由事件
创建事件规则以在微服务间路由事件
4.2.4 模块3：配置前端程序
配置前端应用程序，以连接到您到目前为止建立的后端，并发送些测试订单。
前端应用程序：
- 订购应用程序
- 显示应用程序
- 咖啡师应用程序
五、实验过程及结果展示
本部分主要是根据实验手册动手实验，基于Amazon Serverless构建一个无服务器架构的网上咖啡店的应用，以下对关键节点进行记录，最终成功进行咖啡下单。
5.1 应用实现流程
零售创新应用实现流程如下：
- 头顶显示器显示一个 QR 码，每 5 分钟更改一次。客户扫描此 QR 码以使用他们的移动设备下订单。二维码适用于 5 分钟内的 10 杯饮品，一旦没有更多饮品，二维码就会从屏幕上消失。这有助于防止商家被订单淹没！
- 客户在二维码加载的网络应用程序上下订单。后端验证订单，创建订单号，并将其提供给商家。
- 商家看到订单出现在他们自己的应用程序上。他们可以更改订单的状态，以指示订单的制作时间、完成时间或是否需要取消订单。
- 客户在其移动设备上看到所有商家更新。头顶上的监视器还显示即将到来和已完成的饮料的状态。
5.2 应用架构
使用 亚马逊云科技 Step Functions 处理编排
使用 Amazon EventBridge 处理编排。
5.2.1 前端
三个前端（前端已经部署）：
- 显示应用程序：这显示在头顶监视器上。它提供条形码供客户扫描下订单，并显示即将到来和已完成的饮料订单的实时队列。
- 商家应用程序：这在商家使用的平板电脑上运行。该应用程序允许商家更改饮料订单的状态，或在需要时取消订单。此应用程序的更新会传播到其他应用程序。
- 订购应用程序：客户使用此应用程序下订单。它旨在在移动设备上运行。当进行测试时，将使用带有此应用程序的移动设备下订单。
5.2.2 后端
依据下图完整架构进行构建：
5.3 设置实验环境
使用提供的亚马逊云科技帐户，创建堆栈，启动 Amazon CloudFormation 模块。
注意：CloudFormation创建后不是立马成功的，需要等到状态为CREATE_COMPLETE才成功，大概3-5分钟
创建完成后，我们就可以正式开始构建工作流程了。
5.4 构建工作流程 - 第1部分
本节介绍如何构建通过生产管理饮料订单的工作流。将使用 Amazon Step Functions Workflow Studio 以可视方式构建工作流。
5.4.1 创建 Step Functions 工作流
使用 Workflow Studio 创建应用程序的工作流
5.4.2 商店开门了吗？
- 修改工作流程以检查零售店是否营业并采取相应措施
- 测试新的工作流程并查看输入和输出负载
- 结束后：将拥有一个基于商店是否营业的工作流程
在这种情况下，该 storeOpen 属性为 TRUE，导致选择状态选择 Pass 状态。
5.4.3 有容量吗？
- 修改工作流程以检查零售店的队列是否有能力接受另一个订单
- 添加一个状态来检查打开的工作流的总数是否高于可配置的最大值
- 测试新的工作流程并查看输入和输出负载
- 结束后：如果有可用容量，将拥有一个运行的工作流
在这种情况下，isCapacityAvailable 属性中的 Executions 数组显示一项。这意味着有一个活动执行，因此有可用容量，导致工作流进入通过状态。
5.4.4 第1部分总结
- 在 Amazon Step Functions 中创建了一个新工作流。
- 通过使用选择状态逐步将分支逻辑添加到工作流。
- 使用直接服务集成与 DynamoDB 和 EventBridge 交互，而无需 Lambda 函数中的自定义代码。
5.5 构建工作流 - 第2部分
本节将完成工作流程的构建
5.5.1 添加订单号
- 修改工作流程并为每个零售订单添加订单号。
- 在 DynamoDB 表中添加一个递增计数器值的状态，并将其用于当前执行。
- 测试新的工作流程并查看输入和输出负载。
- 结束后：拥有一个为订单分配订单号的工作流。
选择右侧的Step 输出以查看选择状态的输出路径。JSON 输出显示了一个 Order 属性，其 Payload 中的 orderNumber 为 1。
5.5.2 等待订单
- 修改工作流程以等待客户提交他们的零售订单。
- 修改工作流程以等待零售订单。
- 测试新的工作流程并查看输入和输出负载。
- 结束后：将有一个工作流程，等待客户提供其零售订单的详细信息，然后等待商家下订单。
为客户订单添加回调状态
5.5.3 处理事件
- 对于超时，更改工作流程以发出有关订单超时的信息。
- 订单完成后，将添加一个事件。
- 如果商店尚未准备好接收订单，将修改工作流程以发出事件。
- 测试新的工作流程并查看输入和输出负载。
- 结束后：拥有一个发出几个新事件的工作流。
5.5.4 测试
- 在商店打开和关闭的情况下测试工作流，以在工作流中遵循不同的执行路径。
- 通过启动多次执行并观察容量超出商店可以处理的容量来测试商店容量功能。
- 结束后：拥有一个准备好支持饮料订购应用程序的工作流。
图表检查器显示了由于商店打开而采用的工作流路径
图表检查器显示由于商店关闭而采用的工作流路径。
5.5.5 第2部分总结
- 完成了工作流程的构建。
- 添加了增量订单计数器和等待人工操作的状态。
- 测试了最终的工作流程以查看不同的执行路径。
5.6 路由事件
本节使用 Amazon Step Functions 将事件发送到无服务器事件总线。
5.6.1 创建“全部记录”规则
- 创建一个规则，通过应用程序的自定义总线将每个事件记录到 CloudWatch Logs。
- 通过运行模块 1 中的工作流生成了一个测试事件，并在 CloudWatch Logs 中看到了记录的事件
5.6.2 新订单
- 在 Amazon EventBridge 中创建一个新规则，将 Validator 事件传递到 OrderProcessor 工作流程。
- 通过模拟从验证器服务发送的事件来测试新规则。
新规则已成功将 NewOrder 事件路由到 OrderProcessor 工作流
5.6.3 工作流程开始
- 在 Amazon EventBridge 中创建一个新规则。
- 配置新规则以调用 Amazon Lambda 函数。
- 测试新规则并查看 Lambda 函数输入负载和响应。
当客户从 Customer App 提交饮料订单时，Order Manager 微服务将从 DynamoDB 获取此任务令牌并将其返回给 Step Functions 服务。
5.6.4 等待完成
创建一个新规则，将此事件路由到 Lambda 函数，该函数将serverlesspresso-order-table 使用新的 TaskToken、订单号和订单状态更新 。
在 Serverlesspresso 事件总线上创建了 4 个 EventBridge 规则。
5.6.5 端到端测试
测试这两个工作流程：
- OrderProcessor 工作流管理单个饮料订单的整体路径。
- OrderManager 工作流程处理饮料更新和状态更改。
通过与两者进行交互，可以从头到尾完成订单。
有3个步骤：
- 创建新的饮料订单。
- 将饮料详细信息添加到订单中。
- 完成订单
在 OrderProcessor 选项卡中，执行也完成：
在 serverlesspresso-order-table 中，饮料订单已更新，状态为Completed
5.7 配置前端
配置前端应用程序以连接到目前构建的后端，并发送一些测试订单。
使用已部署托管的UI前端，直接使用。
5.8 显示应用
请注意右上角提供的 4 个管理按钮：
- 配置商家应用程序：在本节后面使用它来将设置传输到商家应用程序。
- 配置订单应用程序：在本节后面使用它来将设置传输到订单应用程序。
- 清除设置：清空本地设置缓存并清除后端设置。这会导致在下次重新加载页面时显示“设置”页面。如果想更改后端设置，请使用此选项。
- 退出：从前端退出 Cognito 用户并返回登录页面。
显示的二维码将每五分钟更改一次，并将订单总数限制为屏幕上显示的值（默认为 10）。稍后，在端到端测试中，将扫描此二维码以开始订购流程。
在浏览器选项卡中保持显示应用程序打开。
5.9 商家应用程序
请注意工具栏上提供的三个管理按钮：
- 打开商店：这会在打开和关闭之间切换商店打开状态。当商店关闭时，订单应用程序无法下任何新订单。
- 清除设置：清空本地设置缓存并清除后端设置。这会导致在下次重新加载页面时显示“设置”页面。如果想更改后端设置，请使用此选项。
- 退出：从前端退出 Cognito 用户并返回登录页面。
保持 Barista App 在浏览器选项卡中打开。
5.10 客户应用程序
客户应用程序在客户的智能手机上运行。当他们第一次使用智能手机扫描二维码时，URL 会将浏览器重定向到此 Web 应用程序。
5.11 端到端测试
是时候使用智能手机使用前端应用程序完成完整的端到端测试了——这一步需要使用 iPhone 或 Android 设备。
验证 Display 和 Barista 应用程序以查看新订单到达。
到了这里。恭喜！ 已完成 Serverlesspresso 应用程序的端到端后端测试。
5.12 清理资源
清理在前面的模块中创建的资源。在免费套餐下，许多资源不会花费任何费用，但建议删除它们。
六、本次线上直播及实验收获
- 学习现代化应用开发方法与最佳实践
- 掌握 Serverless 架构应用的完整构建技能
- 体验 Amazon Step Functions 可视化工作流服务带来的便利
- 感受Amazon EventBridge, Amazon Lambda, Amazon API Gateway 带来的全新架构升级
- 获取完整应用案例全套代码及实验手册
- 全程动手实验录屏记录，作为学习的成果输出记录，用于后续技术再学习。