InfoQ最近与Gojko Adzic进行了一次访谈,谈到了他最近设计的项目Claudia.js。这是一个JavaScript工具,能够帮助用户将Node.js微服务应用部署至Amazon Web Service(AWS)Lambda。Claudia.js可通过一个单一的命令进行AWS Lambda函数与Web API的部署、自动处理IAM角色传递的等待过程、配置console.log的输出以传送至CloudWatch、并且简化了AWS Lambda函数在生产环境、开发环境与测试环境上的版本管理工作。
AWS Lambda是一种计算服务,它对传入的事件进行响应并运行相应的代码,并且能够自动管理底层的计算资源。AWS Lambda可自动地运行代码以响应各种事件,例如某个Amazon S3 bucket中的数据改动、Amazon DynamoDB数据表的修改、或是对于Amazon API Gateway传入的HTTP请求进行响应(此即所谓的“serverless”架构)。
Adzic是Neuri Consulting LLP的合伙人之一,他认为AWS Lambda的部署可能会因为牵涉的步骤太多而显得过于复杂。因此他创建了Claudia.js,通过这个工具可以简化Lambda函数的创建或更新。Claudia.js不仅支持通过单一的命令部署基于Node.js的“微服务”AWS Lambda应用,还实现了各种复杂任务的自动化,比如它允许将console.log的输出传送至CloudWatch中,并且对Amazon API Gateway资源进行配置,使其行为更符合JavaScript开发者的预期。
InfoQ与Adzic进行了一次访谈,谈到了Claudia.js的开发过程、创建这门工具的动力和它的目标、以及使用AWS Lambda处理生产环境中的实际负载的可行性。
InfoQ:你好Gojko,感谢你今天能够抽空与InfoQ进行这次对话。你能否为我们介绍一下由你创建的新型微服务部署项目Claudia.js?
Adzic:Claudia.js能够自动化部署工作流,并且简化了让JavaScript代码在AWS Lambda中正常运行所必须进行的一些容易出错的任务,让开发者能够专注于解决重要的问题,而无需担任AWS服务本身。通过Claudia所配置的部署过程是按照JavaScript开发者所预期的方式运行的,使这些开发者更适应Claudia的使用。在Claudia中只需不到5分钟就能够创建并部署一个简单的HTTP终结点,可以观看这个视频以了解整个过程。
AWS Lambda与API Gateway为用户提供了按需扩展、零运维操作以及几乎免费的执行,按使用量收费的功能。他们确实是在运行服务端代码方面很有力的竞争者。但是,整个配置过程显得过于繁琐,尤其是对于简单的场景来说更为明显。由于其运行时是针对运行Java代码而设计的,因此如果用户需要运行Node.js功能,就必须解决大量的问题,并且在这方面缺乏良好的文档说明。
Claudia.js为用户解决了以上所有问题。举例来说,在传统方式下,将一个JavaScript方面暴露为Web API需要编写约120行shell脚本,而这一切在Claudia中可以由一个单一的命令代替。
InfoQ:Claudia的总体目标是什么,有哪些方面不属于Claudia的目标?举例来说,有关微服务的工具不断涌现,包括Seneca.js、go-kit和Spring Cloud,不过Claudia似乎特别专注于应用的部署?
Adzic:目前来说,微服务在云环境上的应用正在蓬勃发展,新的框架与工具不断涌现。你之前提到的工具多数都属于框架的范畴,它们帮助用户逐步实现标准的通信任务、完成工作的分布以及服务发现。这些功能对于我们的使用场景来说有些过度了。我们只希望运行一些简单的东西,例如响应用户的GET与POST请求、在S3中处理文件,或是操作AWS SQS/SNS队列中的消息。AWS服务已经足够完成这些任务了,我们也不介意直接调用这些服务。
在我们从Heroku平台进行迁移时遇到了一个大问题,即每次迁移都需要进行大量的样板式的配置工作,这种工作即复杂又容易出错。我们并不想改动组织代码、组织项目、连接到服务以及对AWS的功能进行抽象的方式。我们所需的仅仅是让代码能够可靠地、快速地在Lambda中运行。
而Claudia完全符合我们的目标,它为用户承担了所有重复的配置工作,使代码的配置得到了大大的简化。同时,在将现有的API迁移为Lambda时,Claudia几乎不会为用户带来任何负担。它负责收集所有查询字符串、表单提交以及请求头信息,使它们易于在JavaScript代码中进行访问。它对于处理流程进行了适当的配置,让其更符合JavaScript API的期望,并让用户决定如何通过代码实现所需的功能。
InfoQ:与通过标准的方式将应用部署至AWS Lambda相比,使用Claudia进行部署有哪些不同?它与由Mitch Garnaat所设计的“Kappa”工具又有何不同?
Adzic:Claudia同样使用标准方式将应用部署至AWS
Lambda中,它只是将所有样板式的过程实现了自动化。我的想法是不要引入过多的新鲜特性,因此我们使用了标准的AWS Node.js SDK以完成所有工作。它能够帮助用户专注于要解决的问题,而无需死记硬背AWS API调用的顺序、以及各种必须遵循的安全策略。Kappa的功能与Claudia非常相似,但它是针对Python的。此外还有一些针对其他语言的类似的部署工具,例如Apex等等。但我并没有找到一种能够很好地处理JavaScript的工具。泛用的框架虽然能够支持更多类型的运行时,但必须由开发者负责处理各种特定于语言的问题。当我们尝试在Lambda中运行JavaScript时,就遇到了大量特定于语言的问题。
Claudia只支持JavaScript/Node.js环境,但它在这方面的表现非常出色。由于Claudia专注于Node.js,因此它能够自动安装各种模板,将参数与结果转换为可以通过JavaScript轻松调用的对象,并且使它的工作方式符合JavaScript开发者的预期。举例来说,标准的错误报告仍将返回HTTP代码200,这对于Java来说并非什么严重的问题,但它会使多数JavaScript Promise HTTP库无法正常工作。Claudia会自动对API Gatway进行配置,使其返回HTTP 500。
InfoQ:你能否描述一下创建Claudia.js的动力是什么?它是否是一个大型项目中的一个组成部分?
Adzic:在开发MindMup 2.0时,我们开始将后端代码从Heroku迁移至AWS Lambda,为此我们收集了大量的检查清单与故障诊断方面的诀窍,让整个迁移过程更加顺利。而Claudia则通过一个易于使用的API为用户实现了这些任务的自动化。
今后,我们还计划将所有服务端代码都迁移至Lambda上。MindMup 2.0本质上就是一个单一的HTML文件,它通过一个CDN服务展现给用户,通过一些后端API实现动态功能。这使我们能够轻易地支持大规模的用户使用。
InfoQ:你认为AWS Lambda是否已经准备好应用在生产环境中了?如果确实如此,它的典型使用场景又包括哪些?
Adzic:对于我们来说,Lambda出色地完成了我们所需的功能。但其他项目或许会遇到一些不同的限制,因此“准备好应用在生产环境中”这种说法完全取决于你的上下文。在我看来,它可以成为相对隔离式的服务端处理方式的一种良好的替代产品。在服务端处理中产生一到两秒的延迟没什么问题,但吞吐量、并行执行以及按需伸缩等属性则显得非常重要。这方面的例子包括文件转换、处理用户文件上传、发送通知、调度任务、以及认证或验证。
Lambda的竞争优势在于无需管理员的干预而实现自动伸缩且按使用量收费。如果代码本身需要大量的管理性工作,那么使用该工具的意义并不大。而如果应用的延误需要限制在微秒级,那么Lambda(目前来说)或许并非你最佳的选择。
InfoQ:你是否期望用户能够帮助你完善这个项目?如果这样,最好的贡献方式是什么?
Adzic:当然了。Claudia是一个开源项目,我相信一定有许多其他开发者也在考虑迁移至云代码执行环境。目前来说,它满足了我们所需的一切功能,但如果其他人愿意参与这一项目,我们可以将它改造得适应更广泛的使用场景。项目的代码托管在GitHub上,最佳的贡献方式是创建一个fork并提交pull request。该项目的GitHub库地址是https://github.com/claudiajs/claudia。
InfoQ:再次感谢你能够参与这次谈话。还有哪些内容是你希望分享给InfoQ的读者的吗?
Adzic:总的来说,如果你希望创建一些简单的服务,并且运行在AWS Lambda中。或者是你正在寻找一些开销较低的、易于上手的工具,并且只希望使用Node.js运行时,那么Claudia是一个很好的选择。如果你希望使用SDK、对于服务的分布、分配或是发现功能具有细粒度的控制能力,或是能够支持不同类型的运行时等等,那么建议你去寻找其他的替代工具。
在Claudia.js项目的GitHub库上可以找到关于该项目的更多信息,Adzic也创建了一个三分钟的视频“介绍Claudia.js”,提供了对该工具应用方式的一个高层次的概述。
查看英文原文:Deploying Node.js Microservices to AWS Lambda with Claudia.js: Q&A with Author Gojko Adzic