小需求背后的大智慧,揭秘亚马逊云科技事件驱动型架构

简介: 近二三十年来,软件开发领域毫无疑问是发展最为迅速的行业之一。在上个世纪九十年代,世界上市值最高的公司大多是资源类或者重工业类的公司,例如埃克森美孚或者通用汽车,而现在市值最高的公司中,纯粹的软件公司谷歌微软位列前五,而排名第一的苹果公司也有相当部分是软件业务。现在每个企业机构无一例外地都在利用软件优化自己的业务,因此也造就了软件行业非常多的工作机会,从而也吸引了越来越多的小伙伴进入到软件以及相关的行业中。

近二三十年来,软件开发领域毫无疑问是发展最为迅速的行业之一。

在上个世纪九十年代,世界上市值最高的公司大多是资源类或者重工业类的公司,例如埃克森美孚或者通用汽车,而现在市值最高的公司中,纯粹的软件公司谷歌微软位列前五,而排名第一的苹果公司也有相当部分是软件业务。

现在每个企业机构无一例外地都在利用软件优化自己的业务,因此也造就了软件行业非常多的工作机会,从而也吸引了越来越多的小伙伴进入到软件以及相关的行业中。

同样,也正是因为软件行业日新月异,催生了层出不穷的新技术和新范式。从较早的面向对象的编程和二十三个设计模式,到面向服务的软件架构,一直到如今流行的微服务和云原生软件,让人目不暇接。

而在软件架构当中,最为流行的毫无疑问是事件驱动架构(EDA)。这种架构因其具备高容错性,高可升级性以及其各个模块具备低耦合的特性,被各个软件开发团队广泛采用。

作为现代软件开发的基础设施的云计算服务提供商,也针对事件驱动架构软件的开发和部署提供了一系列的原生服务。今天我们就来看看事件驱动架构的应用是怎么一回事。

让我们用一个简单的例子来说明。现在很多网站都具备上传图片的功能,无论是社交媒体网站还是电商网站,都允许用户上传图片,之后上传的图片会显示在这个网站上,例如买家秀这样的功能。

对于普通用户来说,上传图片是一个再简单不过的动作,但是背后的逻辑就需要软件开发团队精心的设计。

得益于现在手机相机强大的功能,用户上传的图片往往大小都比较大,直接放在网站上会超出屏幕显示的大小,挤占网页其他元素的位置,而且太大的图片加载速度较慢,又使得网页加载和显示备受影响,这个时候,把图片缩小成缩略图再显示就是一个很自然的思路。

那么,从“上传图片”到“生成缩略图”然后“展示缩略图”,这个功能如何用软件应用来实现呢?

用传统的数据驱动的思维来进行分析,当图片被用户上传到网站服务器上的时候,直接调用一个压缩图片的方法,然后把原图和缩略图分别保存到文件服务器,然后网站上的图片元素指向缩略图的位置,就可以实现生成缩略图的要求。

然而,随着缩略图功能的用户的增加,用户们提出新要求,因为所使用的设备屏幕有大有小,缩略图功能是否可以应对不同尺寸的屏幕生成多个不同大小的缩略图?一个简单的缩略图功能逐渐开始延展。

与此同时,随着缩略图功能的用户越来越多,网站响应速度越来越慢,甚至直接崩溃。

从网站服务器上看,上传图片的压缩操作和网站响应用户请求的功能耦合在一起同步执行,占用了网站服务器太多资源,使得网站无法响应越来越多用户的请求。

开发团队马上决定将生成缩略图功能单独提取出来,采取定时任务的方式,对于固定文件夹里的图片文件进行压缩,这样可以把压缩功能从网站服务器移出,节省网站服务器的资源。

可是,这么一来,又造成了新的问题,究竟这个定时任务多久执行一次,才能让用户及时看到自己上传的文件呢?如何在定时任务执行的时候确定哪些文件需要被压缩呢?压缩完毕后又应该如何通知网站应用,来加载压缩完毕的文件呢?

看来这么一个小小的功能,设计起来也是颇有讲究,要支持不同类型不同尺寸的压缩功能,需要能够异步执行、能分隔部署到不同的服务器上,加上别的团队对这个功能也有兴趣,这个生成缩略图功能还需要可以和其他应用程序集成。从一个简单的功能扩展开来,要兼顾各种不同的需求,这时候就是应该利用事件驱动架构来构建了。

事件驱动架构,顾名思义就是让架构中的各个模块,按照事件发生的顺序灵活地执行,并且可以把执行结果作为新的事件来驱动下一个模块的执行。

如此一来,每个模块都有了明确的执行边界和启动条件,而架构的作用就是将这些事件和对应的模块组合起来就组成了完整的应用。

