我的Serverless实战——大前端趋势之Serverless从入门到天黑

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，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。理解BaaS，需要搞清楚它与PaaS的区别。

首先BaaS并非PaaS，它们的区别在于：PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。

BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。

Serverless计算如何工作？

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

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

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

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

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

Serverless使用场景

发送通知

诸如 PUSH Notification、邮件通知接口、短信，这一类服务来说，他们都需要基础设施来搭建。并且，他们对实时性的要求相对没有那么高。即使在时间上晚来几秒钟，用户还是能接受的。在我们所见到的短信发送的例子里，一般都会假设用户能在 60 秒内收到短信。因此，在这种时间 1s 的误差，用户也不会恼火的。

轻量级 API

Serverless 特别适合于，轻量级快速变化地 API。其实，我一直没有想到一个合适的例子。在我的假想里，一个 AutoSuggest 的 API 可能就是这样的 API，但是这种 API 在有些时候，往往会伴随着相当复杂的业务。于是，便想举一个 Featrue Toggle 的例子，尽管有一些不合适。但是，可能是最有价值的部分。

物联网

当我们谈及物联网的时候，我们会讨论事件触发、传输协议、海量数据（数据存储、数据分析）。而有了 Serverless，那么再多的数据，处理起来也是相当容易的一件事。对于一个物联网应用的服务端来说，系统需要收集来自各个地方的数据，并创建一个个 pipeline 来处理、过滤、转换这些数据，并将数据存储到数据库中。对于硬件开发人员来说，对接不同的硬件，本身就是一种挑战。而直接使用诸如 AWS IoT 这样国，可以在某种程度上，帮助我们更好地开发出写服务端连接的应用。

数据统计分析等

数据统计本身只需要很少的计算量，但是生成图表，则可以定期生成。在接收数据的时候，我们不需要考虑任何延时带来的问题。50~200 ms 的延时，并不会对我们的系统造成什么影响。

Serverless优缺点

优点

1. 更快的上市时间我们可以更快地将应用程序推向市场，因为OPS变得更加简单，并且将帮助开发人员专注于他们的开发。 OPS团队无需编写可以处理扩展或担心底层基础架构的代码。此外，团队可以在第三方集成的帮助下更快地构建应用程序，例如OAuth，Twitter和Maps等API服务。

2.高度可扩展性每家公司都希望他们的应用程序能够更好地运行，零停机时间，并且随着流量的增加而快速，轻松地扩展，但是通过单一的应用程序开发，它可能变得非常困难。随着应用程序负载的增加，Ops团队必须在扩展底层基础架构时保持警惕。由于交通量的增加，停机时间浪费了大量的时间和金钱。但无服务器计算具有高度可扩展性，可以在几秒钟内对应用程序进行缩放和缩放。

3.低成本在无服务器计算中，开发人员仅在功能运行时付费，与IaaS和PaaS不同，IaaS和PaaS为每台服务器24/7收费。这对于拥有庞大的应用程序，API或微服务设置的公司来说非常有用，这些应用程序，API或微服务目前全天候运行并且100％的时间使用资源，无论是否需要。但是对于无服务器，我们可以按需执行功能并共享资源，而不是全天候运行应用程序，因此我们可以大大减少空闲时间，并使应用程序运行得更快。

4.延迟和地理定位。改进应用程序的可扩展性取决于三个因素：用户数量，用户位置和网络延迟。在当今世界，应用程序拥有全球受众，这可能会增加延迟。但是无服务器平台可以大大减轻延迟的危险。使用无服务器时，实例化容器以在每个事件调用时运行函数，并且可以在用户的​​地理区域附近创建此容器，这将自动提高应用程序的性能。

缺点

1.复杂性增加我们使用应用程序越精细，它就越复杂。每个函数的代码可能会变得更简单，但整个应用程序将变得更加复杂。比如说，我们将应用程序分解为10个不同的微服务。我们必须管理10个不同的应用程序，而在单个应用程序中，它只是一个必须管理的应用程序。

2.缺乏工具支持 假设我们将单片应用程序分解为50种不同的功能。仍然有各种各样的流程和工具来管理，记录，监视和部署整体应用程序。由于无服务器是市场上的新产品，因此监控或记录运行几秒钟的应用程序是有限的并且具有挑战性，但是随着时间的推移，将会有许多有效的方法来实现这一点。

3. 与体系结构的复杂性很难决定函数的粒度，并且评估，实现和测试以检查我们的首选项是耗时的。

4. 管理太多功能会很麻烦，同时忽略粒度会导致我们设置迷你巨石。

5.实施中的缺点无服务器的最大挑战是集成测试难。

小白操作指南

安装

