Serverless体系结构是一种应用程序设计，它包含第三方“后端即服务”（BaaS）服务，和/或包含在“功能即服务”（FaaS）平台上的托管临时容器中运行的自定义代码。通过使用这些思想，以及类似于单页应用程序的相关思想，这样的体系结构消除了对传统的总是在服务器上的组件的大量需求。无服务器体系结构可以从显著降低的操作成本、复杂性和工程提前期中获益，但代价是增加对供应商依赖性和相对不成熟的支持服务的依赖。

Serverless计算，或者更简单地说，无服务器计算，是软件体系结构领域的一个热门话题。“三大”云供应商亚马逊、谷歌和微软都在无服务器领域投入了大量资金，我们看到了大量的书籍、开源项目、会议和软件供应商致力于这一主题。但是什么是无服务器的，为什么它值得考虑呢？

首先，我们来看看什么是Serverless(无服务器)。我们稍后将讨论该方法的优点和缺点。

Serverless是什么？

像软件的许多趋势一样，没有一个清晰的观点来解释什么是无服务器。首先，它包括两个不同但重叠的领域：

Serverless最初用于描述显著或完全结合第三方、云托管应用程序和服务的应用程序，以管理服务器端逻辑和状态。这些应用程序通常是“富客户端”应用程序，比如单页web应用程序，或者使用云可访问数据库（如Parse、Firebase）、身份验证服务（如Auth0、AWS Cognito）等庞大生态系统的移动应用程序。这些类型的服务以前被描述为“（Mobile）Backend as a Service”，我在本文的其余部分使用“ BaaS ”作为缩写。

Serverless也可以指服务器端逻辑仍然由应用程序开发人员编写的应用程序，但是，与传统体系结构不同，它运行在无状态计算容器中，这些容器是事件触发的、短暂的（可能只持续一次调用），并且完全由第三方管理。一种方式是“作为服务的功能”或“ FaaS ”。AWS Lambda是目前最流行的一个Functions-as-a-Service平台的实现，但是还有很多其他的实现。

在本文中，我们将主要关注 FaaS 。不仅是Serverless无服务器领域的更新和推动了大量的宣传，而且它与我们通常对技术架构的思考方式有很大的不同。

BAA和FAA在其操作属性（例如，无资源管理）上是相关的，并且经常一起使用。大型云供应商都有“无服务器产品组合”，包括BaaS和FaaS产品例如，这里是Amazon的无服务器产品页面。Google的Firebase BaaS数据库通过Google云函数为 Firebase 提供了明确的FaaS支持。

小型公司在这两个领域也有类似的联系。Auth0从实现用户管理的许多方面的BaaS产品开始，随后创建了FaaS服务Webtask。该公司在Extend上更进一步地采用了这一理念，这使得其他SaaS和BaaS公司能够轻松地将FaaS功能添加到现有产品中，从而创建统一的无服务器产品。

举几个例子

用户界面驱动的应用程序

让我们考虑一个传统的三层面向客户机的系统，带有服务器端逻辑。一个很好的例子是一个典型的电子商务应用程序我敢说一个在线宠物商店？

传统上，架构看起来像下图。假设它是在服务器端用Java或Javascript实现的，客户端是HTML+Javascript组件：

使用这种体系结构，客户机可能相对不智能，服务器应用程序实现了系统身份验证、页面导航、搜索和事务中的许多逻辑。

对于无服务器体系结构，最终可能会更像这样：

这是一个大大简化的视图，但即使在这里，我们也看到了一些重要的变化：

1. 我们已经删除了原始应用程序中的身份验证逻辑，并将其替换为第三方BaaS服务（例如 Auth0 ）

2. 使用BaaS的另一个例子，我们允许客户机直接访问我们数据库的一个子集（用于产品列表），它本身完全由第三方（例如Google Firebase）托管。我们可能对以这种方式访问数据库的客户机具有与访问数据库的服务器资源不同的安全配置文件。

3. 前两点意味着非常重要的第三点：宠物商店服务器中的一些逻辑现在在客户机中—例如，跟踪用户会话，了解应用程序的UX结构，从数据库读取数据并将其转换为可用视图，等等。客户端正朝着成为单页应用程序的方向发展。

