【翻译】比较4个NodeJS Serverless App的框架

【原作者】Gedalyah Reback

【原文链接】Comparing Frameworks for Node.js Serverless Apps

【推荐阅读】12 Best Nodejs Frameworks for App Development in 2022

正文:

多年来,云部署变得更加复杂。这是他们的责任,但这不一定是错误的——现在你可以做的比过去多得多。随着时间的推移,每一项新服务都变得越来越容易,这种能力的蓬勃发展确实归功于它自己。AWS、谷歌和 Azure 开始提供减轻本地计算基础设施负担的产品。很快,用户和提供商就被需求和新云服务的激增所淹没。

AWS 于 2002 年推出,然后开始提供用自己的基础设施替换本地基础设施。在谷歌和微软推出自己的产品后,Docker 于 2013 年首次亮相,以组织(“容器化”)越来越多的开发人员开始使用的服务。Kubernetes 很快就出现了,从那时起,就有大量的工具试图理解 Kubernetes 本身。显然,这对于新手来说会感到困惑,但对于刚开始使用云计算的新手和老手来说,这足以说明这是需要组织的大量基础架构。

我们现在已经进入了名称不佳的“无服务器”架构时代。就像“在云中”并不意味着文件现在存在于以太中一样,“无服务器”应用程序实际上并没有与服务器分离。无服务器意味着开发人员不必自己管理服务器(粗心大意:“无服务器”应用程序仍在服务器上)。

澄清一下,这些是无服务器应用程序的框架。这些不是 Rest API 框架、MVC 框架,也不是全栈 MVC 框架。您可以查看 一些很棒的Node.js 框架比较以获取更多信息。

1. AWS SAM(Serverless Application Model)

AWS有自己的serverless框架,称之为SAM。 它是开源的,SAM 和 SAM CLI 都在 Apache 2 许可下发布。使用 SAM CLI 部署应用程序是可选的,或者您可以通过基于第三方的管道进行工作。

SAM 让您使用 YAML 为应用程序建模,但 SAM 也有自己的函数和 API 语法。该语法也处理映射和数据库,非常简单。正如您可能已经猜到的那样,SAM 与 AWS 生态系统的其余部分非常集成,因此它会自动采用基本简写语法并将其扩展以匹配 CloudFormation 语法。

然而,SAM 的主要优势也是它的主要缺点——它是 AWS 的一部分,不可分割且不可分割。一方面,几乎有一个工具可以满足所有需求:使用 Cloud9 IDE 进行调试,使用 Lambda 进行无服务器功能,使用 CloudFormation 进行传统监控,使用 CodeDeploy 进行代码部署等。

AWS SAM架构:

操作过程

以Linux为例:

  1. 先拥有一个AWS账号,并且加上IAM全县和AWS凭证,再安装Docker
  2. 更新包:
sudo yum update -y
  1. 安装Docker
sudo amazon-linux-extras install docker
  1. 启动Docker
sudo service docker start
  1. 将ec2-user添加到新的Docker组,以方便在每个命令前不需要带sudo(就是更改权限)
sudo usermod -a -G docker ec2-user
  1. 重新登陆ec2-user账户,以激活权限。
  2. 安装AWS SAM CLI:

如果是ARM架构:

pip install aws-sam-cli

如果是X86架构:

unzip aws-sam-cli-linux-x86_64.zip -d sam-installation

安装:

sudo ./sam-installation/install

2. Architect

Architect(您也可以将其称为arc.codes,它的 URL,以避免在搜索项目信息时造成混淆)是另一个开源框架,它是 OpenJS 基金会的一部分,拥有 Apache 2 许可证。它专注于 AWS。您可以查看其GitHub 存储库以获取更多详细信息。它的维护者称其为“核心”的 IaC 框架(基础设施即代码)。

在函数运行时方面支持其他一些语言:Python、Ruby、.NET、Java 和 Golang。

这就是 Architect 对 AWS 的关注变得显而易见的地方。尽管它作为一个独立于 SAM 的框架工作,但它仍然通过它工作以部署应用程序。Architect 以app.arc文件的形式获取应用程序代码,然后将其编译为 AWS SAM 应用程序,准备最终将其部署到 AWS CloudFormation 中。因此,虽然您的大部分工作都是在 Architect 中完成的,但部署意味着通过与其他方式完全相同的工具管道发送它,如果您刚开始在 AWS SAM 上构建应用程序的话。

但这也是 Architect 最初完全专注于 AWS 的结果,它试图至少稍微远离 AWS。它曾经依赖于 AWS API Gateway,后来转移到了 HTTP API。它还有自己的配置语言——arc——很容易学习。

它的本地开发工作流程让您可以从终端打开一个弧形沙箱。您甚至可以离线测试和调试代码。

快速入门

  1. 开始新的项目,首先要保证Node.js 是14+版本
npm i -g @architect/architect
  1. 在其中创建一个新目录一个新应用程序:
mkdir testapp
cd testapp
arc init
  1. 启动本地开发环境:
arc sandbox
  1. 部署到AWS的临时缓存中(Deploy to staging in AWS)
arc deploy
  1. 部署到AWS的生产环境
arc deploy --production

3. Claudia.js

Claudia与上面2个相似的,但目前来看,它可做更多的事情。它也是一个基于 Javascript 的开源框架,但在 GitHub 上的活动和贡献者大约是三倍。根据其文档,Claudia.js 的目标不是一个成熟的框架,而是一个“开源部署工具”或“部署实用程序”。