Serverless是Node.js CLI工具，因此您要做的第一件事是在计算机上安装Node.js。

注意：无服务器在Node v6或更高版本上运行。

打开一个终端，然后键入npm install -g serverless以安装Serverless。

安装过程完成后，您可以通过在终端中运行以下命令来验证是否成功安装了Serverless：

serverless

要查看已安装的无服务器版本：

serverless --version

测试

将业务逻辑与FaaS Provider分开

class Users { constructor(db, mailer) { this.db = db; this.mailer = mailer; } save(email, callback) { const user = { email: email, created_at: Date.now(), }; this.db.saveUser(user, function (err) { if (err) { callback(err); } else { this.mailer.sendWelcomeEmail(email); callback(); } }); } } module.exports = Users;

const db = require(‘db’).connect(); const mailer = require(‘mailer’); const Users = require(‘users’); let users = new Users(db, mailer); module.exports.saveUser = (event, context, callback) => { users.save(event.email, callback); };

现在，以上类将业务逻辑分开。此外，负责设置依赖关系，注入依赖关系，调用业务逻辑功能以及与AWS Lambda交互的代码位于其自己的文件中，该文件的更改频率较低。这样，业务逻辑就不依赖于提供程序，更易于重用和测试。

此外，此代码不需要运行任何外部服务。取而代之的是真正的db和mailer服务，我们可以通过模拟考试，并断言，如果saveUser和sendWelcomeEmail被调用适当的参数。

可以很容易地编写单元测试以涵盖上述课程。可以通过调用serverless invoke带有夹具电子邮件地址的功能（）来添加集成测试，检查用户是否确实保存到数据库中，并检查是否收到了电子邮件以查看是否一切正常。

部署

使用无服务器框架进行部署：

serverless deploy

无服务器框架将所有语法serverless.yml转换为单个AWS CloudFormation模板。通过依靠CloudFormation进行部署，无服务器框架的用户可以获得CloudFormation的安全性和可靠性。

• AWS CloudFormation模板是从中创建的serverless.yml。

• 如果尚未创建堆栈，则创建该堆栈时除了S3存储桶（S3存储桶）外，将不存储任何资源，S3存储桶将存储您的功能代码的zip文件。

• 如果您使用本地构建的ECR映像，则会为您的服务创建专用的ECR存储库。docker login如果需要，您还将通过登录到该存储库。

• 然后，您的功能代码将打包为zip文件。

• 如果您使用本地构建的ECR图像，则将它们构建并上传到ECR。

• 无服务器获取前一次部署的所有文件的哈希（如果有），并将其与本地文件的哈希进行比较。

• 如果所有文件哈希都相同，则Serverless会终止部署过程。

• 您的功能代码的Zip文件已上传到您的代码S3存储桶。

• 任何IAM角色，功能，事件和资源都会添加到AWS CloudFormation模板中。

• CloudFormation堆栈已使用新的CloudFormation模板进行了更新。

• 每个部署都会为服务中的每个功能发布一个新版本。

部署功能

serverless deploy function --function myFunction

部署程序包

serverless deploy --package path-to-package

• 该--package标志的参数是先前由Serverless（带有serverless package）打包的目录。

• 部署过程绕过了软件包步骤，并使用现有的软件包来部署和更新CloudFormation堆栈。

工作流程

开发流程

1. 编写你的函数

2. serverless deploy仅在serverless.yml对CI / CD系统进行更改时使用。有关为无服务器应用程序设置CI / CD的更多信息，请阅读本文。

3. 在使用serverless deploy function -f myFunction特定的AWS Lambda函数时，可用于快速部署更改。

4. 用于serverless invoke -f myFunction -l在AWS上测试您的AWS Lambda函数。

5. 在控制台中打开一个单独的选项卡，然后通过进入流日志serverless logs -f myFunction -t。

6. 编写测试以在本地运行。

使用阶段

• 至少要使用devandproduction阶段。

• 将不同的AWS账户用于阶段。

• 在较大的团队中，每个成员应使用一个单独的AWS账户和自己的开发阶段。
  自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

最后

资料过多，篇幅有限，需要文中全部资料可以点击这里免费获取前端面试资料PDF完整版！

自古成功在尝试。不尝试永远都不会成功。勇敢的尝试是成功的一半。

89)]

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

[外链图片转存中…(img-OcbJ1yma-1713836473389)]

最后

[外链图片转存中…(img-7kGc070K-1713836473389)]

[外链图片转存中…(img-mTMNIWSm-1713836473390)]

资料过多，篇幅有限，需要文中全部资料可以点击这里免费获取前端面试资料PDF完整版！

自古成功在尝试。不尝试永远都不会成功。勇敢的尝试是成功的一半。