關於環境和環境群組

本頁內容適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

本節說明環境和環境群組。

總覽

Apigee 環境是組織內的軟體環境，用於建立及部署 API Proxy。您必須先將 API Proxy 部署至環境，才能存取該 Proxy。您可以將 API Proxy 部署至單一或多個環境。

每個環境可部署的 API Proxy、共用流程和其他資源數量都有限制。 這些限制會因使用環境的 Apigee 機構類型 (訂閱、隨用隨付或混合式) 而異。詳情請參閱「限制」說明文件。

環境群組 (有時在 Apigee API 中稱為「envgroup」) 是定義要求如何路由至個別環境的基本機制。您可以在環境群組中定義主機名稱 (而非個別環境)，Apigee 會使用這些主機名稱定義，將要求轉送至群組中的環境。

環境必須是至少一個環境群組的成員，您才能存取其中部署的 Proxy。換句話說，您必須先將環境指派給群組，才能使用該環境。

依環境群組邏輯分組環境有下列好處：

  • 集中管理主機名稱：環境群組提供集中管理主機名稱的位置。
  • 匯總洞察：您可以透過群組一次查看整個環境群組的報表，而非個別環境，藉此分析錯誤。
  • 避免衝突：將環境分組後，您就能確保已部署的 Proxy 的基本路徑位於相同的主機名稱下。

支援的部署類型

Apigee 支援環境中的下列部署類型：

類型 說明
Proxy 在 Apigee 開發環境中開發及測試 API Proxy，然後將其部署至 Apigee 整合測試和正式環境。請參閱「部署 API Proxy」。
封存 在 VS Code 中使用 Apigee 開發及測試可程式化 API Proxy。

封存部署作業時，系統會防止執行的動作摘要

在 Apigee 環境中啟用封存檔案部署功能後，為避免發生衝突，您將無法在該環境中執行下列動作：

  • 在 Apigee 使用者介面中，您無法查看、確認部署狀態或管理封存部署作業 (如「部署 API Proxy」一文所述)，也無法使用「偵錯」使用者介面 (如「使用偵錯」一文所述)。如要解決這個問題，可以使用 gcloud 或 API 列出環境中的所有封存部署作業，並使用 Debug API。
  • 您無法使用 Apigee UI、API 或 gcloud 建立、更新或刪除資源檔案或目標伺服器。
  • 目前不支援使用服務帳戶進行 Google 驗證。

如果您嘗試執行上述任何一項禁止動作，系統會顯示下列錯誤訊息，並導致動作失敗：

FAILED_PRECONDITION

Proxy 部署單元

Proxy 部署單位會計算部署至每個區域環境的 Proxy 和共用流程。

部署單元類型如下：

  • 標準 Proxy 部署單元會計算目前部署的 Proxy 數量，這些 Proxy 必須符合標準 Proxy 的資格。
  • 可擴充的 Proxy 部署單元會計算目前部署的 Proxy 數量，這些 Proxy 必須符合可擴充的 Proxy 資格。
  • 共用流程部署單元會計算已部署的共用流程數量。

您的用量可能受部署配額限制，也就是一次可使用的部署單元數量上限。詳情請參閱您的權益 (Pay-as-you-go或訂閱方案 2024)。如要瞭解系統限制，請參閱 每個執行個體可部署的 Proxy 部署單元數量上限。

如要進一步瞭解如何查看機構的 Proxy 部署單元用量和部署配額詳細資料，請參閱「查看 Proxy 部署用量」。

環境類型

如果是隨用隨付方案使用者，建立環境時請選取環境類型：「基礎」、「中級」或「完整」。 環境的相關功能、特性和費用取決於環境類型。 詳情請參閱「隨用隨付環境類型」和「隨用隨付授權」。

如果是訂閱方案，環境類型一律為「全面」，您不需要瞭解環境類型。

轉送 Proxy

Apigee 支援將流量轉送至指定 URI。這項功能適用於環境層級，可用於在 Proxy 中完成初始處理後，將流量導向網際網路。

