赞
踩
Serverless
又名无服务器,所谓无服务器并非是说不需要依赖和依靠服务器等资源,而是开发者再也不用过多考虑服务器的问题,可以更专注在产品代码上。Serverless
是一种软件系统架构的思想和方法,它不是软件框架、类库或者工具。它与传统架构的不同之处在于,完全由第三方管理,由事件触发,存在于无状态(Stateless
)、 暂存(可能只存在于一次调用的过程中)计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时(运行时通俗的讲 就是运行环境,比如 nodejs
环境,java
环境,php
环境)。Serverless
真正做到了部署应用 无需涉及基础设施的建设,自动构建、部署和启动服务。
- 第一种:
狭义 Serverless
(最常见)=Serverless computing 架构
=FaaS 架构
=Trigger(事件驱动)+ FaaS(函数即服务)+ BaaS
(后端即服务,持久化或第三方服务)=FaaS + BaaS
- 第二种:广义
Serverless
=服务端免运维
=具备 Serverless 特性的云服务
- FAAS:函数及服务,通俗来说就是我们可以写一个函数,在该函数内执行业务逻辑,函数由fas平台运行
- BAAS:后端及服务,通常指云服务,该云服务常指中间件服务
整体架构十分简单明了, 用 FC 替代了 Web 服务器,但是换来的是免运维,弹性扩容,按需付费等一系列优点
目前,Serverless 的应用场景广泛,大部分传统业务均可以在 Serverless 云函数上完美支持
前端和后端分离后,彼此独立,这样就导致前端需要关注一些后端关注的问题,如下
作为一个前端,确实大多数人对于服务端的环境,部署基础设施等等东西并不了解。但是现在前端是独立的部署,前端必然面临这些东西。这就是serverless要解决的问题。
传统开发模式
新型的serverless开发模式
正常来说,用户开发 Server 端服务,常常面临开发效率,运维成本高,机器资源弹性伸缩等痛点,而使用 Serverless 架构可以很好的解决上述问题。下面是传统架构和 Serverless 架构的对比:
优势
Serverless
架构中,你不用关心应用运行的资源(比如服务配置、磁盘大小)只提供一份代码就行。Serverless
架构中,计费方式按实际使用量计费(比如函数调用次数、运 行时长),不按传统的执行代码所需的资源计费(比如固定 CPU
)。计费粒度也精确到了毫 秒级,而不是传统的小时级别。个别云厂商推出了每个月的免费额度,比如腾讯云提供了每 个月 40 万 GBs 的资源使用额度和 100 万次调用次数的免费额度。中小企业的网站访问量不 是特别大的话完全可以免费使用Serverless
架构的弹性伸缩更自动化、更精确,可以快速根据业务并发扩容更 多的实例,甚至允许缩容到零实例状态来实现零费用,对用户来说是完全无感知的。而传统 架构对服务器(虚拟机)进行扩容,虚拟机的启动速度也比较慢,需要几分钟甚至更久。不足
当然了 ServerLess 是很诱人,但却不是万能的,有些场景还是不适合的。
事件驱动
单事件处理
自动弹性伸缩
无状态开发
Serverless 应用本质上是由一个个 FaaS 函数组成的,Serverless 应用的每一次运行,其实是单个或多个函数的运行,所以 Serverelss 的运行原理,本质上就是函数的运行原理
函数调用链路:事件驱动函数执行
对于 FaaS 函数来说,一方面可以通过事件来触发执行,另一方面也可以直接调用 API 来执行。FaaS 平台都提供了执行函数的 API。
函数调用方式 :同步调用与异步调用
函数生命周期:冷启动与热启动
下载代码
: FaaS 平台本身不会存储代码,而是将代码放在对象存储中,需要执行函数的时候,再从对象存储中将函数代码下载下来并解压,因此 FaaS 平台一般都会对代码包的大小进行限制,通常代码包不能超过 50MB。
启动容器
: 代码下载完成后,FaaS 会根据函数的配置,启动对应容器,FaaS 使用容器进行资源隔离。
初始化运行环境
: 分析代码依赖、执行用户初始化逻辑、初始化入口函数之外的代码等。
运行代码
: 调用入口函数执行代码。
当函数第一次执行时,会经过完整的四个步骤,前三个过程统称为“冷启动”,最后一步称为 “热启动”。
下面是一个函数的请求示意图,其中 “请求1” “请求3” 是冷启动,“请求2” 是热启动。
函数执行完毕后销毁运行环境,虽然对首次函数执行的性能有损耗,但极大提高了资源利用效率,只有需要执行代码的时候才初始化环境、消耗硬件资源。
并且如果你的应用请求量比较大,则大部分时候函数的执行可能都是热启动。
从函数运行的生命周期中你可以发现,如果函数每分钟都执行,则函数几乎都是热启动的,也就是会重复使用之前的执行上下文
发送通知
诸如 PUSH Notification、邮件通知接口、短信,这一类服务来说,他们都需要基础设施来搭建。并且,他们对实时性的要求相对没有那么高。即使在时间上晚来几秒钟,用户还是能接受的。在我们所见到的短信发送的例子里,一般都会假设用户能在 60 秒内收到短信。因此,在这种时间 1s 的误差,用户也不会恼火的。
轻量级 API
Serverless 特别适合于,轻量级快速变化地 API。其实,我一直没有想到一个合适的例子。在我的假想里,一个 AutoSuggest 的 API 可能就是这样的 API,但是这种 API 在有些时候,往往会伴随着相当复杂的业务。于是,便想举一个 Featrue Toggle 的例子,尽管有一些不合适。但是,可能是最有价值的部分。
物联网
当我们谈及物联网的时候,我们会讨论事件触发、传输协议、海量数据(数据存储、数据分析)。而有了 Serverless,那么再多的数据,处理起来也是相当容易的一件事。对于一个物联网应用的服务端来说,系统需要收集来自各个地方的数据,并创建一个个 pipeline 来处理、过滤、转换这些数据,并将数据存储到数据库中。对于硬件开发人员来说,对接不同的硬件,本身就是一种挑战。而直接使用诸如 AWS IoT 这样国,可以在某种程度上,帮助我们更好地开发出写服务端连接的应用。
数据统计分析等
数据统计本身只需要很少的计算量,但是生成图表,则可以定期生成。在接收数据的时候,我们不需要考虑任何延时带来的问题。50~200 ms 的延时,并不会对我们的系统造成什么影响。
serverless
方面相比其他厂商支持更好一些serverless
合作在腾讯云中集成了 serverless Framework
用我们喜欢的框架开发 serverless
应用。也可以让我们快速部署老项目。我是程序员小月,更多干货在公众号「前端进阶之旅」
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。