託管 Webhook 目標

本指南說明如何在 Cloud Run 服務中託管 Webhook 目標。

Cloud Run 提供適合代管 Webhook 目標的解決方案。Cloud Run 具有更高的彈性,可處理大量並行作業。

在 Cloud Run 服務中託管 Webhook 目標,非常適合下列情境:

  • 您希望要求逾時時間更長 (最多 60 分鐘)
  • 預期會有大量資料,且需要並行處理 (每個執行個體最多 1000 項並行要求)

在 Cloud Run 中建立 Webhook 目標

您可以使用 Cloud Run,以任何選擇的語言定義 Webhook 目標。您只需要建立可接受資料的 HTTP 端點即可。這項作業通常是透過 POST 執行,例如:

from flask import Flask, request
app = Flask(__name__)

@app.route('/', methods=['POST'])
def index():
    data = request.get_json()
    return ('', 200)

在本範例中,網址的索引頁面已設定為只接受 POST 要求,並預期透過 JSON 酬載傳送資料。

與 Webhook 供應商整合

提供 HTTP 回呼的大部分服務都會要求您驗證網址擁有權。 通常是傳送某種權杖、訊息或密碼,並等待有效回應。您必須向服務供應商索取這些規定。使用上述範例的 Webhook 目標,這看起來可能像這樣:

@app.route('/', methods=['POST'])
def index():
    data = request.get_json()
    return data['challenge']

供應商驗證擁有權後,您也必須在自己的帳戶中新增授權。

授權要求

Webhook 目標是公開的開放式網址。大多數服務都會提供符記或密鑰,確保傳入的要求來自授權服務。由於網址是公開的,您無法防止惡意嘗試將資料傳送至 Webhook 目標。不過,使用權杖或密鑰可確保您只處理來自授權來源的資料。

如要驗證要求,您可以設定密鑰,或將密鑰副本儲存為環境變數,或使用某種金鑰管理系統。

將密鑰副本儲存為環境變數時,每個要求都應在要求標頭或 JSON 酬載中包含密鑰或權杖,且您必須檢查密鑰或權杖,確保來源有效。

import os
from flask import request

@app.route('/', methods=['POST'])
def index():
    request_secret = request.headers.get('Secret')
    if request_secret != os.environ.get('SECRET'):
        return ('Unauthorized', 401)
    return ('', 200)

如果 Webhook 供應商不支援密碼或其他驗證機制,只要知道 Webhook 目標網址的人都能傳送訊息。在這種情況下,您的 Webhook 實作項目應可安全地公開至網際網路。

回覆要求

大多數服務都會規定您必須在指定時間內回覆要求。如果發生錯誤回應 (例如 HTTP 狀態碼為 4xx 或 5xx),部分 Webhook 會內建重試方法,因此您需要傳回成功狀態碼 (2xx),讓服務知道事件已正確處理。

@app.route('/', methods=['POST'])
def index():
    data = request.get_json()
    return ('', 200)

逾時

Cloud Run 和 Webhook 供應商都有逾時時間。系統會採用較短的期限。如果資料處理時間超過 Cloud Run 或 Webhook 供應商分配的時間,您需要使用可非同步完成處理作業的產品,例如 Pub/SubCloud Tasks。這些產品可讓您快速交接資料、立即向 Webhook 供應商傳回成功回應,並繼續處理資料,不必擔心逾時問題。這些也是處理失敗和重試的理想選項。

常見的 Webhook 模式

類型 範例
轉送資料 每當呼叫 Webhook 時,使用 Firebase 雲端通訊傳送通知。
儲存資料 將資料儲存在 BigQuery 中,以供日後分析。
觸發動作 在 GitHub 中提交新程式碼時,在 Dialogflow 中執行動作、在 Twitter 上發布回覆,或推送到預先發布環境。

後續步驟