Serverless

什么是Serverless?

Serverless的字面含义是无服务器,但这个无服务器不是真的不需要服务器,而是不需要关注服务器。

在CNCF关于Serverless的白皮书中,更多的关注not require server managemenbilled in response to the exact demand,也即无需关心运维按需付费这两点。

无服务器计算是指构建和运行不需要服务器管理的应用程序的概念。它描述了一个更细粒度的部署模型,将应用程序捆绑为一个或多个功能,上传到一个平台,然后根据当前确切的需求执行、扩展和计费。
——摘自《CNCF WG-Serverless Whitepaper v1.》

而UC Berkeley提出云计算的架构定义serverless com-puting = FaaS + BaaS.
关于Serverless的含义,UC Berkeley给出了一个生动形象的解释:

在云的上下文中,Serverful 的计算就像使用低级的汇编语言编程,而 Serverless 的计算就像使用 Python 这样的高级语言进行编程。例如 c = a + b 这样简单的表达式,如果用汇编描述,就必须先选择几个寄存器,把值加载到寄存器,进行数学计算,再存储结果。这就好比今天在云环境下 Serverful 的计算,开发首先需要分配或找到可用的资源,然后加载代码和数据,再执行计算,将计算的结果存储起来,最后还需要管理资源的释放。自动化内存管理使程序员不必管理内存资源,而无服务器计算使程序员不必管理服务器资源。
——摘自《A Berkeley View on Serverless Computing》

Serverless发展历程

Serverless 架构是云的自然延伸。如下图所示,从容器编排到Paas到Serverless,这个发展过程让我们更多的关注业务,而更少的去关注底层逻辑。
在这里插入图片描述
下图是CNCF组织发布的Serverless生态:
在这里插入图片描述

Serverless的适用场景

Serverless的优势

如果要考虑Serverless在什么场景下适用,也即如何落地,则需要先了解Serverless自身的特点。

Serverless的特性,其实两点就可以完全概括,即无需关注运维按需付费
无需关注运维:开发者无需关心服务运维。如资源分配、弹性伸缩、负载均衡配置。这意味着你可以不需要了解运维细节就能轻松实现高可用

  • 降低运维成本:不需要找运维相关人员专门进行资源管理。
  • 可以快速试错:可以将基础服务交给平台,将精力及资源更多的投入到业务研发当中。
  • 缩短交付时间:Serverless架构的服务粒度更细,能够快速迭代,而不影响其他服务。
  • 灵活的拓展性: Serverless没有“预先计划的容量”的概念,也不需要配置“自动伸缩”触发器或规则。 扩展是自动进行的。

按需付费:按资源使用比例支付而不是按资源分配比例支付。因此不使用则不计费。

  • 降低运营成本:例如在中后台场景下,许多服务并非频繁调用仍需持续付费,按需付费能够有效降低项目的运营成本。
    在这里插入图片描述
Serverless的挑战

由于Serverless架构自身设计的原因,因此当前的Serverless也存在着一些挑战。为了能够弹性伸缩,Serverless自身是没有状态存储的。由于Serverless是事件触发,且事件触发时才创建实例,因此会有一定延时。同时,Serverless降低运维门槛的同时,也失去了资源掌控度。在调试时并不如传统模式方便。因此,Serverless会带来以下问题:

  • 由于运行时更具动态性,与 IaaS 和 PaaS 相比,调试可能更具挑战性。
  • 由于按需结构,如果运行时在空闲时删除函数的所有实例,那么某些无服务器运行 时的“冷启动”方面可能会成为性能问题。
  • 在复杂的场景下可能引入更多的操作量
  • 缺乏标准化和生态系统成熟度。
  • 由于平台的编程模型、事件/消息接口和 BaaS 产品,平台锁定的潜力。
Serverless的适用场景

因此以下场景是Serverless更适用于不依赖状态、对冷启动时间不敏感的场景,可用于应对使用量不可预测的场景,由于无需提前申请资源,在需要快速迭代的场景中也能发挥作用。
可以看到尽管Serverless相对于传统的开发模式有着许多优点,但它并不是万能的,在不适合的场景下适用,或许反而增加操作成本。下文我们将讨论Serverless在合适场景下带来的一些变革。

在这里插入图片描述

BFF:Serverless允许开发人员在 BaaS API 之上构建 REST API,这样他们就可以减少对后端的依赖,降低联调时间。在BFF场景下,以及服务端渲染场景下能够使用Serverless实现云端一体进行开发提效。
在这里插入图片描述

SSR:传统的CSR(客户端渲染)构建方式,因为页面内容在客户端渲染时解析,对于需要能够被搜索引擎爬虫索引到的页面并不SEO友好。目前常见的方式是进行SSR(服务端渲染)将页面解析后再返回,此时服务端代码与页面代码部署在一起能够进行开发提效。
在这里插入图片描述

批处理:高强度并行计算、 IO 或网络访问的作业非常适合Serverless场景,批处理作业可以在以弹性方式运行的时候有效地消耗它们所需要的资源,而不会在不使用它们的时候在当天剩下的时间里产生资源成本。

中后台:中长尾应用服务使用频率往往并不高,而传统的服务方式即时不使用仍然需要支付服务存储费用,Serverless场景下按需付费可以有效降低成本。
在这里插入图片描述

AI/Iot:随着连接到网络的自主设备的爆炸式增长,带来了额外的流量,这些流量不仅体积庞 大,而且比 HTTP 使用更轻的协议。高效的云服务必须能够快速响应信息,并且能 够对信息的扩散或者突然涌入做出规模化的响应。无服务器功能可以有效地管理和过 滤来自物联网设备的 MQTT 消息。它们可以弹性伸缩,并且可以屏蔽负载下游的其他服务。

多媒体处理:多媒体处理场景,往往在某一时间会涌入大流量,Serverless可以自动弹性扩容保证服务的高可用,同时在低使用场景下又能有效降低资费。
在这里插入图片描述

Serverless的技术方案

Serverless处理模型

我们可以将 FaaS 解决方案概括为如下图所示的几个关键元素:在这里插入图片描述

  • 事件源:触发事件或将事件流转化为一个或多个函数实例
  • Function 实例:一个单一的函数/微服务,可以根据需求进行扩展
  • 源码:部署、控制和监视函数实例及其源代码
  • Baas服务:平台服务-FaaS 解决方案使用的一般集群或云服务(有时称为 Backend-as-a-
    Service)

在这里插入图片描述

函数计算(Faas)

在这里插入图片描述
函数的生命周期始于编写代码和提供规范和元数据,“构建器”实体将获取代码和规范,进行编译,并将其转化为构件(代码二进制、包或容 器映像)。然后,工件被部署到一个集群上,其中一个控制器实体负责根据实例上的 事件流量和/或负载来缩放函数实例的数量。

参考资料

  • Serverless白皮书:https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf

  • CNCF Serverless
    workflow:https://github.com/serverlessworkflow/specification/blob/main/specification.md

  • UC Berkeley:https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf?spm=ata.21736010.0.0.30a075f8liRLAf&file=EECS-2019-3.pdf

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值