【问题标题】:Which GCP solution should be used for an infinite-lifespan/long-running process?哪个 GCP 解决方案应该用于无限寿命/长期运行的过程?
【发布时间】:2020-07-27 17:39:17
【问题描述】:

我目前在 Heroku 上托管,它以需要显式更改代码以将内容放入作业队列的方式处理长时间运行的进程。我不想像作业队列那样做显式的代码更改,所以我想把这个特定的块移出。

我在那里运行了一个Gmail.users.watch 电子邮件观察程序,我想将其移至 GCP,因为 Heroku 似乎在我的代码中遇到了R15 - Vastly exceeded memory quota 错误。我相信这是因为 Heroku 处理的每个请求都会生成一个长期运行的 Gmail.users.watch 进程的新实例。 (编辑:开玩笑的,这是内存泄漏)

const beginWatcher = () => {
    gmail.users.watch(
        {
            auth: authClient,
            userId: "me",
            requestBody: {
                topicName: topicURL,
                labelIds: ["INBOX"]
            }
        },
        (error) => {
            if (error) {
                console.log(error)
                return
            }
        }
    )
}

beginWatcher()

我没有太多从零开始的 GCP 经验,我想知道;

  1. 像上面这样长时间运行的进程在 GCP 中的什么位置?
    • Google App Engine 似乎基本上是 Heroku,但我相信服务器的单个实例是我需要的,它可以像上面的代码一样永远运行。
    • Google Compute Engine 似乎是一个启动的单个 VM,但似乎也用于处理繁重的计算负载,而不仅仅是一个电子邮件观察程序,因此它可能有点矫枉过正。
    • Google Kubernetes Engine 似乎在处理托管时考虑到了 Docker,但这似乎过于复杂,因为我必须指定几乎所有内容。
  2. 我应该使用不是上述三种解决方案之一的其他 GCP 解决方案吗?

我的直觉告诉我 Google Compute Engine,但我只是希望有人为我确认; 你在 GCP 中将这样的无限生命周期进程放在哪里

【问题讨论】:

    标签: heroku google-cloud-platform gmail-api


    【解决方案1】:

    如果您选择 Google Compute Engine,您可能会在管理自己的 VM 时产生一些不必要的开销。对于您描述的用例,它不应该那么复杂,但它可能会产生一些意外的惊喜。
    使用 VM 的好处是,您可以通过实现某种垃圾收集器来解决内存泄漏问题,该垃圾收集器将清理死进程,甚至每隔一段时间重新启动一次机器。

    话虽如此,您问题的真正解决方案可能是解决您遇到的内存泄漏问题。在大多数情况下,这比将您的应用迁移到新平台所需的工作量更少。

    【讨论】:

      猜你喜欢
      • 2016-02-23
      • 2012-02-22
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-12-28
      • 1970-01-01
      • 2013-04-18
      • 1970-01-01
      相关资源
      最近更新 更多