未来属于 Serverless

引言

用户已经云这个概念很多年了，但是最近，用户可能已经听说了更多关于 Kubernetes 和 Docker 的信息，就是说，Serverless 正在成为一种极具意义的云架构范式。

Serverless 代表了我们的云中构建应用程序的方式发生这巨大的改变，这种影响不仅体现在工程层面，也体现在业务层，Serverless 计算极大地改变了用户管理云基础架构和构建系统的方式。用户无需一次构建整个系统或微服务，可以一次只部署一些功能。用户只需要关注代码，并且知晓功能将随着应用一起扩展，而无需管理基础架构。

我们首先将对 Serverless 下一个定义，看一些使用场景，确定 Serverless 是否适合用户的技术栈，以及如何大规模管理 Serverless，最后看一下此更改将如何影响未来的业务。

什么是 Serverless

那么到底什么是 Serverless？首先，它还是涉及到服务器的，Serverless 的本质是尽管服务器依然存在，但是它们与用户的应用程序体系结构无关，因此工程团队只需要关注应用程序代码。

Serverless 具体的定义还存在一些争议，本文中，我们集中讨论一些共同的特征。Serverless 是一种云架构，通常遵循以下特征：

• 不需要管理服务器、虚拟机和容器
• 对托管服务的依赖：如云提供商或第三方服务
• 事件驱动的架构，应用代码仅在触发时运行
• 云提供商的计费模式，只需为使用的应用程序付费

Serverless 计算改变了共享责任模型（shared responsibility model），现在 PaaS 服务提供商为用户管理了操作系统和运行时，这样工程师可以专注于代码。

这些是 Serverless 的一些共同特征，可以帮助我们更好地理解讲解的内容，现在让我们深入往下。

FaaS

当人们谈论 Serverless 时，通常会想到功能即服务，即 FaaS，这是因为 FaaS 是 Serverless 的核心。AWS 推广 Lambda，Google 推广 Cloud Functions，Microsoft 推广 Azure Functions，这是大多数云供应商 Serverless 产品中最引人注目的部分。

Serverless 方法并不是完整的应用程序。将一个应用程序，比如后端 REST API，将它们分解成细粒度的各部分，REST API 上的每个端点都变成独立的功能，这些功能仅执行特定的任务，并且仅在收到 Http 请求时才触发这些功能。

用户可以通过组装各种方法，而不是通过单个应用，在数据库中增删改查记录，这样用户就能对方法彼此独立地进行更新和部署。通过解耦这些功能，可以降低因为在某个功能中引入一个 Bug，而导致另一个功能无法执行的风险。

在 FaaS 平台上运行的功能非常短暂，这意味着它们最多运行几分钟，有充足的的时间保证它们能够完成有限的任务。临时也意味着它们在两次调用之间不会保持应用程序状态，相反，应使用外部数据存储来管理应用程序状态。

公共和私有的托管 FaaS 平台种类繁多，在共有云服务中，AWS、Google 和 Microsoft 提供 FaaS 服务和其他托管云服务以构建 Serverless 应用程序。

私有的 FaaS 平台包括 Knative 和 Apache OpenWhish，Knative 强依赖 Kubernetes，OpenWhish 可以在包括 Kubernetes、Mesos 和 Docker Compose 在内的云管理平台上运行。这些私有的 FaaS 平台使用户可以在现有的云管理基础架构上利用 Serverless 架构。

Serverless1.png

其他类型的 Serverless

FaaS 应用程序并不是唯一可视为 Serverless 的云应用程序，还有许多其他 Serverless 计算服务可用，其中包括对象存储、NoSQL 数据库和通知服务。尽管每种 Serverless 计算产品都在基础架构上运行，但作为使用服务的用户，不必担心管理基础架构，PaaS 提供商会提供管理。

此外，也可以使用 Serverless 来构建静态网站，考虑一个使用 HTML、CSS、客户端 JS 脚本和图像构建构建的静态网站，根据一个月内网站的请求数收费。现在，将其与按小时收费的主机上运行的类似站点进行比较，无论那个站点的访问量多少，收费都是固定的。放眼未来，随着越来越多的开发人员转向 GraphQL 服务，我们会看到 Serverless 动态 Web 应用程序的增加。

Serverless2.png

为什么要 Serverless