4. 我们可能希望在服务器中保留一些与用户体验相关的功能，例如，如果它是计算密集型的或需要访问大量数据。在我们的宠物商店中，一个例子是“搜索”。我们可以实现一个FaaS函数，通过API网关（稍后描述）响应HTTP请求，而不是像原始架构中那样始终运行服务器。客户机和服务器的“搜索”功能都从同一个数据库中读取产品数据。

5. 如果我们选择使用AWS Lambda作为FaaS平台，我们可以将搜索代码从原来的Pet Store服务器移植到新的Pet Store搜索函数，而无需完全重写，因为Lambda支持Java和Javascript，这是我们最初的实现语言。

最后，我们可以用另一个单独的FaaS函数替换“购买”功能，出于安全原因，我们选择将其保留在服务器端，而不是在客户端重新实现。它的前面也有一个API网关。在使用FaaS时，将不同的逻辑需求分解为单独部署的组件是一种非常常见的方法。

退一步讲，这个例子演示了关于无服务器架构的另一个非常重要的观点。在原始版本中，所有流、控制和安全都由中央服务器应用程序管理。在无服务器版本中，这些问题没有中央仲裁器。相反，我们更倾向于编排而不是编排，每个组件都扮演着更具体系结构意识的角色这一想法在微服务方法中也很常见。

这种方法有许多好处。正如Sam Newman在他的《构建微服务》一书中指出的那样，以这种方式构建的系统通常“更灵活，更易于更改”，无论是作为一个整体还是通过对组件的独立更新；有更好的关注点划分；还有一些引人入胜的成本效益，Gojko Adzic在这篇精彩的演讲中讨论了这一点。

当然，这样的设计是一种折衷：它需要更好的分布式监视（稍后将详细介绍），而且我们更依赖底层平台的安全功能。更重要的是，与我们最初使用的单片应用程序相比，有更多的移动部件可以让我们的大脑四处走动。灵活性和成本带来的好处是否值得多个后端组件增加的复杂性，这取决于上下文。

消息驱动的应用程序

另一个例子是后端数据处理服务。

假设您正在编写一个以用户为中心的应用程序，它需要快速响应UI请求，其次，它需要捕获正在发生的所有不同类型的用户活动，以便进行后续处理。想想一个在线广告系统：当用户点击一个广告时，你想很快地将他们重定向到该广告的目标。同时，你需要收集点击已经发生的事实，这样你就可以向广告客户收费。（这个例子并不是假设我在Intent Media的前团队正是有这个需要的，他们是以无服务器Serverless的方式实现的。）

传统上，架构可能如下所示。“广告服务器”同步响应用户（未显示），并向频道发布“点击消息”。然后，“点击处理器”应用程序异步处理该消息，该应用程序更新数据库，例如，减少广告客户的预算。

在无服务器Serverless的世界中，情况如下：

你能看出区别吗？与我们的第一个示例相比，架构上的变化要小得多这就是为什么异步消息处理是无服务器技术的一个非常流行的用例。我们已经用FaaS函数替换了一个长寿命的消息使用者应用程序。此函数在供应商提供的事件驱动上下文中运行。请注意，云平台供应商同时提供messagebroker和FaaS环境，这两个系统紧密相连。

FaaS环境还可以通过实例化功能代码的多个副本来并行处理多个消息。这取决于我们如何编写原始过程，这可能是我们需要考虑的一个新概念。

解包“功能即服务”

我们已经提到了很多FaaS，但现在是时候深入研究它的真正含义了。要做到这一点，让我们看看亚马逊的FaaS产品Lambda的开场白。我给它添加了一些标记，我将对此进行扩展。

AWS Lambda允许您运行代码，而无需配置或管理服务器。(1) 使用Lambda，您可以为几乎任何类型的应用程序或后端服务运行代码（2）所有这些都不需要任何管理。只需上传你的代码，Lambda就可以处理运行（3）和扩展（4）你的代码所需的一切。你可以设置你的代码从其他AWS服务自动触发（5）或直接从任何网络或移动应用程序调用它（6）。

1. 从根本上说，FaaS是关于运行后端代码而不管理自己的服务器系统或自己的长期服务器应用程序。与容器和PaaS（平台即服务）等其他现代体系结构趋势相比，第二条长寿命服务器应用程序是一个关键区别。

如果我们回到前面的点击处理示例，FaaS会将点击处理服务器（可能是一台物理机器，但肯定是一个特定的应用程序）替换为不需要配置的服务器，也不需要一直运行的应用程序。

