无服务器架构(MartinFowler,中文译文)_无服务器

需积分: 10 259 浏览量更新于2023-05-27 评论收藏 1.82MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

简单是美美
0人评论83人阅读2018101015:48:02
翻译
ServerlessArchitectures(译文)(1)—(Martin
Fowler)
原文地址：https://martinfowler.com/articles/serverless.html
作者：MartinFowler,MikeRoberts
1.摘要
  无服务器架构是一种应用程序设计方法，它合并了第三方“BackendasaService”（BaaS）提供的服
务，和/或运行在FaaS（FunctionsasaService）平台中的用户代码。使用这样的思路并结合一些类似
spa（单页应用）的应用，设计出的架构消除了对传统常驻服务器组件的大部分需求。无服务器架构将受益于
显著降低的操作成本、复杂性和工程领先时间，但也会因依赖于服务提供商和相对不成熟的支撑技术而增加
成本。
2.引言
  “Serverlesscomputing”，或简称为“Serverless”，是软件架构世界中的一个热点主题。三大云厂商
Amazon,Google,andMicrosoft都对无服务器架构进行了重点布局。我们已经看到许多许多书籍、开源项
目、会议和软件厂商在致力于这个领域。但是什么是无服务器架构，它是否值得研究？通过这篇文章中我希
望能够抛砖引玉。
3.什么是无服务器架构
  对于无服务器架构没有一个清晰的视图。对于初学者，它包含两个不同但重叠的区域：
1.Serverless最初用于描述那些完全包含第三方的、云托管的、管理服务器端逻辑和状态的应用和服务的应
用程序。这些都是典型的“富客户端”应用程序（考虑单页的web应用程序，或者移动应用程序），它们使用
可访问云数据库的庞大生态系统（如Parse、Firebase）、身份验证服务（例如Auth0、AWSCognito）等
等。这些类型的服务以前被描述为““BackendasaService”，在本文中，我使用“BaaS”作为简写。
2.无服务器架构也意味着应用程序开发人员仍然需要编写服务器端逻辑的应用程序，但是，与传统的体系结
构不同，它是在无状态计算容器中运行的。这些容器是事件触发的、临时的（可能只持续一次调用就
挂），并全管理由第三方完。有人也把其称之为“函数即服务”或“FaaS”。AWSLambda是目前最流行的
FaaS平台之一，当然也有一些其它的实现平台。
  在本文中，我们将主要关注FaaS。它不仅是一个更新和更着名气的领域，而且它与我们常用的技术架
构思想有很大的不同。
  BaaS和FaaS在它们的操作属性上是相关的（如没有资源管理），并且经常一起使用。大型云供应商
都有“无服务器架构的产品组合”，包括BaaS和FaaS产品（例如，here’sAmazon’sServerless是亚马逊的
无服务器产品页面。Google的FirebaseBaaS数据库通过使用GoogleCloudFunctionsforFirebase提供显
式的FaaS支持）。
  更多的公司也开始涉足于这两个领域。Auth0开始使用实现了许多用户管理方面功能的BaaS产品，并
随后创建了配套的FaaS服务Webtask。现在该公司已经提供了Extend，这使得其他SaaS和BaaS公司能够
轻松地将FaaS功能添加到现有产品中，以创建一个统一的无服务器架构产品。
3.1.两个示例
有1位粉丝关注了您，
首页 文章 关注 订阅专栏 专家
消息手机阅读
搜索
写文章

3.1.1.UI驱动的应用

让我们考虑一个传统的三层面向客户的系统，它具有服务器端逻辑。一个典型的电子商务应用就是很

好的例子就是...我可以举在线宠物商店的例子吗？

传统架构将如下图所示。如它在服务器端用Java或Javascript实现的，在客户端使用HTML+Javascript

实现：



使用这种体系结构，客户端可能相对薄弱，系统中的许多逻辑功能如身份验证、页面导航、搜索、事

务，都要由服务器应用程序实现。

如果使用无服务器架构，看起来系统是这样的：