用户为什么要采用服务架构？首先，它降低单个工程师操作云基础架构的复杂性，这样，工程师花费更少的时间在基础架构，可以花费更多的时间在代码和有望解决的问题上。此外，降低云复杂性意味着开发人员与运维之间摩擦会减少，这样可以加快功能开发速度，加快产品交付速度。

成本问题是采用 Serverless 的另一个原因，用户为什么要为了不是那么经常使用的云服务付费？通过仅支付活跃使用的云资源费用，组织可以削减成本。这就是将环境中不经常使用的应用程序改建为 Serverless 的原因。但是，并非所有程序都是平等创建的。某些应用程序比其他应用程序具有更好的成本效益。

最后，最重要的是，组织可以专注于其核心能力。现在，每家公司都是技术公司，每个公司都需要大量的技术投资来保持其组织的运转。使用 Serverless 使组织可以在操作应用程序上花费更少的时间和资源，节省下来的时间和资源可以重定向到为客户创造价值。企业组织的独特之处不是它使用的云基础架构，而是它提供给用户的功能和价值。

优点、缺点

与所有技术一样，它也有优点和缺点。在采用 Serverless 解决方案之前，应注意以下几点：

优点

• 高可扩展性：Serverless 的第一个优点是其可扩展性，Serverless 平台负责分配和管理功能实例以满足需求。与传统服务器体系结构上的微服务相比，用户需要在垂直或水平方向上扩展主机以满足需求，这可能需要手动干预，自动缩放规则执行起来很慢。
• 减少云运维的工作量：尽管 Serverless 不能完全消除这一点，但它减少了云基础架构操作的问题。开发人员需要花多少时间等待主机部署新代码？借助 Serverless，同时部署应用程序代码和支持基础架构仅需几分钟，云基础架构几乎不会出错，影响应用程序代码。之前有多少次因为 CPU、内存或磁盘问题导致应用程序报错，这些之后都不再是问题。
• 敏捷性和专注：最后，Serverless 使应用程序开发人员可以专注于其代码尝试解决的问题，而不会被云基础架构所打扰。此外，快速部署的能力意味着团队可以交付更多成功的功能。采用 Serverless 的团队应该能够交付更多的功能，并准确衡量他们是否已提供正确的功能。

缺点

• 供应商绑定：如果用户的组织与供应商绑定在一起，那么 Serverless 不是用户正确的选择。对云提供商的服务使用越深入，就可以从中获取更多的价值。如果用户担心过于依赖云供应商，并希望灵活地更换供应商，那么 Serverless 不是用户的最佳选择。
• 工程实践仍在涌现：Serverless 工程仍在涌现，这意味着开发模式、流程和工具仍在开发中。此外，要找到成熟掌握 Serverless 功能技术的人并不容易，用户需要花一些时间来开发组织的最佳实践和培训资源。
• 不适合所有负载：Serverless 不适用于所有工作负载，尤其是长期运行的工作负载。Serverless 被设计用于短期运行的临时任务。如果用户的任务需要大量的执行时间，或者需要在两次执行之间跟踪磁盘上的状态，那么 Serverless 是不合适的，但是，重构可能或多或少会解决这个问题。

中立

• 成本：几个因素会影响 Serverless 服务的成本，包括工作量、使用的服务类型和平台定价模型。并非所有 Serverless 工作负载都是相同的成本，这意味着某些服务在传统的服务器上运行成本更低，有些在 Serverless 架构上运行成本更低。

什么场景应该使用 Serverless

什么时候使用 Serverless 解决方案？更具体地说，什么时候应该使用 Serverless 功能？某些 Serverless 服务（例如 S3 和 dynamoDB）没有持续时间和使用限制，这意味着用户可以在 S3 桶中存储任意数量的数据。

当用户需要处理计算负载时，Amazon Lambda 之类的 Serverless 功能会提出一些限制，例如：

1. 用户上传的 AWS Lambda 的软件包的最大大小为 50M；
2. Lambda 函数使用的内存最大限制位3GB；
3. 用户持续的功能需要在15分钟内完成。

这些限制决定了哪些用例最适合 Serverless功能，每当用户需要执行短暂的功能时，可以使用 Serverless 功能。在下面这些用例中，使用 Serverless 功能是不错的选择：

• 数据处理 - 管理实时数据分析（而不是ETL作业）
• 聊天机器人 - 通过 Serverless 功能为聊天机器人赋能
• 启用语音的应用程序 - 与 Alexa 类似，使用 Lambda 函数为语音 UI 赋能
• 自动化 - 使用 Serverless 功能管理云基础架构，实施策略等
• 物联网 - 将 Serverless 功能用于物联网的服务端处理，物联网设备的大型网络可以产生大量数据