設定環境中代理伺服器的傳入要求會針對任何納入的政策進行處理 (請參閱「正向代理功能支援」)，然後使用 HTTP 轉送至新 URI。

環境的轉送 Proxy 設定變更會立即生效，但只適用於新要求。系統會以收到要求時的設定，完成處理中的要求。

如需設定轉送 Proxy 的操作說明，請參閱「在環境中設定轉送 Proxy」。

支援轉送 Proxy 功能

並非所有正式發布的 Proxy 功能都適用於轉送 Proxy，或具有相同的適用性。

Apigee 目前不支援使用轉送 Proxy 進行基本驗證，但 Apigee Hybrid 除外。

下表顯示額外功能支援情形：

功能或政策 是否支援/適用於正向 Proxy？
目標端點 是
HTTP 健康狀態檢查 是
服務摘要 是
透過 JavaScript 發出的 HTTP 呼叫 是
整合目標 是
透過本機迴路進行 Proxy 鏈結 否
發布訊息 否
Cloud Logging 否
與同步處理工具通訊 否
透過系統記錄檔記錄訊息 否

轉送 Proxy 限制

目前不支援透過外部目標對象使用 Forward Proxying 傳送 GoogleToken。

重點

下表列出有關環境、機構和環境群組的重要注意事項：

元素 規則
組織
  • 可包含多個環境群組
  • 至少須有一個環境群組
環境
  • 必須至少屬於一個環境群組
  • 可屬於多個群組
  • 與同一群組中的所有其他環境共用主機名稱
  • 可將流量轉送至指定 URI
環境類型
  • 判斷該環境中可用的功能
  • 決定環境的價格

(請參閱「環境類型」一節)。
環境群組
  • 可有多個主機名稱
  • 包含一或多個環境
  • 指派給群組的主機名稱不得重複 (其他群組無法使用)

範例

以下各節說明環境群組中常見的環境結構。

一個環境群組和一個環境

最簡單的結構是單一環境群組，其中包含單一環境。如果機構目前正在評估產品，或尚未設定測試或分析基礎架構，且未在正式環境中部署任何 Proxy，就可能發生這種情況。

單一環境群組中的多個環境

環境群組可以包含多個環境。舉例來說，單一環境群組 prod-group 可以包含三個環境：cart-prod、catalog-prod 和 payment-prod。

環境群組只有一個主機名稱：example.com。您可以使用主機名稱，將要求轉送至部署在任一環境中的 Proxy。請注意，主機名稱是在環境群組層級定義，不會路由至特定環境。

如要瞭解如何建立這個環境群組，請參閱「使用環境群組」。

將路由限制為單一環境

在先前的範例中，要求可透過單一主機名稱，傳送至所有三個環境中的 Proxy。如要限制單一環境 (例如 catalog-prod) 中的 Proxy 存取權，請建立只包含 catalog-prod 環境的另一個環境群組。這樣一來，為該環境群組定義的主機名稱就只能存取 catalog-prod。

舉例來說，環境群組 catalog-prod-group 的主機名稱 catalog.example.com 只能將要求轉送至環境 catalog-prod 中的 Proxy。

 

準備好建立群組了嗎？

開啟主控台

 

 

如要進一步瞭解環境，請參閱下列文章：

繼續閱讀

 

 

如要進一步瞭解環境群組，請參閱下列文章：

繼續閱讀

 

路徑和基本路徑

在簡單的設定中，對已部署 API Proxy 發出的要求包含主機名稱、基本路徑和 API 資源名稱，例如：

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

您可以在環境群組中定義主機名稱，讓多個環境共用這些名稱。 API Proxy 會定義基本路徑和 API 資源。

如要進一步瞭解基本路徑和 API 資源，請先參閱「瞭解路徑」。此外，請參閱「流程設定參考資料」和「流程變數參考資料」，進一步瞭解這些元件如何搭配運作。

主機名稱

建立環境群組時，請將一或多個主機名稱附加至該群組。舉例來說，您可能會有下列環境群組，每個群組都有自己的主機名稱：

環境群組名稱
(環境)		 prod-group

(catalog-prod
cart-prod
pymnt-prod)		 dev-group

