来源：图灵社区

"有些鸟儿是关不住的，因为它们的羽翼太过耀眼。"——肖申克的救赎

Serverless 绝对是近两年最火的词之一，伯克利论断它是云时代的主宰，阿里高级前端专家说它正在颠覆以往的开发模式，腾讯高级前端工程师说它将引发前端的第三次变革。

到底什么是Serverless呢？

Serverless，直译过来就是无服务器，它是一种软件系统架构思想和方法。它的核心思想是让用户无须关注支撑应用服务运行的底层资源，比如：CPU、内存和数据库等，只需要关注自己的业务开发即可。

由于 Serverless 计算在工程效率等方面颠覆式的体验，迅速成为业界的热点，被大量的企业和开发者采用。

下面是一份腾讯云对 Serverless 目前的发展情况统计。

最近几年，微服务和k8s很火。上图可以看到Serverless跟他们的热度对比，其中蓝色曲线是Serverless的热度曲线图。从2016年开始，Serverless的热度是要大于微服务和k8s的。

Serverless最初在2010年被提出，2014年AWS推出了lambda服务，把 Serverless产品化，并收到了很好的效果，微软、Google和IBM看到后，也分别在2016年推出了自己的Serverless产品：Azure function、GCP 和 OpenWisk。阿里云和腾讯云也分别在2017年推出了自己的Serverless产品，腾讯云要早阿里云一天推出。

01 直观理解Serverless

我们明白了Serverless大概是什么，下面这篇“码农翻身”刘欣老师的文章，会让我们理解得更加清晰透彻。

原文请戳：我建议你了解一点儿Serverless

一个新技术的出现不是无中生有，从石头中凭空蹦出来的，而是在原有基础上的继承和发展。

Serverless也不例外，我们回顾下IT基础设施的发展就会发现，Serverless自然就会浮现出来，你自己就可以发明它（但是却实现不了它）。

1. 局域网时代

上世纪90年代，你是一家IT部门的负责人，公司需要建立一个信息管理系统，这时候的系统都是局域网的， 是C/S模式的， 业务逻辑主要在客户端软件中， 需要被安装到各个电脑上去，然后访问同一个数据库。

C/S模式就是指客户端/服务器模式，是计算机软件协同工作的一种模式。

在部署这个系统之前，你需要做很多的工作：

搭建局域网， 购买交换机，路由器。

买服务器，安装操作系统，比如Window NT。

安装数据库软件，例如Oracle。

然后再把那些Delphi/VB/PowerBuilder写的客户端安装到电脑上, 整个系统跑起来了。

2. 数据中心

C/S模式的很大弊端就是客户端更新特别麻烦，服务器能支撑的用户也不大。

Web兴起后，你们公司的应用也与时俱进，从C/S模式变成了B/S模式，用户主要使用浏览器来访问应用，业务逻辑在服务器端运行。

这时候，你还需要买服务器，然后放到数据中心去托管，毕竟那里的条件更好，更稳定。

网络不需要自己来搭建了， 掏钱买数据中心的网络带宽就好。还需要自己安装软件，比如Linux操作系统，Tomcat，Ngnix，MySQL等等。

随着功能的增加，你还需要新的服务器来处理缓存，搜索等功能。为了应对高并发，还需要分布式，负载均衡，数据复制。

你需要仔细地规划，看看这些缓存，搜索，数据库，负载均衡等都需要什么样的服务器，有些要求CPU很强，有些要求内存很大，有些要求硬盘很快。

总之，运维这样一套系统，非常麻烦。

3. 虚拟化

但是，如果你的网站没人访问了，这一套复杂的系统，这些昂贵的服务器就会变成摆设，你想卖都很难卖掉，这是巨大的浪费。

一个想法就会浮现出来：为什么要用物理服务器？ 谁要是能提供虚拟机给我就好了！ 用完了就可以“扔掉”！

于是那些有实力的大厂就这么做了，把这些物理服务器的计算能力，存储能力统一管理，统一调配，对外提供的就是虚拟机。

他们把这种方式叫做云计算，你使用了云计算以后，有很多好处：

物理服务器不用买了，申请虚拟机就可以了。什么样的CPU，多少内存，多大的硬盘，对应的价格也不同。

操作系统会按照你的要求自动给你安装好。网络自然不用操心，要多大带宽直接买就行。

对于PaaS来讲，连运行时环境都安装好了，直接使用就行。

这些虚拟机可以包月，包年计费。但是，如果没有人访问你的应用，没有流量，你也得掏钱。

4. 理想模式

想必你的脑海中已经浮现出了解决方案：

不要再考虑什么物理服务器/虚拟机了， 把代码上传到云端，直接运行。

按使用情况（如CPU时间、内存大小）来收费。

