亚马逊Build On实验心得：基于Serverless构建零售创新应用

前言

博主有幸参加了亚马逊云科技与CSDN联合组织的 BuildOn第三季 动手实验 —— 基于 Serverless 构建零售创新应用实际上早就对无服务应用开发非常感兴趣一直苦于没有机会去实践还有就是云厂商对于这个需要付费所以作为白嫖党一直处于劝退状态这次在CSDN看到亚马逊BuildOn活动的开展也是第一时间报名参加希望能够更加完整学习无服务器开发知识并进行应用。

实验简介

这次实验的主题是基于Serverless构建零售创新应用

在技术创新的驱动下传统零售服务业正在数字化转型升级。Build On将带来通过Serverless的事件驱动架构搭建零售行业场景应用以满足小微企业的转型需求创造弯道超车的可能。全新的Serverless解决方案基于现有的Amazon Serverless架构使消费者能够在短短几秒钟内通过手机完成下
单而无需下载安装应用程序。

使用Serverless架构快速构建零售行业解决方案让开发者专注于业务代码的同时能够实时构建应用使项目快速推向市场降低试错成本更好地适应用户需求。

实验过程

零售创新应用是如何运作的

零售创新应用流程如下

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 Step Functions Workflow Studio 以可视方式构建工作流

可以看到左边侧边栏主要展示可以编排的组件每个组件都是具有原子性地可以跟据自身的应用程序逻辑进行组合编排就和搭积木一样快速构建应用。

期间不是有订单数据的产生吗

我们不需要自己去维护数据库状态直接可以进行数据库组件编排在订单的生成过程中我使用 Step Functions 中的 DynamoDB 集成来增加原子计数器并将该值用作订单号非常的方便。

亚马逊为了保证服务间的耦合降到最低服务与服务间的通信都是通过事件的形式进行交互的在 Amazon EventBridge 控制台下有一个事件总线我们所有的服务都可以通过创建的事件总线进行业务协作重点也是异步的可以大大提高程序效率。

最后后端配置好之后前端把host等配置成功了既可直接使用了因为前端是托管在亚马逊的效果如下

实验心得体会

参加完这场实验我感觉我的传统开发思想已经被颠覆了从一开始的低代码平台到现在的无服务器架构研发的方式越来越现代化现代应用的组件也越来越多样化我们如今站在巨人的肩膀上可以对更多的中小企业提供更高质量的服务在这次实验中让我最直接的感受就是一切皆资源我们不管做什么都是围绕目标进行拆解和组合业务研发也是一样我们把各类数据库、Web Service、Web Logic 都可以看作是一种资源而作为研发就是要快速、稳定、安全地将这些资源组合在一起创造一个新的资源如何快速、稳定和安全的创造资源是我们需要解决的一个问题得益于亚马逊的技术沉淀和解决方案让没有深度研发经验的普通开发者也能体会到极致的软件开发。

亚马逊serverless与其他厂商有什么不一样

作为开发者更应该客观看待新的技术在我进行学习 serverless 时我也发现这项技术并非银弹它对我来说也有局限性首先我先从serverless的优缺点分析一下

优点

• 降低成本: 因为我们只需要为的代码实际运行的时间付费, 因此可以有效降低计算成本。
• 更快的开发周期: 开发人员可以更快地构建和部署应用程序, 因为他们不必担心底层基础架构的配置和管理。
• 更好的可扩展性: 在使用serverless架构时, 应用程序可以自动扩展以响应增加的流量, 这使得应用程序能够应对突发流量。

缺点

• 复杂性: 虽然serverless架构可以简化开发人员的工作, 但是它也可能带来更多的复杂性, 尤其是当尝试在不同的云服务提供商之间迁移时。
• 性能问题: 在某些情况下, serverless架构可能会导致性能问题, 因为它需要时间来启动新的实例以响应流量。
• 更高的延迟: 由于serverless架构需要时间来启动新的实例, 因此在某些情况下可能会导致更高的延迟。
  适用场景:

Serverless架构通常用于轻量级的后端任务, 如数据处理, 媒体转换和事件处理。 它们通常适用于具有突发流量的应用程序, 因为它们可以自动扩展以应对增加的流量。 Serverless架构也适用于快速构建和部署小型应用程序或微服务, 因为它们可以简化开发人员的工作流程。

总之, serverless架构在某些情况下可能是一种有效的云计算选择, 但它并不适用于所有情况。 在决定是否使用serverless架构时, 我们应该考虑我们的特定业务需求和应用程序的性质, 以及serverless架构的优缺点。

亚马逊serverless和阿里云serverless的区别

在阿里云推出serverless服务时我也体验过实际上我在使用阿里云serverless时并没有很大的感受因为这些云厂商都围绕着同一个目的进行研发解决相同的问题大同小异罢了但是每个平台对业务的侧重点都不一样阿里云感觉没有特别看着serverless工作流服务我在创建demo时并没有看到很多的可编排组件实际上也很正常目前serverless还处于发展阶段还是需要不断地去实验、去完善以达到真正的企业级应用。

实验总结

第一次参加这种线上实验活动感觉非常开心我不但完成了对一个陌生领域的学习并且应用也对现代化应用开发方法有了全新的认识切身感受了大厂云服务的技术站在巨人的肩膀上进行研发不得不感慨亚马逊Serverless的强大基于事件驱动架构最大程度减低微服务之间的耦合通过EventBridge连接微服务为用戸提供了完美的扩展机制具有更高的敏捷性并使用户开发专注于分析自身业务逻辑构建业务流。Serverless 可以利用亚马逊多达200+原生服务构建自己的微服务像搭积木一样按照自身业务需要构建应用程序显著降低了一大笔IT基础设施建设和维护成本从而真正为中小企业创造了弯道超车的机会。