關於環境和環境群組

本頁適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

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

總覽

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

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

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

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

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

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

支援的部署類型

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

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

使用封存部署功能禁止的動作摘要

在 Apigee 環境中啟用封存檔部署功能後，系統會禁止您在該環境中執行下列動作，以免發生衝突：

  • 在 Apigee UI 中，您無法查看、確認部署狀態或管理封存的部署作業，如「部署 API Proxy」一文所述；也無法使用「使用偵錯功能」一文所述的偵錯 UI。解決方法是使用 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 或 Subscription 2024)。如要瞭解系統限制，請參閱「 每個執行個體的最大 Proxy 部署單位數量」。

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

環境類型

以預付費方案使用者來說，建立環境時，您需要選取環境類型：基礎、中級或全面。與環境相關的功能、功能和費用取決於環境類型。詳情請參閱「先付後用環境類型」和「先付後用授權」。

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

轉送 Proxy

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

針對任何納入的政策 (請參閱「轉送 proxy 功能支援」)，在已設定的環境程序中傳入要求至 proxy，然後使用 HTTP 轉送至新的 URI。

變更環境的轉送 Proxy 設定後，只會立即對新要求生效。要求已完成處理，且使用收到要求時的設定。

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

支援轉送 Proxy 功能

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

Apigee 目前不支援 Basic Authentication 與轉送 Proxy，但 Apigee Hybrid 除外。

下表說明支援的其他功能：

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

轉送 Proxy 限制

目前不支援透過外部目標對象使用 GoogleToken 的轉寄 Proxy。

重點

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

元素 規則
組織
  • 可包含多個環境群組
  • 至少須有一個環境群組
環境
  • 必須位於至少一個環境群組中
  • 可出現在多個群組中
  • 與同一個群組中的所有其他環境共用主機名稱
  • 可用於將流量轉送至指定的 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。

包含單一環境的環境群組。

 

準備好建立群組了嗎？

開啟主控台

 

 

如要進一步瞭解環境，請按照下列步驟操作：

Keep Reading

 

 

如要進一步瞭解環境群組，請參閱以下說明：

Keep Reading

 

路由和基本路徑

在簡單的設定中，對已部署 API Proxy 的請求由主機名稱、基本路徑和 API 資源名稱組成，例如：

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

您可以在環境群組中定義主機名稱，讓多個環境共用這些名稱。在 API Proxy 中定義 Basepath 和 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 的 API 要求端點。

您可以在環境群組中定義多個主機名稱。這些 Proxy 都可用於呼叫群組中任何環境中部署的 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 會部署至群組內的環境，並與任何主機名稱和基礎路徑相符：

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

共用環境和轉送

一個環境可以屬於多個環境群組。如果您在這種環境中部署 Proxy，Proxy 就會有多個地址，每個環境群組都有一個地址。如果客戶有多個合作夥伴的萬用字元憑證 (例如 *.example.com)，這項功能就很實用。

例如：

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

請注意，兩個主機名稱都會導向相同的環境。這樣一來，每個環境群組都會有專屬的網域名稱。針對 Apigee hybrid，此情況可使用 mTLS，並為每個合作夥伴使用不同的憑證。

關於環境範圍

組織會提供部分 Apigee 功能的範圍。舉例來說，您可以在機構層級提供鍵/值對應 (KVM) 資料，這表示部署至該機構內任何環境的 API 代理程式，都可以存取相同的 KVM 資料。

同樣地，部分功能的範圍可限定為機構內的環境或環境群組。舉例來說，Apigee 數據分析資料會根據機構、環境和 (最終) 環境群組組合劃分。

注意事項

每個環境的部署作業都可能會影響該環境所屬每個環境群組的流量路由。新增 basepath 後，可能會開始擷取全新流量，或是擷取現有部署作業已處理的現有流量子集。

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

您也應考量新增至環境或環境群組的 API Proxy 基本路徑總數。為獲得最佳效能，Apigee 建議每個 Apigee 環境或環境群組最多使用 3,000 個 API 代理程式 basepath。如果超過這項建議，所有新的和現有的 API 代理程式部署作業都可能會延遲。

其他資源

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