2. FaaS产品不需要编码到特定的框架或库。当涉及到语言和环境时，FaaS函数是常规应用程序。例如，AWS Lambda函数可以用Javascript、Python、Go、任何JVM语言（Java、Clojure、Scala等）或任何.NET语言实现。但是，Lambda函数还可以执行与其部署工件捆绑在一起的另一个进程，因此实际上可以使用任何可以向下编译到Unix进程的语言。

但是FaaS函数有很大的体系结构限制，特别是在状态和执行持续时间方面。我们很快就会知道的。

让我们再次考虑一下我们的点击处理示例。当移动到FaaS时，唯一需要更改的代码是“ main method ”（启动）代码，因为它被删除了，并且很可能是作为顶级消息处理程序的特定代码（“ message listener interface ”实现），但这可能只是方法签名的更改。其余的代码（例如，写入数据库的代码）在FaaS世界中没有什么不同。

3. 部署与传统系统非常不同，因为我们没有服务器应用程序可以自己运行。在FaaS环境中，我们将函数的代码上传到FaaS提供程序，提供程序执行资源调配、vm实例化、流程管理等所有必要的操作。

4. 水平缩放是完全自动的、弹性的，并且由提供者管理。如果您的系统需要并行处理100个请求，那么提供者将在不需要任何额外配置的情况下处理这些请求。执行您的函数的“计算容器”是短暂的，FaaS提供程序创建和销毁它们纯粹是由运行时需要驱动的。最重要的是，使用FaaS，供应商可以处理所有底层资源的供应和分配，用户根本不需要集群或VM管理。

让我们回到我们的点击处理器。比如说，我们今天过得很好，客户点击的广告是平时的十倍。对于传统体系结构，我们的点击处理应用程序能够处理这个问题吗？例如，我们开发的应用程序是否能够一次处理多条消息？如果我们这样做了，一个正在运行的应用程序实例是否足以处理负载？如果我们能够运行多个进程，自动缩放是自动的还是需要手动重新配置？使用FaaS方法，所有这些问题都已经得到了回答，您需要提前编写函数以假设水平缩放的并行性，但从那时起FaaS提供程序将自动处理所有缩放需求。

5. FaaS中的函数通常由提供者定义的事件类型触发。在Amazon AWS中，这些刺激包括S3（文件/对象）更新、时间（计划任务）和添加到消息总线的消息（例如， Kinesis ）。

6. 大多数提供者还允许将函数作为对入站HTTP请求的响应来触发；在AWS中，通常通过使用API网关来实现这一点。在我们的宠物商店示例中，我们使用了一个API网关来实现“搜索”和“购买”功能。也可以通过平台提供的API直接调用函数，可以从外部调用，也可以从同一个云环境中调用，但这是一种比较少见的用法。

状态

当涉及到本地（机器/实例绑定）状态时，FaaS函数有很大的限制，即存储在内存变量中的数据，或写入本地磁盘的数据。您确实有这样的可用存储，但是您不能保证这样的状态在多个调用之间是持久的，而且，更重要的是，您不应该假设一个函数的一个调用的状态将可用于同一个函数的另一个调用。因此，FaaS函数通常被描述为无状态的，但更准确地说，需要持久化的FaaS函数的任何状态都需要在FaaS函数实例之外外部化。

对于自然无状态的FaaS函数，也就是说，那些提供从输入到输出的纯功能转换的FaaS函数，这是不需要考虑的。但对于其他人来说，这可能会对应用程序体系结构产生很大的影响，尽管这并不是一个独特的概念，“十二要素应用程序”的概念有着完全相同的限制。这种面向状态的函数通常会利用数据库、跨应用程序缓存（如Redis）或网络文件/对象存储（如S3）来跨请求存储状态，或提供处理请求所需的进一步输入。

执行持续时间

FaaS函数通常被限制在每次调用允许运行的时间。目前，AWS Lambda函数响应事件的“超时”最多为5分钟，然后终止。微软Azure和谷歌云的功能也有类似的限制。

这意味着某些类的长寿命任务不适合FaaS功能，如果不重新架构，您可能需要创建几个不同的协调FaaS功能，而在传统环境中，您可能有一个长时间任务同时执行协调和执行。

启动延迟和“冷启动”

FaaS平台在每个事件之前初始化函数实例需要一些时间。这个启动延迟可能会有很大的变化，甚至对于一个特定的功能，这取决于大量的因素，并且可能在几毫秒到几秒钟的范围内。听起来很糟糕，但是让我们更具体一点，以AWS Lambda为例。

