认识ServerLess,这篇文章就够了

1,877 阅读19分钟

什么是无服务器 ?

生产力决定生产关系,云计算的概念层出不穷,其本质上还是对生产关系和生产力的配置与优化,生产者抛开场景意味追求高大上的技术将譬如“大炮打蚊子”,小题大做,鼓励大家为了满足大家的好奇心进行折腾,毕竟那么多科学发现和重大发明都是因为折腾出来的,不想要一匹跑的更快的马,而是发明汽车的福特,捣鼓炸药的诺贝尔,种豌豆的孟德尔……同时还是要考虑将技术产业化(或许能改变生产关系),提高生产力。 ——Karl Marx

在介绍ServerLess之前,我们先了解几个概念,更有助于我们整体理解ServerLess这个概念。

无服务器

传统上,我们已经构建并部署了 web 应用程序,对这些应用程序,我们可以对服务器发出的 HTTP 请求进行一定程度的控制。我们的应用程序运行在该服务器上,我们负责为其配置和管理资源。但这会产生一些问题:

  • 即使没有处理任何请求,我们也要保持服务器正常运行。
  • 我们负责服务器及其所有资源的正常运行及维护。
  • 我们还负责对服务器进行适当的安全更新。
  • 随着使用量的扩张,我们还需要管理服务器的扩展(扩容),结果是,当我们没有太多使用量时,我们要将其减少(缩容)。

对于较小的公司和个人开发者而言,这可能需要处理很多工作。这使得我们无法专注于我们更重要的工作,构建和维护实际的应用程序。在大型组织中,这是由基础设施团队处理的,并且通常这不是开发者个人的责任。但是,为此所需的过程最终可能减慢开发时间。因为你不能不与基础架构团队合作来帮助你启动和运行而直接继续构建应用程序。作为开发者,我们一直在寻找一种解决这些问题的方法,这就是无服务器的来源。

无服务器计算

无服务器计算(简称 serverless),是一种执行模型,在该模型中,云服务商(AWS,Azure 或 Google Cloud)负责通过动态分配资源来执行一段代码,并且仅收取运行代码所使用资源的费用。该代码通常运行在无状态的容器中,能够被包括 HTTP 请求、数据库事件、队列服务、监控报警、文件上传、调度事件(cron 定时任务)等各种事件触发。被发送到云服务商执行的代码通常是以函数的形式,因此,无服务器计算有时是指 “函数即服务” 或者 FAAS(Funtion As A Service)。以下是主要云服务商提供的 FAAS 产品:

无服务器计算让您可以在不考虑服务器的情况下构建并运行应用程序和服务。它消除了基础设施管理任务,例如服务器或集群配置、修补、操作系统维护和容量预置。您能够为几乎任何类型的应用程序或后端服务构建无服务器应用程序,并且运行和扩展具有高可用性的应用程序所需的所有操作都可由您负责。

无服务器应用程序是由事件驱动的,并通过与技术无关的 API 或消息收发进行松散耦合。为了响应事件而执行事件驱动型代码,例如状态更改或终端节点请求。事件驱动型架构将代码与状态解耦。松散耦合组件之间的集成通常使用消息收发异步完成。

为什么使用无服务器计算?

优势

  • 无服务器管理 无需预置或维护任何服务器。无需安装、维护或管理任何软件或运行时。

  • 灵活扩展

您的应用程序可自动扩展,或通过切换占用资源(如吞吐量、内存)的单位数(而不是切换单个服务器的单位数)来调整容量,从而实现扩展。

  • 按价值付费 为一致的吞吐量或执行持续时间(而不是服务器单元)付费(实际上只需为每个请求付费)。

  • 自动化的高可用性

无服务器应用程序提供内置可用性和容错功能。您无需构建这些功能,因为运行此应用程序的服务在默认情况下会提供这些功能。

劣势

  • 冷启动 性能差

