亚马逊云科技Build On - Serverless搭建零售创新应用学习心得

Build On是什么？

亚马逊云科技开发者Build On是由亚马逊团队策划、开发者社区联合打造的动手实操系列活动。它是以现实技术应用和需求场景为核心，结合时下重点技术领域
与亚马逊云科技的前沿技术方案打造的，面向开发人员、IT技术人员、或技术领域决策者的必备云课程。
2022年亚马逊云科技Build On系列活动将围绕数据、软件、架构、运维和前沿技术领域的核心技术领域展开，旨在通过提供专业技术方向的动手实验、助教指
导、专家答疑等服务，帮助开发者了解相关领域的经典技术框架以及经典案例最佳实践，并最终通过精心设计实验流程环境，由技术专家手把手带领开发者亲自设
计、部署和操作。话题将涵盖云计算入i门基础和应用专业级服务应用，如机器学习、loT技术、Serverless、 基础设施等，覆盖从初创项目到成熟企业的全场景全生命
周期的商业实战案例，无论您是刚接触到云的开发者,还是开发经验丰富的专家，您都将从Build On活动中获得实质性收获。

本次Build On主题 - 基于 Serverless 构建零售创新应用

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

使用 Serverless 架构快速构建零售行业解决方案，让开发者专注于业务代码的同时，能够实时构建应用，使项目快速推向市场降低试错成本，更好地适应用户需求。
Build On活动: https://marketing.csdn.net/p/9e92df6208aa36a1a77baa1f58269cfe
活动链接：https://live.csdn.net/room/csdnnews/0ZwLjrto?spm=1001.2014.3001.5501
实验手册链接：https://pan.baidu.com/s/1-AG3im0xJMFJ7I1Sk0MGWg?pwd=6ez4
提取码：6ez4
复制这段内容打开「百度网盘APP 即可获取」

参与过程

活动实录

之前听说过亚马逊云技术在业内属于执牛耳者，一直想参与体验。参加本次的亚马逊云科技的Build On，是我第一次参加亚马逊云科技的Build On，为此特地注册了亚马逊账号，不过可能是考虑到云服务要根据点击量计费，活动方很贴心的提供了临时账号供参加者使用，相当于免费体验了。

活动先由亚马逊云科技的资深解决方案架构师-郁磊老师来讲解本次活动的主题演讲，EDA（基于事件驱动架构），传统架构事件驱动型架构的区别，消息通过事件总线进行过滤和分发，消费者接收特定消息调用相应工作机制，消息的生产者和消费者互不打扰，这样的好处是实现不同应用模块间的解耦，同时便于应用程序功能扩展。

然后便是介绍Build On的主题，零售创新应用是如何运作的？
1、头顶显示器显示一个 QR 码，每 5 分钟更改一次。客户扫描此 QR 码以使用他们的移动设备下订单。二维码适用于 5 分钟内的 10 杯饮品，一旦没有更多饮品，二维码就会从屏幕上消失。这有助于防止商家被订单淹没！
2、客户在二维码加载的网络应用程序上下订单。后端验证订单，创建订单号，并将其提供给商家。
3、商家看到订单出现在他们自己的应用程序上。他们可以更改订单的状态，以指示订单的制作时间、完成时间或是否需要取消订单。
4、客户在其移动设备上看到所有商家更新。头顶上的监视器还显示即将到来和已完成的饮料的状态。

实操的重点在于订单处理工作流程定义，用到的是事件状态处理机服务Step Function。另外还要搭建基于事件总线的事件规则连接各种服务，使用到亚马逊EventBridge服务。其中OrderManager服务跟踪所有单独的饮料订单及其完成状态。而商家和客户应用程序使用该服务来更新订单状态。此服务通过监听OrderProcessorWorkflow中的事件来保持同步。

活动实操

