环境为运行 API 代理提供隔离上下文或“沙盒”。在单个组织中，您可以创建多个环境。 如需了解详情，请参阅环境和环境组简介。
您在基本安装过程中添加了环境测试。但是，最佳做法是创建多个环境，并为每个环境部署有限数量的代理。
虚拟主机和环境的简介
Apigee Hybrid 使用 Istio Ingress 网关来处理传入的 API 流量。MART 和运行时服务都配置了 Istio Ingress 网关，用于管理暴露在集群外部的连接。这意味着，所有对 API 代理的 HTTP 和 HTTPS 请求都先由 Istio Ingress 网关处理。
在混合环境中，您可以创建一个或多个环境，并为每个环境分配一个主机别名。主机别名是 DNS 名称。传入该 DNS 名称的入站流量由 Ingress 路由到该环境。在内部，每个环境都分配给一个且仅一个消息处理器，该处理器负责处理代理请求、应用政策以及路由来往目标服务的流量。因此，主机别名决定了任何给定传入请求的消息处理器。
以下代码展示了一个定义了多个环境的示例配置。（此类配置属于您的替换文件。）请注意，环境 dev1 和 prod1 具有不同的主机别名：
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
假设已将基本路径为 /foo1 的代理部署到环境 dev1。您可以按如下方式调用代理：
curl -k https://apitest.mydomain.net/foo1
当此调用命中入站流量时，入站流量知道将其发送到与处理请求的 dev1 环境相关联的消息处理器。
同样，如果也将 foo1 部署到 prod1 环境，您可以向主机别名 apiprod.mydomain.net 发出代理请求，如下所示：
curl -k https://apiprod.mydomain.net/foo1
入站流量会将调用路由到与该主机关联的 MP。
简而言之，必须为您创建的每个环境分配主机别名。每种环境都映射到一个且仅有一个消息处理器，并且主机别名决定了接受给定请求的消息处理器。
环境可以共享同一主机别名
通过 Apigee Hybrid，您可以创建多种可根据需要进行管理的环境。例如，您可以创建多个开发环境（如 dev1、dev2、dev3 等等），并将单个主机别名映射到每个环境。此外，您还可以为每个环境部署多个代理。
反模式：将所有代理部署到一个混合环境中。
最佳做法：创建多个环境并为每个环境部署有限数量的代理。用于管理混合路由代理对共享主机别名的正确环境进行调用的技术被称为基本路径路由。
例如，在以下配置中，环境 dev1 和 dev2 共享同一主机别名：
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
如果多个环境共享同一个主机别名，则必须使用名为基本路径路由的配置技术将特定代理基本路径映射到特定环境。如需了解详情，请参阅基本路径路由。
限制代理部署数
对于 Hybrid，许多环境可以共享同一虚拟主机，因此您必须仔细考虑如何管理任何给定环境的代理部署。在 Hybrid 中，最佳做法是创建多个环境并为每个环境部署有限数量的代理。
您应该将多少代理部署到环境？这个问题没有固定的答案；但是，下表提供了关于为何最好限制部署到每个环境的代理数量以及在管理代理部署时需要考虑的事项的常规指导：
| 要考虑的问题 | 说明 |
|---|---|
| 消息处理器启动时间 | 消息处理器 (MP) 启动所需的时间量与部署到该 MP 的代理数有直接关系。在自动扩缩的 Kubernetes 环境中，启动时间增加可能是一个问题。如果需要进行扩缩或重新创建，部署到 MP 的代理越多，该 MP 启动所需的时间就越长。 |
| 扩缩性能 | 如果您已将多个代理部署到一个环境，并且其中一个代理收到大量流量，因此经常自动扩缩，则该环境中的所有代理都会随之扩缩。随着单个高流量代理而扩缩多个代理造成的性能影响可能是一个问题。 |
| 吵杂邻居 | 如果将多个代理部署到同一环境，且一个代理崩溃，则 MP 重启时环境中的所有代理都将关闭。通过限制部署到环境的代理数量，可以最大限度地减少单个代理崩溃的影响。 |
环境配置参考
如需了解环境配置元素的完整列表，请参阅配置属性参考中的 envs。
使用环境
如需详细了解配置，请参阅以下主题：