简单概述 Serverless

本文分享自天翼云开发者社区 @ 《​ ​简单概述Serverless​​》，作者: 我是小朋友

Serverless 是计算的趋势，它使诸如 Web 应用程序之类的代码执行与维护服务器以运行该代码的需求脱钩。 创建，供应和维护服务器上运行的应用程序的操作开销（传统意义上）非常重要。 减少或消除这项工作可以帮助组织管理成本并为员工腾出时间。 Serverless 还提供了创新的计费模型和更容易的可扩展性。

在《Serverless 是什么？》中，作者 Mike Roberts 和 John Chapin 指出了使 Serverless 变得独一无二的核心见解：

使用完全 Serverless 的应用程序，您不再需要将架构的任何部分视为在主机上运行的资源。 您的所有逻辑（无论您是自己编写代码还是与第三方服务集成）都在完全弹性的操作环境中运行。 您的状态也以类似的弹性形式存储。 Serverless 并不意味着服务器已经消失。 这意味着您不再需要担心它们。

Serverless 可以归纳为：

1. 是一种无服务器架构

2. 是 Baas(后端即服务)和 Faas(函数即服务)的综合体

3. 基于事件驱动的编程泛型

目前常见的业界产品有 AWS Lambda、Google Cloud Functions、Azure Functions、IBM OpenWhisk、阿里云函数计算。随着容器技术，IoT，5G，区块链等技术的快速发展， 技术上对去中心化，轻量虚拟化，细粒度计算等技术需求愈发强烈，而 Serverless 必将借势迅速发展。

价值及影响

· 低成本：运营成本和开发成本

· 真正的按需付费

· 高横向扩展

· 只需要传统 5%~15%的计算能力

· NoOps

应用场景

事件驱动及响应式架构

IoT 物联网场景中低频需求

请求对及时响应需求不强

固定时间触发计算资源利用低的的业务

流量突发场景

跨云和混合云

边缘计算

代码运行周期短，长的不适合

不同风格的 Serverless

Serverless 技术有几种不同的版本。尽管 AWS Lambda 被视为启动这一运动的特定技术，但其他供应商提供了减少运营开销的平台。Serverless 产品通常分为两种：

后端即服务（BaaS）-BaaS 提供了 Serverless 方法来处理诸如存储，身份验证和用户管理之类的事情。

功能即服务（FaaS）-FaaS 平台以离散的“功能”单元运行代码，并根据需要调用它们。

Serverless 的 API

最终用户可以使用 API 网关之类的云基础架构来构建可根据需要调用的整个服务，而不必不断监听。云提供商会将传入的请求路由到正确的 Serverless 功能，该功能将完成工作并将响应写回最终用户。

这样就可以开发仅在使用时才收费的 API，并且可以通过最小的更改大规模扩展。 Slobodan Stojanovic 和 Aleksandar Simovic 的书《使用 Node.js 的 Serverless 应用程序》提供了一个示例，说明了为什么要对 API 使用 Serverless：

要了解 Serverless，请考虑一下洗衣机。洗衣服的设备听起来像是一个疯狂的起点，但是如今拥有一台服务器类似于拥有一台洗衣机。每个人都需要干净的衣服，最合乎逻辑的解决方案似乎是购买洗衣机。但是大多数时候，洗衣机都插上电源，什么也不做。最多每周使用 5 到 15 个小时。服务器也是如此。大多数情况下，您的普通应用服务器只是在等待接收请求，什么也不做。

Serverless 存储

传统上，管理 Web 应用程序的数据存储一直是操作应用程序中最困难的部分之一，而数据库管理有时看起来像是一门绝技。但是，Serverless 数据存储（如 Firebase 和 Aurora）的引入使开发人员不必担心优化实例类型，执行备份以及其他可操作的数据库问题。

相反，云提供商将为最终用户处理托管数据存储的事宜。提供者经常具有按需付费的计费模型。默认情况下，数据存储速度很快，并且通常具有吸引开发人员的灵活性，例如缺少预定义的架构。

Serverless 云事件

