环境为运行 API 代理提供隔离上下文或“沙盒”。在单个组织中，您可以创建多个环境。
以下代码展示了定义多个环境的示例替换配置。
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 的代理部署到环境 test。您可以按如下方式调用代理：
curl -k https://api.example.com/foo1
当此调用命中入站流量时，入站流量知道将其发送到与处理请求的 test 环境相关联的消息处理器。
同样，如果也将 foo1 部署到 prod 环境，您可以向主机别名 apiprod.mydomain.net 发出代理请求，如下所示：
curl -k https://apiprod.example.com/foo1
入站流量会将调用路由到与该主机关联的 MP。
反模式：将所有代理部署到一个混合环境中。
最佳做法：创建多个环境并为每个环境部署有限数量的代理。
限制代理部署数
对于 Hybrid，许多环境可以共享在环境组中定义的相同虚拟主机，这意味着必须仔细考虑如何管理任何给定环境的代理部署。在 Hybrid 中，最佳做法是创建多个环境并为每个环境部署有限数量的代理。
您应该将多少代理部署到环境？这个问题没有固定的答案；但是，下表提供了关于为何最好限制部署到每个环境的代理数量以及在管理代理部署时需要考虑的事项的常规指导：
| 要考虑的问题 | 说明 |
|---|---|
| 消息处理器启动时间 | 消息处理器 (MP) 启动所需的时间量与部署到该 MP 的代理数有直接关系。在自动扩缩的 Kubernetes 环境中，启动时间增加可能是一个问题。如果需要进行扩缩或重新创建，部署到 MP 的代理越多，该 MP 启动所需的时间就越长。 |
| 扩缩性能 | 如果您已将多个代理部署到一个环境，并且其中一个代理收到大量流量，因此经常自动扩缩，则该环境中的所有代理都会随之扩缩。随着单个高流量代理而扩缩多个代理造成的性能影响可能是一个问题。 |
| 吵杂邻居 | 如果将多个代理部署到同一环境，且一个代理崩溃，则 MP 重启时环境中的所有代理都将关闭。通过限制部署到环境的代理数量，可以最大限度地减少单个代理崩溃的影响。 |
环境组和虚拟主机
借助环境组，您可以将环境分组在一起。每个组中的环境都共享相同的主机名。您可以按功能、按主机名地址、按区域（如果您要实施多区域混合安装）或者按选择的任何其他指标进行环境分组。
由于路由由环境组主机名、API 代理基本路径和环境的组合管理，因此每个虚拟主机只需列出环境组的名称和任何相应的证书。
以下代码展示了一个定义多个虚拟主机的替换配置示例。请注意，虚拟主机的名称必须为环境组的名称。
gcp: region: us-central1 projectID: hybrid-example k8sCluster: name: apigee-hybrid region: us-central1 org: hybrid-example contractProvider: https://us-apigee.googleapis.com # if using data residency 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 ...