多角度解读 Serverless | 🏆 技术专题第七期征文

时间:2021-1-8 作者:admin

Serveless 到底是什么?

  • 顾名思义,Serverless 即无服务器运算,一种云计算的产物,它不是具体的技术,只是一套理念思想。在行业内对 Serverless 有几种解读方法:

    • 在某些场景下可以解读为一种软件架构方法,通常称为 Serverless 架构
    • 在另外一些情况下,又可以代表一种产品形态,称为 Serverless 产品

Serverless 架构指开发者实现的服务端逻辑运行在无状态的计算容器中,由事件触发,完全被第三方管理(如服务运营商),其业务层面的状态则被开发者使用的数据库和存储资源所记录。

​ 而说起 Serverless 产品,代表的是无需理解、管理服务,按需使用,按使用付费的产品。 Serverless 产品中,其实也可以包括存储,计算等多种类型的产品,而典型的计算产品,就是云函数这种形态。

​ 云函数,或者称为 FaaS (Function as a Server,函数即服务),它和 BaaS(Backend as a Server,后端即服务) 一起,都可以称为 Serverless 产品。通过组合这些产品,开发者可以构建自身的业务 Serveless 架构。

Serverless 架构的优点

降低运维需求

Serverless 是非常简单的外包解决方案。

  • Serverless 使得应用与服务器解耦,业务上线前无需预估资源,无需进行服务器购买、配置。
  • Serverless 也使得底层运维工作量进一步降低,业务上线后,也无需担忧服务器运维,而是全部交给了云平台或云厂商。
降低开发成本
  • IaaS (Infrastructure as a Server,基础设施即服务)和 PaaS (Platform as a Server,平台即服务)存在的前提是,服务器和操作系统管理可以商品化。Serverless 作为另一种服务的结果是整个应用程序组件被商品化。
扩展能力
  • Serverless 架构一个显而易见的优点即“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。从基本的基础设施方面受益最大的好处是,您只需支付您所需要的计算能力。
更简单的管理
  • Serverless 架构明显比其他架构更简单。更少的组件,就意味着您的管理开销会更少。
“绿色” 的计算
  • 按照《福布斯》杂志的统计,在商业和企业数据中心的典型服务器仅提供5%~15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。随着 Serverless 架构的出现,让服务提供商提供我们的计算能力最大限度满足实时需求。这将使我们更有效地利用计算资源。

Serverless 技术的特点

区别于前面讲的 Serveless 架构,这里的技术特点对象特指 Serveless 产品中的计算产品,即云函数,云函数包括了如下的技术特性

1.事件驱动
  • 云函数由事件驱动,即事件触发函数
  • Serverless 应用不会类似于原生的[监听 – 处理] 类型的应用一直在线,而是按需启动
  • 事件的定义可以很丰富,一次 http 请求,一个文件上传,一次数据库记录修改,一条消息发送等等都可以被定义为事件

2.单事件处理
  • 触发启动的一个云函数实例,一次只处理一个事件
  • 无需在代码内考虑高并发高可靠性,可以专注于业务
  • 通过云函数实例的高并发能力,实现业务高并发

3.自动弹性压缩
  • 由于云函数事件驱动及单事件处理的特性,云函数通过自动的伸缩来支持业务的高并发
  • 针对业务的实际事件或请求数,云函数自动弹性合适的处理实例来承载实际业务量
  • 在没有事件或请求时,无运行实例,不占用资源

4. 无状态开发
  • 云函数运行时根据业务弹性,可能伸缩到 0,无法在运行环境中保存状态数据
  • 分布式开发中,均需要保持应用的无状态,以便以水平伸缩
  • 可以利用外部服务、产品,例如数据库或缓存,实现状态数据的保存

Serverless 的应用场景

Web应用
  • Serverless 架构可以支持各类静态和动态Web应用,如RESTful API 的各类请求动作(get、post等)可被映射成 FaaS 的函数。通过 FaaS 的自动弹性扩展功能,Serverless Web应用可以快速能承载高访问量的站点。
移动互联网
  • Serverless 应用通过 BaaS 对接后端不同的服务而满足业务需求,提高应用开发的效率。前端通过FaaS提供的自动弹性扩展对接移动端的流量,开发者可以更轻松地应对突发的流量增长。在 FaaS 的架构下,应用以函数的形式存在。各个函数逻辑之间相对独立,应用更新变得更容易,使新功能的开发、测试和上线的时间更短。