在云环境中，应用程序在诸如 Amazon Web Services 之类的平台中诞生并终生存在。这与更“传统”的应用程序形成对比，这些应用程序可能旨在在自营数据中心的通用商品硬件上运行。由于基于云的应用程序在更高的抽象级别上运行，因此它们也可以与“事件”一起使用，这些事件可以通知最终用户抽象化基础架构中正在发生的事情，从而避免了从较低层次的文件系统中找出问题的负担。蜜蜂。当工程师需要对云平台上发生的事件做出反应时，Serverless 才真正发挥作用。作为提高云事件效率的一个示例，开发人员可能希望在将新文件推送到 S3 存储桶时执行某些操作，例如修改其尺寸并将新文件发布到其他地方。

通过将云提供商的本机抽象用于这些事件，可以大大减轻开发和部署负担。这允许具有创造性的新架构，这些架构可以很好地扩展，甚至可以编织到大数据转换管道中。可以在 Peter Sbarski 的 AWS 上的 Serverless 架构中找到使用 S3 事件的示例。

其他 Serverless 用例

Symphonia 的联合创始人 Mike Roberts 在接受采访时说，Serverless 还具有其他用例。例如，可以被建模为一组异步“实时”（即比人类感知的速度更快）事件的任何系统都可以受益于使用 Serverless 快速响应所有这些事件。对于请求模式不一致的用例，例如 webhooks，这可能会派上用场。 Webhook 可能不会经常触发，但是当它发生时，让 Serverless 功能执行工作而不是服务器上的进程来全天候保留计算能力可能会为企业带来巨大的成本和运营节省。

公司喜欢尝试 Serverless 的一个领域是操作和与呼叫相关的自动化。警报，自动缩放，响应用户消息的聊天机器人，以及所有这些都适合于非对称调用的工作环境，这些工作很有用，但由于并不直接面向最终用户，因此可以进行试验。一旦证明这些系统成功，公司可能会更愿意推出面向用户的服务

何时使用 Serverless

Serverless 必须提供的最大好处之一是它能够减少将某些产品推向市场所需的时间。 不必过多担心订购和配置服务器，可以使工程师解放精力，专注于其他任务，例如快速交付软件。 同样，随着 Serverless 产品继续在堆栈中向上移动，使 Web 应用程序更易于组合在一起，可以大大减少人工成本，因为需要编写和维护的代码更少。

减少劳力不仅可以直接带来金钱上的收益，还可以带来更快乐，更有生产力的开发商。当开发人员知道从构思到生产的想法可能会遇到更少的绊脚石和操作负担时，可能会交付更多的软件，并且更有可能生产出更好的产品。

Serverless 的障碍

Serverless 是一种相对较新的技术，最佳实践仍在完善中。因此，Serverless 非常适合那些有前瞻性思维的人，他们不介意袖手旁观，并且对歧义和风险感到满意。

Serverless 新手应该注意的一个特定领域是其不可预测的使用模型。使用 AWS EC2 之类的传统设置的账单费用更具可预测性，因为该费用基于提前知道的大多数事情，例如实例类型，运行多少小时以及带宽使用情况。另一方面，Serverless 对水平可伸缩性有很高的限制，这使得扩展更容易，但也使计费费用的积累变得更加容易。同样，调用 Serverless 功能可能很便宜，将其输出写入日志实用程序的成本最终可能会比预期更快地产生高成本。例如，随着 AWS Lambdas 向其写入日志，AWS CloudWatch 日志记录成本将迅速增加。如果第三方监视工具（例如 Datadog）也从 CloudWatch 摄取此数据，则可能会产生进一步的费用。

最后，了解 Serverless 供应商的实际承诺可能很模糊。对于传统服务器，事先就可以很好地了解有关分配给计算机的可用性和资源的协议，并在合同中进行了详细说明。在 Serverless 的情况下，冷启动时间，错误的函数调用以及其他“陷阱”可能潜伏在角落。这些最终可能会破坏您的预期用例。例如，迈克·罗伯茨（Mike Roberts）表示，要求亚毫秒级响应时间的应用程序仍然不是当今大多数 Serverless 产品的理想选择。像任何新的范例一样，明确的期望和解决缺陷的方法可能会随着时间而逐渐成熟，但是目前，Serverless 用户只能自己进行试验。

原文链接：https://blog.csdn.net/AndroidYingZi/article/details/120926519