亚马逊云科技 Build On -轻松搭建咖啡点单系统

【前言】

1、什么是Build On？
通俗来讲，就是为了宣传Amazon云服务产品而打造的一个项目。不过由于这个项目质量做得实在不错，因此也可以作为一个非常适合学习的动手试验课程。这波Amazon和学生双赢。
详细来说，Build On是亚马逊团队基于亚马逊云服务开发，打造的一系列可快速上手的实操性活动。通过通俗易懂的场景案例、简单快捷的开发路径，参与者可快速理解目标任务涉及的相关知识，同时对亚马逊云服务具备一定的认知。
Build On活动至今已举办至第三期，每期的形式均为理论知识介绍加实践操作，整个实验长度大约需要3~4小时，实操部分有操作手册进行指导，有助教随时进行问题解答。只要有耐心，任何新手均可快速上手。

2、为什么要参加Build On活动？
第一个原因是Amazon的李沐老师。作为Amazon的首席科学家，李沐老师技术逻辑非常清晰同时非常和蔼可亲，从此之后对于Amazon的活动非常感兴趣。

第二个原因是在研究生期间，由于在做人工智能方向的研究，实验室资源师兄师弟轮流用，实在是捉襟见肘。因此经常需要用到（白嫖）一些云资源，Amazon对于学生具有免费试用的资格，在研究生期间提供了不少的帮助。

第三个原因是在创业的朋友的亲身体验。有位朋友在创业时购买了亚马逊的云服务，在企业使用方面，亚马逊云服务相来说并不是价格最优惠的，但总体使用下来却是性价比最高的。根据朋友的体验，虽然之前选用的一家云服务价格相对优惠，但每次发生问题时，解决问题总是非常拖沓。而Amazon提交问题后很快就会有专人解决，最终算起来还替朋友节约了成本。

3、本次的任务目标是什么？
本次活动的主题为基于Serverless快速搭建零售创新应用。实操案例采用的是快速搭建一个线上咖啡点单系统，包括用户端、商家端和商户取餐显示大屏端。通过此次实验，参与者可以了解到如何使用亚马逊云科技中的各项服务实现Severless快速搭建零售新应用。
新零售领域的新手也不要担心，博主本人在人工智能、IoT和计算机视觉领域有一些经验，但新零售还是第一次接触，动手实践之前主讲老师的讲解足够你了解这个领域的基础背景知识了。而且实验手册可真是太详细了，比课后题答案都详细。
直播回顾传送门：https://live.csdn.net/room/csdnnews/8heG73pP

【背景知识】

以下介绍可以让你3分钟看懂Serverless（不是）。以下是在系统结构方面的基础知识，简单来讲，传统架构由于耦合性高导致在产品开发过程中牵一发而动全身，很难进行敏捷开发，从而催生了事件驱动架构的诞生。而Amazon是在事件驱动架构搭建的佼佼者。

使用事件驱动的架构（EDA）构建新应用程序

1 耦合

耦合在应用程序中无处不在，在传统架构下，由于耦合性太强，导致即使是小的任务目标的变更实现起来也相当复杂。在事件驱动的架构中，通过各个任务模块的解耦，可以减少任务任务中的耦合性，进而减少应用更新的难度。
耦合的种类：

技术依赖性：Java vs C++
地址依赖性： IP地址、DNS
数据格式依赖性：二进制、XML、JSON、ProtoBuf、Avro
数据类型依赖性：int16、int32、string、UTF-8、null、empty
语义依赖性：名称、中间名、邮编
时序依赖性：同步、异步
交互方式依赖性：消息、RPC、查询风格（GraphQL）
对话依赖性：分页、缓存、重试

2 事件驱动架构方案

事件驱动方案的主要特征有三部分：分别为解耦和分散应用程序组件、连接微服务和协调数据流。

事件驱动架构存在三要素分别为：

事件的生产者：生产事件
事件的收集者：存储和过滤，路由事件
事件的消费者：处理事件