尽管上图是一个简化后的视图，但我们仍从其中看到许多变化：

1.我们看到原来应用中的鉴权逻辑已经被第三方的Baas服务所替代（如Auth0）。

2.使用另一个Baas服务,我们可以看到客户端可以直接访问我们一个数据库子集（完全由第三方提供，例

如GoogleFirebase）。相比于之前在服务端访问数据库资源，可以在客户端通过实施不同的安全策略

来访问数据库。

3.前面的两点引导出了重要的第三点：在这个宠物店服务器端的一些应用逻辑已经转移到了客户端，如维

护一个用户会话，从数据库中读取数据并将其转换为可用的视图。客户端变成了一个SPA（单页面应

用）。

4.我们也希望在服务端保留一些与用户体验相关的功能，例如访问大量的数据并做密集计算。在我们的宠

物店商店中，这样的一个功能可能是“查询”。不像原来架构中需要一直在运行的服务器，可以实现一个

响应经过API网关的HTTP请求的FaaS函数达到这一目的。客户端和服务端的“查询”功能都是从同一个产

品数据库中读取数据。如果选择AWSLambda作为FaaS平台，可以将原来的查询代码原封不动地移植

过来，因为Lambda支持java和javascript语言。

5.最后，可以用另一个单独的FaaS函数来替代我们的“购买”功能，出于安全考虑，选择将它放在服务器

端，而不是在客户端重新实现它。它也依赖于一个API网关。在使用FaaS时，将不同的逻辑需求分解为

单独部署的组件是一种非常常见的方法。

退一步说，这个示例展示了另一个对无服务器架构而言非常重要的观点：在传统架构中，所有流、

控制和安全性都由中央服务器应用程序管理，而在无服务器架构中，没有处理这些的中央控制器。相

反，我们倾向于通过对组件的编排完成目标（choreographyoverorchestration），将每个组件都设计

为更易被架构感知，这种设计思路在微服务方法中也很常见。

这种设计方法有很多好处。正如SamNewman在他的“BuildingMicroservices"这本书中指出的那

样：以这种方式构建的系统通常“更灵活，更易于改变”，既可以对于整体，也可以通过对组件进行系统

的更新;具有更好的划分关注点;还有一些令人着迷的成本效益，GojkoAdzic在这次精彩的演讲中讨论了

这个问题。

当然，这样的设计也需要权衡：它需要更强大的分布式监控，并且依赖于底层平台安全能力。更重

要的是，相比于单块系统，在我们的头脑中环绕着更多的灵活组件，而且增加多个后端组件的带来的复

杂性会让我们考虑其所带来的灵活性和降低成本是否值得。如何权衡需要依赖于具体应用上下文。

3.1.2.消息驱动的应用

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

假设您正在编写一个以用户为中心的应用程序，它需要快速响应UI请求，其次，它需要捕获正在发

生的所有不同类型的用户活动，以便进行后续处理。考虑这样一个在线广告系统：当用户点击一个广告

时，需要快速地将他们重定向到广告目标。与此同时，你需要收集对这个广告的点击事件以便于向广告

客户收费（这个例子是真实的，我以前在IntentMedia里的团队有这样的需求，他们以一种无服务器方

式实现了这个需求）。

使用传统方法，体系结构可能如下图所示。“AdServer”同步响应用户（未显示在图中），并

将“clickmessage”事件发送到一个消息通道。然后，这个消息由一个更新数据库的“clickprocessor”应用

程序异步处理，例如，用来根据统计信息减少广告客户的预算。



如果使用无服务器架构，看起来是这样的：



你能看出其中的区别吗？与我们的第一个示例相比，这里的体系结构的变化要小得多——这就是为

什么异步消息处理对于无服务器技术来说非常流行的原因。我们用FaaS函数替换了一个常驻的消息消

费者应用程序。这个函数在云平台供应商提供的事件驱动上下文中运行。请注意，云平台供应商应同时

提供messagebroker和FaaS环境——这两个是紧密联系的。

