【前言】
1、什么是Build On？
Build On是亚马逊团队基于亚马逊云服务开发，打造的一系列可快速上手的实操性活动。通过通俗易懂的场景案例、简单快捷的开发路径，参与者可快速理解目标任务涉及的相关知识，同时对亚马逊云服务具备一定的认知。
Build On活动至今已举办至第三期，每期的形式均为理论知识介绍加实践操作，整个实验长度大约需要3~4小时，实操部分有操作手册进行指导，有助教随时进行问题解答。只要有耐心，任何新手均可快速上手。
2、本次的任务目标是什么？
本次活动的主题为基于Serverless快速搭建零售创新应用。实操案例采用的是快速搭建一个线上咖啡点单系统，包括用户端、商家端和商户取餐显示大屏端。
通过此次实验，参与者可以了解到如何使用亚马逊云科技中的各项服务实现Severless快速搭建零售新应用。
【背景知识】
使用事件驱动的架构（EDA）构建新应用程序
1 耦合
耦合在应用程序中无处不在，在传统架构下，由于耦合性太强，导致即使是小的任务目标的变更实现起来也相当复杂。在事件驱动的架构中，通过各个任务模块的解耦，可以减少任务任务中的耦合性，进而减少应用更新的难度。
耦合的种类：
-
技术依赖性：Java vs C++
-
地址依赖性： IP地址、DNS
-
数据格式依赖性：二进制、XML、JSON、ProtoBuf、Avro
-
数据类型依赖性：int16、int32、string、UTF-8、null、empty
-
语义依赖性：名称、中间名、邮编
-
时序依赖性：同步、异步
-
交互方式依赖性：消息、RPC、查询风格（GraphQL）
-
对话依赖性：分页、缓存、重试
2 事件驱动架构方案
事件驱动方案的主要特征有三部分：分别为解耦和分散应用程序组件、连接微服务和协调数据流。
事件驱动架构存在三要素分别为：
- 事件的生产者：生产事件
- 事件的收集者：存储和过滤，路由事件
- 事件的消费者：处理事件
事件驱动的优势：解耦、异步和削峰。
在传统架构中，当增加新功能时，如为购物系统增加积分功能时，在传统架构中需要考虑积分服务的上下游耦合信息，在开发积分新功能的同时，需要同时变更原有系统。
在事件驱动型的架构中，为购物系统增加积分功能时，由于信息流的传递由总线机制进行了解耦，只需要专注于积分功能本身的开发，不会对原有系统造成影响。
3 基于亚马逊云服务实现事件驱动架构方案
亚马逊云服务中含有200+种服务可以生产事件，同时支持自定义事件，通过亚马逊云服务可以快速实现事件驱动架构方案。一种常用的事件驱动架构搭建方案如图。
【开始实验】
1 实验目标程序功能
- 吧台上方显示器显示一个QR码，每5分钟更改一次。用户使用手机扫描此QR码进行下单。吧台的产能限制为每5分钟制作10杯饮品，一旦在5分钟内订单超过10杯，则QR码消失，防止商家被订单淹没。
- 用户在扫描QR码进入的程序下单咖啡，后端进行订单验证，创建订单号后提供给商家。
- 商家端显示用户的订单，商家可以修改订单的状态，指示订单的制作时间、完成时间或是否需要取消订单。
- 客户在手机上可以看到商家的状态更新。吧台上方的显示器显示即将到来和已完成的订单状态。
2 实验流程
项目的前端程序已经部署，本次实验需要构建后端并将后端与前端程序进行连接。
前端程序包含显示应用程序、商家应用程序和订购应用程序。后端程序应用架构使用Amazon Step Functions、Amazon EventBridge、Amazon Lambda、Amazon API Gateway、Amazon S3、Amazon DynamoDB和Amazon Cognito进行搭建。
完成架构如下图：
在实验过程中，通过可视化模块进行流程搭建，并且每一步执行均可以从下图的流程图中查看执行进程。
3 实验结果
商家端：
商家页面显示订单接收详情，可以进行订单状态更改，商家开始制作时可以点击下图中的Make，则商品进入制作状态，制作完成后点击Pickup按钮，则商品进入可提货状态。
吧台大屏幕端：
吧台大屏幕正在制作的订单和可以领取的订单，左侧的二维码为点单二维码，可以扫描进行点单。
带二维码的图片发出后显示图片违规，此处不添加效果图了。实际样式参考肯德基吧台上方的点单大屏幕。
用户端：
用户扫描大屏幕上的二维码进入下图所示的程序，点击页面图标即可下单，下单后页面会进行咖啡状态更新，根据指示等待咖啡制作完成进行领取。
【后记】
通过本次实验可直观地感受到使用亚马逊云服务实现Serverless搭建零售创新应用的快捷性和便利性，可对微服务领域和亚马逊的相关服务形成基本的认识。