实操部分由薛东老师讲解，同时CSDN有一个群，是动手实验的，有助教老师发放了实验手册，一拿到实验手册，就开始操作了。资料写的超级详细，对于第一次接触云技术的小白也非常友好，虽然跟不上现场的操作速度，但是根据实验手册的步骤也是一步步做下来了，亚马逊的开发界面非常容易上手，仅有的编程也主要针对基于JSON的消息API，按照手册CTRL+C CTRL+ V就好了，不过要是自己写肯定功力还不够，消化起来还是需要一定时间的。

1. 状态机模拟订单流程

构建订单处理流程OrderProcessorWorkflow，通过可视化流程workflow studio构建，使用亚马逊的各种服务和逻辑根据实际需要搭建，拖拽式的操作，十分的简单方便：

说明
判断开店状态 DynamoDB查询服务
咖啡店关门 产生EventBridge事件
咖啡店是否满负荷 最大20个订单，通过查询状态机数量实现
客户下单 EventBridge事件，需在5分钟产生回调，否则超时；
等待出单 EventBridge事件，需在15分钟回调，否则超时；
订单完成 产生EventBridge事件
订单超时 客户未在5分钟下单或者咖啡师在15分钟内没有出单（后面这种情况现实中好像不太常见），通过EventBridge分发

由于此时还无法调用其他微服务，测试时用到了CloudShell命令行服务，用来模拟客户下单动作事件产生的回调，其中YOU_TASK_TOKEN需要被事件log中task token替换。

aws stepfunctions send-task-success  --task-output '{"orderId":1}' --task-token YOUR_TASK_TOKEN

状态机模拟下单流程！绿色代表整个流程全部跑通。

小结：
1、每一步状态机构建都需要验证，这个过程还是有必要的，容易及时发现问题并及时更正；
2、Workflow Started和Awaiting Completion是两个不同事件，会产生不同的TaskToken，注意区分否则在命令行模拟时出错。

2. 建立事件路由

下面需要建立事件规则，基于事件总线实现OrderWorkflow与其他微服务之间的通讯：
LogAll 将所有事件总线上的事件记录到CloudWatch Log；
NewOrder 将 Validator 事件传递到的 OrderProcessor 工作流程，其中Validator由客户扫描二维码触发；
WorkflowStarted 调用OrderManager服务，使用其Lambda函数将订单信息写入 DynamoDB 表；
WaitingCompletion 调用OderManager服务，使用其Lambda函数创建新的 TaskToken、订单号和订单状态更新。

每个事件包括有事件源（这里是JSON编写的事件模式）和事件目标（可以是Lambda函数或者Step Functions状态机等AWS服务）。测试过程使用EventBridge发送事件，及OderManager状态机验证模拟客户下单，商家接单和完成订单的操作。并利用DymonoDB表单验证数据写入过程。

小结：
通过事件路由，基于事件总线打通OrderWorkflow与其他微服务的通信，完成了OrderWorkflow和OrderManager端对端的验证。

3. 前端配置

最后前端验证是通过一个搭建好的框架，包含有一个前台页面，一个咖啡师页面，一个用户页面，该前端框架托管在服务器上，使用时只需要简单配置一下poolID和host参数就可以了，需要用到CloudShell查询，还是很方便的，另外用到了Amazon Cognito服务配置用户信息。

收获

这次参加活动，真切感受到亚马逊Serverless的强大：基于事件驱动架构最大程度减低微服务之间的耦合，通过EventBridge连接微服务为用戸提供了完美的扩展机制，具有更高的敏捷性，并使用户开发专注于分析自身业务逻辑构建业务流。Serverless 可以利用亚马逊多达200+原生服务构建自己的微服务，像搭积木一样按照自身业务需要构建应用程序，显著降低了一大笔IT基础设施建设和维护成本，从而真正为中小企业创造了弯道超车的机会。
整体活动下来，收获就是既学到了新的技术，还有很棒的奖品。对Serverless技术我想说：Serverless，未来已来。