Serverless 简介
Serverless（无服务器架构）指的是服务端逻辑由开发者实现，运行在无状态的计算容器中，由事件触发，完全被第三方管理，而业务层面的状态则记录在数据库或存储资源中。用户无需管理服务器等基础设施，只需编写代码和选择触发器（trigger)，比如 RPC 请求、定时器等并上传，其余的工作（如实例选择、扩缩容、部署、容灾、监控、日志、安全补丁等）全部由 serverless 系统托管。用户只需要为代码实际运行消耗的资源付费——代码未运行则不产生费用（Pay as you go）。
Serverless 相比 Serverful，有以下 3 个改变：
- 弱化了存储和计算之间的联系。服务的储存和计算被分开部署和收费，存储不再是服务本身的一部分，而是演变成了独立的云服务，这使得计算变得无状态化，更容易调度和扩缩容，同时也降低了数据丢失的风险。
- 代码的执行不再需要手动分配资源。不需要为服务的运行指定需要的资源（比如使用几台机器、多大的带宽、多大的磁盘等），只需要提供一份代码，剩下的交由 serverless 平台去处理就行了。当前阶段的实现平台分配资源时还需要用户方提供一些策略，例如单个实例的规格和最大并发数，单实例的最大 CPU 使用率。理想的情况是通过某些学习算法来进行完全自动的自适应分配。
- 按使用量计费。Serverless 按照服务的使用量（调用次数、时长等）计费，而不是像传统的 serverful 服务那样，按照使用的资源（ECS 实例、VM 的规格等）计费。
Serverless 两个重要的产品：
- FaaS（Function as a Service， 函数即服务，也称为云函数）：FaaS 提供了一个计算平台，在这个平台上，应用以一个或多个函数的形式开发、运行和管理。FaaS 平台提供了函数式应用的运行环境，一般支持多种主流的编程语言，如 Java、PHP 及 Python 等。FaaS 可以根据实际的访问量进行应用的自动化动态加载和资源的自动化动态分配。大多数 FaaS 平台基于事件驱动（Event Driven）的思想，可以根据预定义的事件触发指定的函数应用逻辑。
- BaaS（Backend as a Service，后端即服务）：通过 BaaS 平台将应用所依赖的第三方服务，如数据库、消息队列及存储等服务化并发布出来，用户通过向 BaaS 平台申请所需要的服务进行消费，而不需要关心这些服务的具体运维。
FaaS 与 PaaS 的比较：大部分 PaaS 应用无法针对每个请求启动和停止整个应用程序，而 FaaS 平台生来就是为了实现这样的目的。FaaS 和 PaaS 在运维方面最大的差异在于缩放能力。对于大部分 PaaS 平台，用户依然需要考虑缩放。但是对于 FaaS 应用，这种问题完全是透明的。就算将 PaaS 应用设置为自动缩放，依然无法在具体请求的层面上进行缩放，而 FaaS 应用在成本方面效益就高多了。
Serverless 架构的优点
- 降低运营成本：Serverless 是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑，否则您就不得不自己来维护。由于这个服务使用者的数量会非常庞大，于是就会产生规模经济效应。在降低成本上包含了两个方面，即基础设施的成本和人员（运营/开发）的成本。
- 降低运维需求：Serverless 使得应用与服务器解耦，业务上线前无需预估资源，无需进行服务器购买、配置 Serverless 也使得底层运维工作量进一步降低，业务上线后，也无需担忧服务器运维，而是全部交给了云平台或云厂商
- 降低开发成本：IaaS 和 PaaS 存在的前提是，服务器和操作系统管理可以商品化。Serverless 作为另一种服务的结果是整个应用程序组件被商品化。
- 缩短迭代周期、上线时间：Serverless 架构带来的是进一步的业务解耦，应用功能被解构成若干个细颗粒度的无状态函数，开发可以聚焦在单功能的快速开发和上线。同时，拆解后的云函数，也都可以进行独立的迭代升级，更快速的实现业务迭代，缩减功能的上线时间
- 扩展能力：Serverless 架构一个显而易见的优点即“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。从基本的基础设施方面受益最大的好处是，您只需支付您所需要的计算能力。
- 更简单的管理：Serverless 架构明显比其他架构更简单。更少的组件，就意味着您的管理开销会更少。
- 快速试错：利用 Serverless 架构的简单运维、低成本及快速上线能力，可以来快速尝试业务的新形态、新功能，利用 Serverless 产品的强弹性扩容能力，在业务获得成功时，也无需为资源扩容而担心
- “绿色”的计算：按照《福布斯》杂志的统计，在商业和企业数据中心的典型服务器仅提供 5%～ 15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。随着 Serverless 架构的出现，让服务提供商提供我们的计算能力最大限度满足实时需求。这将使我们更有效地利用计算资源。
Serverless 架构的缺点
- 状态管理：要想实现自由的缩放，无状态是必须的，而对于有状态的服务，使用 serverless 这就丧失了灵活性，有状态服务需要与存储交互就不可避免的增加了延迟和复杂性。
- 延迟：应用程序中不同组件的访问延迟是一个大问题，我们可以通过使用专有的网络协议、RPC 调用、数据格式来优化，或者是将实例放在同一个机架内或同一个主机实例上来优化以减少延迟。而 serverless 应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题，单纯使用 serverless 的应用程序是不太现实的。
- 本地测试：Serverless 应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于无服务应用的集成或者端到端测试尤其困难，很难在本地模拟应用程序的各种连接，并与性能和缩放的特性结合起来测试，并且 serverless 应用本身也是分布式的，简单的将无数的 FaaS 和 BaaS 组件粘合起来也是有挑战性的。
Serverless 适用的场景：
- 异步的并发，组件可独立部署和扩展
- 应对突发或服务使用量不可预测（主要是为了节约成本，因为 Serverless 应用在不运行时不收费）
- 短暂、无状态的应用，对冷启动时间不敏感
- 需要快速开发迭代的业务（因为无需提前申请资源，因此可以加快业务上线速度）
Serverless 常见的应用：
WEB 及移动后端
通过结合使用云函数和 API 网关或 HTTP 触发器，可以对外提供 URL 访问地址，成为 Web、小程序、或移动应用等的后端服务。Serverless 架构既可以直接用于构建后台来服务应用，也可以通过类似 BFF 模式，构建中台和应用间的桥梁。
Serverless 架构提供的强弹性能力，使得可以支撑业务或应用的暴涨；而提供的低运维需求，使得开发者可以专注于业务实现和优化；同时，按实际使用量的付费方式，使得开发者无需预配置资源，无需担心预配置资源的浪费。消息处理
Serverles 架构的应用本身是由事件触发的，因此极其适合于进行消息处理。无论是消息队列中传递的业务消息，还是 Kafka 中采集应用日志，均可以对接到云函数上，进行实时的消息处理、分析。对象存储文件处理
在 Serverless 应用场景中，由对象存储中的文件上传事件，来触发云函数的运行，也是一种常见场景。
针对图片文件的上传，可以借助云函数完成图片的缩略图生成、二维码或水印标记、图片优化处理；而针对数据文件的上传，可以启动数据的自动化分析物联网
物联网意味着成千上万的设备会连入网络，时刻在不断的产生数据，这对数据的分析、处理的及时性提出了很高的挑战。通过使用 Serverless 架构，物联网设备所采集的数据将可以作为云函数的触发事件，而实现数据的实时处理、分析和应用。
随着物联网设备计算能力的进一步提升，云函数作为最小粒度的计算单元，有机会被调度到设备端运行，实现边缘计算，达到「端 - 云」联合的 Serverless 架构。运维及集成
通过对接云函数以及云上的各个产品、日志服务、监控告警系统，云时代的运维也都可以用云函数来构建。定时触发的云函数，将可以方便地替代需要在主机上来运行的定时任务；而日志或告警触发的云函数，将可以对云中的事件作出立刻回应及处理。
Serverless 技术特点
事件驱动
- 云函数的运行，是由事件驱动起来的，在有事件到来时，云函数会启动运行
- Serverless 应用不会类似于原有的「监听 - 处理」类型的应用一直在线，而是按需启动
- 事件的定义可以很丰富，一次 http 请求，一个文件上传，一次数据库条目修改，一条消息发送，都可以定义为事件
单事件处理
- 云函数由事件触发，而触发启动的一个云函数实例，一次仅处理一个事件
- 无需在代码内考虑高并发高可靠性，代码可以专注于业务，开发更简单
- 通过云函数实例的高并发能力，实现业务高并发
自动弹性伸缩
- 由于云函数事件驱动及单事件处理的特性，云函数通过自动的伸缩来支持业务的高并发
- 针对业务的实际事件或请求数，云函数自动弹性合适的处理实例来承载实际业务量
- 在没有事件或请求时，无实例运行，不占用资源
无状态开发
- 云函数运行时根据业务弹性，可能伸缩到 0，无法在运行环境中保存状态数据
- 分布式应用开发中，均需要保持应用的无状态，以便于水平伸缩
- 可以利用外部服务、产品，例如数据库或缓存，实现状态数据的保存
参考文档
从 IaaS 到 FaaS—— Serverless 架构的前世今生