在这个图片上传功能的例子中,首先发生的事件就是用户上传,当网站服务器接收到用户上传的图片,则将图片存储在文件服务器中,则可将“上传完毕”的结果返回给客户,简单而迅速;文件服务器上的文件变化就成为了第二个事件,这个事件则可以即时驱动缩略图模块的启动,将图片作为参数传入缩略图模块,以异步的方式执行,从而使得其他模块的执行不会被阻挡,提高其他模块的响应速度。

同时,不同尺寸的压缩任务可以串行也可并行执行,就如同流水线一般将任务传递下去,每个模块仅仅只负责一个独立的任务,高效而简洁,而模块的组合则由架构灵活控制,方便未来的扩展和修改。

如此一来,刚才看似复杂功能,就变成了简单的功能组合,而且可以灵活响应不同事件的发生,开发的任务也就变得简单明了。

未来,当运营团队提出新的要求,例如为用户上传添加日志功能,就变得十分简单,只需要添加一个日志功能,然后将其设置为到用户上传事件驱动,功能就实现了。

并且,因为每个模块都是独立的,因此测试和扩容都变得简单了,整个应用也变得更加健壮和快速了。从工程构建的角度,事件驱动架构满足了软件开发高内聚低耦合的规范,大大简化了开发和扩展的难度,因此,国内外的大大小小的开发团队都在积极拥抱事件驱动架构应用。

在目前的科技巨头里,亚马逊云科技是对于事件驱动架构支持力度最大的头部玩家之一。在亚马逊云科技平台上,其原生的无服务器的微服务就完全遵循了事件驱动架构的范式。还是用上传图片的功能作为事例,当上传图片被保存到亚马逊云科技S3存储上的时候,就可以触发文件增加事件,而开发者只需要把缩略图功能作为一个微服务写入Lambda Function之中,然后将该微服务的触发条件设置为相应的文件增加事件,就可以在图片上传保存之时被触发执行。

在亚马逊云科技平台上,Lambda Function提供了多种云服务常用的事件可供开发团队直接使用,其中包括刚刚提到的亚马逊云科技S3储存服务上的事件,还有云服务监控监测到的事件,物联网Alexa设备上的事件,API Gateway上的API调用事件,DynamoDB NoSQL数据库的事件,MQ信息流事件等等。

想了解更多,可以复制这个链接到浏览器中查看:https://aws.amazon.com/cn/lambda/这些原生支持的事件产生的信息被很好地封装了起来,供Lambda Function使用。丰富的事件形态支持使得开发人员不必过多关心这些事件背后的底层技术,从而能更好地把注意力集中到实现业务逻辑上。亚马逊云科技对于事件驱动架构的全面拥抱,就体现在这里——几乎所有的亚马逊云科技提供的云计算服务,都实现了对于事件的支持。这些云计算服务的事件触发器有着统一而完善的接口,使得开发者能够自由组合,以产生最佳的组合效应。

在开发团队关心的应用运行性能问题和云计算成本问题,亚马逊云科技也通过利用事件驱动架构做了极具伸缩性的设计。

在事件驱动架构的应用中,事件驱动的逻辑模块都可以是异步调用的,也就是说,如果事件不发生,则对应逻辑模块不加载不执行。

这样一来,应用加载的云计算服务可以在一定程度上最小化,比如前文所举的缩略图功能的例子,网站应用只有在用户上传文件的时候才调用缩略图微服务,在没有用户上传图片之时,无服务器Lambda Function微服务处于休眠状态,不发生成本。

而在微服务启动之时,亚马逊云科技也是按照秒级单位来计算微服务运行的时间,按使用时间收费。与此同时,微服务也具备自动弹性伸缩的能力。

亚马逊云科技Lambda Function允许用户设置同时运行的微服务数量上限,如果将这个上限设为1000,则表明微服务可以同时启动1000个实例来响应事件的触发,同时,微服务因为其无服务器的高度虚拟化的特性,启动执行和回收资源都发生在毫秒级别,在面对大量的事件触发之时,真正做到了唯快不破。而且微服务还有各种其他涉及到性能和资源自动伸缩的设置,可以满足用户各种不同的需求模式。

回到缩略图功能的事例,产生不同大小的缩略图的微服务可以并行执行,用同一个S3储存的新增文件事件来驱动多个不同的缩略图微服务,辅以不同的压缩参数,可以并行生成不同大小的缩略图。

那么,如果我们需要在缩略图生成以后,再为不同大小的缩略图添加水印,这就需要微服务能够串行执行。

开发人员可以直接将水印功能的代码加入缩略图微服务中,但更好的做法,显然是单独将水印功能封装成为单独的微服务独立部署,这样,不仅功能上得到了更好的划分,同时也提升了网站应用程序整体的运行性能和健壮性。