Lambda函数的初始化要么是“热启动”（从以前的事件中重用Lambda函数的实例及其主机容器），要么是“冷启动”（创建新的容器实例、启动函数主机进程等）。在考虑启动延迟时，不出所料，最令人担忧的是这些冷启动。

冷启动延迟取决于许多变量：您使用的语言、使用的库数量、拥有的代码数量、Lambda函数环境本身的配置、是否需要连接到VPC资源等。这些方面很多都由开发人员控制，因此，作为冷启动的一部分，通常可以减少启动延迟。

与冷启动持续时间相同的变量是冷启动频率。例如，如果一个函数每秒处理10个事件，而每个事件的处理时间为50毫秒，那么您很可能只会看到每100000–200000个左右事件的Lambda冷启动。另一方面，如果您每小时处理一次事件，您可能会看到每个事件都会冷启动，因为Amazon会在几分钟后停用不活动的Lambda实例。了解这一点将有助于您了解冷启动是否会对聚合产生影响，以及您是否希望对函数实例执行“保持有效”以避免它们被丢弃。

冷启动是个问题吗？它取决于应用程序的样式和流量形状。我以前在Intent Media的团队有一个用Java实现的异步消息处理Lambda应用程序（通常是启动时间最慢的语言），它每天处理数以亿计的消息，他们不关心这个组件的启动延迟。这就是说，如果您正在编写一个低延迟的交易应用程序，那么此时您可能不想使用云托管的FaaS系统，无论您使用什么语言来实现。

不管你是否认为你的应用程序可能有这样的问题，你都应该用生产负载测试性能。如果您的用例现在不起作用，您可能需要在几个月后再试一次，因为这是FaaS供应商持续改进的一个主要方面。

API网关

我们在前面讨论过的Serverless的一个方面是“API网关”。API网关是HTTP服务器，其中路由和端点在配置中定义，每个路由都与处理该路由的资源相关联。在无服务器架构中，这样的处理程序通常是FaaS函数。

当API网关接收到请求时，它会找到与请求匹配的路由配置，并且在FaaS支持的路由的情况下，它会用原始请求的表示调用相关的FaaS函数。通常，API网关将允许从HTTP请求参数映射到FaaS函数的更简洁的输入，或者允许传递整个HTTP请求，通常作为JSON对象。FaaS函数将执行其逻辑并向API网关返回一个结果，API网关又将此结果转换为HTTP响应，并将其传递回原始调用方。

amazonweb服务有自己的API网关（有点令人困惑地称为“API网关”），其他供应商也提供类似的功能。Amazon的API网关是一个BaaS（是的，BaaS！）服务本身就是一个外部服务，您可以配置它，但不需要自己运行或配置。

除了纯粹的路由请求，API网关还可以执行身份验证、输入验证、响应代码映射等。（当你考虑这是否真的是一个好主意时，如果你的蜘蛛感觉到刺痛，那么保持这个想法！我们稍后会进一步考虑。）

使用FaaS函数的API网关的一个用例是以无服务器的方式创建HTTP前端的微服务，其中包含FaaS函数带来的所有扩展、管理和其他好处。

当我第一次写这篇文章时，Amazon的API网关的工具，至少是非常不成熟的。自那时以来，这些工具有了很大改进。像aws api gateway这样的组件并不是很“主流”，但希望它们比以前少一点痛苦，并且只会继续改进。

工具集

上面关于工具成熟度的评论一般也适用于无服务器。2016年的情况相当艰难；到2018年，我们已经看到了明显的改善，我们预计工具会变得更好。

FaaS世界中几个优秀的“开发者用户体验”的显著例子值得一提。首先是auth0webtask，它将开发人员UX作为其工具的重要优先权。其次是微软，他们的Azure功能产品。微软一直将反馈循环紧密的visualstudio放在开发人员产品的前列，Azure功能也不例外。它提供的在本地调试函数的能力（给定来自云触发事件的输入）非常特殊。

一个仍然需要显著改进的领域是监测。我稍后再讨论。

开源

到目前为止，我主要讨论了专有供应商产品和工具。大多数无服务器应用程序都使用这种服务，但世界上也有开源项目。

