我們正在公司開始一個新專案，我們基本上每天兩次為每個客戶運行幾個 Python 腳本。因此，我們的想法是，每天將觸發兩次 Cloud Function，其中該函式將為每個客戶端觸發 Python 腳本，創建 App Engine / Cloud Run 或 Google 提供的任何其他無服務器服務的新實體。
一開始我們想使用 Cloud Functions，但很快我們發現它們不適合長時間運行的 Python 腳本，這些腳本最終會為每個客戶端計算和收集不同的資訊并將它們寫入 Firebase。
流程將是：Cloud Function 觸發 -> 每個客戶端的函式觸發 GCP 實體 -> 為每個客戶端運行的腳本 -> 輸出被保存到 Firebase。
如果沒有專用服務器，推薦的方法是什么，哪些 GCP 無服務器服務最適合？
uj5u.com熱心網友回復：
有很多很棒的答案！這里的關鍵是解耦和分發處理。
當您談論解耦時，您可以使用 Cloud Task（您可以在其中添加具有速率限制的流量控制或在將來推遲任務）或 PubSub（更簡單的訊息佇列解決方案）。
Cloud Run 要求運行長達 15 分鐘的處理。但是您必須對其進行微調（請參閱下面的提示）
所以，總結一下程序
- 您必須每天觸發兩次 Cloud Functions。您可以為此使用 Cloud Scheduler。
- 觸發的 Cloud Functions 獲取客戶端串列（在資料庫中？），并為每個客戶端在 Cloud Task 上創建一個任務（或在 PubSub 中創建一條訊息）
- 每個任務（或訊息）呼叫 Cloud Run 上的一個 HTTP 端點，該端點為每個客戶端執行該程序。在 Cloud Run 上將超時設定為 30 分鐘。
但是，如果您的處理是計算密集型的，則必須調整 Cloud Run。如果在 1vCPU 上處理 1 個客戶端需要 15 分鐘，這意味著如果您不想達到超時，則每個 CPU 不能處理超過 1 個客戶端（2 個客戶端可能會導致您在相同的 CPU，您可以達到超時）。為此，我建議您將 Cloud Run 的并發引數設定為 1，一次只處理一個請求（當然，如果您在 Cloud Run 上設定了 2 或 4 個 CPU，您也可以將并發引數設定為 2 或 4允許在同一實體上進行并行處理，但在不同的 CPU 上）。
如果處理不是 CPU 密集型的（您執行 API 呼叫并等待答案），則很難說。嘗試使用 5、10、30 的并發...并觀察已處理請求的行為/延遲。不用擔心，使用 Cloud Task 和 PubSUb，您可以設定超時重試策略。
最后一件事：你的處理是冪等的嗎？我的意思是，如果您為同一個客戶端運行 2 次相同的行程，結果是正確的還是有問題？嘗試使解決方案具有冪等性，以克服分布式計算（包括重播）上可能發生的重試問題和全域問題
uj5u.com熱心網友回復：
@NoCommandLine 的回答是最好的建議，如果您想設定更長的運行時間，Cloud Run 也是一個不錯的選擇，因為超時可以設定在 5 分鐘（默認）和 60 分鐘之間。您可以通過Cloud Console、命令列或 YAML設定或更新請求超時。
同時，Cloud Function 的執行時間只有 1 分鐘（默認），最長可以設定為 9 分鐘。
您可以查看以下完整檔案：
- 請求 Cloud Run 超時
- 請求云功能超時
您還可以通過此鏈接檢查相關的 SO 問題。
uj5u.com熱心網友回復：
您可以使用Cloud Tasks執行“長時間”運行的 Google App Engine (GAE)任務。
多長時間（這就是我用引號引起來的原因）取決于您用于 GAE 專案實體的縮放型別。設定為“自動擴展”的實體最長限制為 10 分鐘，而設定為“手動”或“基本”的實體最長執行時間為 24 小時。
從之前的鏈接
....所有作業人員必須向 Cloud Tasks 服務發送 HTTP 回應代碼 (200-299)，在此實體中，在基于服務的實體擴展型別的截止日期之前：自動擴展為 10 分鐘，最多為 24 小時手動縮放。如果發送了不同的回應，或者沒有回應，則重試該任務....
添加更新（30 分鐘和 24 小時之間似乎有些混淆）
標準 HTTP 請求的最長執行時間為 30 分鐘（來源），而如果您使用手動擴展，GAE 端點最多可以運行 24 小時（來源）
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/423128.html
標籤：
上一篇：無法匯入pyrebaseGAE