一个可以参考的做法是,第一步将用户上传的图片原图存储于第一个S3文件basket,这个basket会触发新增文件的事件,来驱动缩略图微服务的执行;当缩略图微服务执行完毕,就会将缩略图存储于S3的第二个basket中,而这第二个basket则会驱动下一个新增文件的事件,来驱动添加水印的微服务;最后,添加水印的微服务将最终的图片文件存入第三个basket中,交还给网站引用。

如此一来,通过一系列的事件的驱动,多个微服务可以灵活组成不同的逻辑流程来处理信息,实现用户期待的功能。

这充分表明了事件驱动架构在亚马逊云科技中的广泛应用,而且亚马逊云科技也切实利用事件驱动架构的优势来为用户和开发者赋能。

如果我们完整地看待缩略图功能的实现,除了刚才提到的亚马逊云科技的各个服务,亚马逊云科技还提供了数以百计的其他服务来完善缩略图功能。

API Gateway提供了将微服务组织起来的API统一接口;亚马逊云科技CloudFront CDN网络可以将缩略图缓存到不同地区的数据中心,加速网络资源的访问速度;亚马逊云科技还提供了完备的开发者工具,让开发者方便地管理代码、自动部署、监控应用状态等。

亚马逊云科技一站式服务及工具集合为开发团队、运营团队和最终用户提供了最接近完美的解决方案。


现代软件工程技术的发展中,事件驱动架构应用并不是一个新概念,在多年的发展中历久弥新,在现在云计算技术爆炸的当下,完美地指引了软件应用应该如何灵活高效地设计和构建。

亚马逊云科技作为云计算平台的领军者,也受益于对事件驱动架构的全面拥抱,也进一步巩固了其在云计算领域的领先优势,也是开发团队的不二之选。

下个月就会是亚马逊云科技中国峰会(线上直播),峰会中将会涉及到事件驱动架构的应用实践,除此之外大会还涉及到:机器学习的演进趋势、Web3的发展和趋势等等。内容十分丰富,强烈推荐每一位技术同学观看直播。


相关文章
|
2月前
|
消息中间件 监控 测试技术
事件驱动架构是一种编程范式
【10月更文挑战第7天】事件驱动架构是一种编程范式
115 65
|
1月前
|
人工智能 Cloud Native 算法
|
2月前
|
存储 消息中间件 人工智能
ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用
本文整理自2024年云栖大会阿里云智能集团高级技术专家金吉祥的演讲《ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用》。
148 10
|
2月前
|
存储 设计模式 监控
事件驱动架构的实现方式?
【10月更文挑战第7天】事件驱动架构的实现方式?
59 7
|
3月前
|
设计模式 开发框架 前端开发
在开发框架中实现事件驱动架构
【9月更文挑战第2天】事件驱动架构(EDA)通过事件机制让组件间解耦交互,适用于动态扩展和高响应性的系统。本文提供一个基于Beego框架实现事件驱动的示例,通过事件管理器注册和触发事件,实现用户注册和登录时的不同处理逻辑,展示了其在Web应用中的灵活性和高效性。
92 5
|
4月前
|
弹性计算 监控 数据挖掘
事件驱动架构的优势与应用:深度解析与实战应用
【8月更文挑战第17天】事件驱动架构以其松耦合、可扩展性、异步处理、实时性和高可靠性等优势,在实时数据处理、复杂业务流程、弹性伸缩和实时通信等多个领域展现出巨大的应用潜力。通过合理应用事件驱动架构,可以构建灵活、可扩展和可维护的系统架构,满足不断变化的业务需求和技术挑战。对于开发者而言,深入理解事件驱动架构的核心概念和优势,将有助于更好地设计和实现高质量的软件系统。
|
4月前
|
消息中间件 缓存 Kafka
混合云中的事件驱动架构
混合云中的事件驱动架构
46 4
|
4月前
|
消息中间件 Kafka Java
Spring 框架与 Kafka 联姻,竟引发软件世界的革命风暴!事件驱动架构震撼登场!
【8月更文挑战第31天】《Spring 框架与 Kafka 集成:实现事件驱动架构》介绍如何利用 Spring 框架的强大功能与 Kafka 分布式流平台结合,构建灵活且可扩展的事件驱动系统。通过添加 Spring Kafka 依赖并配置 Kafka 连接信息,可以轻松实现消息的生产和消费。文中详细展示了如何设置 `KafkaTemplate`、`ProducerFactory` 和 `ConsumerFactory`,并通过示例代码说明了生产者发送消息及消费者接收消息的具体实现。这一组合为构建高效可靠的分布式应用程序提供了有力支持。
120 0
|
5月前
|
消息中间件 监控 Java
在Java项目中实现事件驱动架构
在Java项目中实现事件驱动架构
|
5月前
|
消息中间件 监控 Java
使用Kafka实现分布式事件驱动架构
使用Kafka实现分布式事件驱动架构