它也仅限于 AWS,但在这种情况下,API Gateway 是 AWS Lambda 之外的。为此,它包含一个 API Builder,Claudia 的维护者认为它是“最小且独立的”。它包括用于 API 构建和聊天机器人开发的扩展库。

它也有非常简单的命令。他们还吹嘘能够使用 NPM 包来构建和部署 API,而无需使用像 Swagger 这样的额外工具。Claudia 中默认设置了一些常见配置,例如错误路由或 CORS 支持。

它有许多针对不同 API 的扩展库,一个简单的版本控制工具,并且非常容易学习(任何有基础的Javascript学习者都应该快速掌握这个)。

快速入门

Claudia.js 在安装方面非常简单。先决条件包括 NPM、Node.js 以及具有 IAM 和 Lambda 访问权限的 AWS 账户。使用 NPM 安装它,然后创建一个指定的 AWS 配置文件来连接它。

  1. 首先,在本地安装。我们将在这里为您提供最快的安装分解,作为一个全球实体(根据 Claudia 的文档,最简单的源)
npm install claudia -g

(也可以作为本地依赖包来安装,但即使是依赖Claudia的安装过程也相当简单)

  1. 接下来,在 AWS 上,创建一个完全权限的账户(完全访问权限和/或管理员权限的配置文件)

    1. IAM
    2. Lambda
    3. API Gateway
  2. 然后,将AWS_PROFILE变量设置为您想要的任何名称(我们称之为 ours jeanCLAUDIAvanDAMN)。保存密钥集(大概是您通常保存 AWS 密钥的位置,一般在~/.aws):

[jeanCLAUDIAvanDAMN]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_ACCESS_SECRET
  1. 如果您想使用单独的配置文件来访问 Claudia.js,您可以通过 AWS Node.js API 创建多个配置文件。默认访问权限将转到您在第 3 步中使用的访问权限,但您始终可以添加更多:
AWS_PROFILE=profileNumberTWO claudia <options>

4. Serverless

对于构建和部署无服务器应用程序的框架来说,它绝对是最受欢迎的选择。但是由于它的名称,搜索任何(小写)无服务器框架的信息将不可避免地导致您找到有关(大写)无服务器框架©的信息。(您也可以将其风格化为“无服务器⚡”以适应其旧徽标)。

这个框架还有更多的东西,但不仅仅是它的营销友好名称。它有非常广泛的选择。它适用于所有三种主要的云服务,并支持 10 多种不同的语言。它还有一长串插件。是的,它也是开源的。

同样,它可以处理多云部署。这意味着您可以将 AWS Lambda 与 Amazon Cloud、Azure Functions 与 Azure 的云服务以及 Google Functions 与 GCP(谷歌云平台)一起使用。

但它比这更进一步。它提供实时日志记录和指标,深入了解您可能期望可观察性服务提供商提供的一些服务。它的 AWS 监控将自动包括例如 Lambda 日志、AWS 跨度,最后是 HTTP 跨度。您还可以在以下位置关闭所有这些默认设置serverless.yml

custom:
  enterprise:
    disableHttpSpans: true
    disableAwsSpans: true
    collectLambdaLogs: false

与 AWS SAM 等框架选择相比,Serverless框架有一个大型插件贡献社区。另一方面,它有很多质量较低的插件。并且独立于庞大的云生态系统,它依赖于第三方工具进行监控。即使您希望将这些第三方工具放在您的堆栈中,这也会使事情变得更加耗时.

即使考虑到这些负面因素,它也比其他工具灵活得多。部署无服务器应用程序更快,在更新时提供有关软件更新的详细信息,以及更简单的 CLI 参数。

要安装,请确保您具备所有先决条件,然后只需使用 NPM 下载:

npm install -g serverless

[注意]:国内的Serverless和腾讯云深度绑定,怎么都避不开,谨慎使用

最后:比较Serverless的框架数据

AWS SAMClaudia.jsArchitectServerless
版本1.44.0(2022.03.29)5.14.1(2022.03.17)10.0.5(Taniwha)3.9.0(2022.03.24)
Github stars8500+3700+2000+42400+
贡献人数2253832935
CloudsAWS onlyAWS onlyAWS onlyAWS, Azure, GCP, 腾讯云
除Node外的语言Python, Ruby, Go, Java, .NETNOPython, Ruby, Go, Java, Deno, .NET(C#)Python, Ruby, Go, Java, C#, F#,Scala, Swift, PHP, Kotlin

这种可扩展性和后台处理弥补了 Node.js 的一些缺点。使用Serverless架构补充已经由事件驱动的运行时(如 Node.js)为Serverless应用程序堆栈创建了一个强大的基础。无论您选择哪种语言,Serverless应用程序都比之前的应用程序高出一步。它们具有更快的部署周期,在抽象云基础架构的同时可进行扩展,并且大量维护工作在您自己的组织之外处理。

尽管如此,当前的Serverless调试标准仍有很多不足之处。通过单独的行进行调试要么受到限制,要么不可用,而过于复杂的日志记录是许多开发人员认为可以弥补这一缺点的唯一选择。最重要的是,您面临着与微服务更常见的相同挑战:多个配置、多组权限,以及在设置这些设置时出错的更多机会。