亚马逊云科技 Build On - 毫厘控制传统行业快速搭建部署智能业务这件事“钱花在刀刃上”——迎云计算更高一层精专形态的下一个时代Serverless

Posted 2023-01-21 炜翼

/*本文章总计6052词，可能需要16分钟进行阅读，创作时间近1周，尽量将Serverless干货打包满满，并尝试向您解释清楚。
无论是路过还是看得乐呵的看官姥爷只求能给个👍点赞和⭐收藏，谢谢您嘞❤
P.S.CSDN侧边可以查看目录，就不在前面占用大家视野啦*/

本人有幸于12月17日当天参加了亚马逊云科技与CSDN联合组织的 2022 Build On 第三季 线上动手实验。正巧那天是从学校赶回家后的第二天，有些匆忙，不过还是赶上了。主要目的是想参与行业技术领头企业组织的开发者活动，毕竟我个人参加这类社区活动的次数还停留在未接触启始的情况，想在开拓眼界的同时认识一些前沿的热点概念及其实现案例展示，显然这次活动让我不虚此行。

这次 Build On 第三季主要内容是？

基于Amazon Serverless理念构建零售创新应用，通过学习使用亚马逊云科技各项服务的运行最终实现Serverless 搭建零售创新应用，实质是对传统行业实现智能业务需求的一次尝试新思路的缩影式案例实验。

通过实验去了解以Amazon Step Functions为业务构建核心，联结Amazon EventBridge、Amazon Lambda、Amazon API Gateway、Amazon S3、Amazon DynamoDB和Amazon Cognito其他关键云服务共同作用下实现Serverless概念的预期效果。

亚马逊云科技是全世界率先完成Serverless云生态全面布局的“领头企业”，所以他们才有底气把这次Build On活动主题定为业界前沿的Serverless。

以下是AWS官方提供的资料，感兴趣的开发者可以点击查看详情：

亚马逊云科技 2022 Build On 第三季直播宣讲

亚马逊云科技 2022 Build On 第三季实验手册

什么是Serverless

前面出现了诸多Serverless这一关键词，那么其究竟为何物？他被誉为云计算的下一个十年。

Serverless是一种后端的架构技术，准确来说是后端架构的概念或思维。亚马逊云科技是最早布置Serverless技术的那一批企业。

Serverless相较于当前行业的传统架构（可以称为Serverful）其”创新“点或“优势”点在何处？而我在本文章标题采用”钱花在刀刃上“对其特征进行了形象的比喻。

后端架构的演进

要明白其突出的”优势所在“，我们首先要对服务器后端架构的演进有一个充分的认识，以下这幅图就很好地概况了这一系列的历史进程。

分析各个阶段的进化特征：

物理机时代跨越到虚拟机时代	不再关心硬件设备的管理
虚拟机时代跨越到容器时代	摆脱了运行环境和集群管理的繁杂工作
容器时代跨越到Serverless时代	不再关心运行环境和服务器资源的调配

最终可以总结出后端架构的变化奥义：

云服务提供商与开发者（企业）的分工越来越精细明确，云服务提供商给予的基础设施解决方案日益针对问题专业化、深度化，而开发者（企业）的事务范围发展趋势逐步回到产品业务逻辑这一工作本原上来，逐渐减少在硬件层面及其附加操作的关注付出和技术成本。类似前往某地出差而不用再费心思于”使用怎样的交通工具“和”路途行程安排“这些本就不是任务点的途力问题上。

Serverless的优势特征

上面通过对各个时代后端架构的比较，其实已经非常明显能够得知Serverless的优势特征，接下来就是对这个话题进行细节深入地讨论。

前面我们认为当前传统的架构统称为Serverful，这是相较于Serverless的名词。

Serverful	服务器的一切都需要开发者进行人工地干预
Serverless	开发者不用关心服务器的运维，服务器相关的工作交给云服务提供商