现在的云服务商,基于不同的语言特性,冷启动平均耗时基本在 100~700 毫秒之间。得益于 Google 的 JavaScript 引擎 Just In Time 特性,Node.js 在冷启动方面速度是最快的。

  • 监控与调试复杂

  • 依赖云厂商

举个🌰(Lambda)

无服务器应用程序通常使用完全托管的服务作为跨计算、数据、消息收发和集成、流传输以及用户管理和身份层的构建块来构建。AWS Lambda、API Gateway、SQS、SNS、EventBridge 或 Step Functions 等服务是大多数应用程序的核心,受 DynamoDB、S3 或 Kinesis 之类的服务支持。

类别服务说明
计算AWS LambdaAWS Lambda 让您可以在托管平台上运行无状态的无服务器应用程序,该平台支持微服务架构、部署和管理函数层的执行。
API 代理API GatewayAmazon API Gateway 是一项完全托管型服务,可让开发人员轻松地在任何规模下创建、发布、维护、监控和保护 API。它为 API 管理提供综合平台。使用 API Gateway,您可以处理数十万个并发的 API 调用,并且可处理流量管理、授权和访问控制、监控和 API 版本管理。
消息收发SNSAmazon SNS 是完全托管的消息发布/订阅服务,可轻松分离和扩展微服务、分布式系统和无服务器应用程序。
消息收发SQSAmazon SQS 是完全托管的消息队列服务,可轻松分离和扩展微服务、分布式系统和无服务器应用程序。
事件EventBridgeAmazon EventBridge 是无服务器事件总线,可使用您自己的应用程序数据将应用程序连接在一起,集成软件即服务(SaaS) 应用程序和 AWS 服务。
编排Step FunctionsAWS Step Functions 让您能够使用可视化工作流程图轻松协调分布式应用程序和微服务的组件。

尽管无服务器计算对开发人员抽象了底层基础设施,但服务器仍然参与执行我们的函数。由于你的代码将要作为独立的函数执行,我们需要知道以下几点:

微服务

当向无服务器计算的世界过度时,我们面临的最大变化是我们的程序需要被组织成函数的形式。你可能习惯于将你的应用程序部署为单个 Rails 或 Express 整体应用程序。但是在无服务器计算的世界里,你通常需要采用更多基于微服务的架构。你可以通过在单个函数中作为一个整体运行你的整个应用程序并自行处理路由来解决此问题。但不建议这样做,因为减小你的函数的大小更好。我们将在下面讨论。

无状态函数

你的函数通常运行在安全的(几乎是)无状态容器中,这意味着你将无法在一个事件已经完成后长时间执行的应用服务器中运行代码,或者无法使用先前的执行上下文为请求提供服务。你不得不有效地假定你的函数每次都在一个新容器中被调用。

冷启动

由于你的函数在需要响应事件的容器中运行,因此存在一定的延时。这被称为”冷启动”。当你的函数执行完成后,你的容器可能会保留一段时间。如果另一个事件在此时被触发,则它的响应速度要快得多,这通常被称为”热启动”。

冷启动的持续时间取决于特定云服务商的实现。在 AWS Lambda 上,它的范围从几百毫秒到几秒不等。它可能取决于使用的运行时(或编程语言)、函数(以包的形式)的大小,当然,还取决于所讨论的云服务商。多年以来,随着云服务商在优化时延方面变得越来越出色,冷启动已经大为改善。

函数处于运行状态插件

什么是 Serverless?

Serverless(无服务器架构)是指服务端逻辑由开发者实现,运行在无状态的计算容器中,由事件触发,完全被第三方管理,其业务层面的状态则存储在数据库或其他介质中。即是一个由事件驱动的全托管的云计算服务。所以说Serverless是云原生技术发展的高级阶段,可以使开发者更聚焦在业务逻辑,从而减少对基础设施的关注。

另外,Serverless强调的是NoServer,并不是无服务,它的代码仍然运行在服务器上。只是业务侧更聚焦在业务逻辑代码。

