本文仅代表个人观点，旨在分享技术，如出现错误望各位大佬多多见谅。

一、Serverless为什么出现？

原因

       Serverless的出现是零售电商类的企业日益增多，原有的电商平台的开发模式逐渐受到挑战，随着用户的激增和订单量的变大，系统的运维成本逐渐占据了小微企业的成本的大头，更别提硬件方面的维护和一系列人员成本。拥有庞大用户量的大厂同样面临着运维成本大，增量迭代复杂的问题。

解决方法

       为此Serverless的解决方案是，将原本企业自主运维的，负责分发路由或者做缓存消息队列的中间服务器全交由云服务器统一，云服务器厂商向企业提供资源服务，整体开发架构由原来的mvc式的模式变为了以事件驱动的架构，极大程度上降低了人员成本以及运维成本，进一步提高了企业效率以及应用的性能。

二、Build On是什么?

       亚马逊云科技开发者 Build On 是由亚马逊团队策划、开发者社区联合打造的动手实操系列活动。它是以现实技术应用和需求场景为核心，结合时下重点技术领域与亚马逊云科技的前沿技术方案打造的，面向开发人员、IT技术人员、或技术领域决策者的必备云课程。 

       本季 Build On 为您带来正是通过 Serverless 的事件驱动架构搭建快消行业场景应用，以满足小微企业的转型需求，创造弯道超车的可能。全新的 Serverless 解决方案基于现有的 Amazon Serverless 架构，使消费者能够在短短几秒钟内通过手机完成下单，而无需下载安装应用程序。
使用无服务器架构快速构建新零售行业解决方案，让开发者专注于业务代码的同时，能够实时构建应用，使项目快速推向市场降低试错成本，更好地适应用户需求。

 三、使用 Amazon Serverless 构建零售创新应用

本部分主要根据 Build On 活动的直播内容，向大家讲解Serverless相关知识

 实验场景

（1）利用Amazon Step Functions 编排业务逻辑的

（2）利用 Amazon EventBridge 的整体发布和管理事件的过程

（3）通过 Amazon DynamoDB 与Amazon Cognito 来实现零售创新应用场景的完整业务流构建。

实验运作模式

零售创新应用流程如下：
（1）头顶显示器显示一个 QR 码，每 5 分钟更改一次。客户扫描此 QR 码以使用他们的移动设备下订单。二维码适用于 5 分钟内的 10 杯饮品，一旦没有更多饮品，二维码就会从屏幕上消失。这有助于防止商家被订单淹没！

（2）客户在二维码加载的网络应用程序上下订单。后端验证订单，创建订单号，并将其提供给商家。

（3）商家看到订单出现在他们自己的应用程序上。他们可以更改订单的状态，以指示订单的制作时间、完成时间或是否需要取消订单。

（4）客户在其移动设备上看到所有商家更新。头顶上的监视器还显示即将到来和已完成的饮料的状态。

前端 

前端已经部署。构建后端后，您将向前端提供环境变量以使它们能够连接。三个前端是：

• 显示应用程序：这显示在头顶监视器上。它提供条形码供客户扫描下订单，并显示即将到来和已完成的饮料订单的实​​时队列。
• 商家应用程序：这在商家使用的平板电脑上运行。该应用程序允许商家更改饮料订单的状态，或在需要时取消订单。此应用程序的更新会传播到其他应用程序。
• 订购应用程序：客户使用此应用程序下订单。它旨在在移动设备上运行。当您今天进行测试时，您将使用带有此应用程序的移动设备下订单。

后端 

后端应用程序架构使用Amazon Step Functions、Amazon EventBridge、Amazon Lambda、Amazon API Gateway、Amazon S3、Amazon DynamoDB和Amazon Cognito。

具体架构如图

设置实验环境 

 使用或创建亚马逊云科技账户于完成模块的操作。

注：CloudFormation创建后不是立马成功的，需要等到状态为CREATE_COMPLETE才成功，大概3-5分钟 

  

构建工作流程 

后续工作流程详见实验手册 

链接: https://pan.baidu.com/s/1WMJGj7wUF_VH4RogHFBl8A?pwd=hmjf 提取码: hmjf 复制这段内容后打开百度网盘手机App，操作更方便哦

实验结果

商户管理页面

​​​​​​​

 

 用户界面

 咖啡师界面 

 

 四、对活动的建议

这是我个人参加的第一次亚马逊的Build On活动，整体体验下来确实可以称得上是科技盛宴，但还是有一些建议要提

（1）线下活动太少了，只在北京、上海、深圳几个沿海城市举办，确实那里开发者多，但中国内陆像重庆、成都这类城市随着国家政策的倾向也产生了不少优秀企业和开发者，不应该只在沿海地区。

（2）实现过程太过冗杂并且一些说明不详，对有开发经验的从业者还好，对初学者和一些学生很容易导致做了一半 不知道自己在干嘛，完全失去了活动的初衷，我们实验的目的是为了更加了解Amazon Serverless的架构和开发模式不是单纯为了实验。

（3）直播讲解Amazon Serverless时没有讲解具体成效，如成本降低百分之多少、性能提升了多少、减少了多少人员成本......

（4）活动时间太短了，就两天时间账号也就两天时间，很多功能没有及时去了解账号过期了。

 四、总结

       本次实验最直观的感受就是国内外都在推动Serverless的发展，通过这次实验能看出亚马逊的Amazon Serverless已经很成熟了使用门槛也很低，国内的腾讯、阿里等企业也一直在推动实现内部产品Serverless化的进程，阿里已经推出了二十余款Serverless产品，23年双十一更是首次使用了Serverles化的架构比往年节省了30%左右的运维成本，Serverless必将是以后发展的大趋势。

       在技术层面上看Serverless确实实现了对现今的主流架构进一步解耦、削峰，其对电商类系统上的性能提升更是拔尖。但不能否认Serverless确实具有一些学习成本，并且出了bug其排查难度也更大，其使用者大多是拥有一定开发经验的开发者，这又进一步增大了其的推广难度，目前国内也只有一些大厂有条件、有环境进行Serverless的开发。希望未来Serverless更加简化，更加容易上手之后我们都能拥抱这项技术。