我们会更详细地研究下列用例，以更好的理解，以下是几个 Serverless 功能的典型使用场景：

用例一：将数据上传到云存储后进行处理

当用户将数据上传到对象存储器后（例如 S3、Cloud Storage 或 Azure Storage），可以触发 Serverless 功能以立即处理数据。例如：在一个费用跟踪 App 中，用户为收据拍照时，需要将图像存储到对象存储器中，然后对其进行处理，对于 Serverless 功能，这是一个很好的应用场景。

为了实现此解决方案，需要配置对象存储器，使得在 S3 中创建对象时可以触发事件调用特定的 Serverless 功能。场景不仅限于使用对象存储器，用户也可以在自己的方法中使用 Serverless 计算服务。示例中，我们可以处理图像，将图像存储在其他对象存储桶中，然后在 Serverless 数据库表中更新一行。

用例二：客户端App访问数据库

构建具有丰富客户端功能的应用程序变的越来越普遍，例如基于 React 等框架构建的 App 或单页 Web 应用程序。出于安全原因，它们缺乏对数据库的直接访问权限，通常用户希望通过 Web 服务队输入进行身份验证。

例如，已登录的用户希望查看其个人资料被查看了多少次，以及被谁查看。当用户单击其个人资料时，我们要显示其最新的个人资料统计信息。Web 应用程序向 Rest API 网关发出 Get 请求，而 Rest API 网关又调用 Serverless 功能，Serverless 功能会调用数据库获取用户配置文件数据，汇总数据并返回结果，然后 Web 应用程序显示数据。这是短暂的操作，不需要运行专门的服务器。

用例三：数据流处理

Serverless 功能非常适合处理定期更新的数据流。例如，可以将一个方法与 Apache Kafka 或 Amazon Kinesis 一起使用以聚合数据并将其存储在数据库中。在此用例中，Kafka 将存储数据流，然后 Lambda 方法将轮询 Kafka，以50个项目为一组，消费其中的数据并存储在数据库中。

用例四：突发事件

如果用户的应用程序收到突发的活动，维护额外的服务器容量可能会非常昂贵，自动伸缩规则执行的速度也会很慢。

例如，用户的后端服务同时支持 PC 和移动端应用程序。今天是您的幸运日，您的应用程序在 AppStore 的首页上显示，然后在 Hasker News 上进行推广。这样的成功带来了意想不到的活动热潮。

在后端使用 Serverless 设计，用户永远不会知道您是否期待他们。Serverless 基础架构可以扩展以满足需求，而不会因为系统无法处理负载而导致系统故障。诸如金融业监管局（FINRA）之类的公司每天可以处理多达5万亿个 Serverless 功能调用。用户系统收到的所有负载（无论是计划内的还是计划外的）都将由 Serverless 架构妥善处理。

什么场景不应该使用 Serverless

使用 Serverless 架构不能控制所有计算类型实例，根据系统需要，Serverless 不适用于某些执行环境，以下是 Serverless 功能不适用的场景：

长期运行的代码

Serverless 功能通常有最长执行时间的限制，因此，如果用户的代码需要连续执行，或者需要执行较长的计算，则它们不是理想的选择。例如，用户的应用程序具有一种调度算法，可将数千名学生和班级与老师进行匹配，匹配算法大约需要一个小时才能完成。此代码无法作为 Serverless 功能成功运行。由于用户无法更改 Serverless 功能的执行时间限制，因此用户需要更改实现或将应用程序部署到服务器上。

进程间通信

由于 Serverless 功能在隔离的环境中运行，因此无法在两个功能之间共享内存。这种情况最有可能来自多线程实现，其中每个线程使用共享内存区域来回传递数据。也就是说，用户可以使用单独的缓存来存储数据，可以在方法和方法之间共享此缓存。

遗留系统

如果用户将现有系统迁移到 PaaS 平台，不多数不是为了短暂的活动运行而设计的，因此，它不适合 Serverless 功能。由于大多数企业系统被设计为一旦启动永久运行，知道它们停止运行或崩溃，所以升降机方法可能不适合 Serverless 计算模型。但是，一旦系统迁移到云中，就可以将应用程序的部分迁移到 Serverless 架构。