Serverless 的历史

IaaS

IaaS(Infrastructure as a Service),2006年由AWS推出,本质上讲是服务器租赁并提供基础设施外包服务。

Paas

PaaS(Platform as a Service),构建在 IaaS 之上的一种平台服务,提供操作系统安装、监控和服务发现等功能,用户只需要部署自己的应用即可。

Saas

Saas (Software as a Service), 改变了传统软件服务的提供方式,减少本地部署所需的大量前期投入,进一步突出信息化软件的服务属性。

历史上第一个 Serverless 平台可以追溯到 2006 年,名为 Zimki(该公司已倒闭);

总结:

Serverless 实际发展已经有 15 年之久,而随着以 Kubernetes 为基础的的云原生应用平台的兴起,serverless 再度成为人民追逐的焦点。

Serverless 的组成

FaaS

FaaS(Functions as a Service)函数即服务,FaaS 是无服务器计算的一种形式,当前使用最广泛的是 AWS 的 Lambada。FaaS 本质上是一种事件驱动的由消息触发的服务。

aa.jpeg

与传统的服务器端软件不同是经应用程序部署到拥有操作系统的虚拟机或者容器中,一般需要长时间驻留在操作系统中运行,而 FaaS 是直接将程序部署上到平台上即可,当有事件到来时触发执行,执行完了就可以卸载掉。

BaaS

BaaS(Backend as a Service)后端即服务,一般是一个个的 API 调用后端或别人已经实现好的程序逻辑,比如身份验证服务 Auth0,这些 BaaS 通常会用来管理数据,还有很多公有云上提供的我们常用的开源软件的商用服务,比如亚马逊的 RDS 可以替代我们自己部署的 MySQL,还有各种其它数据库和存储服务。

bb.jpeg

Landscape

Serverless 的使用场景

CNCF Serverless Whitepaper v1.0 中给出了更多 Serverless 使用场景的详细描述。

示例

我们以一个游戏应用为例,来说明什么是 serverless 应用。

一款移动端游戏至少包含如下几个特性:

  • 移动端友好的用户体验
  • 用户管理和权限认证
  • 关卡、升级等游戏逻辑,游戏排行,玩家的等级、任务等信息

传统的应用程序架构可能是这样的:

这样的架构开发起来比较容易,但维护起来十分复杂,前后端开发都需要十分专业的人 和 环境配置。还要有人专门维护数据库、应用的更新和升级等等。

而在 serverless 架构中,我们不再需要在服务器端代码中存储任何会话状态,而是直接将它们存储在 NoSQL 中,这样将使应用程序无状态,有助于弹性扩展。前端可以直接利用 BaaS 而减少后端的编码需求,这样架构的本质上是减少了应用程序开发的人力成本,降低了自己维护基础设施的风险,而且利用云的能力更便于扩展和快速迭代。

Serverless 的优缺点

Serverless 架构不是一劳永逸的,是否使用 Serverless 也需要根据实际需要来选择,请先考虑 Serverless 的优缺点。

优点

今天大多数公司在开发应用程序并将其部署在服务器上的时候,无论是选择公有云还是私有的数据中心,都需要提前了解究竟需要多少台服务器、多大容量的存储和数据库的功能等。并需要部署运行应用程序和依赖的软件到基础设施之上。假设我们不想在这些细节上花费精力,是否有一种简单的架构模型能够满足我们这种想法?这个答案已经存在,这就是今天软件架构世界中新鲜但是很热门的一个话题——Serverless(无服务器)架构。

——AWS 费良宏

  • 降低运营成本

Serverless 是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑,否则您就不得不自己来维护。由于这个服务使用者的数量会非常庞大,于是就会产生规模经济效应。在降低成本上包含了两个方面,即基础设施的成本和人员(运营/开发)的成本。

  • 降低开发成本:

