哪種 GCP 解決方案應該用於無限壽命/長時間運行的流程？

Question

我目前在 Heroku 上托管，它以一種需要顯式代碼更改才能將事情放入作業隊列的方式處理長時間運行的進程。 我不想像作業隊列那樣進行顯式代碼更改，所以我想將這個特定的塊移出。

我有一個Gmail.users.watch email 觀察者在那里運行，我想將它移到 GCP，因為 Heroku 似乎遇到了R15 - Vastly exceeded memory quota錯誤。 我相信這是因為對於 Heroku 處理的每個請求，它都會生成一個長期運行的Gmail.users.watch進程的新實例。 （編輯：開個玩笑，這是 memory 泄漏）

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 似乎是一個啟動的單一虛擬機，但似乎也用於繁重的計算負載，而不僅僅是一個 email 觀察者，所以它可能有點矯枉過正。
   • Google Kube.netes 引擎似乎在處理托管時考慮了 Docker，但這似乎過於復雜，因為我必須指定幾乎所有內容。
2. 我應該使用不是上述三個之一的其他 GCP 解決方案嗎？

我的直覺告訴我 Google Compute Engine，但我只是希望有人為我確認； 你到底把這樣一個無限生命周期的過程放在 GCP 的什么地方。

Answer 1

如果您選擇 Google Compute Engine，您可能會因管理自己的 VM 而產生一些不必要的開銷。 對於您描述的用例來說，它不應該那么復雜，但它可能會產生一些意外的驚喜。
使用 VM 的好處是，您可以通過實施某種垃圾收集器來清理死進程或什至每隔一段時間重新啟動機器來解決 memory 泄漏。

話雖如此，您問題的真正解決方案可能是解決您遇到的 memory 泄漏。 在大多數情況下，這比將您的應用程序遷移到新平台需要更少的努力。