【问题标题】:Best practice for connecting to Google Cloud SQL instances from GCF [closed]从 GCF 连接到 Google Cloud SQL 实例的最佳实践 [关闭]
【发布时间】:2020-12-25 02:08:18
【问题描述】:

我正在寻找关于如何从我的 GCF 函数中最好地设置对云 Sql 的数据库访问的最佳实践。我正在编写一个应用程序,在该应用程序中我大量使用 Google Cloud Functions 进行业务逻辑,并且正在使用 Google Cloud SQL (Postgres)用于后端数据库。数据库在 postges 服务器的多个实例上分片。

关于如何最好地连接,似乎有两种选择。

  1. GCF 允许直接访问 Cloud SQL。在这种情况下,我似乎可以为用于执行查询的函数创建一个连接池,但由于我不知道该函数将在内存中保留多长时间,因此不清楚要配置多少个连接。我不确定这将如何工作?我知道每个函数一次使​​用 1 个连接,但是这将如何扩展?如果我收到大量查询,这会成为瓶颈吗?为了获得最佳效率,我肯定想使用某种连接池。

  2. 我可以使用 postgres 客户端库创建一个专用的 http 服务器(我使用 node.js),并让 GCF 函数调用 http 服务器,该服务器又调用 Cloud SQL。该服务器可以处理连接池并全天候 24/7 运行,并且在扩展大量查询时似乎更自然。但是,它确实在此过程中添加了额外的网络调用。我可以在 Google Cloud Run 中运行它或通过 app-engine 设置。

我正在寻找可以提供最佳性能并随着我的应用扩展而扩展的最佳实践。

我曾尝试在网上对此进行研究,但没有找到任何关于什么是最好的真正建议或文章……只是“如何”文章。

感谢任何反馈。

【问题讨论】:

    标签: google-cloud-functions google-cloud-sql google-cloud-run


    【解决方案1】:

    这是我对您的建议的建议

    1. 一个函数一次只能处理一个请求。根据您的代码设计,但如果您不同时管理数据库请求,则您的函数中需要一个包含 1 个连接的池。 (如果您的代码管理多达 10 个对数据库的并发请求,请创建一个 10 个池)。然后,将此池放入一个全局变量中。第一次使用它时,初始化池(像这样执行延迟加载,比减少冷启动的急切加载更好)并使用它。每次创建 Cloud Functions 实例时,都会初始化池。每次销毁实例时,池都会关闭。如果数据库连接是瓶颈,您可以使用 Cloud Functions 上的最大实例参数来保留您的数据库。

    2. 这不是一个好主意。你添加了一个新层,一个新的潜在故障点,你需要维护、更新、修补这个虚拟机……我不建议你这样做。

    我希望我已经回答了你的问题。如果没有,请评论它

    【讨论】:

    • 感谢您的回复。在深入研究之后,我决定将我的云功能移动到我可以部署在 Cloud Run 上的 node.js 服务器中。它解决了连接池的问题,并消除了我在 GCF 上使用冷启动时遇到的问题。
    • Cloud Run 和 Cloud Functions 在相同的底层基础架构上工作。它们的行为(放大和缩小)完全相同。我对池的建议也是有效的(使用全局变量、延迟加载...),但这次将池设置为 80,因为 Cloud Run 最多可以管理 80 个并发请求(除非您更改并发参数)。 max-instance 参数也在这里保存和保存您的数据库连接池,以防大规模扩展。
    猜你喜欢
    • 2021-12-25
    • 1970-01-01
    • 2018-07-26
    • 2010-10-11
    • 2013-02-16
    • 1970-01-01
    • 1970-01-01
    • 2014-06-22
    • 1970-01-01
    相关资源
    最近更新 更多