託管 Webhook 目標

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

Cloud Run 提供不錯的解決方案，可用於託管 webhook 目標。Cloud Run 提供更大的彈性，並可透過並行處理處理更大量的資料。

在 Cloud Run 服務中託管 Webhook 目標，最適合下列情況：

  • 您希望要求逾時時間更長 (最多 15 分鐘)
  • 預期大量流量，且需要並行處理能力 (每個執行個體 80 個並行要求)

在 Cloud Run 中建立 Webhook 目標

您可以使用 Cloud Run，以任何語言定義 webhook 目標。您只需建立可接受資料的 HTTP 端點即可。通常會使用 POST 執行這項操作，例如：

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

在這個範例中，URL 的索引頁面會設為只接受 POST 要求，並預期資料會透過 JSON 酬載傳送。

與 Webhook 供應器整合

提供 HTTP 回呼的服務大多會要求您驗證網址擁有權。這通常是透過傳送某種權杖、訊息或密鑰，並預期有效回應的方式完成。您必須向服務供應商取得這些要求。使用上述範例的 webhook 目標，這可能會如下所示：

def index():
    data = request.get_json()
    return data['challenge']

供應商驗證你的擁有權後，你也必須在自己的端新增授權。

授權要求

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

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

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

def index():
    request_secret = request.headers['Secret']
    if request_secret != os.environ['SECRET']:
        return ('Unauthorized', 401)

如果 webhook 供應商不支援密鑰或其他驗證機制，任何擁有 webhook 目標網址的使用者都能傳送訊息。在這種情況下，您實作的 webhook 應可安全地公開至網際網路。

回覆要求

大部分服務都會要求您在服務指定的時間內回應要求。如果發生錯誤回應 (例如 HTTP 狀態碼為 4xx 或 5xx)，某些 webhook 會採用內建的重試方法，因此您需要傳回成功的狀態碼 (2xx)，讓服務知道事件已正確處理。

def index():
    data = request.get_json()
    return ('', 200)

逾時

Cloud Run 和 Webhook 供應商都設有逾時限制。兩者中較短的時間會套用至您的應用程式。如果資料處理時間超過 Cloud Run 或 webhook 供應商分配的時間，您就必須使用可讓您以非同步方式完成處理的產品，例如 Pub/Sub 或 Cloud Tasks。這些產品可讓您快速移交資料、立即向 webhook 供應商傳回成功回應，並繼續處理，不必擔心逾時問題。這些也是處理失敗和重試情況的好方法。

常見的 webhook 模式

類型 範例
轉送資料 每次呼叫 webhook 時，透過 Firebase 雲端通訊傳送通知。
儲存資料 將資料儲存在 BigQuery 中，以利日後分析。
觸發動作 在 GitHub 中提交新程式碼時，在 Dialogflow 上執行動作、在 Twitter 上發布回覆，或將程式碼推送至測試環境。

後續步驟