FaaS环境也可以通过实例化函数代码的多个副本来并行处理多条消息。这可能是我们迁移原来代

码时需要考虑的一个新问题。

3.2.解密FaaS

我们已经提到了FaaS，现在是时候深入研究它真正的含义了。为了做到这一点，我们来看看亚马

逊的FaaS产品Lambda的开头描述。在这段描述中已经添加了一些标记。

...

AWSLambda允许您在没有配置或管理服务器的情况下运行代码。（1）…使用Lambda，您几乎

可以运行任何类型的应用程序或后端服务（2）这些程序都是零管理，只要上传你的代码，Lambda就

会处理、运行（3）和缩放（4）你的代码以实现高可用性。您可以设置您的代码从其他AWS服务自动

触发（5），或者直接从任何web或移动应用程序调用（6）。

...

1.从根本上说，FaaS运行后端代码不需要考虑服务器系统或常驻应用程序的管理。如果回到之前的点

击处理示例，FaaS将取代点击处理服务器（可能是一个物理机器，但肯定是一个特定的应用程

序），它不需要一个指定的服务器，也不需要一个常驻的应用程序。

2.FaaS产品不需要对特定的框架或库进行编码。当涉及到语言和环境时，FaaS函数是常规的应用程

序。例如，AWSLambda函数可以在Javascript、Python、Go、任何JVM语言（Java、Clojure、

Scala等）或任何.NET语言中实现“firstclass”。然而，您的Lambda函数也可以执行与它的部署组件

捆绑在一起的另一个进程，因此实际上可以使用任何能编译成Unix进程的语言（参见Apex）。

FaaS函数还是具有特定架构限制的，特别是在状态和执行时间方面。我们很快就会讲到。

我们仍然考虑一下点击处理示例。在迁移到FaaS时，惟一需要更改的代码是“main方法”（启动）代

码，它将被删除。还有就是顶层消息处理程序（“消息侦听器接口”实现）的特定代码，但可能仅需要

更改一下方法签名。代码的其余部分（例如，写入数据库的代码）在FaaS世界中没有什么不同。

3.部署方式与传统系统非常不同，因为不需要使用服务器应用程序来运行。在FaaS环境中，将函数代

码上载到FaaS提供商，提供商则负责提供所有需要的资源、实例化vm、管理流程等其他一切必要的

内容。

4.水平扩展是完全自动的、有弹性的，并且由提供商管理。如果您的系统需要并行处理100个请求，那

么平台会自动处理这种伸缩性。执行函数的“计算容器”是暂态的，FaaS何时创建和销毁它们纯粹由运

行时需求驱动。最重要的是，使用FaaS，提供商处理所有底层资源供应和分配——用户根本不需要

集群或VM管理。

让我们回到点击处理器。比如说我们今天的点击率不错，顾客们点击的广告数量是平时的十倍。对于

传统的架构，我们的点击处理应用程序能够处理这个问题吗？例如，我们是否开发了能够一次处理多

个消息的应用程序？如果我们这样做了，应用程序的一个运行实例是否足以处理这样的负载？如果运

行多个进程，自动伸缩配置需要手动配置吗？有了FaaS，所有这些问题都已经得到了回答，当然所

编写函数需要适配并行伸缩机制，FaaS实现自动处理所有伸缩需求的机制。

5.FaaS中的函数通常由提供商定义的事件类型触发。AmazonAWS中的触发方式包括S3（文件/对象）

更新、时间（预定任务）和添加到消息总线的消息（例如，Kinesis）。

6.大多数提供商还允许函数作为入站HTTP请求的响应触发函数;在AWS中，通常通过使用API网关来实

现这个功能。在前面的宠物商店示例中，使用了一个API网关来进行“搜索”和“购买”功能。函数还可以

通过平台提供的API直接调用，但这是一种相对少见的用法。

3.2.1.状态

当涉及到本地（机器/绑定实例）状态时，FaaS函数有很大限制。如存储在内存变量的数据，或