(dev-env)		 test-group

(test-env)
主機名稱 catalog.example.com
payment.example.com		 dev.example.com test.example.com

您可以在建立 Proxy 時定義 Proxy 的基本路徑。

將 Proxy 部署至群組中的環境時，主機名稱加上基本路徑和資源名稱，會共同定義傳送至該 Proxy 的 API 要求端點。

您可以在環境群組中定義多個主機名稱。這些方法都可用於呼叫部署至群組中任何環境的任何 Proxy。舉例來說，如果主機名稱 catalog.example.com 和 payment.example.com 定義在同一個環境群組中，catalog.example.com/proxy1 和 payment.example.com/proxy1 都會呼叫 proxy1 資源。

轉送範例

例如：

  • prod-group 環境群組包含下列環境：

    • catalog-prod
    • cart-prod
    • pymnt-prod

  • prod-group 定義了下列主機名稱：

    • catalog.example.com
    • payment.example.com

  • 下列 Proxy 會部署至這些環境：

    • catalog 上的 Proxy，基本路徑為 /catalogcatalog-prod
    • cart 上的 Proxy，基本路徑為 /catalog/cartcart-prod
    • payment 上的 Proxy，基本路徑為 /paymentpymnt-prod

這會建立下列端點：

  • catalog.example.com/catalog 會將要求轉送至 catalog-prod 環境中的 catalog Proxy。
  • catalog.example.com/catalog/cart 會將要求轉送至 cart-prod 環境中的 cart Proxy。
  • payment.example.com/payment 會將要求轉送至 pymnt-prod 環境中的 payment Proxy。

以下範例顯示要求會根據主機名稱和基本路徑，路由至部署在群組環境中的不同 Proxy：

根據主機名稱和基本路徑，將 API 要求轉送至群組內的不同環境

共用環境和轉送

一個環境可以屬於多個環境群組。如果您將 Proxy 部署到這類環境，Proxy 會有多個地址，每個地址對應環境所屬的環境群組。如果客戶有多個合作夥伴的萬用字元憑證 (例如 *.example.com)，這項功能就非常實用。

例如：

  • shared-env 屬於兩個環境群組：
    • partner-1 搭配主機別名 api.partner-1.com
    • partner-2 搭配主機別名 api.partner-2.com
  • Proxy foo 會部署至 shared-env，並使用基本路徑 /foo。由於兩個環境群組共用 shared-env，因此 foo 有兩個地址：
    • api.partner-1.com/foo
    • api.partner-2.com/foo

請注意，這兩個主機名稱都會導向相同環境。這樣一來，每個環境群組都會有專屬網域名稱。如果是 Apigee Hybrid，這個情境可以使用 mTLS，為每個合作夥伴提供不同的憑證。

關於環境範圍

機構會提供部分 Apigee 功能的範圍。舉例來說，您可以在機構層級提供鍵/值對應 (KVM) 資料，也就是說，部署至該機構內任何環境的 API Proxy 都可以存取相同的 KVM 資料。

同樣地，部分功能可限定於機構內的環境或環境群組。舉例來說，Apigee 數據分析資料會依機構、環境和 (最終) 環境群組的組合進行分割。

注意事項

部署至環境的每個項目，都有可能影響該環境所屬環境群組的流量路徑。新增基本路徑後，系統可能會開始擷取全新的流量，也可能開始擷取現有部署作業已處理的現有流量子集。

同樣地，移除基本路徑時，這些路徑可能對應到不再接收任何流量的端點，也可能導致現有流量重新轉送至其他 Proxy。重新導向流量時，流量可能會導向至相同環境中的 Proxy，或是在多個環境共用單一環境群組時，導向至不同環境中的 Proxy。

此外，也應考量新增至環境或環境群組的 API Proxy 基礎路徑總數。為獲得最佳效能，Apigee 建議每個 Apigee 環境或環境群組的 API Proxy 基本路徑數量不要超過 3,000 個。如果超過建議值，所有新舊 API Proxy 部署作業的延遲時間都會增加。

其他資源

以下說明如何管理環境和環境群組：