关键字: [Amazon Web Services re:Invent 2023, Serverless Espresso, Event Driven Architectures, Serverless Applications, Microservices, Workflows, Real Time Updates]
本文字数: 1500, 阅读完需: 8 分钟
视频
如视频不能正常播放,请前往bilibili观看本视频。>> https://www.bilibili.com/video/BV1fg4y1f7v5
导读
Serverlesspresso 是一种事件驱动的 Serverless 工作负载,它使用 Amazon EventBridge 和 Amazon Step Functions,协调微服务中的事件,并支持每天数千个订单。本论坛探讨了在构建此应用程序时所做的设计决策,新功能如何影响开发过程,以及使用此方法创建生产就绪应用程序时吸取的教训。探索有用的可扩展性模式和选项,这些模式和选项有助于设计健壮、可扩展的解决方案,该解决方案每天的运行成本约为一美元。本论坛包括可以应用于 Serverless 应用程序的示例,以及大型应用程序的复杂体系结构挑战。
演讲精华
以下是小编为您整理的本次演讲的精华,共1200字,阅读时间大约是6分钟。如果您想进一步了解演讲内容或者观看演讲全文,请观看演讲完整视频或者下面的演讲原文。
Amazon API Gateway支持前端应用程序与后端服务间的沟通,为微服务提供了RESTful API。
-
作为亚马逊云科技的Amplify Console,其使用诸如Vue.js等JavaScript框架来部署和托管三个前端应用。通过基于Git的工作流程,它简化了构建和部署的过程。
-
借助Amazon Cognito,面向客户的应用程序实现了用户身份验证以确保安全性。用户可通过输入其手机号码进行注册。
在接收订单前,需确认商店状态,包括检查咖啡师的容量情况。客户的订单等待时间限制为5分钟,以便生成具有高可读性的订单号(目前最多80,000个)。咖啡师的操作时间限制为15分钟,同时需要处理已取消的订单。
起初,Lambda函数负责处理诸如容量检查等自定义逻辑。核心的工作流程由右侧的Step Functions完成,它会消费并发射相关事件。左侧的未定义微服务则负责协助工作流程的运行。在完成准备工作后,下一个挑战是通过QR码启动订单。团队开发了一个能生成并验证动态二维码的QR服务,一旦成功扫描,将触发工作流程的事件发射。订购和展示应用为工作流程提供了初步的测试方法。
QR服务依赖于API Gateway和Lambda来实现其主要功能。它创建了一个DynamoDB表,其中包含每5分钟过期的五位随机代码,每个代码允许10次扫描。验证功能会检查扫描结果是否与当前活跃的代码相匹配。
这种方法通过在高峰期降低扫描速度来保护下游系统免受高需求的影响。团队发现他们可以实时动态更新菜单,方法是直接编辑后端DynamoDB表。当表发生更改时,事件会通知所有前端进行刷新,展示出事件驱动架构的优势。
接下来的挑战是让客户和咖啡师能够与正在进行的订单互动。他们需要查看、更新和取消订单,而应用程序需要开放订单状态。考虑的选项包括:
- 轮询API以获取订单状态
- 发送SMS更新
- 利用API网关的websockets
最终的解决方案是创建一个满足这些需求的订单管理微服务。它为前端提供REST API,并监听存储在DynamoDB中的任务令牌事件。这实现了对打开订单的快速查询,并为管理员应用程序提供支持。整合订单管理减少了跨lambda的重复。
随着订单的进行,实时更新前端应用程序成为一个障碍。需要双向通信来同步状态,响应商店的开张/关闭,并提供响应式的用户体验。轮询API或SMS通知等选项无法提供所需的实时推送更新。尽管Websockets具有潜力,但直接实现它们被证明具有挑战性。
优雅的解决方案是使用Amazon IoT Core,James将其比喻为“亚马逊云科技的Websockets”。它使用MQTT主题来处理Websocket管理的复杂性。后台服务发布事件,前端订阅更新。这使得将消息轻松发送给大量订阅者变得容易。即使应用程序断开连接,IoT Core的重试逻辑确保最终传递。
实施过程使用了将EventBridge事件路由到IoT Core主题的发布者微服务。前端应用程序的VueJS订阅消耗更新,并通过更新本地数据模型来自动刷新用户界面。 James描述了整个端到端流程,展示了各个组件是如何相互作用的:
- 前端调用REST API并接受实时Websocket通知
- 微服务将事件发布到中央EventBridge总线
- Step Functions工作流协调订单处理
- 发布者服务将来自总线的更新分发到前端
在回顾关键经验教训时,詹姆斯强调了精心设计的活动的重要性,并考虑了胖事件和瘦事件之间的适度包含。他建议引入版本控制以确保生产者与消费者之间的兼容性。为了增加可见性,使用诸如Schema Registry之类的工具来跨不同、相互独立的团队映射事件。通过使用真实事件进行注入而非依赖API进行测试,实现了有价值的验证。借助EventBridge的存档和重放功能,可在改进过程中重现生产环境。
詹姆斯对比了微服务之间的事件驱动通信与服务内部协调。他指出,通过为每个微服务分配单独的栈的方式来打破单体部署,从而加速了开发过程。其他见解还包括运用CQRS和发布/订阅模式来构建可扩展、具有弹性的系统。最大优势在于事件驱动架构所带来的意外可扩展性——可以在不进行侵入性更改的情况下添加新功能。
詹姆斯自豪地总结道,他们已经成功交付了一个高度复杂且实用的应用程序,每天仅需花费约1美元。无服务器Espresso成为了一个引人注目的案例研究,展示了如何通过精心策划地利用亚马逊云科技的无服务器服务来构建可扩展且经济实惠的应用程序。
最后,詹姆斯为观众提供了一系列资源,以便他们能够继续探索现实生活中的无服务器开发。通过有条不紊地经历这个过程,詹姆斯传授了关于如何在亚马逊云科技中采用事件驱动架构的一手宝贵经验。
下面是一些演讲现场的精彩瞬间:
詹姆斯·贝克(James Bek)担任亚马逊云科技开发者倡导团队的负责人,他拥有软件工程师、产品管理和构建大规模无服务器应用程序的丰富经验。
为了减轻下游系统的压力,QR服务被设计成通过计算扫描次数并在需要时移除条形码。
将API网关和DynamoDB直接集成可以避免使用lambda函数,从而为高容量微服务带来更大的规模和提高响应速度。
Bek强调了一个复杂的微服务如何通过重构简化成一个由一个Lambda函数驱动的Step Functions工作流。
在项目中预留一些额外功能空间可以帮助团队在将来更容易地添加新功能。
通过使用事件驱动的方式进行微服务通信并结合编排与编舞技巧,可以实现卓越的可扩展性和成本节约。
负责人还强调了技能构建器、快速入门指南和数字徽章等学习资源,帮助开发者掌握如何在亚马逊云科技上构建无服务器解决方案。
总结
-
“无服务器Espresso”的设计目标是实现最少的代码量、可扩展性、可伸缩性和成本效益。团队首先在白板上规划需求,编写伪代码,并使用亚马逊云科技(Amazon Web Services)的Step Functions将系统建模为状态机工作流程,以协调订单处理和处理超时等事件。
-
微服务之间通过事件总线而非私有API进行通信。一个订单管理微服务会监听工作流程事件并存储任务令牌。实时前端则通过IoT Core进行更新,采用可扩展的发布/订阅架构。API Gateway和Step Functions工作流程减少了微服务中的代码重复。
-
团队从项目中吸取的经验教训包括定义清晰的事件模式、保持事件的不可变性、记录事件以及在开发过程中记录所有事件。其他建议还包括使用EventBridge进行测试存档和重放,以及拆分大型无服务器部署。
-
实用的模式包括使用CQRS进行websocket通信,使用IoT Core进行全局和用户特定主题,适当组合编排和协调,以及在工作流程中管理等待状态。演讲最终以一项成本分析作为结论,表明“无服务器Espresso”具有很高的成本效益。
演讲原文
https://blog.csdn.net/just2gooo/article/details/134811471
想了解更多精彩完整内容吗?立即访问re:Invent 官网中文网站!
2023亚马逊云科技re:Invent全球大会 - 官方网站
点击此处,一键获取亚马逊云科技全球最新产品/服务资讯!
点击此处,一键获取亚马逊云科技中国区最新产品/服务资讯!
即刻注册亚马逊云科技账户,开启云端之旅!
【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用”
亚马逊云科技是谁?
亚马逊云科技(Amazon Web Services)是全球云计算的开创者和引领者,自 2006 年以来一直以不断创新、技术领先、服务丰富、应用广泛而享誉业界。亚马逊云科技可以支持几乎云上任意工作负载。亚马逊云科技目前提供超过 200 项全功能的服务,涵盖计算、存储、网络、数据库、数据分析、机器人、机器学习与人工智能、物联网、移动、安全、混合云、虚拟现实与增强现实、媒体,以及应用开发、部署与管理等方面;基础设施遍及 31 个地理区域的 99 个可用区,并计划新建 4 个区域和 12 个可用区。全球数百万客户,从初创公司、中小企业,到大型企业和政府机构都信赖亚马逊云科技,通过亚马逊云科技的服务强化其基础设施,提高敏捷性,降低成本,加快创新,提升竞争力,实现业务成长和成功。