serverless及小程序云开发实践总结

# 一、Serverless 架构详解

# 1.1 什么是serverless

我们使用函数的时候不用关心后端IP、域名，只需要调用函数，后端的服务是一个函数。serverless并不是没有服务器，只是服务器部署在云上面的，比我们去自己维护更方便多

• Serverless又名无服务器,所谓无服务器并非是说不需要依赖和依靠服务器等资源,而是开发者再也不用过多考虑服务器的问题,可以更专注在产品代码上。
• Serverless是一种软件系统架构的思想和方法，它不是软件框架、类库或者工具。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态(Stateless)、 暂存(可能只存在于一次调用的过程中)计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时(运行时通俗的讲 就是运行环境，比如 nodejs 环境，java 环境，php 环境)。Serverless 真正做到了部署应用 无需涉及基础设施的建设，自动构建、部署和启动服务。

• 第一种：狭义 Serverless（最常见）= Serverless computing 架构 = FaaS 架构 = Trigger（事件驱动）+ FaaS（函数即服务）+ BaaS（后端即服务，持久化或第三方服务）= FaaS + BaaS
• 第二种：广义 Serverless = 服务端免运维 = 具备 Serverless 特性的云服务

• FAAS：函数及服务，通俗来说就是我们可以写一个函数，在该函数内执行业务逻辑，函数由fas平台运行
• BAAS：后端及服务，通常指云服务，该云服务常指中间件服务，

FAAS+BAAS 构成了Serverless架构

整体架构十分简单明了, 用 FC 替代了 Web 服务器，但是换来的是免运维，弹性扩容，按需付费等一系列优点

目前，Serverless 的应用场景广泛，大部分传统业务均可以在 Serverless 云函数上完美支持

# 1.2 Serverless要解决什么？

问题：前端和后端分离后，彼此独立，这样就导致前端需要关注一些后端关注的问题，如下。

• 完整的后端应用上线流程
• 机器管理运维：扩缩容
• 降级、熔断、限流
• 域名、性能、监控

是不是触及了很多同学的知识盲区。作为一个前端，确实大多数人对于服务端的环境，部署基础设施等等东西并不了解。但是现在前端是独立的部署，前端必然面临这些东西。这就是serverless要解决的问题。

# 1.3 Serverless做什么事？

问题：是不是可以弄一个工具，我们只需要关心前端代码，服务器的东西工具自动帮我们做好。

这就是serverless做的事情。如下图，我们只需要关心业务代码，不需要关心服务器的基础设施。

# 1.4 Serverless和函数计算的区别

# 1.5 Serverless 的技术特点

事件驱动

• 云函数的运行，是由事件驱动起来的，在有事件到来时，云函数会启动运行
• Serverless 应用不会类似于原有的「监听 - 处理」类型的应用一直在线，而是按需启动
• 事件的定义可以很丰富，一次 http 请求，一个文件上传，一次数据库条目修改，一条消息发送，都可以定义为事件

单事件处理

• 云函数由事件触发，而触发启动的一个云函数实例，一次仅处理一个事件
• 无需在代码内考虑高并发高可靠性，代码可以专注于业务，开发更简单
• 通过云函数实例的高并发能力，实现业务高并发

自动弹性伸缩

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

无状态开发

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

# 1.6 传统服务器架构 VS Serverless架构

1. 传统的开发模式

2. 新型的serverless开发模式

正常来说，用户开发 Server 端服务，常常面临开发效率，运维成本高，机器资源弹性伸缩等痛点，而使用 Serverless 架构可以很好的解决上述问题。下面是传统架构和 Serverless 架构的对比：

云函数计算是一个事件驱动的全托管计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，并提供日志查询，性能监控，报警等功能。借助于函数计算，您可以快速构建任何类型的应用和服务，无需管理和运维。

# 1.7 使用serverless优缺点

优势

1. 无运维：我们不需要购买服务器，直接可进行
2. 资源分配: 在 Serverless 架构中，你不用关心应用运行的资源(比如服务配置、磁盘大小)只提供一份代码就行。
3. 计费方式: 在 Serverless 架构中，计费方式按实际使用量计费(比如函数调用次数、运 行时长)，不按传统的执行代码所需的资源计费(比如固定 CPU)。计费粒度也精确到了毫 秒级，而不是传统的小时级别。个别云厂商推出了每个月的免费额度，比如腾讯云提供了每 个月 40 万 GBs 的资源使用额度和 100 万次调用次数的免费额度。中小企业的网站访问量不 是特别大的话完全可以免费使用。

4. 弹性伸缩: Serverless 架构的弹性伸缩更自动化、更精确，可以快速根据业务并发扩容更 多的实例，甚至允许缩容到零实例状态来实现零费用，对用户来说是完全无感知的。而传统 架构对服务器(虚拟机)进行扩容，虚拟机的启动速度也比较慢，需要几分钟甚至更久。

