传统上，我们已经构建并部署了 web 应用程序，对这些应用程序，我们可以对服务器发出的 HTTP 请求进行一定程度的控制。我们的应用程序运行在该服务器上，我们负责为其配置和管理资源。但这会产生一些问题：
1、即使没有处理任何请求，我们也要保持服务器正常运行。
2、我们负责服务器及其所有资源的正常运行及维护。
3、我们还负责对服务器进行适当的安全更新。
4、随着使用量的扩张，我们还需要管理服务器的扩展，结果是，当我们没有太多使用量时，我们要将其减少。
对于较小的公司和个人开发者而言，这可能需要处理很多工作。这使得我们无法专注于我们更重要的工作，构建和维护实际的应用程序。在大型组织中，这是由基础设施团队处理的，并且通常这不是开发者个人的责任。但是，为此所需的过程最终可能减慢开发时间。因为你不能不与基础架构团队合作来帮助你启动和运行而直接继续构建应用程序。作为开发者，我们一直在寻找一种解决这些问题的方法，这就是无服务器的来源。
无服务器计算
无服务器计算（或简称 serverless），是一种执行模型，在该模型中，云服务商（AWS，Azure 或 Google Cloud）负责通过动态分配资源来执行一段代码，并且仅收取运行代码所使用资源的费用。该代码通常运行在无状态的容器中，能够被包括 HTTP 请求、数据库事件、队列服务、监控报警、文件上传、调度事件（cron 任务）等各种事件触发。被发送到云服务商执行的代码通常是以函数的形式，因此，无服务器计算有时是指 “函数即服务” 或者 FAAS。以下是主要云服务商提供的 FAAS 产品：
- AWS:AWS Lambda
- Microsoft Azure:Azure Functions
- Google Cloud:Cloud Functions
尽管无服务器计算对开发人员抽象了底层基础设施，但服务器仍然参与执行我们的函数。由于你的代码将要作为独立的函数执行，我们需要知道以下几点：
微服务
当向无服务器计算的世界过度时，我们面临的最大变化是我们的程序需要被组织成函数的形式。你可能习惯于将你的应用程序部署为单个 Rails 或 Express 整体应用程序。但是在无服务器计算的世界里，你通常需要采用更多基于微服务的架构。你可以通过在单个函数中作为一个整体运行你的整个应用程序并自行处理路由来解决此问题。但不建议这样做，因为减小你的函数的大小更好。我们将在下面讨论。
无状态函数
你的函数通常运行在安全的（几乎是）无状态容器中，这意味着你将无法在一个事件已经完成后长时间执行的应用服务器中运行代码，或者无法使用先前的执行上下文为请求提供服务。你不得不有效地假定你的函数每次都在一个新容器中被调用。 对此有一些微妙之处，我们将会在 什么是 AWS Lambda 一章中进行讨论。
冷启动
由于你的函数在需要响应事件的容器中运行，因此存在一定的延时。这被称为”冷启动”。当你的函数执行完成后，你的容器可能会保留一段时间。如果另一个事件在此时被触发，则它的响应速度要快得多，这通常被称为”热启动”。
冷启动的持续时间取决于特定云服务商的实现。在 AWS Lambda 上，它的范围从几百毫秒到几秒不等。它可能取决于使用的运行时（或编程语言）、函数（以包的形式）的大小，当然，还取决于所讨论的云服务商。多年以来，随着云服务商在优化时延方面变得越来越出色，冷启动已经大为改善。
除了优化你的函数，你还可以使用一些简单的技巧，例如使用单独的调度函数每隔几分钟来调用你的函数以使其保持运行状态。我们在此教程中使用的 Serverless Framework 中，有一些插件能够帮助保持你的函数处于运行状态。
既然我们对无服务器计算有了一些了解，让我们更深入地了解什么是 Lambda 函数以及你的代码是如何被执行的。
Serverless = Faas + Baas。它代表的是无（少）服务器架构开发，从而使得开发者的精力主要放在了系统架构和软件开发上。
全文一览：
- 什么是 Faas、Baas？
- Serverless 执行过程是怎样的？
- Serverless 技术特点是什么？
- Serverless 优缺点与应用场景？
什么是 Faas、Baas？
Faas 是 Function-as-a-service 的缩写。这里指的是“云函数运行平台”。开发者可以拆分业务逻辑，并将其上传到云函数平台，配置函数触发条件、路由等。
Baas 是 Backend-as-a-service 的缩写。这里指的是“后端服务组件”，例如文件存储、数据库、实时通信等等。
Fass 和 Bass 共同组成了 Serverless。
Serverless 执行过程是怎样的？
根据我自己的使用情况，Serverless 的执行过程主要途径三个主体：Client => Function => Backend。
举个例子，如果想在云服务中，用超级管理员的身份对云数据库进行读写，根据文档，超级管理员只能在 Function 中通过 SDK 使用。因此，整个处理逻辑是：
- 微信开发者工具调用编写好的云函数
- 云函数进行鉴权
- 鉴权成功后，启动容器，加载 sdk，执行逻辑
- sdk 通过 HTTP API 的方式调用云数据库服务
- 云数据库的运行结果原路返回给微信开发者工具
除此之外，有时候可能的调用流程是：Client => Function，这种情况可能是为了不影响用户体验，而将复杂计算放入了云函数中。
有时候可能的调用流程是：Client => Backend。比如在微信开发工具内，内置了云开发 SDK，可以直接调用云开发后端组件，大大降低了开发难度。
Serverless 技术特点是什么？
事件驱动
这里的“事件”含义比较丰富，包括 http 请求等各种方式的调用。只有当事件发生时，云函数才会执行，后端服务组件才会开始计算。完成后，结果返回给用户，相关容器会被销毁。
弹性扩缩
云计算厂商会根据实际使用的资源量（调用次数、云函数运行内存、云存储空间等等）来进行计费。
并且在业务量激增的情况下，云计算厂商会自动调度资源进行分配，开发者无需关心高并发的情况（只要充钱，就能变强）。
无状态与有状态
云函数是无状态的，在事件发生时计算，计算后相关资源会被释放。
而状态是存放在后端服务组件中，例如云数据库。
这点和传统的服务器开发有区别。
Serverless 优缺点与应用场景？
优点
- 免运维，自动弹性扩容
- 快速开发，不需要自建后端服务
- 开发者关注点集中在业务上
缺点
- 调试成本高：目前的解决方法主要是通过查看调用/报错日志。体验上，和本地开发工具调试有差距。
- 启动时间长：目前的解决方法是对于经常性任务采取“热启动”，对用到的第三方库提前缓存，减少网络调用链路上的节点。
应用场景
- 交互体验：将计算放入云函数，避免影响用户体验
- AI 计算：直接调用云计算厂商提供的 AI 服务
- IoT：设备不具备计算能力（大小、电池）