在Serverless中，开源最常见的用途是FaaS工具和框架，尤其是流行的Serverless框架，其目的是使使用awsapi网关和Lambda比使用AWS提供的工具更容易。它还提供了大量的跨供应商工具抽象，一些用户认为这很有价值。类似工具的例子包括Claudia和Zappa。另一个例子是Apex，它特别有趣，因为它允许您用Amazon直接支持的语言以外的语言开发Lambda函数。

不过，大厂商本身并没有在开源工具派对上落在后面。AWS自己的部署工具SAM无服务器应用程序模型也是开源的。

专有FaaS的主要好处之一是不必关心底层的计算基础设施（机器、vm，甚至容器）。但是如果你想关心这些事情呢？也许你有一些云供应商无法满足的安全需求，或者你已经买了一些服务器，不想扔掉。开源能在这些场景中提供帮助，让您运行自己的“服务器式”FaaS平台吗？

是的，这方面的活动也很多。开源FaaS的最初领导者之一是IBM（使用OpenWhisk，现在是一个Apache项目），至少让我吃惊！-微软（Microsoft）开放了其Azure平台的大部分功能。许多其他自托管FaaS实现都使用底层容器平台，通常是 Kubernetes ，这有很多原因。

什么不是无服务器的？

到目前为止，在本文中，我将Serverless描述为两种思想的结合：后端即服务和函数即服务。我还深入研究了后者的能力。要更精确地了解我所看到的无服务器服务的关键属性（以及为什么我认为像S3这样的旧服务是无服务器的）。

在我们开始研究非常重要的优点和缺点之前，我想再花一点时间讨论一下定义。让我们定义一下无服务器不是什么。

与PaaS的比较

考虑到无服务器FaaS功能与12因素应用程序非常相似，它们是否只是Heroku那样的“平台即服务”（PaaS）的另一种形式？

如果您的PaaS能够高效地在20ms内启动运行半秒的实例，那么就称之为无服务器。

换句话说，大多数PaaS应用程序并不是为了响应事件而使整个应用程序上下移动，而FaaS平台正是这样做的。

如果我是一个优秀的12要素应用程序开发人员，这并不一定会影响我如何编程和构建我的应用程序，但它确实会对我如何操作它们产生很大的影响。既然我们都是优秀的DevOps工程师，我们在考虑开发的同时也在考虑运营，对吧？

FaaS和PaaS在操作上的关键区别是可伸缩性。一般来说，对于PaaS，您仍然需要考虑如何进行扩展，例如，对于Heroku，您希望运行多少个动态节点？对于FaaS应用程序，这是完全透明的。即使您将PaaS应用程序设置为自动伸缩，您也不会将其设置为单个请求的级别（除非您有一个非常特定的流量配置文件），因此FaaS应用程序在成本方面效率更高。

既然有这个好处，为什么还要使用PaaS呢？有几个原因，但工具可能是最大的。另外，有些人使用诸如cloudfoundry之类的PaaS平台来提供跨混合公共云和私有云的通用开发体验；在撰写本文时，还没有FaaS这样成熟的平台。

与容器比较

使用无服务器FaaS的原因之一是避免在操作系统级别管理应用程序进程。PaaS服务，比如Heroku，也提供了这种功能，我在上面已经描述了PaaS与无服务器FaaS的区别。另一种流行的流程抽象是容器，Docker是这种技术最明显的例子。诸如Mesos和Kubernetes之类的容器托管系统从操作系统级部署中抽象出单个应用程序，现在越来越流行。沿着这条路走得更远，我们可以看到云托管容器平台，如amazonecs和EKS，以及googlecontainer Engine，它与无服务器FaaS一样，让团队完全不必管理自己的服务器主机。考虑到集装箱的发展势头，还值得考虑无服务器FaaS吗？

基本上，我为PaaS提出的论点仍然适用于容器—对于无服务器的FaaS，扩展是自动管理、透明和细粒度的，这与我前面提到的自动资源调配和分配有关。容器平台传统上仍然需要您管理集群的大小和形状。

我还认为容器技术还不成熟和稳定，尽管它越来越接近成熟和稳定。当然，这并不是说无服务器FaaS已经成熟，但选择您喜欢的粗糙边缘仍然是当前的工作重点。

还有一点很重要，即自伸缩容器集群现在可以在容器平台中使用。Kubernetes内置了“ Horizontal Pod Autoscaling ”，像AWS Fargate这样的服务也承诺了“无服务器容器”