物联网(Internet of Things,IoT)
  • 物联网(Internet of Things,IoT)应用需要对接各种不同的数量庞大的设备。不同的设备需要持续采集并传送数据至服务端。Serverless 架构可以帮助物联网应用对接不同的数据输入源。
多媒体处理
  • 视频和图片网站需要对用户上传的图片和视频信息进行加工和转换。但是这种多媒体转换的工作并不是无时无刻都在进行的,只有在一些特定事件发生时才需要被执行,比如用户上传或编辑图片和视频时。通过 Serverless 的事件驱动机制,用户可以在特定事件发生时触发处理逻辑,从而节省了空闲时段计算资源的开销,最终降低了运维的成本。
数据及事件流处理
  • Serverless 可以用于对一些持续不断的事件流和数据流进行实时分析和处理,对事件和数据进行实时的过滤、转换和分析,进而触发下一步的处理。比如,对各类系统的日志或社交媒体信息进行实时分析,针对符合特定特征的关键信息进行记录和告警。
系统集成
  • Serverless 应用的函数式架构非常适合用于实现系统集成。用户无须像过去一样为了某些简单的集成逻辑而开发和运维一个完整的应用,用户可以更专注于所需的集成逻辑,只编写和集成相关的代码逻辑,而不是一个完整的应用。函数应用的分散式的架构,使得集成逻辑的新增和变更更加灵活。

上述都能在常规的容器云平台上构建部署,不过有了 Serverless 更高层次的抽象和封装,我们可以更快地开发构建部署,服务可以有更好的运行姿态,从而一步步接近我们想象中那个只写代码,不关心服务器的美好愿景。

为什么要用 Serveless

  • “Serveless` 是云计算发展的必经历程
  • 理念、技术大多不是凭空诞生的,很明显 Serveless 的应用就是为了解放生产
    • Serverless 模式下封装了几乎所有的底层资源和系统运维工作,开发人员更容易使用云基础设施,只需将大多精力关注业务层面,交付时间变快。
    • Serverless 可以降低成本,体现在计算资源和人力成本两个层面。弹性扩缩容量和按需付费使得计算资源由固定成本变成了可变成本,由于不需要过多关注底层架构,可以缩小这部分的工作量和人力占比。

Serverless 现状与局限性

完全依赖第三方,厂商锁定
  • 平台提供 Serverless 架构给玩家,如 AWS Lambda ,运行它所需要使用的 AWS 指定的服务,比如 API 网关DynamoDBS3 等,一旦应用此服务开发复杂系统,就会粘紧AWS,付费计算任由运营厂商说了算,有种被掐脖子的感觉。也是因为这个主要原因,大家或多或少都心存顾虑,不敢真正地放上自己的线上服务,所以实际落地寥寥可数
  • 迁移成本高。不同平台有基于它们平台内部特定的事件触发机制,导致迁移成本很高。
冷启动慢&高频触发场景
  • Serverless 技术通过事件触发,在应用不运行的时候,会进入“休眠状态”,下次请求来临时,应用需要一定启用时间,即“冷启动”,这个冷启动时间会因为开发语言不同而不同Node.js 应用还好,如果是拥有虚拟机的Java 和 C# 耗用的时间可能比较长,这个时候可以结合一些手段来定期唤醒应用。如果应用处于长期不间断运行状态,处理大量请求,这个时候 Serverless 模式其实是不适合的,因为计费会很高。
工具链(调试、开发、日志工具缺乏)
  • 有过 Serverless 相关实践的朋友应该都能深深感受到这一点,不过这也是生态不够成熟导致的,如果 Serverless 应用越来越火的话,这个痛点是会慢慢消失的。

结语

​ 看好和看扁 Serverless 的人都很多,但毋庸置疑的是Serverless 应用投入生产还有很长一段路要走。

参考文章:

从IaaS到FaaS—— Serverless架构的前世今生

Serverless 基本概念入门

Serverless的初心、现状和未来

当我们聊Serverless时你应该知道这些

Serverless架构的优缺点

花了1000G,终于弄清楚了Serverless (中):Serverless 架构的优缺点

🏆 技术专题第七期 |万物皆可 Serverless

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。