IaaS 和 PaaS 存在的前提是,服务器和操作系统管理可以商品化。Serverless 作为另一种服务的结果是整个应用程序组件被商品化。

  • 扩展能力:

Serverless 架构一个显而易见的优点即“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。从基本的基础设施方面受益最大的好处是,您只需支付您所需要的计算能力。

  • 更简单的管理:

Serverless 架构明显比其他架构更简单。更少的组件,就意味着您的管理开销会更少。

  • 降低人力成本

不需要再自己维护服务器,操心服务器的各种性能指标和资源利用率,而是关心应用程序本身的状态和逻辑。而且 serverless 应用本身的部署也十分容易,我们只要上传基本的代码但愿,例如 Javascript 或 Python 的源代码的 zip 文件,以及基于JVM的语言的纯 JAR 文件。不需使用 Puppet、Chef、Ansible 或 Docker 来进行配置管理,降低了运维成本。同时,对于运维来说,也不再需要监控那些更底层的如磁盘使用量、CPU 使用率等底层和长期的指标信息,而是监控应用程序本身的度量,这将更加直观和有效。

在此看来有人可能会提出 “NoOps” 的说法,其实这是不存在的,只要有应用存在的一天就会有 Ops,只是人员的角色会有所转变,部署将变得更加自动化,监控将更加面向应用程序本身,更底层的运维依然需要专业的人员去做。

  • 降低风险

对于组件越多越复杂的系统,出故障的风险就越大。我们使用 BaaS 或 FaaS 将它们外包出去,让专业人员来处理这些故障,有时候比我们自己来修复更可靠,利用专业人员的知识来降低停机的风险,缩短故障修复的时间,让我们的系统稳定性更高。

  • 减少资源开销

我们在申请主机资源一般会评估一个峰值最大开销来申请资源,往往导致过度的配置,这意味着即使在主机闲置的状态下也要始终支付峰值容量的开销。对于某些应用来说这是不得已的做法,比如数据库这种很难扩展的应用,而对于普通应用这就显得不太合理了,虽然我们都觉得即使浪费了资源也比当峰值到来时应用程序因为资源不足而挂掉好。

解决这个问题最好的办法就是,不计划到底需要使用多少资源,而是根据实际需要来请求资源,当然前提必须是整个资源池是充足的(公有云显然更适合)。根据使用时间来付费,根据每次申请的计算资源来付费,让计费的粒度更小,将更有利于降低资源的开销。这是对应用程序本身的优化,例如让每次请求耗时更短,让每次消耗的资源更少将能够显著节省成本。

  • 增加缩放的灵活性

以 AWS Lamba 为例,当平台接收到第一个触发函数的事件时,它将启动一个容器来运行你的代码。如果此时收到了新的事件,而第一个容器仍在处理上一个事件,平台将启动第二个代码实例来处理第二个事件。AWS lambad 的这种自动的零管理水平缩放,将持续到有足够的代码实例来处理所有的工作负载。

但是,AWS 仍然只会向您收取代码的执行时间,无论它需要启动多少个容器实例要满足你的负载请求。例如,假设所有事件的总执行时间是相同的,在一个容器中按顺序调用Lambda 100 次与在 100 个不同容器中同时调用 100 次 Lambda 的成本是 一样的。当然 AWS Lambada 也不会无限制的扩展实例个数,如果有人对你发起了 DDos 攻击怎么办,那么不就会产生高昂的成本吗?AWS 是有默认限制的,默认执行 Lambada 函数最大并发数是 1000。

  • 缩短创新周期

小团队的开发人员正可以在几天之内从头开始开发应用程序并部署到生产。使用短而简单的函数和事件来粘合强大的驱动数据存储和服务的 API。完成的应用程序具有高度可用性和可扩展性,利用率高,成本低,部署速度快。