者写入本地磁盘的数据。不能保证这种状态数据会在多个调用中保持，而且更重要的是，不能假定一

次函数调用的状态可用于同一函数的另一次调用。因此，FaaS函数通常被描述为无状态的，更准确

地说，任何需要持久的FaaS函数状态都需要在FaaS函数实例之外实施。

对于FaaS函数来说，它们是天然无状态的，如对那些提供对输入进行纯功能转换输出的应用。

但对另一些应用来说，这可能会对应用程序架构产生很大影响，尽管不是唯一的——“TwelveFactor

app”概念也有完全相同的限制。这种面向状态的函数通常会使用数据库、跨应用的缓存（如

Redis）、或网络文件/对象仓库（如S3）用于在请求之间存储状态，或者提供处理请求所需的更多输

入。

3.2.2.执行时间

FaaS函数通常对每次调用允许运行的时间有限制。目前，AWSLambda函数对事件响应的“超

时”最多为5分钟，然后会终止。微软Azure和Google云功能也有类似的限制。

这意味着FaaS函数不适合某类长时间运行任务。因而需要重新设计架构——可能需要创建几个

不同的协同FaaS函数，而在传统环境中，可能有一个常驻运行任务进行协调和执行。

3.2.3.启动延迟和“冷启动”

一个FaaS平台需要一些时间在处理每个事件之前初始化一个函数实例。这种启动延迟对于一个

特定的功能可能会有很大的不同，根据不同上下文，可能在几毫秒到几秒之间。这听起来的确糟糕，

但是让我们花点时间研究一下AWSLambda的例子。

Lambda函数的初始化是一个“热启动”过程,也是一个“冷启动”过程：重用一个处理先前事件的

Lambda函数实例及其宿主容器是一个“热启动”过程；创建一个新的容器实例、启动一个函数宿主进

程是一个“冷启动”过程。很明显，启动延迟主要是这些“冷启动”所带来的。

冷启动延迟依赖于许多因素：使用的语言；使用的库；代码数量；使用的Lambda函数环境变

量；是否需要连接VPC资源等等。但这些因素中的大部分都是开发者可控的，因此通常可以优化这些

因素以降低启动延迟。

与冷启动时间同样重要的是冷启动频率。例如，如果一个函数每秒处理10个事件，每个事件的处

理时间为50ms,你将会看到一次冷启动可处理100,000–200,000个事件。但如果一个事件需要一个小

时来处理，你将会看到每次处理一个事件都需要一次冷启动，因为Amazon的每个Lambda函数实例

只持续数分钟。了解这些可以帮助你了解冷启动是否会产生影响，以及是否想要执行“保留”函数实

例，以避免它们被释放。

是否需要关注冷启动带来的影响依赖于应用程序应用形态与业务类型。我的一个IntentMedia团

队使用JAVA实现了一个异步消息处理Lambdaapp，这个app每天处理上亿的消息，但是团队并不关

心这个组件的启动延迟。也就是说，如果你正在编写一个低延迟的交易应用程序，可能不希望在这个

时候使用FaaS平台。

不管你是否认为你的应用程序是否存在这样的问题，都应该使用类似于生产环境的负载来测试性

能。如果用例现在不起作用，可在几个月内再次尝试，这也是FaaS供应商不断改进的主要领域。

关于冷启动的更多细节，可参考我的另一篇文章。

3.2.4.API网关

剩余15页未读，继续阅读

心有猛虎-细嗅玫瑰

粉丝: 0
资源: 8

会员权益专享

无服务器架构(Martin Fowler,中文译文)

评论0

会员权益专享

最新资源

无服务器架构(Martin Fowler,中文译文)

评论0

重构 学习笔记 refactoring martin fowler

重温大师经典：Martin Fowler的持续集成

uml distilled中文 pdf

SpringBoot笔记-上篇.pdf

语篇分析理论的参考文献综述，要求五千字

会员权益专享

最新资源

重构学习笔记 refactoring martin fowler