亚马逊在2007 年通过简化虚拟机配置，永远改变了IT 基础设施。从那时起，
现代应用的架构改进基本上是循序渐进的。十年之后，亚马逊的Lambda 平台通
过简化配置函数，引领了另一场技术变革风潮。这种“无服务器架构”生态系统
正在彻底改变我们设计、开发和运营互联网应用的方式。
作为Lambda 平台的早期采用者，我有幸与Slobodan 和Aleksandar 合作，目
睹了“无服务器架构”构想对上市时间和运营成本的巨大影响。与此同时，这个
平台发展极为迅速，以至于用户很容易在其中迷失方向。为了真正从新的操作方
式中获益，开发人员必须重新考虑身份验证、会话管理、存储、容量规划和分发
策略。在本书中，Slobodan 和Aleksandar 提供了有关此次变革的前沿报告，以及
面向希望从新一代平台中获益的JavaScript 开发人员的宝贵指南。
本书致力于帮助人们快速完成在AWS Lambda 中的简单工作，而不是试图改
变我们构建或运行项目的方式。许多无服务器架构应用框架将AWS 服务抽象出
来，这样固化的框架可能带来巨大风险，因为开发生态仍在快速发展。本书作者
并没有强迫我们选择他们使用的框架，而是讲解如何轻松地使用所有相关服务。
对于刚接触AWS 的人，本书不仅介绍AWS Lambda，还介绍了一系列相关服务，
如DynamoDB(存储)、Cognito(身份验证)、API Gateway(运行Web 服务)和
CloudWatch(事件处理和调度)。即使之后不再使用作者选择的工具，也只需要以
不同的方式再次部署就可以继续使用所有代码。
本书还通过引入几个重要的实际应用来介绍无服务器架构平台，包括Web
API、聊天机器人、付款处理和订单管理。通过为虚拟的比萨餐厅逐步构建在线
商店，作者提供了大多数人在云平台上启动现代商业方案过程中可能需要的几乎
所有的现成组件。通过这种知识积累方式，本书得以更深入地探索开发过程中的
问题，例如如何组织自动化测试和设计易于维护的应用。本书的最后一部分讨论
迁移策略，并回答一些最常见的问题，这些问题来自那些已经在其他云平台上部
分运行应用的人，以及那些希望通过速成来缩短上市时间或降低运营成本的人。
请尽情享受本书给你带来的乐趣，你将发现一种更好地利用云平台软件快速
创造价值的方法。
节选自《Node.js无服务器应用实战 使用AWS Lambda和 Claudia.js》一书
---------------------------------------------------图书基本信息-----------------------------------------------------------
书名：《Node.js无服务器应用实战 使用AWS Lambda和 Claudia.js》
ISBN:9787302551874
定价：98元
出版时间：2020年5月
--------------------------------------------------------试读样章----------------------------------------------------------------------
无服务器比萨店
Maria 姨妈是个意志坚强的人。三十多年来，她一直在经营一家比萨店，这是
附近几代人的聚会场所：很多人在那里和家人一起共度时光，开怀大笑，甚至约
会。但最近，她的比萨店遇到了困难。她告诉你她的顾客越来越少了。技术的进
步使她的客户更喜欢通过网站或手机从竞争对手的比萨店在线订购。
她的比萨店已经有了一个网站，但需要一个后端应用来处理和存储关于比萨
和订单的信息。
在本书的第Ⅰ部分，你的目标是构建一个无服务器API，以帮助Maria 姨妈
赶上她的竞争对手。但是，由于你在无服务器应用开发方面还是个新手，因此你
首先需要了解无服务器是什么，以及它如何帮助构建比萨店API(见第1 章)。然后
继续向比萨店API 添加路由，并使用Claudia 将其部署到AWS Lambda(见第2 章)。
为了维持和交付所有订单，你需要将新的API 连接到DynamoDB 表(见第3
章)并与第三方服务Some Like It Hot Delivery API 进行通信(见第4 章)。
在开发过程中，你还将面临一些问题，并学习如何调试无服务器应用(见
第5 章)。
要使API 完全正常工作，你需要学习如何对用户进行身份验证和授权(见第6
章)以及如何保存和操作比萨图片(见第7 章)。
第1章 使用Claudia的无服务器 架构介绍
本章要点：
● 什么是无服务器
● 无服务器的核心概念
● 无服务器和托管服务器Web 应用之间的区别
● 如何配置Claudia
● 为什么使用无服务器
无服务器是一种在云基础设施上部署和运行应用的方法，基于使用付费，不
需要租用或购买服务器。无服务器平台供应商将负责替你进行容量的规划、扩展、
平衡和监控；供应商还可以将应用视为函数。
等等，没有服务器？无服务器似乎是一个新的流行词，是一种时髦的云趋势，
有望让你的生活变得更美好。
本章重点介绍无服务器的概念：它是什么，它为什么重要，以及与服务器托
管的Web 应用开发对比结果如何。本章的主要目标是了解基本的无服务器的概念，
并为后面的学习打下良好的基础。1.1 服务器和洗衣机
要理解无服务器，只需要稍微联想一下洗衣机即可。从一台洗衣服的设备开
始听起来有些让人摸不着头脑，但是现在拥有一台服务器就像拥有一台洗衣机。
每个人都需要干净的衣服，最合理的解决办法似乎就是买一台洗衣机。但是大多
数时候洗衣机插着电源，什么也不做。最多每周使用5～15 小时。服务器也是如
此。大多数时候，普通的应用服务器只是等待接收请求，什么也不做。
有趣的是，服务器和洗衣机有许多共同的问题。它们都有可以处理的最大重
量或体积。拥有一台小型服务器就像拥有一台小型洗衣机。如果积攒了一大堆衣
服要洗，洗衣机就无法一次洗完。可以买一台更大的、可以洗更多衣服的洗衣机，
但你会发现当自己只想洗一件衬衫时，用一台洗衣机来洗似乎很浪费。此外，设
置所有应用都安全地运行在一台服务器上是很棘手的，有时甚至是不可能的。一
个应用的正确设置可能会完全打乱另一个不同设置的应用。同样，使用洗衣机时，
必须根据颜色来区分衣服，然后选择合适的程序、洗衣液和柔顺剂组合。如果不
能正确地进行设置，洗衣机会洗坏衣服。
这些问题，加上不是每个人都能拥有洗衣机的问题，导致自助洗衣店或干洗
店的兴起。对于服务器，同样的需求已经导致许多公司开始提供服务器租赁服务，
无论是在本地还是云端。可以租用服务器，服务器供应商负责存储、电源和基本
设置，但自助洗衣店和租赁服务器都只是部分解决方案。
对于洗衣机和服务器的租赁，你仍然需要知道如何组合衣服或应用，并设置
机器，选择合适的洗衣液或环境。你还必须平衡机器的数量和它们的大小限制，
计划需要多少台机器。
在洗衣行业，一种新的趋势——“蓬松和折叠”服务在20 世纪50 年代后开
始出现。可以带一件或一袋衣服来，他们会为你清洗、烘干和叠好衣服。有些甚
至可以送到指定的地址。他们通常是按件收费的，所以不需要攒够特定数量的衣
服来洗，也不需要操心洗衣机、洗衣液和清洗程序。
与洗衣行业相比，软件行业仍然处于自助洗衣店的时代，很多人仍然租用服
务器或求助于平台即服务(PaaS)提供商。我们仍在评估潜在的请求数量(衣服的数
量)，我们将处理和保留足够的服务器以处理负载，这样做要么经常浪费钱买服务
器，要么操作满负荷或超负荷，无法处理所有客户的请求。
1.2 核心概念
那么无服务器是如何改变这一点的呢?这个名称暗示了根本没有服务器，似乎不是逻辑解决方案。
什么是无服务器
无服务器是在云端部署和运行应用的一种方法，基于使用付费，不需要租用
或购买服务器。
与名称截然相反，无服务器并不排除服务器的存在；软件运行需要硬件。无
服务器只是消除了公司、组织或开发人员实际租用或购买服务器的需求。
你可能想知道为什么无服务器如此命名。答案在于无服务器是抽象化的服务
器概念。不必租用服务器、设置环境并部署应用，而是将应用上载到无服务器供
应商，后者负责分配服务器、存储、应用处理、设置和执行。
注意有些人可能想知道无服务器是否会消除公司对大型 DevOps 团队的需求。
在大多数情况下，答案是肯定的。
更准确地说，供应商将应用存储在某个容器中。容器表示一种独立的环境，
其中包含应用需要运行的所有内容。可以把容器想象成栽培盆。栽培盆里的泥土
中饱含植物赖以生存的所有矿物质。
与栽培盆一样，容器允许无服务器提供者安全地移动和存储应用，并根据需
要执行和复制应用。但是，无服务器的主要好处在于基本上不需要进行任何服务
器配置、平衡、扩展，不需要进行任何类型的服务器管理。无服务器供应商为你
管理所有这些，同时还保证，如果同时发生针对应用的大量调用，它将克隆足够
的容器来处理所有调用，并且每个克隆都是首个调用的精确副本。如果需要，无
服务器供应商将创建数千个克隆。只有当应用的请求数量变得非常大，以致当前
容器无法处理所有传入的请求时，无服务器供应商才决定复制容器。
除非有对应用的请求(调用)，否则不会运行应用的单个实例，因此不会浪费
空间、服务器时间或能量。无服务器供应商负责所有操作细节，例如知晓应用存
储在哪里、如何以及在哪里复制应用、何时加载新的容器甚至何时减少已复制容
器的数量以卸载未使用的服务器。
从洗衣机的角度看，这个过程就像是呼叫衣服清洗服务；送货员出现在你的
家门口，拿走你的脏衣服，清洗后把衣服还给你。无论你有多少衣服，无论是什
么衣料(羊毛、棉花、皮革等)，洗衣店都要负责所有的衣物分类过程、洗衣液的
选择和清洗程序的选择。
无服务器和FaaS
最初，术语无服务器的解释与现在有所不同。在无服务器的早期，它被定义
为后端即服务(Backend as a Service，BaaS)，因为它表示部分或完全依赖于第三方服务的应用以实现基于服务器的逻辑。后来，它几乎被专门描述为函数即服务
(Function as a Service，FaaS)，因为无服务器提供程序将应用视为函数，只有在被
请求时才调用它们。
1.3 无服务器的工作方式
如前所述，无服务器提供程序为应用提供独立的计算容器。计算容器是由事
件驱动的，因此只有在某个事件触发时才会激活它。
事件是一些特定的外部操作，其行为与物理触发器完全相同。以家中的灯为
例：打开它们的事件可能不同。典型的灯开关是由压力激活的，运动传感器与运
动检测相连，光照传感器在太阳落山时打开灯。但是容器不仅限于监听指定的事
件和调用其中包含的函数，它们还为函数自己创建事件提供了一种方法，或者更
准确地说，提供了一种发射事件的方法。通过更技术性的方式，使用无服务器提
供程序，可以让函数容器既是事件监听器又是事件发射器。
最后，无服务器提供程序提供了可以运行函数的各种触发器。触发器列表取
决于提供程序和实现，但最常见的触发器有HTTP 请求、文件上传到文件存储、
数据库更新和物联网(Internet of Things，IoT)事件，等等。
注意无服务器函数仅在触发时运行，而你只需要在执行期间付费。执行后，无
服务器供应商关闭函数，同时保持触发器处于活动状态。
1.4 无服务器实践
整个无服务器环境包含许多移动部件，因此我们慢慢介绍它们。我们将构建
一个示例应用，并一次引入一个部件，这样就可以看到无服务器是如何配置的。
当慢慢学习每个新概念时，将扩展这个示例应用。
本书将采取一种新的方法来展示示例应用(从头开始构建)，并且更精确地处
理小公司的问题，我们的比萨店应用由虚构的Maria 姨妈管理。Maria 姨妈将面临
许多现实世界的问题，而你的目标是帮助她同时掌握一些概念。像每一项新技术
一样，无服务器技术引入了许多新概念，这些概念很难同时处理。
注意对于希望切换环境的读者(将当前应用迁移到无服务器环境)，可直接跳到
本书的最后一部分。如果不熟悉无服务器，在跳到本书的最后一部分之前，
至少应该先读完前几章。1.4.1 Maria 姨妈的无服务器比萨店应用
Maria 姨妈是个意志坚强的人。三十多年来，她一直在经营一家比萨店，许多
人在这里与家人共度时光，一起欢笑，甚至进行浪漫约会。但最近，她的比萨店
遇到了困难。她告诉你店里的顾客越来越少了。许多客户现在更喜欢通过网站或
手机在线订购，而不是亲自购买。一些新的比萨店开始抢走她的顾客。例如，新
开的Chess 比萨店提供了比萨预览和在线订购的移动应用，以及通过各种通信应
用进行订购的聊天机器人。虽然顾客喜欢她的比萨店，但大多数人都想从家里订
购，所以她的生意开始衰落。Maria 姨妈的比萨店已经有了一个网站，但是需要一
个后端应用来处理和存储关于比萨和订单的信息。
1.4.2 一种常见的方法
鉴于 Maria 姨妈的资源有限，最简单的解决方案是使用流行的Node.js 框架(如
Express.js 或Hapi)构建一个小型API，并在同一个实例(很可能是MongoDB、
MySQL 或PostgreSQL)中建立比萨数据库。
使用典型的API 可将代码结构化为类似于三层架构的几层，这意味着代码被
划分为表示层、业务层和数据层。
三层架构
三层架构是一种客户端/服务器软件架构模式，其中，用户界面(表示)、函数
流程逻辑(“业务规则”)、计算机数据存储和数据访问，通常在单独的平台上作
为独立模块进行开发和维护。
要了解关于三层架构的更多信息，请访问https://en.wikipedia.org/wiki/Multier_
Architecture#Three-tier_architecture。
典型的三层应用设计类似于图1.1，为比萨、订单和用户提供单独的路由，
此外还将为聊天机器人和支付处理器提供Web 接口。所有路由都会触发业务层
中的一些处理函数，处理后的数据将被发送到数据层(数据库)以及文件和图片
存储。
这种方法非常适合任何给定的小应用。这种结构对比萨店API 很有用，至少
在网上比萨订单增长到一定水平之前是这样。然后需要扩展基础设施。
但是为了能够扩展整体应用，必须分离数据层(因为为了保持数据一致性，你
不想复制数据库)。之后，应用将类似于图1.2。但是，你仍然拥有应用的联合体，
其中包含所有的API 路由管理和业务逻辑。如果用户太多，则可以复制应用，但
每个实例也将复制所有服务，而不管使用情况如何。
图1.1 比萨API 的典型三层设计
图1.2 使用比萨API 的外部数据库和文件存储的常用方法
整体应用
整体应用是一种软件应用，其中用户界面和数据访问代码在平台上被组合成
程序。整体应用是独立的，独立于其他计算应用。
1.4.3 无服务器方法
创建无服务器应用需要一种不同的方法，因为这些应用是事件驱动的，并且
是完全分布式的。应用的每个部分都独立于那些独立的、可自动扩展的容器，而
不是只有单个带有API 端点和业务逻辑的服务器。在无服务器应用中，请求由只
有一个函数的API 路由管理器处理：它接收HTTP 请求并将它们发送到底层的业
务层服务。无服务器架构中的API 路由管理器始终是独立管理的。这意味着应用
开发人员不维护API 路由管理器，而由无服务器提供程序自动扩展以接收API 正
在接收的所有HTTP 请求。此外，你只为处理的请求付费。对于比萨店API，路
由管理器将接收来自移动和Web 应用的所有API 请求，并在必要时处理来自聊天
机器人和支付处理器的Web 接口。
一个API 请求在被发送之后，将被传递到另一个容器，其中包含要处理的业
务层服务。无服务器应用的业务逻辑通常被拆分为更小的单元，而不是只有一个
完整的应用。每个单元的大小取决于个人偏好。单元可以小到单个函数，也可以
大到整个应用。大多数情况下，单元的大小不会直接影响基础设施的成本，因为
只需要为执行的函数付费。单元也会自动扩展，并且不需要为不处理任何内容的
单元付费，因此拥有一个或多个单元的成本相同。但是，对于小型应用和没有太
多信息的情况，可以通过将一个与服务相关的函数捆绑到业务单元来节省托管和
维护费用。对于比萨店API，明智的解决方案是创建一些模块，分别用于处理比
萨和订单、付款聊天机器人以及图片和文件。无服务器API 的最后一部分是数据
层，类似于按比例缩放的完整应用中的数据层，具有单独缩放的数据库和文件存
储服务。最好的情况是，数据库和文件存储也是独立的和可扩展的。无服务器
应用的另一个好处是，数据层可以直接触发无服务器函数。例如，当把比萨图
片上传到文件存储时，可以触发图片处理服务，可以调整照片的大小并与特定比
萨关联。
可在图1.3 中看到无服务器比萨店API 的流程。
图1.3 比萨API 的无服务器方法
1.5 无服务器基础设施——AWS
无服务器比萨店API 的运行需要基础设施。无服务器框架刚刚流行开来，目
前只有几个基础设施可供选择。这些选择中的大多数都由大供应商拥有，因为无
服务器需要大的基础设施才能进行扩展。最著名、最先进的基础设施是亚马逊的
AWS Lambda 无服务器计算容器、微软的Azure 功能以及谷歌的云服务。
本书关注的是AWS Lambda，因为AWS 有市场上最成熟的无服务器基础设
施，有稳定的API 和许多成功的案例。
AWS Lambda 是由事件驱动的无服务器计算平台，由Amazon 作为Amazon Web
服务的一部分提供。Lambda 是一种计算服务，可以运行响应事件的代码，并自动
管理代码所需的计算资源。谷歌的云服务和微软的Azure 功能
谷歌在 2016 年年中推出了云服务，这是对亚马逊的AWS Lambda 的回应。
谷歌的云服务被解释为基于事件的轻量级微服务，允许在Node.js 运行时中运行
JavaScript 函数。函数可由HTTP 请求、Google 云存储和其他Google Cloud Pub/Sub
服务触发。在撰写本书时，谷歌的云服务仍然处于测试中，所以定价还不清楚，
可从官方网站https://cloud.google.com/functions/.microsoft 了解更多信息。
对Azure 的无服务器功能的实现是微软Azure 云计算平台的一部分，微软将
这描述为一种基于事件的无服务器计算体验，可以加速开发，根据需求进行扩展，
并且只对消耗的资源收费。Azure 允许在JavaScript、C、F、Python 和其他脚本语
言之间做出选择。Azure 的定价与AWS Lambda 类似：每月每执行100 万次收取
20 美分的费用，每GB 的资源消耗收取0.000 016 美元的费用，每月前100 万次
请求和400 000 GB 资源免费。有关详细信息，请访问官方网站https://azure.microsoft.
com/en-us/services/functions/。
注意在本书中，你将学到的大部分内容对于其他无服务器供应商也是可行的，
但是有些服务可能有所不同，因此一些解决方案可能需要稍微不同的方法。
在亚马逊平台中，无服务器一词通常与AWS Lambda 直接相关。但是当构建
无服务器应用(例如比萨店API)时，AWS Lambda 只是构建块之一。对于完整的应
用，通常需要其他服务，例如存储、数据库和转发服务。在表1.1 中，可以看到
AWS 已为所有这些开发了全套服务：
● Lambda 用于计算。
● API Gateway 是一种路由管理器，用于接收HTTP 请求并根据路由管理调
用其他服务。
● DynamoDB 是可自动扩展的数据库。
● 简单存储服务(S3)是一种存储服务，可以抽象标准硬盘并为你提供无限的
存储空间。
表1.1 AWS 中无服务器应用的构建块
功能 AWS 服务简短的介绍
计算 Lambda 计算组件，用于业务逻辑
路由 API Gateway 路由组件，用于将HTTP 请求数据发送到Lambda 函数
数据库 DynamoDB 可自动扩展的文档数据库
存储 S3 可自动扩展的文件存储服务
Lambda 是你需要了解的最重要的无服务器组成部分，因为其中包含了业务逻
辑。Lambda 是AWS 的无服务器计算容器，可在发生事件触发时运行函数。如果许多事件同时触发函数，Lambda 会自动缩放。要将比萨店API 开发为无服务器
应用，需要使用AWS Lambda 作为无服务器计算容器。当某个事件发生时，例如
HTTP 请求，将触发Lambda 函数，其中包含来自事件、上下文和回复事件的数据
作为参数。Lambda 函数是一种用支持的语言之一编写的简单处理程序。在撰写本
书时，AWS Lambda 支持以下语言：
● Node.js
● Python
● Java 以及其他JVM 语言
● C#(.NET Core)
在Node.js 中，事件数据、上下文和函数回调可作为JSON 对象传递。context
对象包含有关Lambda 函数及其当前执行的详细信息，例如执行时间、触发函数
的内容以及其他信息。Lambda 函数接收的第三个参数callback 允许回复一些将被
发送回触发器的有效负载或错误。代码清单1.1 显示了一个小型AWS Lambda 函
数的Node.js 示例，该函数返回文本Hello from AWS Lambda。
代码清单1.1 使用Node.js 的Lambda 函数示例
function lambdaFunction(event, context, callback) {
callback(null, 'Hello from AWS Lambda')
}
exports.handler = lambdaFunction
注意如代码清单 1.1 所示，使用exports.handler 而不是标准的Node.js，
module.exports 导出函数，这是因为AWS Lambda 要求将模块导出为具有
命名处理程序方法的对象，而不是直接使用函数。
如前所述，Lambda 函数中的事件是由触发Lambda 函数的服务传递的数据。
在AWS 中，可以通过许多方式调用函数，例如通过API Gateway 的HTTP 请求或
S3 的文件操作等常见事件，以及使用AWS SDK 进行代码部署、更改基础结构甚
至控制台命令等更奇特的事件。
以下是可以触发AWS Lambda 函数的最重要事件和服务的列表，以及它们将
如何转换为比萨店API：
● 通过API Gateway 发送HTTP 请求——发送比萨订购请求。
● 通过S3 上传新的比萨照片——进行图片上传、删除以及文件操作。
● 通过DynamoDB 更新数据库——收到新的比萨订单。
● 使用简单通知服务(AWS SNS)——比萨送到。● 使用亚马逊的语音命令Alexa——客户使用语音命令从家中订购比萨。
有关触发器的完整列表，请参阅http://docs.aws.amazon.com/lambda/latest/dg/
invoking-lambda-function.html。
Lambda 函数有一些限制，例如有限的执行时间和内存。例如，默认情况下，
Lambda 函数的执行时间最多为3 秒，这意味着如果代码尝试处理更长的时间，将
超时跳出。另外，由于只有128 MB 的RAM，这意味着不适合执行复杂的计算。
注意可以在函数设置中配置这两个限制。超时可以增加到15 分钟，内存可以增
加到3 GB。配置这两个限制可能会影响函数每次执行的成本。
Lambda 函数的另一个重要特性在于它们是无状态的，因此在两次调用之间状
态将会丢失。
无服务器的定价
无服务器的主要卖点之一是价格。亚马逊按小时为标准的虚拟服务器 Elastic
Compute Cloud (Amazon EC2)定价。AWS Lambda 的每小时成本比Amazon EC2
高，但相比之下，除非使用，否则不需要付费。每月执行AWS Lambda 函数需要
支付20 美分，每月的每GB 资源消耗需要支付0.000 016 美元。亚马逊还提供免
费套餐，每月免费提供100 万次请求和400 000 GB 免费套餐。对于比萨店API，
Maria 姨妈在每月达到100 万次执行之前不需要支付任何费用。
有关定价的更多信息，请访问官方网站https://aws.amazon.com/lambda/pricing/。
如图1.4 所示，Lambda 函数的流程如下：
(1) 发生某个事件，处理事件的服务会触发Lambda 函数。
(2) Lambda 函数(如代码清单1.1 中的函数)开始执行。
(3) 函数执行结束，可以返回成功或错误消息，也可以因超时结束。
图1.4 AWS Lambda 函数的执行流程
另一个可能影响无服务器比萨店API 的重要因素是函数延迟。因为Lambda
函数容器由供应商而不是应用操作员管理，所以无法知道现有容器是否将提供触发器，以及平台是否将实例化新的容器。如果需要在函数执行之前创建并初始化
容器，则需要更长的时间，这被称为冷启动，如图1.5 所示。启动新容器所需的时
间取决于应用的大小和用于运行应用的平台。根据经验，在编写本书时，Node.js
和Python 的延迟明显低于Java。
图1.5 AWS Lambda 函数的冷启动与热启动
比萨店API 的成本
按照本书后面章节中的描述开发比萨店API，成本应低于一杯咖啡。AWS
Lambda 本身是免费的，但是用于比萨店API 开发的一些服务(例如DynamoDB 和
Simple Storage Service)对数据的存储收取少量费用。这些服务及其定价都将在后
面的章节中介绍。应用的最终价格取决于数据量及其使用情况。
Lambda 函数非常易于理解和使用。最复杂的部分是部署过程。
将无服务器应用部署到AWS Lambda 有几种方法。可以使用AWS API 通过
AWS Lambda 控制台或终端的可视UI，也可以直接使用AWS SDK 支持的语言之一
进行部署。部署无服务器应用比部署传统服务器应用简单，但还可以变得更容易。
1.6 什么是Claudia，应如何配置
Claudia 是一个Node.js 库，它可以简化Node.js 项目到AWS Lambda 和API
Gateway 的部署。Claudia 可以自动执行所有容易出错的部署和配置任务，并将所
有内容设置为JavaScript 开发人员常用的开箱即用方式。
Claudia 构建于AWS SDK 之上，使开发更容易。Claudia 不是AWS SDK 或
AWS CLI 的替代品，而是一种扩展，可以轻松快速地完成一些常见任务，例如部署和设置触发器。
Claudia 的核心价值包括：
● 使用单个命令创建和更新函数(无须手动压缩应用，然后通过AWS
Dashboard UI 上传zip 文件)。
● 不使用样板文件，从而允许你专注于自己的工作并保持首选的项目设置。
● 轻松管理多个版本。
● 通过非常平坦的学习曲线在几分钟内开始工作。
Claudia 可以充当命令行工具，允许从终端创建和更新函数。但Claudia 生态系
统附带了另外两个有用的Node.js 库：Claudia API Builder，允许在API Gateway
上创建API；以及Claudia Bot Builder，允许为许多消息传递平台创建聊天机器人。
与从未部署到AWS 客户端的工具Claudia 相反，Claudia API Builder 和Claudia
Bot Builder 始终部署到AWS Lambda(见图1.6)。可以在没有Claudia 的情况下使
用AWS Lambda 和API Gateway，直接使用AWS 生态或使用某些替代方案。
最广为人知的替代方案如下：
● 由AWS 创建的无服务器应用模型(SAM)允许通过AWS CloudFormation
创建和部署无服务器应用。更多信息可访问https://github.com/awslabs/
serverless-application-model。
● 无服务器框架虽然具有与SAM 类似的方法，但也支持其他平台，例如
Microsoft Azure。更多信息可访问https://serverless.com。
图1.6 Claudia、Claudia API Builder 和Claudia Bot Builder 与AWS 平台关系的可视化表示
● Apex 是另一个命令行工具，可帮你部署无服务器应用，但它支持更多编
程语言，如Go 语言。更多信息可访问http://apex.run。
注意 本书的所有内容都可以使用其中一种Claudia 替代方案完成。你可能想知道为什么我们选择使用Claudia。Claudia 的常见问题解答提供了最
佳解释：
● Claudia 是部署用的实用程序而不是框架。Claudia 并没有抽象出AWS 服
务，而是让它们更容易入门。与Serverless 和Seneca 相反，Claudia 并没
有试图改变项目的构建或运行方式。可选的Claudia API Builder 则简化了
Web 传递，这是运行时唯一附加的依赖项，结构已经最小化且可以单独
使用。微服务框架有许多很好的插件和扩展，可以帮助启动标准任务，但
Claudia 只关注部署。设计的关键目标之一是不要引入太多变化，让人们
按照他们想要的方式构建代码。
● Claudia 专注于Node.js。与Apex 和类似的部署器相反，Claudia 的范围要
窄得多。Claudia 仅适用于Node.js，但做得确实很好。通用框架支持更多
语言运行的同时，需要开发人员自行处理特定于语言的问题。因为Claudia
专注于Node.js，所以会自动安装模板以将参数和结果转换为JavaScript
可以轻松使用的对象，并使事情按照JavaScript 开发人员常用的开箱即用
方式工作。
更多详细信息可参阅https://github.com/claudiajs/claudia/blob/master/FAQ.md。
本书的目的是教会你以无服务器方式思考，从而轻松开发和部署高质量的无
服务器应用。直接使用AWS 生态会带来很多干扰，例如学习如何与AWS 平台的
不同部分进行交互和配置。Claudia 不是试图替换AWS SDK，而是建立在AWS
SDK 之上，并且Claudia 使用单个命令自动执行大多数常见工作。
Claudia 倾向于代码而非配置，因此几乎没有任何配置过程。这使得学习、理
解和测试变得更容易。编写高质量的应用需要进行适当的测试，有很多配置并不
意味着不需要测试。
Claudia 拥有最少的命令，允许以愉快的开发体验构建无服务器应用。Claudia
背后的主要思想是尽量减少变化，并在显示因调用命令而发生的事情时保持透明。
尽管API 很小，但Claudia 可以让你开发很多东西：可以从头开始构建无服
务器应用，将当前的Express.js 应用迁移到无服务器，甚至可以构建自己的无服务
器聊天机器人和语音助理。
1.7 何时以及在何处使用无服务器
无服务器架构不是银弹(银弹一词来自《人月神话》。银弹原本应该指某种策
略、技术或技巧可以极大地提高程序员的生产力，但实际上却是不存在的)。无服
务器架构并不能解决所有问题，并且很可能包括你正面临的问题。
例如，如果正在构建严重依赖Web 接口的应用，那么无服务器并不适合。AWSLambda 最长可以工作15 分钟，此时不能保证保持唤醒以监听Web 接口消息。
如果延迟对应用至关重要，即使快速唤醒容器，也可能需要付出代价。代价
是几十毫秒，但对于某些应用来说，时间可能有些长。
无须配置是无服务器的主要卖点之一，但这种优势对某些应用类型来说可能
是巨大的不足。如果要构建需要系统级配置的应用，那么应考虑采用传统方法。
可以在某种程度上自定义AWS Lambda，比如可以提供静态的二进制文件并使用
Node.js 进行调用，但在许多情况下这可能会矫枉过正。
另一个重要的缺点是所谓的供应商锁定。这本身不是大问题，因为它们只是
标准的Node.js 功能，但如果将自己的完整应用构建为无服务器应用，那么某些服
务将不易迁移。但是，这个问题十分常见，它与无服务器无关，并且可以通过良
好的应用架构将影响最小化。
也就是说，无服务器利大于弊，本书的其余部分将向你展示一些很好的用例。
1.8 本章小结
● 无服务器架构正在将服务器从软件开发中抽象出来。
● 无服务器应用与传统应用的不同之处在于无服务器应用是事件驱动的、分
布式的且可自动扩展的。
● 无服务器基础架构有几种选择，最先进的是亚马逊的AWS Lambda。
● AWS Lambda 是由事件驱动的无服务器计算平台，允许运行用Node.js、
Python、C#或Java 语言编写的函数。
● AWS Lambda 具有某些限制，例如执行时间(最长可达15 分钟)和可用内
存(最多可达3 GB)。
● 在AWS 中，无服务器应用开发的最复杂部分是部署和功能配置。
● 一些工具和框架可以帮助你更轻松地部署和配置应用。最容易使用的是
Claudia 以及Claudia API Builder 和Claudia Bot Builder。
● Claudia 可以充当命令行工具，它提供了一组命令，使你可以享受愉悦的
无服务器应用开发体验。
● 无服务器架构不是万能的，在某些情况下它不是最佳选择，例如带有Web
接口的实时应用。
想了解更多关于《Node.js无服务器应用实战 使用AWS Lambda和 Claudia.js》的内容，