当前位置: 首页 > 后端技术 > Java

学习无服务器-认识Serverless

时间:2023-04-01 19:29:06 Java

简介:Serverless架构已经被越来越多的企业采用,成为他们的技术选择。大多数开发人员已经超越了对Serverless概念的理解并开始实施它。本文带你了解为什么Serverless可以帮助开发者专注于核心业务价值,以及哪些场景更适合使用Serverless架构!作者|蒋宇(阿里云Serverless产品经理)介绍:从云计算到Serverless2009年,加州大学伯克利分校发表文章:AbovetheClouds:ABerkeleyViewofCloudComputing,其中首次定义了云计算:云计算包括Internet上的应用服务以及数据中心中提供这些服务的硬件和软件设施。没有尽头。随着云计算的快速发展,云计算的形态也在不断演变。从IaaS到PaaS,再到SaaS,云计算逐渐“找到了正确的发展方向”。(云计算的发展形态)Iron.io副总裁KenForm在2012年写的一篇名为WhyTheFutureofSoftwareandAppsisServerless的文章中提出了一个新的观点:虽然云计算已经逐渐兴起,但是大家还在围着服务器转。不过,这种情况不会持续太久,云应用程序正在转向无服务器,这将对应用程序的创建和分发方式产生重大影响。并首次将“Serverless”这个词带入了大众视野。到2017年,各大云厂商基本都在Serverless上做了基础部署,尤其是国内几大云厂商,也在这一年进入了“Serverless时代”。从下图我们可以看到,在从IaaS到PaaS再到SaaS的演进过程中,云计算的去服务器化越来越明显。那么上一篇KenForm提出的Serverless到底是什么?云计算在发展过程中起到什么作用,在多大程度上去服务器化?什么是无服务器?Serverless翻译成中文就是serverless。所谓serverless并不是说不需要依赖服务器等资源,而是开发者不需要再过多考虑服务器问题,可以更专注于产品代码。同时,计算资源也开始作为服务出现,而不是作为服务器的概念。Serverless是构建和管理基于微服务的架构的完整过程,它允许用户在服务部署级别而不是服务器部署级别管理他们的应用程序部署。与传统架构不同的是,完全由第三方管理,由事件触发,无状态(Stateless)存在,暂时存储(可能只存在于一次调用过程中)在计算容器中,Serverless部署应用不需要涉及更多的基础设施建设,基本可以实现服务的自动化构建、部署和启动。近年来,微服务(MicroService)是软件架构领域的另一个热门话题。如果微服务是基于专注于单一职责和功能的小功能块,采用模块化的方式组合复杂的大型应用,那么可以进一步认为Serverless架构可以提供更加“代码碎片化”的软件架构范式,这部分称为功能即服务(FaaS)。所谓“功能”提供了比微服务更小的程序单元。例如,微服务可以表示为客户执行所有CRUD操作所需的代码,而FaaS中的函数可以表示客户将执行的每个操作:创建、读取、更新和删除。当“createaccount”事件被触发时,相应的“function”会以函数的形式执行。单从这个意义上来说,Serverless架构可以简单等同于FaaS的概念。但是,如果深入探究具体的概念,Serverless和FaaS还是有区别的。Serverless和FaaS被广泛接受的关系是:Serverless=FaaS+BaaS(+.....)在这个关系中,可以看出Serverless的重要性除了FaaS和BaaS(BackendasaService),还有一个组成中的一系列省略号。其实这就是Serverless给大家的想象空间,也是对这个时代的一些期待。在前面的描述中,Serverless架构在结构、行为、特性等方面的定义可以概括为下图的形式:“从组合定义的角度”MartinFowler认为,在Serverless架构中,一部分应用服务器的逻辑仍然由开发者完成,但与传统架构不同,它运行在一个无状态的计算容器中,由事件驱动,生命周期短(甚至一次调用),完全由第三方管理。这种情况称为FaaS。此外,Serverless架构还有部分依赖第三方(云)应用或服务来管理服务器端逻辑和状态的应用,这些服务被认为是“BaaS”部分。《从行为定义的角度》CNCF在上述基础上对Serverless架构的定义,进一步完善了描述:Serverless是指构建和运行不需要服务器管理的应用程序的概念。它描述了一种更细粒度的部署模型,其中应用程序被打包为一个或多个功能,上传到平台,然后根据当时的确切需求执行、扩展和计费。《从特性定义的角度》2019年UCBerkeley在文章CloudProgrammingSimplified:ABerkeleyViewonServerlessComputing中也从Serverless架构特性的角度补充描述了什么是Serverless:简单来说,Serverless=FaaS+BaaS。对于被认为是Serverless的服务,它必须具有弹性伸缩和按需付费的特性;Serverless的概念在信通院云原生产业联盟发布的《云原生发展白皮书(2020 年)》中也有描述:Serverless(即Serverless)是一个架构概念。其核心思想是将提供服务资源的基础设施抽象为各种服务,以API接口的形式为用户提供按需调用,真正做到按需扩容和按用计费。这种架构架构省去了传统海量持续在线的服务器组件,降低了开发和运维的复杂度,降低了运营成本,缩短了业务系统的交付周期,使用户能够专注于更高价值密度的业务逻辑开发。随着各大厂商在Serverless领域的逐步布局,Serverless正逐渐从启蒙和市场教育阶段走向生产应用和最佳实践阶段,下面我们将详细介绍。Serverless的发展2017年,CNCFServerlessWG成立,开始借助社区的力量推动Serverless的快速发展,包括CNCFServerlessWhitepaper、CloudEvents等相关项目的研究和探索。2017年底,ChrisJ.eWEEK的Preimesberger发表文章Predictions2018:WhyServerlessProcessingMayBeWaveoftheFuture表达了大家对“新阶段”Serverless的看法和期待。在本文中,多位知名团队和公司的相关负责人发表了对ServerlessIdea的看法:Serverless可能是继容器之后的未来,可以预见Serverless的影响力将不断扩大;重塑软件的构建方式。2018年,Serverless的发展速度比预期的要快。国内外云厂商持续推进新技术引进。同年,CNCF也正式发布了Serverless领域的白皮书:CNCFServerlessWhitepaperV1.0,阐明了Serverless技术的概况,生态系统的状态,以指导CNCF下一步的发展。同时,CloudEvnent规范进入CNCF沙箱。这一年,加州大学伯克利分校发表了ServerlessComputing:OneStepForward,TwoStepsBack,表达了对Serverless的担忧和挑战。笔者认为Serverless会阻碍开源服务的创新。事实上,任何新的技术或概念都会遇到一定的挑战和担忧,就像过去云计算出现时,也被一些人认为只是商业炒作的另一种概念。当然,事实也证明,任何新生事物,只有经历过各种挑战和质疑,才能变得更强大。从2019年开始,Serverless进入了真正的生产应用和最佳实践快速发展阶段。今年对于Serverless来说是一个里程碑,被很多人定义为“Serverless正式发展元年”。今年,不仅有KubeCon在中国上海CloudNativeCon上关于Serverless的“海量主题演讲”,还有UCBerkeley的最新文章CloudProgrammingSimplified:ABerkeleyViewonServerlessComputing。在这篇文章中,经过一年的发展,加州大学伯克利分校的学者们也从一年前的怀疑和悲观转变为自信和期待,并且这篇文章一针见血地断言Serverless将在未来十年内被采用并迅速发展,他认为Serverless将引领云计算的下一个十年,并关注以下新观点:将发明新的BaaS存储服务,以扩展和运行更多适应于Serverless计算程序类型的应用程序。这种存储可以与本地块存储的性能相匹配,具有短暂和持久的选项。比现有的x86微处理器更多的异构计算机。更安全易用的编程,不仅具有高级语言的抽象能力,而且具有良好的细粒度隔离性。基于Serverless计算的价格会低于Serverful计算,至少不会高于Serverful计算。Serverless会接入更多的后台支撑服务,比如OLTP数据库、消息队列服务等,一旦serverless计算取得技术突破,将导致serverful服务的衰落。Serverless将成为云时代默认的计算范式,将取代Serverful计算,这意味着服务器-客户端模型的终结。除了这些断言,对于什么是“Serverless”,Berkeley也给出了自己的思考:简单来说,Serverless计算=FaaS+BaaS。在我们的定义中,要将服务视为无服务器,它必须自动扩展且无需显式配置,并根据使用情况计费。可以看出,从IaaS到FaaS再到SaaS,再到现在的Serverless,云计算的发展在过去十年间发生了翻天覆地的变化。相信随着5G时代的到来,Serverless将会在更多领域发挥至关重要的作用。Serverless的最佳应用场景作为云原生技术未来的演进方向,Serverless架构正在逐渐被边缘化。根据Gartner过去的预测数据,到2020年,全球20%的企业将部署Serverless架构。Serverless将进一步释放云计算的能力,将安全性、可靠性和可扩展性需求传递给基础设施,让用户只需关注业务逻辑,而不是具体的部署和运行,大大提高应用开发效率。同时,这种方式促进了社会分工协作,云厂商可以通过规模化和集约化进一步优化计算成本。聚焦业务核心价值随着云服务的发展,计算资源高度抽象,从物理机到云服务器,再到容器服务,计算资源逐渐精细化。Serverless架构将成为未来云计算领域的重要技术架构。它将被更多的企业采用,成为其技术选择。那么,我们将进一步研究在哪些场景下,在哪些类型的Serverless中能够有出色的表现。也许在现场表现不是很理想?或者说,哪些场景更适合使用Serverless架构?Serverless架构的应用场景通常是由其特性决定的,支持的触发器决定了具体的场景。CNCFServerlessWhitepaperv1.0中描述的用户场景如上图所示。在CNCFServerless白皮书v1.0中,Serverless架构的适用用户场景包括:异步并发,组件可独立部署和扩展,以应对突发性或不可预知的服务使用场景短期、无状态应用,以及不存在的场景对冷启动时间敏感的需要快速开发迭代的业务,因为不需要提前申请资源,所以可以加快业务上线速度。给出了基于Serverless架构的CNCF的特点。除了四种用户场景,结合常用触发器给出了详细的示例:响应数据库变化(insert、update、trigger、delete)的执行逻辑物联网传感器输入消息(如MQTT消息)的解析处理流处理(Analyzing或修改运动中的数据)管理需要在短时间内进行大量处理的单个提取、转换和存储(ETL)通过聊天机器人界面进行认知计算(异步)安排在短时间内执行的任务,例如CRON或批处理为持续集成管道调用机器学习和人工智能模型,为按需构建作业提供资源,而不是从等待作业分配的主机池中维护构建任务。以上是对Serverless架构适用的场景或业务的理论描述。云厂商从自身业务角度,整体描述Serverless架构的典型场景。通常,在Serverless架构中对象存储作为触发器的典型应用场景包括视频处理、数据ETL处理等;API网关会为用户赋能外部访问链接和相关功能等,当API网关作为触发serverless相关产品时,常见的应用场景是后端服务,包括后端服务App,网站的后台服务,甚至微信小程序等相关产品的后台服务。同时,部分智能音箱还会开放相关接口,该接口还可以通过API网关触发云端功能,获取相应的服务;除了对象存储触发器和API网关触发器,常见的触发器还有消息队列触发器、Kafka触发器和日志触发器。常见应用场景“Web应用/移动应用后端”Serverless架构结合云厂商提供的其他云产品,开发者可以构建可弹性扩展的移动或Web应用——轻松创建丰富的serverless后端,并且这些程序可以高可用地运行在多种数据中中心无需在可扩展性、备份冗余方面执行任何管理工作。例如Web应用处理示例:(Web应用后端处理示例)“实时文件/数据处理”视频应用、社交应用等场景,用户上传的图片、音频、视频往往体积庞大数量多,频率高。性能和并发性都有很高的要求。例如,对于用户上传的图片,可以使用多种功能分别进行处理,包括图片压缩、格式转换、色情和恐怖主义检测等,以满足不同场景的需求。例如:(实时文件处理示例)通过serverless架构支持的丰富的事件源和事件触发机制,只需几行代码和简单的配置就可以对数据进行实时处理,例如:解压对象存储压缩包,清理日志或数据库中的数据,自定义消费MNS消息等:(实时数据处理示例)“离线数据处理”通常需要处理大数据,需要搭建框架与Hadoop或Spark等大数据相关,同时拥有处理数据的集群。通过Serverless技术,只需要将获取的数据不断的存储在对象存储中,通过对象存储相关触发器触发数据拆分函数,拆分相关数据或任务,然后调用相关处理函数即可。处理完成后,存储在云端数据库中。例如:某证券公司每12小时统计一次该时段的交易情况,并整理出该时段前5笔交易量;每天处理秒杀网站的交易流水日志,获取因售罄导致的错误,从而分析商品热度、趋势等。函数计算近乎无限的扩展能力,让用户可以轻松进行大容量数据的计算。使用serverless架构,可以在源数据上并发执行多个mapper和reducer功能,在短时间内完成工作;与传统的工作方式相比,使用Serverless架构可以避免资源的闲置浪费,节约成本。整个过程可以简化为:(数据ETL处理示例)“人工智能领域”在训练好AI模型后,可以使用Serverless架构提供推理服务。通过将数据模型包装在调用函数中,代码将在实际用户请求到达时运行。与传统的推理预测相比,这样做的好处是无论是功能模块还是后端GPU服务器,以及与之相连的其他相关机器学习服务,都可以按量付费,自动缩放,所以在保证性能的同时保证服务的稳定性:“物联网等物联网领域”目前,很多厂商都在推出自己的智能音箱产品。用户可以对智能音箱说一句话,智能音箱可以通过互联网将这句话传递给后台服务,然后得到反馈结果返回给用户。通过Serverless架构,可以结合API网关、云函数、数据库产品,替代传统的服务器或虚拟机。通过这样的架构,一方面可以保证资源按量付费,功能部分只在使用时才计费。另一方面,当用户量增加时,通过Serverless实现的智能音箱系统后端,也会进行Elasticscaling,保证用户端服务的稳定性。当需要维护其中一个功能时,相当于维护了一个单一的功能,不会对主进程造成额外的风险。相对来说,会更安全、稳定等:(IoT后端处理示例)《监控与自动化运维》在实际生产中,往往需要做一些监控脚本来监控网站服务或API服务是否健康,包括可用性、响应速度等。传统的方式是通过一些网站监控平台(如阿里云监控等)提供监控和报警服务。互联的服务器会定期发起请求,判断网站或服务的可用性。当然,其中许多服务都很受欢迎。尽管它们用途广泛,但在实践中并不一定适用。比如现在需要监控某个网站的状态码,不同区域的延迟,设置一个延迟阈值。当网站状态异常或延迟过大时,将通过邮件发送通知和告警。对于这样的定制需求,目前据说大部分监控平台都难以直接实现,所以定制开发一款网站状态监控工具就显得尤为重要。此外,在实际生产运维中,对使用的云服务进行监控和告警也是非常必要的。例如,在使用Hadoop和Spark时,需要监控节点的健康状况;使用K8S时,需要监控APIServer、ETCD等多维度指标;使用Kafka时,还需要监控数据积压、Topic、Consumer等指标;对这些服务的监控往往无法通过简单的URL和某些状态来完成,传统运维中通常会在额外的机器上设置一个定时任务来绕过监控相关服务。Serverless架构的一个很重要的应用场景就是运维、监控和告警。结合定时触发器使用,可以非常简单的实现对某些资源的健康状态的监控和感知,并进行一些告警功能的构建和自动化运维能力。构建:(网站监控告警示例)结语从虚拟空间到云主机,从自建数据库等服务到云数据库等服务,云计算发展迅猛,但未来方向和形态模糊,没有人知道云计算的最终状态是什么。的确,现在有人说Serverless实现了云计算的初衷,Serverless才是真正的云计算,但谁也不能肯定Serverless就是云计算的最终体现。客观的说,或许,Serverless只是一个过渡的产物,但这需要时间去验证。原文链接本文为阿里云原创内容,未经许可不得转载。