在云的上下文中，Serverful的计算就像使用低级的汇编语言编程，而Serverless的计算就像使用Python这样的高级语言进行编程。例如c=a+b这样的简单表达式，如果用汇编描述，就必须先选择几个寄存器，把值加载到寄存器进行数学运算，再储存结果。

这就好比今天在云环境下Serverful的计算，开发者首先需要分配或找到可用的资源，然后加载代码和数据，再执行计算，将计算的结果储存起来，最后还需要管理资源的释放。

——摘自2019年2月加利福尼亚伯克利大学论文《Cloud Programming Simplified: A Berkeley View on Serverless Computing》

Serverful关心问题	Serverless关心问题

Serverless架构是采用FaaS（函数即服务）和BaaS（后端即服务）来解决问题的一种设计。

对于开发者而言BaaS是黑盒，实现任务功能只需编写业务逻辑的代码并交付到FaaS。

由此我们可以总结出Serverless的特点：

”弹性收缩 + 按量付费“的组合可以预想到：不再为服务器的扩容半夜惊醒。当流量洪峰来临时，自动调配更多的服务器资源去支撑；当流量低谷时，自动释放服务器的资源来节约成本。

Build On的”零售创新“实验

解释了这么多理念或概念的东西，那么Serverless与“传统行业搭建部署智能业务”这件事能产生什么样的化学反应呢？前面也已经提到过本次Build On关于“零售创新“的课题其实就是对那件事的缩影观察——以“零售应用案例”与Serverless的结合去以小见大窥探出那件事的效果反馈，这是一种以个例见普遍、投射效应般的实验方法。

活动流程

官方直播讲师是由亚马逊云科技的资深解决方案架构师 Dr.郁磊 担任。

宣讲内容主题	持续时间
使用事件驱动的架构（EDA）构建新应用程序	30 Mins

1. 有关耦合的方方面面

   耦合实际上是系统之间、模块与模块之间相互的关系。

   耦合很重要但也很复杂，在传统架构里对应用进行调整或迭代时因为“耦合”变得繁重。

   

2. 事件驱动架构提供解决的方案

   模块与模块之间通过“事件”来触发进行”解耦“，微服务之间通过“事件”进行调度和串联。

   

3. 事件驱动型架构的三要素

   

4. 事件驱动型架构的好处

   解耦、削峰、异步

   讲师通过业务举例比较事件驱动型架构与传统架构的区别优势。

   传统架构	事件驱动架构

介绍期间，令我印象最深刻的是反复逐步诠释的”解耦“思想，以及最后总结时提到Serverless“弹性收缩 + 按量付费”组合特征能够为开发者（企业）降低成本的考虑。

任务目标

我们将扮演商家和客户两种角色，要做的是通过使用开发者的能力去搭建部署用于零售的智能业务，所展现的操作逻辑现实存在应该为：

首先作为客户扫描某头顶显示器的QR码在移动设备下单，然后转化为商家时能够通过内部管理的应用程序实时查看到客户的订单并做出相关商业行为，如果交易成功当我再变为客户时应该能在大屏看到自己已经付款的饮品并于不久后开心地收到货物。

置身于开发者的身份时，只需按照官方提供的实验手册逐步照葫芦画瓢即可（给实验手册的编辑老师加🍗每一步真的都非常细致到位），如下是我最终实验成功的截图。

冬天的第一杯奶茶（Em… it must be Latte）~

Display	Make	Ready	Complete

与此同时前端的店铺大屏页面和商家管理页面。

架构分析

开发者的任务是在AWS云环境下配置相关基于“Serverless构建思想”的微服务，以下是整个业务逻辑所需用到的技术媒介及其总架构图：

我们最先要做的是在Amazon Step Functions中去编排我们的业务逻辑，这个过程很像我们创建工作流并为后面预留将各个业务环节串联起来，专业点说还有点类似于定制CI/CD管道的每个节点。

