環境提供獨立的內容或「沙箱」,用於執行 API Proxy。您可以在單一機構中建立多個環境。詳情請參閱「關於環境和環境群組」。
以下程式碼顯示覆寫設定範例,其中定義了多個環境。請注意,環境 prod 和 test 的主機別名不同:
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 ...
virtualhosts 屬性,將其 routingRules 對應至環境。virtualhosts:
- name: default
hostAliases: ["api.example.com"]
sslCertPath: ./certs/fullchain.pem
sslKeyPath: ./certs/privkey.pem
routingRules:
- env: testvirtualhosts:
- name: external
hostAliases: ["apiprod.example.com"]
sslCertPath: ./certs/fullchain.pem
sslKeyPath: ./certs/privkey.pem
routingRules:
- env: prod
假設具有基本路徑 /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。您可以建立轉送規則,指定要將特定 API 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 發生當機的影響降至最低。 |
環境設定參考資料
如需環境設定元素的完整清單,請參閱「設定屬性參考資料」中的 envs。
使用環境
如要進一步瞭解設定,請參閱下列主題: