(大前端)Serverless 学习记录

93 阅读18分钟

是什么?

由事件(event)驱动(例如 HTTP、pub/sub)的全托管计算服务。

1、概念:

Serverless = FaaS + BaaS

FaaS 提供运行函数的功能,且每个函数的执行都是孤立和短暂的。但我们需要持久存储和临时存储,以及在存储中进行数据管理,所以需要 BaaS。

BaaS 是一系列后端的功能的集合,比如云数据库、对象存储、消息队列、通知服务。没有 BaaS,函数的能力是非常有限的。整个 BaaS 也都由云供应商厂商提供,开发者不需要关心具体细节、实现,只需要在 FaaS 中使用 BaaS,这样才能构建整个应用。

2、分类:

Serverless 下包含的两个概念:函数即服务FaaS、后端即服务Baas.

FaaS∶让用户无需关注基础设施服务器,让客户专注于编写和上传核心业务代码,交由平台完成部署、调度、流量分发、弹性伸缩等能力。

BaaS∶可以直接向云厂商购买的云产品和云服务,实现了开箱即用,无需考虑部署、升级、优化等问题。

3、特点:

● 优点:

(1)、无需运维

Serverless 架构的核心思想是:构建和运行程序不需要管理服务器等底层资源。

基于 Serverless 架构,应用的部署、扩容、备份、容灾、监控、日志等都不需要开发者关心,这些功能全都由云供应商提供。开发者就可以从以往繁琐的运维工作中解脱出来,专心实现自己的产品。

(2)、低运营成本

传统的 Serverfull 架构,我们需要为资源付费。但很多时候云服务器等资源都是空闲的,但也需要计算费用,这造成了不必要的浪费。但 Serverless 架构,我们只需要为计算付费。

(3)、更简单

相比传统架构,基于 Serverless 架构的开发将变得更简单。云计算平台已经为我们提供了一系列的基础设施,我们只需要在此之上进行开发。传统架构,犹如编程语言中的底层语言,如汇编,我们需要关心每一个细节,细致到 CPU 寄存器这样的级别。

而基于 Serverless 的开发,就犹如 Node.js、Python 等高级语言,我们只需要专注于业务逻辑的实现,可以很高效地构建一个应用,并且这个应用天然就是弹性可伸缩的。

(4)、事件驱动

FaaS函数是短暂且临时的,用完就销毁,FaaS函数在接收请求时产生资源消耗,不使用就没有消耗,用完资源后就会马上释放。

(5)、自动扩缩容

用户无需关注 FaaS 函数的水平扩展,Serverless 平台会自动根据调用量扩展运行代码所需要的容器,轻松做到高并发调用。

(6)、函数即应用,各 FaaS 函数可以独立地进行扩缩容,粒度小扩容快。

● 缺点:

(1)、性能

相比传统架构,Serverless 架构下,程序的运行需要经过一些列步骤:

1、下载代码

2、启动容器

3、启动运行环境

4、执行代码

前三步统称为冷启动。传统应用则完全没有冷启动时间。冷启动时间的长短,直接决定了应用性能的高低。

解决方案:

a、冷启动时间需要 Serverless 服务提供商去优化;

b、第一,从应用的角度,选用合适的编程语言。因为 Java 等高级语言的冷启动时间大约是 Node.js、Python 等语言的 100 倍。第二,为函数分配合适的内存。一般而言,内存越大,冷启动的时间越短。

c、重复利用函数的执行上下文。当一个事件来临,函数冷启动并执行之后,运行环境并不会立即被销毁,而是在一定时间内处于冷冻状态继续等待下一次函数执行。

d、(笨方法)对函数进行预热。通过定时对函数进行调用的方式,使函数一直处于“温暖”状态,从而避免真实请求到来时函数进行冷启动,进而达到提高性能的目的。

(2)、严重依赖云服务。

云服务的稳定性直接决定了业务的稳定性。

(3)、无状态。

要想实现自由的缩放,无状态是必须的,而对于有状态的服务,使用 serverless 这就丧失了灵活性,有状态服务需要与存储交互就不可避免的增加了延迟和复杂性。

(4)、本地测试

Serverless 应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境,但对于无服务应用的集成或者端到端测试尤其困难,很难在本地模拟应用程序的各种连接,并与性能和缩放的特性结合起来测试,并且 serverless 应用本身也是分布式的,简单的将无数的 FaaS 和 BaaS 组件粘合起来也是有挑战性的。

4、发展历程

1、从哪来?

2012 年,Serverless 这个单词第一次出现,由 Iron 公司提出,字面意思就是不需要服务器。但是真正被大家所熟知,是在 2014 年 AWS 推出 Lambda 的时候。

Lambda 产品的推出开启了云计算的新时代,之后所有的大厂都在跟进,比如微软、谷歌、IBM 都先后推出自己的 Serverless 产品。国内是在 2017 年的时候,阿里云和腾讯云先后推出了自己的 Serverless 平台。

2、到哪去?

随着云计算的发展,Serverless 已经成为一个技术趋势、一个理念、一个云的发展方向。

大面积取代 Serverful,变为默认的计算范式:虽然 Serverful 不会完全消失,但随着 Serverless 存在的不足被逐个攻克,Serverlsss 在云计算中所占的比重将会逐渐提升,变成云时代默认的计算范式。

(1)、拥抱整个容器生态:Serverless 会更多的去拥抱整个容器生态,当下容器是整个业界的一个主流的趋势。Serverless 会和容器做更多的集成,比如镜像部署、镜像加速、以及集成 K8S 很多的能力。

(2)、加速运维关系的变化:Serverless 将会加速运维关系的转变,运维同学会从资源运维,逐步走向业务运维。

(3)、复杂任务编排、工具链及可观测等能力提升:Serverless 会加强复杂任务编排、工具链和可观测等方面的能力。因为 Serverless 平台对底层资源做了高度封装,所以一定要把很多的监控指标去透露给用户,通过这些指标来做业务级的管理和管控。

为什么?

1、与传统方式的区别:

(1)、传统的架构模式是指C/S架构。在典型的web应用程序中,服务器接收前端的HTTP请求处理,在保存或查询数据库之前,数据可能会经过多个应用层,最终后端会返回一个响应。在传统开发模式中,开发流程:产品提出需求 -> 设计师设计页面 -> 服务端 和 前端分别开发 -> 前后端联调 -> 运维。在传统开发模式中,开发一个应用程序,从开始到上线需要不同的角色来做不同的事情,沟通成本非常大,并且运维过程中需要考虑到 服务器的负载均衡、事务、集群、缓存、消息传递和数据冗余等等这些事情,在目前传统模式中存在如上问题。

(2)、Serverless架构中。应用业务逻辑是基于 FaaS 架构形成多个相互独立的功能组件的。以API服务的形式向外提供服务,在 FaaS 中,后端的应用被拆分成为一个个函数,我们只需要编写完成函数后部署到serverless服务即可。后续我们也不用关心任何服务器的操作。整个流程就只需要一个前端工程师的角色来完成所有的开发工作,沟通成本就降低了。

2、对比传统方式的优势:

(1)、低运营成本

在传统应用系统的部署实施中,必须按业务峰值需求来构建业务系统,但在大部分时间里该业务系统是空闲的,这就导致了严重的资源浪费和成本上升。在 Serverless 架构下,不同用户能够通过共享网络、硬盘、CPU 资源,峰谷时按需自动缩容,按调用次数收费,不调用不收费,有效节约企业成本支出。(PS:占比不高,主要是运维问题)

(2)、简化设备运维

在 Serverless 架构中,开发人员面对的将是自定义或者第三方开发的 API 和 URL,云厂商部署好底层基础设施与运维设施,让开发人员专注于核心代码和应用的开发。

(3)、提升可维护性

目前,一些公有云服务中提供了大量的服务,如登录、鉴权服务,云数据库服务等第三方服务,它们在安全性、可用性、性能方面都进行了大量优化,在 Serverless 架构下,第三方公司集成了各类服务,运维服务的有效性得到很大的提升,降低成本。

(4)、开发速度更快

由于开发人员仅需专注于业务逻辑功能的开发,无需关心应用系统部署、调度、流量分发、弹性伸缩等功能的研发,软件架构和软件功能实现都大大简化,不仅节省开发时间,更可提升开发效率,降低开发难度。

对前端的影响

开发模式

MVVM存在的问题

1、UI 和业务混乱。

Vue 框架是传统的 MVVM 模式,有三个概念:Model、View、ViewModel,都在端侧定义并管理的。统一管理的好处是一个工程维护一套业务,研发效率比较高;缺点就是代码管理成本比较高,复杂业务需要借助一些端侧代码框架,比如 Vuex。虽然但是, UI 和业务的管理还是比较混乱。

2、技术栈的适配和迁移成本较高。

比如从 Vue 迁移到 React 或者是小程序。不光要适配 UI 层,还需要重写逻辑。但若是使用云函数的开发方式,就不需要重写业务逻辑,因为这部分是卸载云函数上的,可复用的,我们在迁移的过程中只需要关注交互就行了。

3、前端对接口的控制能力不足。

服务端会针对业务提供定制的接口,复用度较差。数据格式转化到 Model 的过程中,还需要端侧做一些适配、转化及容错处理。

当然前端也可以通过 BFF 层,Backend For Frontend,顾名思义,服务前端的后端。但这是一层是非常轻量级的服务层,主要做的是数据的重组,字段补全、格式校验、标准化等能力。最终的数据能力还是没有大的改变。

基于FAAS

还是熟悉的 MVVM 研发模式,只是端侧只剩下了View、把 Model 和 ViewModel 都迁移到了 FaaS 侧。大部分更新 UI 的工作通过事件通信来实现。

接口的服务能力变了:FaaS 函数跟 Severless 的配合,服务端会提供领域级别的服务,这些领域服务一般设计成可复用,不跟具体的业务逻辑耦合。

对业务的逻辑处理,数据的编排和重组,都放在 FaaS 层。这样前端的逻辑也放在了 FaaS,FaaS 的能力和职责是被放大了。

FaaS 本身是一种无状态的服务,在逻辑处理过程中如果需要使用一些状态存储的能力,就要借助于 BaaS 才能完成一些状态保存的能力。而且业务逻辑和数据编排的能力放在一起,可以让整个业务逻辑不再割裂,可以更好地进行抽象设计,甚至编排。

应用场景

比较适合的场景:

(1)、异步的并发,组件可独立部署和扩展

(2)、应对突发或服务使用量不可预测(主要是为了节约成本,因为 Serverless 应用在不运行时不收费)

(3)、短暂、无状态的应用,对冷启动时间不敏感

(4)、需要快速开发迭代的业务(因为无需提前申请资源,因此可以加快业务上线速度)

**SSR

**小程序云开发

云函数

腾讯云:云函数技术文档

是什么?

腾讯云云函数(Serverless Cloud Function,SCF),我们只需使用平台支持的语言编写核心代码并设置代码运行的条件,即可在腾讯云基础设施上弹性、安全地运行代码。

腾讯云云函数支持您通过 Serverless 控制台Serverless Framework云 API 开发、部署、测试函数。

相关概念:

1、 无服务器:开发者无需关心运维

2、 函数即服务:一种直接在云上运行无状态的、短暂的、由事件触发的代码的能力

3、 触发器和触发源:任何可以产生事件的。触发器在本身产生事件后,通过将事件传递给云函数来触发函数运行。触发器在触发函数时,具有同步和异步的方式。

a) 同步:触发器将等待函数执行完成并获取到函数执行结果;

b) 异步:触发器将仅触发函数而忽略函数执行结果。

4、 触发事件:触发器在触发函数时会将事件传递给云函数。事件以 JSON 格式的数据结构传递,并以函数 event 入参的方式传递给云函数,这些无需人工转换。

工作原理

1、函数运行时的实例模型

2、调用类型

(1)、同步调用:将会在调用请求发出后持续等待函数的执行结果返回。

(2)、异步调用:将不会等待结果返回,只发出请求并获得当前请求的 Request ID。

当发生异步调用时,异步事件会先放置到云函数内置的异步队列,然后再消费异步队列内的事件执行函数。异步队列有如下限制:异步队列是触发器维度的,一个函数触发器一个队列。

异步事件在队列中的保留时长最大 6 小时。

异步队列的长度上限为 10 万条消息。

3、SCF 事件函数

1、执行方法:对应项目的主函数,是程序执行的起点。

2、函数入参:即通常理解的函数入参,但在云函数环境下,入口函数的入参为平台固定值,详情见 函数入参。

3、函数返回:对应项目中主+函数的返回值,函数返回后,代码执行结束。

4、函数返回

SCF 平台会获取到云函数执行完成后的返回值,并根据下表中不同的触发方式进行处理。

触发方式处理方式
同步触发● 通过 API 网关、云 API 同步 invoke 触发函数的方式为同步触发。● 使用同步方式触发的函数在执行期间,SCF 平台不会返回触发结果。● 在函数执行完成后,SCF 平台会将函数返回值封装为 JSON 格式并返回给调用方。
异步触发● 使用异步方式触发的云函数,SCF 平台接收触发事件后,会返回触发请求 ID 。● 在函数执行完成后,函数的返回值会封装为 JSON 格式并存储在日志中。● 用户可在函数执行完成后,通过返回的请求 ID 查询日志获取该异步触发函数的返回值。

注意:Node.js 语言会返回 JSONObject 结构

5、选型分析

以下从不同维度对比 SCF 两种不同函数类型的特性:

条目事件函数Web 函数
设计思想新的事件驱动架构(EDA)开发模式,通过事件触发函数运行,纯粹纯托管 FaaS,天然与云上产品打通,降低开发门槛,缩短研发周期。应对主流的 Serverlessful 多线程开发模式,解决传统 Web 框架 FaaS 化改造成本高的问题,用户可以直接发送 HTTP 请求到 URL 触发函数执行。
编程范式函数入参固定为 JSON 格式的 event 和 context,其中 context 为平台信息,不支持用户自定义,event 为用户自定义信息或格式固定的触发器传入信息。函数接收原生的 HTTP 或 WebSocket 请求,函数的编写方式接近原生的 Web 服务,并可通过请求头、请求体获取事件结构。
部署方式代码、镜像代码、镜像
触发支持定时触发器、Ckafka 触发器、COS 触发器、API 网关触发器、CLB 触发器、MPS 触发器、TDMQ 触发器、CLS 触发器、云 API。API 网关器,支持 HTTP 或者 WebSocket 协议。
同步/异步执行同步/异步同步
请求多并发不支持支持
自定义启动文件不支持支持
设置监听端口不需要需要监听固定端口 9000
应用场景与云产品事件结合紧密的业务、拆分合适粒度的业务、计算型密集型场景。Web 建站、API 服务站点托管。

6、应用场景:

1、移动及 Web 应用

云函数可以作为移动应用及 Web 应用的后端,实现服务端应用逻辑,并通过 API 对外提供服务。通过与云缓存、云数据库、对象存储等产品的紧密结合,开发者能够构建可弹性扩展的移动或 Web 应用程序,轻松创建丰富的无服务器后端,并且这些程序可在多个数据中心高可用运行,无需在可扩展性、备份冗余方面执行任何管理工作。

2、小程序

云开发 是微信团队和腾讯云联合开发的,集成于小程序控制台的原生 Serverless 云服务。其核心功能包括:云函数、云数据库和云存储。其中云函数可以让开发者在云端运行代码,开发者只需编写自身业务逻辑代码。结合微信私有默认鉴权,平台保证安全和隔离性,并且根据请求自动伸缩。

我的总结

前端开发流程:

1、 根据需求抽象出领域模型

2、 在配置平台设计字段

3、 在云函数处理业务逻辑或编排数据

4、 在H5/小程序端渲染视图,处理交互

详细描述

1、 通过发掘需求的背景和内容,思考该需求是属于什么类型,它具备怎样的属性,完成该需求需要怎样的字段,怎样把字段做成更加通用的方式。或者说,这个需求能不能做成一个通用的组件。要做好这一点,需要多了解领域驱动设计(DDD)。

2、 配置平台不是传统的数据仓库,我理解它应该是我们领域模式的具体表现。它的字段应该是通俗易懂的干净的结构,是云函数数据结构的映射。所以,在设计配置中台字段的时候,不仅要基于显示需求,还是思考怎样设计出更符合领域模型的字段,更加通用可复用的字段。要做好这一点,需要靠经验的积累,同时也可以去学习同学们优秀设计方案。

3、 云函数现在的任务相当于 MVVM 中的 VM,在这里处理业务的具体逻辑、编排端侧需要的易用与渲染的数据结构。在动手之前,必须先充分了解配置平台的数据形态以及我们业务的核心需求是什么,返回怎样的数据是最有利于页面渲染的。

4、 端侧主要负责处理数据的状态、交互和视图渲染。得益于 vue 的响应式,我们处理数据的状态不用每次都手动更新,要警惕这样带来的弊端:无意义的响应式变化。要解决这个问题,就是要设计响应式变化的条件,设置触发响应式的开关。复杂的交互可以套用 hooks 的方式:一个基本的处理基础数据的 hook,这部分这一命名为 useXXStatus,一个套用基础 hook 能力的 control 层面的 hook 处理生命周期,事件,回调, 这部分可以命名为 useXX。