之后再结合其它相关且支持事件驱动架构的AWS云服务让它完全“动”起来。而Amazon Web Services能用于EDA的云生态应用又多达200+种，总有一款是适合开发者（企业）的业务需求地。

在我们这次实验中使得每个业务环节最终依序产生预期效果所联结的部件：

应用程序架构	作用概述	界面示例
Amazon EventBridge	不同云应用之间进行消息通讯的事件总线
Amazon Lambda	实现云函数依托的媒介，即前面提到被用于Serverless解决实际问题的FaaS
Amazon API Gateway	用于创建、发布、维护、监控应用程序接口的API管理中心	NULL。本次实验直接使用手册中提供的完整现成API json参数
Amazon S3	对象存储服务	NULL。本次实验并未详细接触
Amazon DynamoDB	NoSQL数据库服务
Amazon Cognito	跨应用的用户身份验证及身份权限管理中心

六大架构的配置管理都是与实例资源隔开独立存在的，但在实际经营中又和业务系统的运作紧密联系、融融一体，这就近乎完美地达到了前面 Dr.郁磊 “解耦”要求下所呈现的效果。而后四者也是现如今Serverless过渡期原有大环境非常流行常用且在传统架构时就已经发展为集大成者的几类基础设施，兼续沿用旧有架构设计使用习惯的同时又具备Serverless思想要求的技术模式。

其中，Amazon EventBridge是最令我惊喜、亮眼的这么一个架构，我称之为缘分…他是前面郁磊老师讲到业务系统中作为事件收集者的存在。

不瞒大家说，在我自己某个正在开发的系统底层中，一直想实现某种通讯池作为支撑上层建筑运行的核心构件之一。这种通讯池是上层应用之间进行数据信函交换的调度中心，这么设计的初心是为避免出现不同应用通讯另需独立端对端架桥这般不统一协议更不方便无缝扩展的境遇。要达到这种目的即是要令信息发送者与接收者“解耦”，由一万向兼容桥进行分设权级管理，生产者设立接收条件门槛但不知道具体由谁得到信函，消费者按先决配置被赋予的条件权限在“池”中捕捉函件。

此前正苦恼于没有遇到合适的现成架构用于技术参考、无从起手——直到碰见了他~

当时第一眼也是感慨道简直100个Presents完全契合我上面所讲的“通讯池”效果预期并向全世界宣布了这个“知音”。

进一步对Amazon EventBridge的深究让我Get到EventBus这个早已在业界某些框架设计里出现过许多次的名词，幡然醒悟到原来这种底层模式其实就是类同于面向对象设计方法论中非常经典、而自己知道RSS订阅却又没留意过其本质的发布订阅模式！

（与之相对应的则是我个人曾用过非常多次“回调监听事件”的观察者模式）

浅浅地发个朋友圈	发布订阅模式与观察者模式的模型

回归主题，纵观本实验总的架构模型，我们不难发现：整个过程里开发者无需再去思索如果使用代码构建承载应用业务逻辑的底层容器，只需将云服务提供商给予的基础设施拿来开箱即用即可。总架构图也是没有出现过任何具体的硬件化名称等字眼，而云服务提供商的基础设施命名也是直接与其实际发挥的技术作用关联地，符合之前讲到过的后端架构演进趋势抽象规律。

操作纪实

工作流的头部每响应一次业务请求，服务器就会产生一个状态机实例去按照预设步骤有序实现业务操作，这与工厂流水线接收订单然后生产产品的过程实质是一致的。

以下是本次实验用到的两个工作流总览：

订单处理工作流（亲手创建）	店家处理工作流（已提供好）

订单信息由前端发出并由Amazon EventBridge路由通知给相应的工作流。

这是本实验最终一次跑完全部流程实现任务目标的状态机（亲自创建）工作成果检视。

每个状态机实例运行时都能监控到其所有环节的数据处理结果，运行完成后就能在检查图下方位置查看每个节点的行为记录，方便开发者进一步调试业务系统。

在整个实验过程中还可以学习到很多其它AWS云服务操作：

