前言
本文隶属于专栏《大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见大数据理论体系
概览
Serverless 是一个云原生开发模型，允许开发人员构建和运行应用程序，而无需管理服务器。
Serverless 也有服务器，但是它们会从应用程序开发中被抽象出来。
云提供商处理配置、维护和扩展服务器基础架构的日常工作。
开发人员只需将代码打包到容器中进行部署。
一旦部署，Serverless 应用程序响应需求，并根据需要自动扩展。
来自公有云提供商的 Serverless 产品通常通过事件驱动的执行模型按需计量。
因此，当 Serverless 功能闲置时，它不会花费任何费用。
Serverless 架构概述
Serverless 与其他云计算模型的不同之处在于，云提供商负责管理云基础设施和应用程序的扩展。
Serverless 应用程序部署在容器中，在调用时自动按需启动。
根据标准的基础设施即服务（IaaS）云计算模型，用户预购容量单位，这意味着你向公有云提供商支付全天候服务器组件的费用，以运行你的应用程序。
用户有责任在需求旺盛时期扩大服务器容量，并在不再需要该容量时缩小服务器容量。
即使应用程序未被使用，运行应用程序所需的云基础设施也是有效的。
相比之下，使用 Serverless 架构，应用程序仅根据需要启动。
当事件触发应用程序代码运行时，公有云提供商会动态为该代码分配资源。
当代码完成执行时，用户停止付款。
除了成本和效率效益外，Serverless 还使开发人员摆脱了与应用程序扩展和服务器配置相关的日常繁琐任务。
对于 Serverless，操作系统和文件系统管理、安全补丁、负载平衡、容量管理、扩容、日志记录和监控等常规任务都会转交到云服务提供商。
可以构建一个完全 Serverless 的应用程序，或者一个由部分 Serverless 和部分传统微服务组件组成的应用程序。
Baas & Faas
在 Serverless 模型下，云提供商运行物理服务器，并且作为用户的代理人动态地分配资源，将代码直接部署到生产环境中。
Serverless 计算产品通常分为两组，后端即服务（BaaS）和功能即服务（FaaS）。
Baas
BaaS 允许开发人员访问各种第三方服务和应用程序。
例如，云提供商可能会提供身份验证服务、额外的加密、云可访问的数据库和高保真使用数据。
使用 BaaS，Serverless 函数通常通过应用程序编程接口（API）调用。
Faas
更常见的是，当开发人员提到 Serverless 时，他们谈论的是 FaaS 模型。
在 FaaS 下，开发人员仍然编写自定义服务器端逻辑，但它在完全由云服务提供商管理的容器中运行。
Function-as-a-Service（FaaS）是一个事件驱动的计算执行模型，开发人员编写逻辑，该逻辑部署在完全由平台管理的容器中，然后按需执行。
与 BaaS 不同，FaaS 为开发人员提供了更大程度的控制权，开发人员创建自定义应用程序，而不是依赖预写服务库。
代码部署到由云提供商管理的容器中。具体来说，这些容器是：
- 无状态的，使数据集成更简单。
- 短暂的，允许它们运行很短的时间。
- 事件触发的，因此它们可以在需要时自动运行。
- 完全由云提供商管理，因此你只需支付所需的费用，不用始终启动应用程序和服务器。
使用 FaaS，开发人员可以通过 FaaS 提供商通过 API 网关处理的 API 调用 Serverless 应用程序。
Serverless 适合哪些应用场景？
Serverless 架构非常适合可以立即启动的异步无状态应用程序。
同样， Serverless 非常适合经常出现不可预测的需求激增的场景。
想想看，像批量处理传入的图像文件这样的任务，这些文件可能很少运行，但是当大量图像同时到达时，也必须准备就绪。
或者一项任务，例如监视数据库的传入更改，然后应用一系列功能，例如根据质量标准检查更改，或自动翻译它们。
Serverless 应用程序也非常适合涉及传入数据流、聊天机器人、计划任务或业务逻辑的用例。
其他一些常见的 Serverless 应用场景是后端 API 和 Web 应用程序、业务流程自动化、无间断网站以及跨多个系统的集成。
Serverless 计算的利弊是什么？
利
Serverless 计算可以提高开发人员的生产力并降低运营成本。
通过卸任配置和管理服务器的常规任务，开发人员有更多时间专注于他们的应用程序。
Serverless 通过减少开发人员明确描述他们需要操作来为他们配置的基础设施，从而帮助实现 DevOps 的采用。
通过整合第三方 BaaS 产品的全部组件，可以进一步简化应用程序开发。
在 Serverless 模型中，运营成本会降低，因为你可以根据需要支付基于云的计算时间，而不是一直运行和管理自己的服务器。
弊
不运行自己的服务器或控制自己的服务器端逻辑可能会有缺点。
云提供商可能对其组件如何交互受到严格限制，进而影响你自己的系统的灵活性和定制程度。
在 BaaS 环境中，开发人员可能会受到代码超出其控制范围的服务。
更换云提供商还可能带来升级系统以遵守新供应商规格的成本。
Serverless 的演变
随着容器和按需云产品的普及， Serverless 架构和 FaaS 的概念齐头并进。
Serverless 的演变要追溯到三个阶段。
Serverless 1.0
Serverless 的 1.0 阶段存在局限性，使其不适合一般计算。
Serverless 1.0 的特点是：
- HTTP和少数其他几个来源
- 仅限函数
- 执行时间有限（5-10分钟）
- 没有编排
- 有限的本地开发经验
Serverless 1.5
Kubernetes 的出现开启了 Serverless 1.5 时代，许多Serverless 框架开始自动扩缩容容器。
Serverless 1.5 的特点是：
- 原生的
- 基于 Kubernetes 的自动扩缩容
- 微服务和函数
- 易于在本地调试和测试
- 多语言和便携式
Serverless 2.0
今天，随着集成和状态的增加，Serverless 2.0 时代正在出现。
云提供商已经开始添加缺失的部件，以使 Serverless 适合通用业务工作负载。
Serverless 2.0 的特点是：
- 基本的状态处理
- 企业集成模式的使用
- 高级消息传递功能
- 与企业 PaaS 混合
- 企业级的事件源
- 状态集成
什么是 Knative 和 Serverless Kubernetes？
作为在自动化基础设施上运行容器化应用程序的一种方式，Kubernetes容器编排平台是运行 Serverless 环境的热门选择也就不足为奇了。
但 Kubernetes 本身还没有准备好原生运行 Serverless 应用程序。
Knative 是一个开源社区项目，它添加了在 Kubernetes 上部署、运行和管理 Serverless 应用程序的组件。
Knative Serverless 环境允许你将代码部署到 Kubernetes 平台，如 Red Hat OpenShift。
使用 Knative，你可以通过将代码打包为容器映像并将其交给系统来创建服务。
你的代码仅在需要时运行，Knative 会自动启动和停止实例。
Knative 由 3 个主要组成部分组成：
- 构建：将源代码构建到容器中的灵活方法。
- 服务：通过基于需求的服务工作负载的请求驱动模型实现容器的快速部署和自动扩展。
- 事件：消耗和制作事件以刺激应用程序的基础设施。应用程序可以由各种来源触发，例如来自您自己的应用程序的事件、来自多个提供商的云服务、软件即服务（SaaS）系统。
与早期的 Serverless 框架不同，Knative 旨在部署任何现代应用程序工作负载——从整体应用程序到微服务和微小功能。
作为由单个服务提供商控制的 FaaS 解决方案的替代品，Knative 可以在任何运行 Kubernetes 的云平台上运行。
这可能包括在本地数据中心运行。
这使组织在运行 Serverless 工作负载时具有更大的灵活性和灵活性。
