亚马逊Build On实验心得：基于Serverless构建零售创新应用
前言
博主有幸参加了亚马逊云科技与CSDN联合组织的 BuildOn第三季 动手实验 —— 基于 Serverless 构建零售创新应用，实际上早就对无服务应用开发非常感兴趣，一直苦于没有机会去实践，还有就是云厂商对于这个需要付费，所以作为白嫖党，一直处于劝退状态；这次在CSDN看到亚马逊BuildOn活动的开展，也是第一时间报名参加，希望能够更加完整学习无服务器开发知识，并进行应用。
实验简介
这次实验的主题是：基于Serverless构建零售创新应用
在技术创新的驱动下，传统零售服务业正在数字化转型升级。Build On将带来通过Serverless的事件驱动架构搭建零售行业场景应用，以满足小微企业的转型需求，创造弯道超车的可能。全新的Serverless解决方案基于现有的Amazon Serverless架构，使消费者能够在短短几秒钟内通过手机完成下
单，而无需下载安装应用程序。
使用Serverless架构快速构建零售行业解决方案，让开发者专注于业务代码的同时，能够实时构建应用，使项目快速推向市场降低试错成本，更好地适应用户需求。
实验过程
零售创新应用是如何运作的？
零售创新应用流程如下：
- 头顶显示器显示一个 QR 码，每 5 分钟更改一次。客户扫描此 QR 码以使用他们的移动设备下订单。二维码适用于 5 分钟内的 10 杯饮品，一旦没有更多饮品，二维码就会从屏幕上消失。这有助于防止商家被订单淹没！
- 客户在二维码加载的网络应用程序上下订单。后端验证订单，创建订单号，并将其提供给商家
- 商家看到订单出现在他们自己的应用程序上。他们可以更改订单的状态，以指示订单的制作时间、完成时间或是否需要取消订单
- 客户在其移动设备上看到所有商家更新。头顶上的监视器还显示即将到来和已完成的饮料的状态。
项目应用结构
接下来我们将创建将现有前端与后端无服务器应用程序集成的各种微服务。我们会使用 亚马逊云科技 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基础设施建设和维护成本，从而真正为中小企业创造了弯道超车的机会。