云生态服务	功能	界面示例
AWS CloudShell	能够像在传统架构里通过Shell命令控制服务器那样去管理我们的Serverless云生态资源
AWS CloudFormation	模板化管理、快速建模和设置云基础设施，比如部署这次实验中用到的前端页面

这次实验对于我个人来说比较遗憾的是：即使是照葫芦画瓢，也没能以抢先的名额快速做完整个实验（想要个更具纪念性的奖品🎁QWQ）。

因为在”前端提交订单后加载页面假死“这个问题上耽误了很多时间，联系助教支援逐一排查关键部位也确认我自己亲自处理的那些后端配置是完全没有问题的。我的动手实验还未完全结束，腾讯会议就因时间关系先解散…还在做实验的小伙伴也不多了…

当时确实也挺late——该食晚餐惹QAQ。

前端就是卡在这个地方：下完订单后页面一直留白不跳转到“Look out for your order on the big screen”这一步，导致工作流停滞使得店铺大屏页面和商家管理页面无法出现我的订单信息，同时间点店铺大屏页面饮品库存预留数量减少的现象可以印证“后端正在等待前端事件回调但前端却假死”这一推测。

前端卡住页面	饮品库存预留数量减少

因为是官方提供的前端（现成），应该不存在代码上的Bug。毕竟服务器在美国…也许是我本地网络问题…所以完全可以理解吧💦

如图是当时截取到的尴尬处境，许多因假死滞留、无法继续的状态机实例们，正在运行地一个个排着队…

放眼宏观

现在我们在脑中勾画一下，如果使用传统架构的方法同样去搭建部署并实现本次实验的任务目标，大概要走哪几步？然后再来对比一下我们本次实验所用到的这个创新方法，相较之下前者可能存在什么优势或劣势？其实结果已经非常明显了，前面我们也多次在细节处比划过…

本章开头提到了这是缩影式的实验。但如果我是某某传统行业公司的CEO，真正面临着要往智能业务方向发展的转型问题时——因为本身自己企业确实没有涉猎过智能业务的先例，更别说那还不是自己扎根的熟悉领域，从零开始出发往“组建技术部门”这口井投入试探成本多久之后才响起水花声都是未知数，更别提想要在短时间内看到智能业务反哺于我原本经营的产品领域，所以还真就非常乐意去尝试这种新思路新方法。因为Serverless的出现提供了一次很好的机遇，对于传统行业新晋的开发者而言不用再去思考“如何构建整个智能业务的底层架构”这种在互联网科技行业都属于深层次水平的技术问题，只需关注业务逻辑本身。

而我个人在本次实验动手过程中确实深深感受到使用Serverless方法搭建部署智能业务的速度是又快又好，学习成本相较于那些需要关心技术底层构造的业务系统也低很多。

所以在使用Serverless方法将智能业务投入到实际生产环境这一过程中，传统行业不仅付出的技术成本低且能很好地达到目的，进而成功转型、跟上时代步伐。这也反映了Serverless不仅是科技企业或大厂的竞争利器，对于其它中小企业来说也是实打实、一针见效益的福利。特别是刚起步的初创企业，既没有丰富的市场经验也没有丰厚的技术积累，通过Serverless搭建部署智能业务能减少走很多弯路“钱花在刀刃上”。市场上难得的多向共赢！

像我自己本人玩了5年服务器，但从来没有对云计算这一领域有完全真正深入过，感谢这次亚马逊云科技Build On活动提供的机遇，让我亲手接触到云计算新形态Serverless的实体并在实验结束后困惑兴起好好地重新研究了一番Web后端架构的发展进程，写下了这篇文章有感。

感谢您看到最后，希望对正在阅读这篇文章的你去认识“云计算的下一个十年”有所帮助。如果觉得写得还行，恳请👍点赞与⭐收藏，这是对于作者更新长篇知识分析来讲是非常重要的动力与鼓励。谢谢❤！