（IBM： 我的大机一直按使用情况收费，你们玩了几十年，终于回到我这里了 ^-^）

如果没有人访问你的应用，就不要部署它，这样只会占用一点点存储空间，不用使用CPU和内存；如果有人访问，把应用部署到某个服务器上，执行这次请求，返回给用户，然后卸载这个应用。

和之前的方式相比，最大的特色是即用即走，不会在服务器/虚拟机中常驻。

但是这么做可能吗？ 不行！应用的粒度太大，一个应用几十，上百模块，每个请求来了就部署整个应用，只执行那么一点儿代码， 然后就卸载掉。 如果每个请求这么来回地部署和卸载，你是疯了吗，兄弟？

那微服务呢？粒度还是太大 ！ 如果是微服务中的一个API，或者说就是一个“函数”呢？ 这个粒度应该差不多了。

这里说的函数到底是什么？ 需要看具体的业务来划分，比如搜索产品，图像转换，它需要足够小，足够单一，能快速启动，运行，卸载。

一个“函数”真的只做一件事情，并且不保持状态。 这样一来它可以轻松地被扩展到任意多的服务器/虚拟机/docker容器中去。请求多了就扩容，请求少了，就收缩，请求没了，就卸载，实在是太爽了。

这种方式现在称为Serverless，并不是说没有服务器，而是说服务器对用户来说是透明的。应用的装载、启动、卸载，路由是需要平台来搞定。

Serverless的开发模式和运行模式类似这样：

1. 程序员编写完成业务的函数代码

2. 上传到支持Serverless的平台，设定触发的规则

3. 请求到来，Serverless平台根据触发规则加载函数，创建函数实例，运行

4. 如果请求比较多，会进行实例的扩展，如果请求较少，就进行实例的收缩

5. 如果无人访问，卸载函数实例

02 了解Serverless架构

Serverless架构或者Serverless工程的核心思想是函数即服务。从技术角度来讲，互联网上最准确的 “Serverless计算” 的定义如下：

“Serverless计算又称为函数即服务（FAAS），它是一种云计算和代码执行模型，其中云提供商管理函数的容器——平台即服务（PaaS）——的启动和停止。”

定义中的“函数即服务”，就是说任何Serverless模型都有一个在云平台上运行的函数。这些函数只不过是代码块，它们的执行取决于与之相关联的触发器。

下图展示了AWS Lambda环境中的所有触发器。

只要有触发器触发了某个函数，云平台就会启动一个容器，用来执行该函数。一旦该函数执行成功并返回结果，或者运行超时，那么运行该函数的容器就将被云平台回收或者销毁。在高负载的情况下，或者当两个触发器之间几乎存在时间间隔时，这种回收机制使得容器能够被重复利用。

定义中的“函数的容器”，就是说函数在容器中启动和执行。

Docker公司将“容器”的概念发扬光大，它对“容器”的标准定义为：

“容器映像是一个轻量级、独立且可执行的软件包，其中包含了软件运行所需的一切：代码、运行时、系统工具、系统库、设置。”

容器的作用是将函数的代码、运行时环境等打包到单个部署包中，以实现无缝执行。部署包中包含了该函数的主代码文件，以及执行该函数所需的所有非标准库。部署包的创建过程与Python虚拟环境的创建过程非常相似。

因此，我们可以明确地指出，对于采用Serverless架构的应用程序，其服务器不会一直运行。其好处显而易见，那就是无须专门的运维团队成员来维护和管理服务器。

03 Serverless常见误解

由于Serverless架构以函数即服务的形式运行，而函数由一组可用的触发器来触发，所以Serverless架构经常被用作实时系统。

但是，单纯将Serverless架构看作实时系统是一种常见的误解，因为Serverless系统除了可用作实时系统之外，也适用于批处理架构。

并不是所有的研发团队都需要使用或者拥有实时系统，因此学会将Serverless系统用作批处理架构会给研发团队带来更多的可能性。

可以通过如下方式将Serverless系统用作批处理架构：

• 触发器的cron功能
• 队列

首先来了解一下触发器的cron功能。

我们可以在云平台的Serverless系统中设置*控器监**，将*控器监**设置为一个普通的cron任务，该*控器监**便会每隔几分钟或者几小时触发一次触发器。这有助于把Serverless配置为cron批处理任务。在AWS环境中，Lambda可以通过AWS CloudWatch作为cron触发，为此，可以手动输入时间间隔来设置cron任务的频率，也可以在cron格式中选择间隔。

还可以利用队列来构建Serverless批处理架构。让我们设置一个示例数据管道，以此来理解队列的概念。假设我们要构建一个系统来执行以下任务。

1. 用户或者服务将一些数据发送到数据库或者更简单的数据存储系统中，例如AWS的S3
2. 一旦数据存储系统中的文件数量超过100，就执行一项任务。比如，对文件进行一些分析，例如计算文件的总页数