不足

当然了 ServerLess 是很诱人，但却不是万能的，有些场景还是不适合的。

• ServerLess 不仅仅是一门技术也是一种理念和微服务一样，很多老系统不能直接上 ServerLess，得相应的进行升级和拆解才能更好的适应 ServerLess，这是一个门槛。
• 同时 ServerLess 针对开发语言的可定制性和可开放性，ServerLess 会选择处于稳定版的语言且更新具有一定的滞后性，特别是 Node.JS 这样的版本更新帝，最新稳定版是10，但是提供的却是8。同时如果对语言有底层的修改而无法通过 Plugin 实现同样也无法适应相关场景。
• 不适合长时间的进行计算处理的场景，ServerLess 是产生计算后按时间计费的，适合那些触发类短时间计算的，如果有长时间进行计算的场景就不适合。

# 1.8 如何理解理解Serverless技术—FaaS和BaaS

Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 完全被第三方管理，其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless涵盖了很多技术，分为两类：FaaS和BaaS。

FaaS（Function as a Service，函数即服务）

• FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其他现代化架构最大的差异。
• FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。
• FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。
• 迁往FaaS的过程中，唯一需要修改的代码是“主方法/启动”代码，其中可能需要删除顶级消息处理程序的相关代码（“消息监听器接口”的实现），但这可能只需要更改方法签名即可。在FaaS的世界中，代码的其余所有部分（例如向数据库执行写入的代码）无须任何变化。

相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。

FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。

大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）

BaaS（Backend as a Service，后端即服务）

BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务

# 1.9 Serverless计算如何工作？

同步调用的特性是，客户端期待服务端立即返回计算结果。请求到达函数计算时，会立即分配执行环境执行函数。

以 API 网关为例，API 网关同步触发函数计算，客户端会一直等待服务端的执行结果，如果执行过程中遇到错误， 函数计算会将错误直接返回，而不会对错误进行重试。这种情况下，需要客户端添加重试机制来做错误处理。

异步调用的特性是，客户端不急于立即知道函数结果，函数计算将请求丢入队列中即可返回成功，而不会等待到函数调用结束。

函数计算会逐渐消费队列中的请求，分配执行环境，执行函数。如果执行过程中遇到错误，函数计算会对错误的请求进行重试，对函数错误重试三次，系统错误会以指数退避方式无限重试，直至成功。

异步调用适用于数据的处理，比如 OSS 触发器触发函数处理音视频，日志触发器触发函数清洗日志，都是对延时不敏感，又需要尽可能保证任务执行成功的场景。如果用户需要了解失败的请求并对请求做自定义处理，可以使用 Destination 功能。函数计算是 Serverless 的，这不是说无服务器，而是开发者无需关心服务器，函数计算会为开发者分配实例执行函数。

# 2.0 FAAS 冷启动

FaaS 中的冷启动是指从调用函数开始到函数实例准备完成的整个过程。 冷启动我们关注的是启动时间，启动时间越短，我们对资源的利用率就越高。现在的云服务商，基于不同的语言特性，冷启动平均耗时基本在 100～700 毫秒之间。得益于 Google 的 JavaScript 引擎 Just In Time 特性，Node.js 在冷启动方面速度是最快的。

请求第一次访问时，云服务商就可以利用构建好的缓存镜像，直接跳过冷启动的下载函数代码步骤，从镜像启动容器，这个也叫预热冷启动。所以如果我们有些业务场景对响应时间比较敏感，我们就可以通过预热冷启动或预留实例策略，加速或绕过冷启动时间。

# 2.1 FAAS 分层

• 容器
• 运行时runtime
• 具体函数代码

云服务商负责的就是容器和 Runtime 的准备阶段了。而开发者自己负责的则是函数执行阶段。一旦容器 &Runtime 启动后，就会维持一段时间，这段时间内的这个函数实例就可以直接处理用户数据请求。当一段时间内没有用户请求事件发生（各个云服务商维持实例的时间和策略不同），则会销毁这个函数实例。

SFF（Serverless For Frontend）指前端数据请求过来，函数触发器触发我们的函数服务；我们的函数启动后，调用后端提供的元数据接口，并将返回的元数据加工成前端需要的数据格式；我们的 FaaS 函数完全就可以休息了。

# 2.2 后端应用 BaaS 化

回到我们的进程模型，用完即毁型是天然的 Stateless，因为它执行完就销毁，你无法单纯用它持久化存储任何值；常驻进程型则是天然的 Stateful，因为它的主进程不退出，主进程可以存储部分值。

# 2.3 Serverless使用场景

发送通知

物联网

登录