Cloud Endpoints 架構總覽

Endpoints 是分散式 API 管理系統，其中包含服務、執行階段和工具。Endpoints 可提供管理、監控和驗證功能。

構成 Endpoints 的元件包括：

  • 可擴充服務 Proxy (ESP) 或可擴充服務 Proxy V2 (ESPv2)：用於插入 Endpoints 功能。

  • Service Control：用於套用 API 管理規則。

  • Service Management：用於設定 API 管理規則。

  • Google Cloud CLI：用於部署和管理。

  • Google Cloud 控制台：用於記錄、監控和共用。

Endpoints 架構

Endpoints 架構

Endpoints 元件

ESP

ESP 是一種 NGINX Proxy，可在後端的前面執行，並可置入各種 Endpoints 功能 (例如驗證、監控和記錄)。ESP 會從 Service Management 擷取服務設定，並利用該設定來驗證傳入的要求。

ESP 經過設計，適合部署於容器化環境中，並可驗證 JWT 和 Google ID 符記。此外，還採用各種技術，例如重度快取和非同步呼叫，以保持簡易性和高效能。

ESP 支援下列平台：

ESPv2

ESPv2 是一種以 Envoy 為基礎的高效能且可擴充的 Proxy，會在 OpenAPI 或 gRPC API 後端的前面執行。ESPv2 上的 Endpoints 支援第 2 版的 OpenAPI 規範和 gRPC 規範。

ESPv2 可與 Google 服務基礎架構整合，以便大規模啟用 API 管理功能，包括驗證、遙測報表、指標和安全性。

ESPv2 支援以下平台：

服務控制

Service Control 會在執行階段套用 API 管理規則，例如金鑰驗證、監控和記錄。Service Control 提供下列方法：

  • 檢查：確認驗證和 API 金鑰，並指示是否應允許某個呼叫

  • 報告：向系統通報記錄和監控功能的相關記錄

服務管理

您將使用 OpenAPI 規格以稱為 Endpoints 設定的文字檔來描述 API 的介面和行為。您將利用會設定 API 管理規則的 gcloud CLI，將 Endpoints 設定部署到 Service Management。其他設定相關工作也會在這裡進行，例如與其他開發人員共用您的 API、在不同的專案中啟用或停用 API，以及產生 API 金鑰。

gcloud CLI

gcloud CLI 提供 Google Cloud CLI，可用來呼叫各種 Google Cloud 服務。您可以使用 Google Cloud CLI，將 Endpoints 設定部署到 Service Management。

Google Cloud 控制台

Google Cloud 控制台是Google Cloud的圖形使用者介面。Endpoints 會使用Google Cloud 主控台公開由 ESP 或 ESPv2 傳送並由 Service Control 記錄的監控和記錄資料，也會透過這個主控台與其他開發人員共用 API，方便他們產生 API 金鑰來呼叫 API。

部署情境

部署選項會因使用 ESP 或 ESPv2 做為 Endpoints 代理而異。ESPv2 可部署為遠端 Proxy，ESPv2 和 ESP 則可在 Sidecar 模式下部署，如後續章節所述。

遠端 Proxy 模式

如果使用 ESPv2，Endpoints 可部署為遠端 Proxy。這個模式可用於支援在無伺服器平台上執行的應用程式，例如 Cloud Run、Cloud Run 函式和 App Engine 標準環境。

在這個模式中，ESPv2 會以 Cloud Run 應用程式的形式部署。應用程式會使用 OpenAPI 服務設定中的 x-google-backend 欄位，將 ESPv2 設為遠端後端。在這種部署模式中，如果 ESPv2 用於遠端 Proxy，則可支援多個遠端後端。

詳情請參閱「設定 Endpoints」。

側車模式

ESP 和 ESPv2 都支援在容器中部署，並與後端的每個執行個體搭配使用。這個伺服器/本機拓撲非常適合用於網路端的 API 以及微服務。ESP 可避免常與集中式 Proxy 相關聯的網路躍點，也可以讓 API 管理功能維持高度的效能與擴充性。

通常在流量到達 ESP 或 ESPv2 之前，系統就會套用負載平衡功能。在 App Engine 上，負載平衡功能會自動執行。在 Compute Engine 上，這項作業是透過 Cloud Load Balancing 來完成。針對 Kubernetes 部署作業，您可以使用輸入 Proxy 來進行負載平衡。在 Google Kubernetes Engine 中，您可以使用 Cloud Load Balancing 或輸入 Proxy 來進行負載平衡。

ESP 或 ESPv2 在啟動時會從 Service Management 取得自己的服務設定。服務設定是利用 OpenAPI 規格或 gRPC (服務設定 YAML 檔案) 產生。此設定會告知 ESP 或 ESPv2 要代管的 API 介面及代管政策，例如哪些方法需要驗證，以及哪些需要 API 金鑰。

轉送要求

收到要求後，ESP 或 ESPv2 會為 Cloud Trace 建立追蹤記錄符記。

接著，ESP 或 ESPv2 會比對傳入要求的路徑與 API 介面。找到相符的路徑後，ESP 或 ESPv2 會針對指定方法執行任何驗證步驟。

如果必須進行 JWT 驗證，ESP 或 ESPv2 會使用簽署者的適當公開金鑰進行驗證，並驗證 JWT 中的目標對象欄位。如果需要 API 金鑰，ESP 或 ESPv2 會呼叫 Service Control API 來驗證金鑰。

Service Control 會查詢金鑰以進行驗證，並確保與金鑰相關聯的專案已啟用 API。如果金鑰無效或專案尚未啟用 API，則會拒絕呼叫，並透過 Service Control API 進行記錄。

如果 Service Control 成功驗證金鑰，系統即會將要求以及所有原始標頭和 JWT 驗證標頭 (如適當) 轉送至後端。

當 ESP 或 ESPv2 收到後端的回應時，就會將該回應傳回給呼叫端，並將最後的時間資訊傳送到 Trace。系統會透過 Service Control API 記錄呼叫點，該 API 會將指標和記錄寫入適當的目的地。

Kubernetes 上的 ESP 或 ESPv2

下圖顯示了整體架構，其中 ESP 位於 API 服務應用程式容器的前面，以補充容器的形式執行，而 my-api API 由 my-api.com 託管並由 Kubernetes 服務提供支援。使用 ESPv2 的附加元件部署架構會相同。

Kubernetes 上的 Endpoints 總覽

後續步驟