该系统可以通过队列来实现。这个例子是一个相对简单的Serverless系统。它可以通过以下方式实现。

1. 用户或者服务将数据上传或者发送到我们选好的数据存储系统中。
2. 为这个任务配置一个队列。
3. 为S3存储桶或者数据存储系统配置一个事件，这样，只要有数据进来，就向上一步配置的队列中发送消息。
4. 设置监控系统以监控队列中的消息数量。建议你使用云提供商的监控系统，以便保持系统完全Serverless化。
5. 为监控系统设置告警，并配置告警阈值。例如，一旦队列中的消息数量达到或者超过100就触发告警。
6. 该告警可以扮演Lambda函数触发器的角色。Lambda函数首先接收队列消息，然后使用消息中的文件名来查询数据存储系统，以此对文件进行分析。
7. 文件由Lambda函数分析之后，将被发送到另外一个数据存储系统中存放。
8. 所有任务完成之后，运行Lambda函数的容器或者服务器将自动终止，因此整个传输流程完全Serverless化。

04 Serverless优缺点

我们需要了解Serverless系统的优缺点，以便软件开发人员和架构师决定何时在现有系统中利用Serverless范式。

Serverless系统的优点如下。

• 降低了运营成本：部署了Serverless系统，服务器就不再需要昼夜不停地运转，因此设备成本得以大幅缩减。当函数被触发时服务器才会启动，而当函数执行完毕时服务器会自动停止，因此用户只需为函数运行的时间段付费。
• 减少了维护工作：鉴于以上情况，我们不再需要对服务器进行持续不断的监控和维护。由于函数和触发器高度自动化，因此Serverless系统几乎不需要维护。
• 提升了开发效率：由于开发人员不需要操心服务器的维护工作以及宕机情况的发生，因而可以专注于提升软件质量的相关工作，例如扩展和设计功能。

Serverless系统的缺点：

• 函数运行有时限：无论是AWS Lambda还是GCP云，其函数运行时长的上限都是5分钟，这使得计算密集型的任务变得难以运行。为了解决这个问题，可以用nohup模式来执行配置工具的脚本。然而，配置脚本、设置容器以及其他工作也必须在5分钟内完成。一旦超过5分钟的时限，容器便会自动终止。
• 无法控制容器环境：开发人员无法控制用来执行函数的容器环境。操作系统、文件系统等均由云供应商一手掌控。比如，执行AWS Lambda函数的容器运行着亚马逊的Linux操作系统。
• 缺乏对容器的监控：云提供商通过其内部监控工具为用户提供了基本的监控功能，除此之外，没有为执行Serverless函数的容器提供详细监控服务的其他机制。当扩展Serverless系统以适应分布式系统时，监控工作将变得更为艰难。
• 无法控制安全性：由于缺乏对容器环境的监控，所以无法保证数据流的安全性。但是，容器可以在开发人员选择的VPC和子网中运行，这有助于解决该问题。

然而，Serverless系统可以扩展到执行大规模计算的分布式系统中，此时开发人员不必担心时限问题。

05 Serverless注意事项

为了直观地了解如何在单个整体式系统上选择Serverless系统来执行大规模计算，让我们看看在做这种架构决策时需要注意的重要事项。

将Serverless系统扩展到分布式系统时的注意事项如下。

• 要想将Serverless系统扩展到Serverless的分布式系统，需要知道nohup的运行方法。它是一个允许程序和进程在后台运行的POSIX命令。
• 正确记录nohup进程的日志，包括输出日志和错误日志。进程的所有信息都应记录在日志中。
• 需要一个配置工具，例如Ansible、Chef或者类似工具，用来创建一个master-worker架构，并在执行Serverless函数的容器中以nohup模式运行它。
• 对于所有由配置工具的master服务器执行的任务，需要进行正确的监控并记录其日志，因为一旦所有设置执行完毕，就无法获取其日志了。
• 使用云提供商的临时凭证工具来适当保证安全性。
• 应确保系统正确关闭。所有的worker及master任务在执行完成之后应当立即自行终止。这一点非常重要，它是保证系统Serverless化的关键。
• 通常，大多数环境中临时凭证的有效期为3600秒。因此，如果开发人员使用临时凭证执行任务的时间超过凭证的有效期，那么凭证就存在过期的风险。
• 调试分布式Serverless系统是一项非常困难的任务，原因如下。1. 监控和调试nohup进程非常困难。其调试方法有两种：一种是参考进程创建的日志文件，另一种是通过进程ID将nohup进程杀死，然后手动运行脚本进行调试。
• 2. 由于所有任务在配置工具中按顺序执行，因此任务实例存在被终止的风险，原因是开发人员在调试进程之前可能会忘记杀死nohup进程。
• 3. 因为这是一个分布式系统，所以毫无疑问，该架构在任何失败或者出错的情况都应当能够自我修复。一个示例场景是：一个worker任务在对一堆文件执行某种操作时发生了崩溃，导致所有文件都丢失了，而且没有办法恢复。
• 4. 另一个更严重的灾难场景是两个worker任务在操作文件时发生崩溃。在这种情况下，开发人员并不知道哪些文件已成功执行，哪些没有。
• 确保所有worker任务获得相同数量的负载是一种很好的做法，这可以实现分布式系统的负载均衡，同时使得时间和资源得到很好的优化

06 类似架构（微服务）的优缺点

与Serverless的概念类似，面向微服务的设计策略最近也非常流行。这种架构设计在Serverless的概念出现以前就已经存在很长时间了。就像我们试图通过互联网上的技术定义来理解Serverless架构一样，我们也应通过互联网上的技术定义来理解微服务。微服务的技术定义如下：

“微服务又称为微服务架构，它是一种架构风格，将应用程序构建为一组松耦合的服务，以实现业务功能。”

与Serverless架构一样，规划和设计微服务形式的架构同样有利有弊。我们要熟知微服务架构的优缺点，以便使用时能够扬长避短。在阐述微服务的缺点之前，先来看看它的优点。

微服务能够帮助软件团队保持敏捷和逐步改进。简单来说，由于各个服务之间彼此分离，因此升级和改进一项服务非常容易，并且不会导致其他服务崩溃。例如，在社交网络软件中，如果聊天和订阅功能都是微服务，那么当软件团队尝试升级或者修复聊天服务时，订阅服务完全不会受影响。然而，在大型整体式系统中，很难像微服务那样将功能独立开来。因此，在整体式架构中，即使是一个小组件的修复或者升级都会导致所有服务的停止，而修复所需的时间也往往超出预期。

整体式架构的代码量非常庞大，任何一个小故障都会影响整个系统的运转。微服务则对代码进行了精简和细分，从而极大地提升了开发人员的工作效率。开发人员可以在开销极小甚至为零并且不需要停机的情况下修复和改进服务。容器可以让我们更好地利用微服务，它提供了有效且完整的虚拟操作系统环境，能够隔离进程，并且提供底层硬件资源的专属访问权限。

当然，微服务也有缺点，其中最主要的一点是，它依赖分布式系统。由于各个服务之间是相互独立的，所以架构师需要弄清楚各个服务之间的交互方式，从而构建出功能完整的产品。因此，服务之间的交互方式，以及它们之间数据的传输策略，都是架构师需要认真考虑的问题。分布式系统的主要问题，比如共识、CAP定理、维持共识的稳定性以及连接，都是工程师在构建微服务时需要处理的问题。确保和维护安全性也是分布式系统和微服务中的主要问题。你需要为每个微服务制定单独的安全模式和层级，还需要为服务之间的数据交互制定安全策略。

本文中，我们了解了什么是Serverless。最重要的是，知道了如何判断Serverless能否为其团队或项目所用，以及如何从现有基础设施转换或者迁移到Serverless范式。

我们还研究了微服务范式及其如何帮助实现轻量级和高度敏捷的架构，并且详细介绍了团队何时应该考虑采用微服务，以及何时可以将其现有的整体式服务迁移到或者分解为微服务等。

想继续深入学习，可以阅读下面这本书，上面大部分内容来源于这本书。

《Serverless架构应用开发：Python实现》

作者：[印] Jalem Raj Rohit

译者：安翔

手把手教你用 Python 建立

无须专人托管的服务器

本书主要基于云架构的Python示例来讲解Serverless的概念。

本书采用目前流行的Python语言，通过云架构中的示例，手把手教你在AWS和微软Azure Functions中构建Serverless架构、部署Serverless API、处理日志和监控、将Lambda函数部署为基础设施即代码，等等。本书还详细介绍了VPC和SAM等技巧。

本书分为三个模块：第一个模块解释Serverless架构的基本原理以及AWS lambda函数的作用；第二个模块教你构建、发布并部署应用到生产环境；第三个模块将带领你完成高级主题，例如为应用构建Serverless API。你还将学习如何扩展Serverless应用并处理生产中的分布式Serverless系统。在本书的最后，你将能够使用Serverless框架构建可扩展的高效Python应用程序。

参考资料：

https://www.ituring.com.cn/book/tupubarticle/27778

https://www.infoq.cn/article/SZzkUKeqdxpP5FkNPZOQ

https://blog.csdn.net/cpongo3/article/details/89026731

https://mp.weixin.qq.com/s/k0RVMNhBa-VS6IHHuZ1CNQ

https://zhuanlan.zhihu.com/p/84054729