创建多个轻量级Google Cloud Functions的最佳实践?

bal*_*ton 5 google-cloud-functions

Google Cloud Functions的工作方式如下:

  • 您的模块放在functions目录中
  • functions然后,该目录包含一个package.json文件,以包含所有模块之间的共享依赖关系
  • 每个模块可以包含许多导出的功能
  • 谷歌云函数和firebase函数对如何处理模块中导出的函数有不同的看法
    • 对于gcp,它的工作方式似乎是这样的:上传模块,然后通过Web界面或命令行指定应从加载的模块中调用哪个导出方法
    • 对于firebase,它的工作方式似乎是这样的:侦听器方法从firebase-functions返回处理程序,但还将触发器元数据附加到该处理程序。该firebase-toolsCLI应用程序,然后要求你的代码在本地,抓住导出的函数,然后基于从火力,功能材料及其连接的元数据每个导出方法创建的云功能。这样,如果将所有云功能放在同一模块中,则它将为每个云功能多次部署该模块,并且对于每个云功能,将加载整个模块,然后调用特定的导出功能。
  • 如果将导出的功能配置为http触发器,则它将使用undefined.express.js版本,以及捆绑的中间件的数量和顺序是不确定的

这很奇怪,因为:

  • 说即使模块one.jstwo.js在运行时需要不同的软件包,package.json它们之间的共享也意味着它们的启动时间将比单独完成要慢,因为它们都需要安装软件包的所有依赖项,而不仅仅是安装它们自己的依赖项
  • 如果内部有多个导出的函数index.js(例如hi()和)hello(),那么即使不使用它,cloud函数也将在内存中加载hihello()函数,而即使不使用它,hellocloud函数也将hi()在内存中加载,对于生成的云函数仍将使用相同的index.js文件,即使不需要其他部分,也将模块内的所有内容加载到内存中

因此,确保您的云功能以最轻的运行时占用空间最佳运行的最佳实践是什么?看起来Google的设计决策意味着您做出的云功能越多,则每个云功能捆绑的杂物就越多,这会使它们变慢并增加成本。


顺便说一句,在我看来,这对于Google来说是一种更好的方法:每个云函数都应该有自己的目录,并且在每个目录中都有一个package.json文件和一个index.js文件。然后index.js文件执行module.exports = function(...args){}export default function(...args){}

这样,架构与人们期望云功能的运行方式保持一致-是云功能代表一个功能-而不是云功能是所有云功能之间共享依赖项的安装,然后是可以包含多个云功能,但只使用其中一个,然后从已加载的模块中仅执行一个功能。

有趣的是,Azure Functions似乎完全按照我期望云函数运行的方式进行设计:https : //docs.microsoft.com/zh-cn/azure/azure-functions/functions-reference-node

Fil*_*ipe 3

我正在使用 modofun ( https://modofun.js.org ),它是一个基于请求路径进行多个操作的路由器。这使我能够将相关函数收集到作为单个 Google Cloud Function 部署的模块中。该模块中所有函数的依赖关系都是相同的,因此它具有高效的依赖关系。您还可以共享通用的全局资源,例如数据库连接。

我同意单独部署每个功能会浪费资源,而且很难维护。

我为生产中的 Google Cloud Functions 部署执行了此操作。

  • 您可以从同一代码中导出多个函数,但是在部署云函数时,您需要指定应使用哪个导出的函数。如果有多个,则需要多次部署相同的代码,但每次使用不同的导出函数都有处理程序。所以这是非常浪费的,每个函数都必须从冷开始,即使它们都共享相同的代码。我认为谷歌很快就会发布某种形式的 API 管理,这将允许更好地使用多种功能。 (4认同)