事件驱动的优势：解耦、异步和削峰。
在传统架构中，当增加新功能时，如为购物系统增加积分功能时，在传统架构中需要考虑积分服务的上下游耦合信息，在开发积分新功能的同时，需要同时变更原有系统。

在事件驱动型的架构中，为购物系统增加积分功能时，由于信息流的传递由总线机制进行了解耦，只需要专注于积分功能本身的开发，不会对原有系统造成影响。

3 基于亚马逊云服务实现事件驱动架构方案

亚马逊云服务中含有200+种服务可以生产事件，同时支持自定义事件，通过亚马逊云服务可以快速实现事件驱动架构方案。一种常用的事件驱动架构搭建方案如图。

【开始实验】

1 实验目标程序功能

简单来说就是实验一个类似于肯x基的一个点单系统，该系统包括用户端、商家端和店面吧台的大屏幕。下面进行任务拆解：

吧台上方显示器显示一个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按钮，则商品进入可提货状态。

吧台大屏幕端：
吧台大屏幕正在制作的订单和可以领取的订单，左侧的二维码为点单二维码，可以扫描进行点单。
带二维码的图片发出后显示图片违规，此处不添加效果图了。实际样式参考肯x基吧台上方的点单大屏幕。
用户端：
用户扫描大屏幕上的二维码进入下图所示的程序，点击页面图标即可下单，下单后页面会进行咖啡状态更新，根据指示等待咖啡制作完成进行领取。

【总结】

Amazon云服务的优势不仅在于产品开发极致，同时社区建设和产品活动也非常用心。有工作经验的小伙伴应该明白这对于一个项目一个团队来说是一个多么理想又多么难以达到的状态。
首先从产品本身来说，Amazon平台具有模块化、可视化和低代码的特点。就这些特点而言，Amazon服务非常适合创新型企业使用。

模块化：系统的前端后端，前后端中的各项小功能均为独立模块，各模块的耦合性很小，能够实现单模块的改动几乎不影响其他模块的功能。任何模块开发完成后均可以自由接入系统的任何部分。
可视化：亚马逊云服务中内置了丰富的功能模块，并进行了可视化。整个咖啡流程点单系统均可以通过拖动模块的方式进行搭建。系统的运行流程在网页端进行可视化展现，便于随时定位程序运行问题。整个咖啡点单系统可以实现几乎0代码搭建。
低代码：通过类似搭积木的方式，用户可以在2~3个小时内实现整个系统的搭建调试。

相对而言，国内的几家云服务厂商在服务的易用性上尚未投入太多。就个人的体验而言，在使用国内的云服务时，组件丰富性很少，距离低代码的目标还很遥远。可能对于大型企业来说，可以投入大量的专业人才进行开发维护，从而忽略云服务的易用性特性。但对于中小型企业、创新类企业和学生、研究人员来说，Amazon云服务是更好的一个选择。

其次从社区建设来说， Amazon的技术社区建设让Amazon的各项服务拥有多种实际案例应用，如果你向开发一个功能，完全可能在官网找到一个符合你需求的现成的应用。同时，李沐老师这样的CTO主动走向台前为Amazon代言，退一万步讲，如果Amazon的服务让你不爽而又没有人理你，你甚至可以去直接戳他们的CTO。（当然这种情况基本不可能发生）

在研究生期间，我试用过国内的几家主流云服务厂商，也体验过一些小型的云服务厂商。不能说国内的云服务不好，只能说各具特色。国内的几家巨头对于学生也有特殊优惠，也能够试用（白嫖）。但在使用体验方面Amazon是明显好一些的。首先服务的稳定性、速度几家巨头都是可以得到保障的，但在云服务使用时的交互性、组件和案例的丰富性等方面国内的厂商依然存在一些差距。

总结：对于程序员来说，Talk is cheap，Show me your code。反正大家都有免费试用啦，不如都去试试，别人说得好不如自己用着好！