当我们看到无服务器faa和托管容器之间在管理和扩展方面的差距缩小时，它们之间的选择可能会归结为应用程序的样式和类型。例如，对于每个应用程序组件只有很少的事件类型的事件驱动样式，FaaS被视为更好的选择，而对于具有许多入口点的同步请求驱动组件，容器被视为更好的选择。我预计在相当短的时间内，许多应用程序和团队将同时使用这两种体系结构方法，看到这种使用模式的出现将是一件非常有趣的事情。

NoOps

Serverless并不意味着“没有操作”--尽管它可能意味着“没有系统管理员”，这取决于你在Serverless兔子洞里走了多远。

“Ops”不仅仅意味着服务器管理。它还意味着至少监视、部署、安全、联网、支持，以及一些生产调试和系统扩展。这些问题在没有服务器的应用程序中仍然存在，你仍然需要一个策略来解决它们。在某种程度上，在一个没有服务器的世界里，Ops是很困难的，因为很多都是全新的。

系统管理员仍然在发生你只是外包它与无服务器。这不一定是一件坏事（或好事），我们外包了很多，它的好坏取决于你正试图做什么。不管是哪种方式，在某个时候抽象可能会泄漏，您需要知道某个地方的人类系统管理员正在支持您的应用程序。

Stored Procedures as a Service

我看到的另一个主题是无服务器FaaS是“存储过程即服务”。我认为这是因为FaaS函数的许多示例（包括我在本文中使用的一些）都是与数据库紧密集成的小块代码。如果这就是我们可以使用FaaS的全部，我认为这个名字会很有用，但是因为它实际上只是FaaS功能的一个子集，我不认为用这些术语来考虑FaaS是有用的。

也就是说，值得考虑的是FaaS是否与存储过程有一些相同的问题，包括Camille在上面提到的tweet中提到的技术债务问题。从使用存储过程中得到的许多经验教训值得在FaaS的上下文中回顾，看看它们是否适用。请考虑存储过程：

1. 通常需要特定于供应商的语言，或者至少需要特定于供应商的语言框架/扩展

2. 很难测试，因为它们需要在数据库上下文中执行

3. 很难进行版本控制或将其视为一级应用程序

虽然并非所有这些都必须适用于存储过程的所有实现，但它们肯定是可能遇到的问题。让我们看看它们是否适用于联邦航空局：

（1） 对于我目前看到的FaaS实现来说，这绝对不是一个问题，所以我们可以马上把它从列表中删除。

对于（2）来说，既然我们处理的是“仅仅是代码”，那么单元测试肯定和其他代码一样简单。集成测试是一个不同的（合法的）问题，我们将在后面讨论。

对于（3），同样由于FaaS函数是“只编码”的，所以版本控制是可以的。直到最近，应用程序打包还是一个值得关注的问题，但是我们已经开始看到这里的成熟，有了Amazon的无服务器应用程序模型（SAM）和我前面提到的无服务器框架之类的工具。2018年初，亚马逊甚至推出了“无服务器应用程序存储库”（SAR），为企业提供了一种基于AWS无服务器服务的应用程序和应用程序组件分发方式。

好处

到目前为止，我一直试图坚持自定义和解释无服务器架构的含义。现在我将讨论这种设计和部署应用程序的方法的一些优点和缺点。您绝对不应该在没有充分考虑和权衡利弊的情况下决定使用Serverless。

让我们从彩虹和独角兽的土地开始，看看无服务器的好处。

降低运营成本

Serverless最简单的就是一种外包解决方案。它允许你付钱给某人来管理服务器、数据库甚至应用程序逻辑，否则你可能会自己管理。由于您使用的是其他许多人也将使用的预定义服务，因此我们看到了规模经济效应：您为托管数据库支付的费用更少，因为一个供应商正在运行数千个非常相似的数据库。

在您看来，降低的成本是两个方面的总和。第一种是纯粹通过与他人共享基础设施（如硬件、网络）获得的基础设施成本收益。第二个是劳动力成本收益：与自己开发和托管的同等系统相比，您可以在外包的无服务器系统上花费更少的时间。

然而，这种好处与基础设施即服务（IaaS）或平台即服务（PaaS）的好处并没有太大区别。但我们可以通过两种关键方式来扩展这一优势，一种是针对无服务器的BAA和FAA。

BaaS：降低开发成本

IaaS和PaaS的前提是服务器和操作系统管理可以商品化。另一方面，无服务器后端即服务是整个应用程序组件商品化的结果。

