關於環境和環境群組

本頁面適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

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

總覽

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

每個環境可部署的 API Proxy、共用流程和其他資源數量皆有上限。 這些限制會因使用環境的 Apigee 組織類型 (訂閱、即付即用或 Apigee hybrid) 而異。詳情請參閱限制說明文件。

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

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

依環境群組將環境邏輯分組，可帶來下列好處：

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

支援的部署類型

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

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

封存部署作業中遭封鎖動作的摘要

在 Apigee 環境中啟用封存部署項目後，您將無法在環境中執行下列操作，以免發生衝突：

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

注意：您可以在已啟用封存部署作業的 Apigee 環境中，管理鍵/值對應 (KVM) 和 TLS 鍵儲存庫。

如果嘗試執行上述任何受限動作，系統會顯示下列錯誤訊息：

FAILED_PRECONDITION

Proxy 部署單元

Proxy 部署單位 (PDU) 會根據 API Proxy 和共用流程在基礎架構中的部署情況，衡量 Apigee 容量用量。

Proxy 部署單元是指各環境各執行個體 (區域) 中部署的一個 API Proxy 或共用流程修訂版本。Apigee 會隨著基礎架構擴充，因此如果單一 Proxy 部署至涵蓋多個執行個體的環境，可能會計為多個單元。

計算 PDU

PDU 總數的計算方式，是將貴組織所有環境的部署單元加總。每個環境的 PDU 貢獻值，是部署的修訂版本數量乘以環境附加的執行個體 (區域) 數量。

在 Apigee Hybrid 中，設定環境的每個 Kubernetes 叢集都會計為 PDU 計算中的執行個體 (區域)。

總 PDU 的一般公式如下：

Total PDUs = Σ (Deployed Revisions in Envn × Instances for Envn)

其中總和是 Proxy 或共用流程部署的所有環境 (Env_n)。

如果 Proxy 或共用流程部署至多個環境，且這些環境連結的執行個體數量相同，則可使用簡化公式：

PDUs = (Deployed Revisions) × (Environments) × (Instances)

範例

下表舉例說明在不同基礎架構情境下，如何計算 PDU：

情境	Proxy	環境	執行個體 (區域)	PDU 總數
單一區域 小規模部署	1	1	1	1
多區域高可用性 兩個區域使用相同 Proxy	1	1 (已附加至 2 個執行個體)	2	2
多環境 開發和測試環境中的相同 Proxy	1	2 (開發、測試)	1	2
企業規模 跨多個環境全球部署 (假設正式環境和測試環境都連結至所有 3 個執行個體)	5	2 (正式環境、測試環境)	3 (美國、歐盟、亞洲)	30

Proxy 部署單元類型

Proxy 部署單元會計算每個區域中，部署至環境的 Proxy 和共用流程數量。

部署單元類型如下：

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

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

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

環境類型

如果是即付即用使用者，建立環境時，請選取環境類型：「底層」、「中層」或「完整」。環境的功能、特色和費用取決於環境類型。詳情請參閱「即付即用環境類型」和「即付即用授權」。

如果是 Apigee 會員方案，環境類型一律為 Apigee Comprehensive，您不需要瞭解環境類型。

轉送 Proxy

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

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

對環境轉送 Proxy 設定所做的變更會立即生效，但僅適用於新要求。已在處理中的要求會按照收到要求時的設定完成。

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

支援正向 Proxy 功能

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

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

下表列出其他功能的支援情形：

功能或政策	是否支援/適用於轉送 Proxy？
目標端點	是
HTTP 健康狀態檢查	是
服務呼叫	是
透過 JavaScript 傳送 HTTP 呼叫	是
整合目標	是
透過本機回送進行 Proxy 鏈結	否
發布訊息	否
Cloud Logging	否
與同步器通訊	否
透過 Syslog 記錄訊息	否

轉送 Proxy 限制

目前不支援透過外部目標對象使用 GoogleToken 進行轉送 Proxy。

重點

下表列出環境、組織和環境群組的重要注意事項：

元素	規則
組織	可包含多個環境群組 至少須有一個環境群組
環境	必須至少位於一個環境群組中 可出現在多個群組中 與同一群組中的所有其他環境共用主機名稱 可將流量轉送至指定的 URI
環境類型	判斷該環境中及搭配該環境可用的功能 決定環境的價格 (請參閱「環境類型」)。
環境群組	可有多個主機名稱 包含一或多個環境 指派給群組的主機名稱不得與該群組重複 (其他群組不得使用)

Apigee Hybrid 使用者： 您建立的每個環境群組若有附加環境，則必須包含在所有使用該環境的覆寫檔案中。

範例

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

一個環境群組和一個環境

最簡單的結構是單一環境群組，其中包含單一環境。如果貴機構目前正在評估產品，或尚未設定測試或數據分析基礎架構，也未在正式環境中部署任何 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 資源是在 API Proxy 上定義。

注意：環境和群組名稱不會影響 API 端點的網址。這些名稱僅供您整理及設定環境，不會向 Proxy 的使用者顯示。

如要進一步瞭解基本路徑和 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-prod 上的 catalog Proxy，基本路徑為 /catalog
  • cart-prod 上的 cart Proxy，基本路徑為 /catalog/cart
  • pymnt-prod 上的 payment Proxy，基本路徑為 /payment

這會建立下列端點：

• 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，並比對任何主機名稱和基本路徑：

提示：

您在環境群組中定義的主機名稱：

• 在組織的所有環境群組中不得重複，且不得用於多個群組
• 不支援萬用字元
• 基準路徑在環境群組中不得重複 (環境群組中不得有兩個 Proxy 具有相同的基準路徑)

詳情請參閱「將主機名稱新增至群組」。

共用環境和轉送

一個環境可以屬於多個環境群組。如果您將 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 部署作業的延遲時間可能會增加。

其他資源

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

• 使用 Apigee UI：

  • 使用環境
  • 使用環境群組

• 使用 Apigee API：

  • Environments API
  • 環境群組 API
  • 環境群組連結 API