以 Docker 为代表的容器技术仅仅是缩短了应用程序的迭代周期,而 serverless 技术是直接缩短了创新周期,从概念到最小可行性部署的时间,让初级开发人员也能在很短的时间内完成以前通常要经验丰富的工程师才能完成的项目。

缺点

  • 状态管理

要想实现自由的缩放,无状态是必须的,而对于有状态的服务,使用 serverless 这就丧失了灵活性,有状态服务需要与存储交互就不可避免的增加了延迟和复杂性。

  • 延迟

应用程序中不同组件的访问延迟是一个大问题,我们可以通过使用专有的网络协议、RPC 调用、数据格式来优化,或者是将实例放在同一个机架内或同一个主机实例上来优化以减少延迟。

而 serverless 应用程序是高度分布式、低耦合的,这就意味着延迟将始终是一个问题,单纯使用 serverless 的应用程序是不太现实的。

  • 本地测试

Serverless 应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境,但是对于无服务应用的集成或者端到端测试尤其困难,很难在本地模拟应用程序的各种连接,并与性能和缩放的特性结合起来测试,并且 serverless 应用本身也是分布式的,简单的将无数的 FaaS 和 BaaS 组件粘合起来也是有挑战性的。

具体实操就不写了,网上有很多教程,分享一个感觉不错的文章:ServerLess前端实践

开源框架:

  • booster - Booster is a framework for building and deploying reliable and scalable event-driven serverless applications.
  • dapr - Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
  • dispatch - Dispatch is a framework for deploying and managing serverless style applications.
  • easyfaas - EasyFaaS 是一个依赖轻、适配性强、资源占用少、无状态且高性能的函数计算服务引擎.
  • eventing - Open source specification and implementation of Knative event binding and delivery.
  • faas-netes - Enable Kubernetes as a backend for Functions as a Service (OpenFaaS).
  • firecamp - Serverless Platform for the stateful services.
  • firecracker - Secure and fast microVMs for serverless computing.
  • fission - Fast Serverless Functions for Kubernetes.
  • fn - The container native, cloud agnostic serverless platform.
  • funktion - A CLI tool for working with funktion.
  • fx - Poor man's serverless framework based on Docker, Function as a Service with painless.
  • gloo - The Function Gateway built on top of Envoy.
  • ironfunctions - IronFunctions - the serverless microservices platform.
  • keda - KEDA is a Kubernetes-based Event Driven Autoscaling component. It provides event driven scale for any container running in Kubernetes.
  • knative-lambda-runtime - Running AWS Lambda Functions on Knative/Kubernetes Clusters.
  • knix - KNIX MicroFunctions is a serverless computing platform that combines container-based resource isolation with a lightweight execution model using processes to significantly improve resource efficiency and decrease the function startup latency. KNIX MicroFunctions works in Knative as well as bare metal or virtual machine-based environments.
  • kubeless - Kubernetes Native Serverless Framework.
  • layotto - A fast and efficient cloud native application runtime.
  • nuclio - High-Performance Serverless event and data processing platform.
  • openfaas - OpenFaaS - Serverless Functions Made Simple for Docker & Kubernetes.
  • openwhisk - Apache OpenWhisk (Incubating) is a serverless, open source cloud platform that executes functions in response to events at any scale.
  • osiris - A general purpose, scale-to-zero component for Kubernetes.
  • riff - Riff is for functions.
  • serverless - Serverless Framework – Build web, mobile and IoT applications with serverless architectures using AWS Lambda, Azure Functions, Google CloudFunctions & more!
  • serving - Kubernetes-based, scale-to-zero, request-driven compute.
  • spec - CloudEvents Specification.
  • sqoop - The GraphQL Engine powered by Gloo.
  • thanos - Highly available Prometheus setup with long term storage capabilities.

参考文档:

jimmysong.io/awesome-clo…

www.liangzl.com/get-article…

aws.amazon.com/cn/getting-…

juejin.cn/post/684490…

serverless.com

juejin.cn/post/684490…

serverLess白皮书