身份验证就是一个很好的例子。许多应用程序编写自己的身份验证功能代码，其中通常包括注册、登录、密码管理以及与其他身份验证提供者的集成等功能。总的来说，这种逻辑在大多数应用程序中都非常相似，而且像Auth0这样的服务已经被创建，允许我们将现成的身份验证功能集成到我们的应用程序中，而无需我们自己开发。

在同一个线程上是BaaS数据库，比如Firebase的数据库服务。一些移动应用程序团队发现，让客户端直接与服务器端数据库通信是有意义的。BaaS数据库消除了大量的数据库管理开销，并且通常以无服务器应用程序所期望的模式为不同类型的用户提供适当授权的机制。

FaaS：扩展成本

无服务器FaaS的一个好处是，正如我在本文前面所说的——“水平扩展是完全自动的、有弹性的，并且由提供商管理的。”这有几个好处，但在基本的基础设施方面，最大的好处是您只需支付所需的计算费用，在AWS Lambda的情况下，下降到100ms边界。取决于你的交通规模和形状，这可能是一个巨大的经济胜利给你。

示例：偶尔请求

假设您运行的服务器应用程序每分钟只处理一个请求，处理每个请求需要50毫秒，一小时的平均CPU使用率为0.1%。如果将此应用程序部署到自己的专用主机上，则效率非常低。一千个其他类似的应用程序都可以共享一台机器。

无服务器FaaS抓住了这一低效，以更低的成本为您带来好处。使用上面的示例应用程序，您每分钟只需支付100毫秒的计算时间，这是总时间的0.15%。

这有以下连锁反应的好处：

• 对于负载需求非常小的准微服务，它支持按逻辑/域分解组件，即使这种细粒度的操作成本在其他方面可能会很高。
• 这样的成本效益是一个很大的民主化。如果公司或团队想要尝试一些新的东西，那么当他们使用FaaS来满足他们的计算需求时，他们的运营成本就非常低。事实上，如果您的总工作量相对较小（但并非完全不重要），那么由于FaaS供应商提供的“免费层”，您可能根本不需要为任何计算付费。

示例：不一致的流量

让我们看另一个例子。假设你的流量非常尖峰也许你的基准流量是每秒20个请求，但是每五分钟你就会收到每秒200个请求（通常的10倍），持续10秒。为了这个例子，我们还假设您的基准性能超过了首选的主机服务器类型，并且您不希望在流量峰值阶段减少响应时间。你怎么解决这个问题？

在传统环境中，您可能需要将硬件总数增加10倍，而不是处理峰值，即使峰值的总持续时间不到总机器正常运行时间的4%。在这里，自动伸缩可能不是一个好的选择，因为在新实例启动之前，服务器的新实例需要多长时间才能出现峰值阶段就结束了。

不过，对于无服务器的FaaS，这不是问题。实际上，如果你的流量分布是一致的，你所做的没有什么不同，你只需要为尖峰阶段的额外计算能力付费。

显然，我在这里特意挑选了一些无服务器FaaS可以节省大量成本的例子，但重点是要表明，从扩展的角度来看，除非您有一个非常稳定的流量形状，始终使用服务器主机的全部容量，否则您可以使用FaaS节省资金。

关于上面的一个警告：如果你的流量是一致的，并且能够持续地很好地利用正在运行的服务器，那么你可能看不到这种成本优势，而实际上使用FaaS可能会花费更多。您应该做一些计算，将当前提供商的成本与运行全职服务器的成本进行比较，看看成本是否可以接受。

关于FaaS成本效益的更多细节，我推荐gojkoadzic和robertchatley撰写的论文“无服务器计算：经济和架构影响”。

优化是节约成本的根本

关于FaaS成本，还有一个更有趣的方面值得一提：您对代码进行的任何性能优化不仅会提高应用程序的速度，而且会直接和直接地降低运营成本，具体取决于供应商收费方案的粒度。例如，假设一个应用程序最初需要一秒钟来处理一个事件。如果通过代码优化，这将减少到200毫秒，它将（在AWS Lambda上）立即看到80%的计算成本节省，而无需进行任何基础设施更改。

更易于操作管理

在无服务器的BaaS方面，很明显为什么操作管理比其他架构更简单：支持更少的组件就意味着更少的工作。

在FaaS方面有很多方面，我将深入研究其中的几个方面。

将FaaS的好处扩展到基础设施成本之外