管理 Serverless 服务

在考虑过滤到 Serverless 功能时，用户还需要研究如何有效地管理它们。由于采用 Serverless 可减少运营和管理的开销，用户需要适当的工具确保功能可靠、安全且经济地运行。

身份验证和授权

应用程序身份验证和授权可以采用云供应商的服务（如 AWS Cognito）、第三方 SaaS 服务（例如 Auth0），或者采用自定义的授权功能方法。组织通常依赖某种令牌或 API 密钥功能来控制公共访问，合规性要求需要保证员工在有限的基础上访问敏感数据。依靠 IP 白名单或 VPC 连接可能无法提供大型组织中所需的细粒度控制。

限流

Serverless 内置的可扩展性可能使用户产生错觉，不需要限流功能，但事实并非如此。大多数平台都提供基于使用情况的支付模型，因此，使用量激增可能导致大笔账单，无论是否有意为之。

对于每个传入的 API 请求，云供应商都负责分配功能示例来处理该请求。随着 Serverless 的可伸缩性和满足需求的重担转移到了云供应商，为什么还要对 API 限流呢？因为从实际运行的角度来说，云供应商会对服务施加限制和配额，而且，这些限制通常涉及范围很广，这意味着，过度使用某个 API 会影响其他 API 成功运行。幸运的是，云供应商可以评估 API 服务的速率或限制函数调用的并发性。对于更智能的限流逻辑，用户可能需要考虑使用自己的 API 网关（例如 Kong）进行限流。

可观察性：度量、监控、记录和追踪

我们之前提过，Serverless 会减少但不是不需要云运维工作。Serverless 及其事件驱动的体系结构会导致一定程度的应用程序复杂性。当出现问题时，需要知道是执行链中的哪一环出错了。保证 Serverless 应用程序运行意味着需要增加整个应用程序堆栈的可观察性，但这并没有增加整体负载。在管理主机上节省时间意味着有更更多时间主动确保应用程序的可靠性。

安全

Serverless 安全隐患类似于当今的虚拟化或容器化的服务。应用程序代码和应用程序依赖的安全性都非常重要，而且相同的做法也可以延续到 Serverless。没有了服务器后，无需花费时间在主机级别的安全问题上，例如软件补丁和访问控制。相反，应将注意力转向保护云基础架构和功能代码，以防止诸如远程执行代码或 SQL 注入之类的攻击。

使用 API 网关

像 Kong 这样的 API 网关可以使用户更轻松地管理 Serverless 功能。Kong 无需在每个功能中实现所有这些管理功能，而可以将它们放在集中且易于管理的位置。它充当代理并接受来自客户端的调用，然后将其传递给 Serverless 方法。添加身份验证、安全性、可观察性等功能就如同从 Kong Hub 中添加插件一样容易。此外，与云供应商分开的 API 网关允许用户管理多个云环境中的方法。

这进一步减少了发布新功能所需的开发工作量，不必担心服务器基础结构或服务管理，意味着开发人员可以专注于业务逻辑并加快产品的上市时间。

Serverless 如何改变业务

改变组织流程和结构的技术并不新鲜，看下共有云的采用和其产生的影响即可知。对于 Serverless，同样会再次发生。竞争优势将属于优先采用这些做法的公司，这是当前世界已经发生变革的一些方式。

DevOps 的兴起

首先，Serverless 将开发人员和运营人员转向 DevOps 角色，使得他们工作更加紧密。通过将基础架构和代码结合在一起，软件开发人员将不需要运维工程师将其代码投入生产。一些组织将看到传统的运维工程师重新培养新技能并成为开发团队的一部分，他们将在这个新职位上处理团队服务的运营需求。这是 DevOps 的梦想：一个完整的跨职能团队，涉及软件开发和运维生命周期的所有成员。

更多地关注业务成果

工程团队将更加专注于实现组织目标。Serverless 的专注、速度和敏捷性意味着更注重结果，这是因为团队现在有时间这样去做。团队无需再为工作的前期技术需求而烦恼，他们可以更快地交付产品，并花费时间评估交付的产品是否成功。想象一下，一个团队不仅关注他们的设计，而且关注他们的工程是否有价值、有意义。

对于拥有大量代码库的公司而言，采用 Serverless 架构并非易事。类似 Kong 这样的解决方案通过为用户提供对身份验证、限流等现成支持，可以更轻松地采用和管理 Serverless 功能。