環境提供獨立的內容或「沙箱」，用於執行 API Proxy。您可以在單一機構中建立多個環境。
以下程式碼顯示覆寫設定範例，其中定義了多個環境。
namespace: my-namespace org: my-organization ... envs: - name: test serviceAccountPaths: synchronizer: "your_keypath/synchronizer-manager-service-account.json udca: "your_keypath/analytic-agent-service-account.json - name: prod serviceAccountPaths: synchronizer: "your_keypath/synchronizer-manager-service-account.json udca: "your_keypath/analytic-agent-service-account.json ...
假設具有基本路徑 /foo1 的 Proxy 部署至 test 環境。您可以這樣呼叫 Proxy：
curl -k https://api.example.com/foo1
當這項呼叫傳送至 Ingress 時，Ingress 會知道要將其傳送至與 test 環境相關聯的訊息處理器，由該處理器處理要求。
同樣地，如果 foo1 也部署到 prod 環境，您可以對主機別名 apiprod.mydomain.net 提出類似這樣的 Proxy 要求：
curl -k https://apiprod.example.com/foo1
而 Ingress 會將通話轉送至與該主機相關聯的 MP。
反模式：將所有 Proxy 部署至一個混合式環境。
最佳做法：建立多個環境，並在每個環境中部署有限數量的 Proxy。
限制 Proxy 部署項目數量
如果是混合式，由於許多環境可以共用環境群組中定義的相同虛擬主機，因此您必須仔細思考如何管理 Proxy 部署作業，才能將 Proxy 部署至任何指定環境。在混合式環境中，最佳做法是建立多個環境，並在每個環境中部署有限數量的 Proxy。
您應該在環境中部署多少個 Proxy？這個問題沒有標準答案，但下表提供一般指引，說明為何最好限制部署至每個環境的 Proxy 數量，以及管理 Proxy 部署作業時需要考量的事項：
| 需要考慮的問題 | 說明 |
|---|---|
| 訊息處理器啟動時間 | 訊息處理器 (MP) 的啟動時間長度與部署至該 MP 的 Proxy 數量直接相關。在自動調度資源的 Kubernetes 環境中，啟動時間變長可能會造成問題。部署至 MP 的 Proxy 越多，如果需要擴充或重新建立 MP，所需時間就越長。 |
| 擴充效能 | 如果您在環境中部署多個 Proxy，其中一個 Proxy 的流量過大，導致系統頻繁自動調度資源，該環境中的所有 Proxy 都會隨之調度資源。使用單一高流量 Proxy 擴充多個 Proxy 的效能可能會造成問題。 |
| 吵鬧的鄰居 | 如果您在同一個環境中部署多個 Proxy，其中一個 Proxy 發生當機情形時，環境中的所有 Proxy 都會停止運作，MP 則會重新啟動。限制部署至環境的 Proxy 數量，可將單一 Proxy 發生當機的影響降至最低。 |
環境群組和虛擬主機
環境群組 可讓您將環境分組。每個群組中的環境共用相同的主機名稱。您可以依功能、主機名稱地址或區域 (如果您要實作多區域混合式安裝)，或是依您選擇的任何其他指標，將環境分組。
由於路由是由環境群組主機名稱、API Proxy 基本路徑和環境組合管理，因此每個虛擬主機只需要列出環境群組的名稱和任何適當的憑證。
以下程式碼顯示覆寫設定範例，其中定義了多個虛擬主機。請注意，虛擬主機的名稱必須是環境群組的名稱。
gcp:
region: us-central1
projectID: hybrid-example
k8sCluster:
name: apigee-hybrid
region: us-central1
org: hybrid-example
instanceID: "my_hybrid_example"
virtualhosts:
- name: group-1 # the name of an environment group
sslCertPath: ./certs/keystore.pem
sslKeyPath: ./certs/keystore.key
virtualhosts:
- name: group-2
sslCertPath: ./certs/keystore.pem
sslKeyPath: ./certs/keystore.key
...