虽然从上一节开始，缩放在我们的脑海中是新鲜的，但值得注意的是，FaaS的缩放功能不仅降低了计算成本，还减少了操作管理，因为缩放是自动的。

在最好的情况下，如果您的扩展过程是手动的，比如说，一个人需要显式地向FaaS服务器阵列添加和删除实例，您可以很高兴地忘记这一点，让FaaS供应商为您扩展应用程序。

即使您已经到了在非FaaS架构中使用自动伸缩的地步，这仍然需要设置和维护。FaaS不再需要这项工作。

类似地，由于扩展是由提供者在每个请求/事件上执行的，因此 您不再需要考虑在内存耗尽或看到太多性能影响（至少不是在FaaS托管组件中）之前可以处理多少并发请求的问题 。下游数据库和非FaaS组件将不得不重新考虑，因为它们的负载可能显著增加。

降低了打包和部署的复杂性

打包和部署FaaS函数比部署整个服务器简单。你要做的就是把你所有的代码打包成一个zip文件，然后上传。没有Puppet/Chef，没有start/stop shell脚本，没有关于是否在机器上部署一个或多个容器的决定。如果您刚刚开始，您甚至不需要打包任何可以在供应商控制台中编写代码的东西（显然，这不建议用于生产代码！）。

这个过程并不需要很长时间来描述，但对于一些团队来说，这个好处可能是绝对巨大的：一个完全无服务器的解决方案需要零系统管理。

PaaS解决方案具有类似的部署优势，但正如我们前面所看到的，将PaaS与FaaS进行比较时，FaaS所特有的可伸缩优势。

上线时间和持续试验

更简单的操作管理是我们工程师所理解的一个好处，但这对我们的业务意味着什么？

显而易见的原因是成本：花费在操作上的时间越少，操作所需的人员就越少，正如我已经描述的那样。但在我看来，一个更重要的原因是上市时间。随着我们的团队和产品越来越倾向于精益和敏捷流程，我们希望不断尝试新事物并快速更新现有系统。虽然在连续交付的环境中进行简单的重新部署可以快速迭代稳定的项目，但是对初始部署能力有一个好的新想法可以让我们以低摩擦和最低成本尝试新的实验。

FaaS的初始部署故事的新想法通常是优秀的，特别是对于由供应商生态系统中成熟定义的事件触发的简单功能。例如，假设您的组织已经在使用AWS Kinesis，一个类似Kafka的消息传递系统，通过您的基础设施广播各种类型的实时事件。有了AWS Lambda，你可以在几分钟内开发和部署一个新的生产事件监听器，你可以在一天内尝试几个不同的实验！

虽然成本效益是无服务器最容易表达的改进，但正是这种提前期的缩短让我最兴奋。它可以使我们的产品开发思维持续不断的实验，这是一个真正的革命，我们如何在公司交付软件。

“绿色”计算？

在过去的几十年里，世界上数据中心的数量和规模都有了巨大的增长。除了建造这些中心所需的物理资源外，相关的能源需求也是如此之大，以至于苹果、谷歌等公司都在谈论在可再生能源附近建立一些数据中心，以减少这些网站对化石燃料燃烧的影响，而这些影响本来是必要的。

闲置但通电的服务器消耗了大量的能源，这也是我们需要如此多、更大的数据中心的主要原因：

商业和企业数据中心的典型服务器在一年中平均提供其最大计算输出的5%到15%。

--福布斯

这是非常低效的，并造成了巨大的环境影响。

一方面，云基础设施可能已经有助于减少这种影响，因为企业只有在绝对需要的时候才可以按需“购买”更多服务器，而不是提前很长时间提供所有可能需要的服务器。不过，也有人可能会说，如果很多服务器都没有足够的容量管理，那么配置服务器的方便性可能会使情况变得更糟。

无论我们使用的是自托管服务器、IaaS还是PaaS基础设施解决方案，我们仍然需要手动决定应用程序的容量，这通常会持续数月或数年。通常情况下，我们对容量管理持谨慎态度，这是正确的，因此我们过度提供了资源，导致了刚才描述的效率低下。使用无服务器的方法， 我们不再自行决定容量 ，而是让无服务器供应商提供足够的计算容量，以满足我们的实时需求。然后，供应商可以在整个客户范围内制定自己的容量决策。

与传统的容量管理方法相比，这种差异将导致跨数据中心更有效地利用资源，从而减少对环境的影响。