本页面上的示例使用舰队展示了一些假设场景，说明了我们指南中的一些概念和最佳实践。在阅读本指南之前，您应该熟悉舰队简介以及舰队要求和最佳实践中的概念。
示例 1：具有生产、预演、开发资源的队列
第一个示例中有四个集群。两个集群用于生产（位于两个区域以实现冗余目的），其中一个用于预演和测试，另一个用于开发。所有集群均由平台团队拥有并进行集中管理。此简单示例中有两个服务：frontend 和 backend。但是，更复杂的场景可能同时具有多个服务和集群。
方法 1：用于生产、预演、开发的单独队列
利用队列的一种可行方法是为生产、预演、开发资源创建单独的队列。
为此，我们创建了三个单独的队列宿主项目，并将资源放入这些项目中，或者对于本地开发集群，请将集群注册到 example-dev 项目。鉴于本示例中的复杂性，我们不必处理多个命名空间的相同性和服务相同性问题，但我们已经确保 prod-east 和 prod-west 集群的命名空间都经过了标准化处理。
此方法的优点是，各个队列之间的隔离度非常高。此方法的主要缺点是我们需要管理三个不同的队列，这使得生产、预演、开发之间较难实现一致性。开发团队也较难针对预演服务进行开发。
方法 2：为所有资源创建一个队列
在此方法中，我们为所有资源创建一个队列。
为此，我们可以保留 example 项目中的资源，并在该项目中创建队列。我们可以将生产资源和预演资源放入其他队列宿主项目并使用共享 VPC 来分离生产资源和预演资源，但在本示例中，我们选择不这样做。
通过此方法，我们需要确保命名空间和服务在整个队列中都是标准化的。例如，我们在生产集群和预演集群中分别将通用的 frontend 重命名为 frontend-prod 和 frontend-staging。最后，虽然我们可以保留开发命名空间的原始名称，但会提供一个更清晰的名称（例如 frontend-dev-alice），以表示它们是开发命名空间。
通过此方法，我们为了简化管理工作而取消隔离。我们依靠服务网格授权来防范不需要的服务间通信，但可以轻松地通过一个队列来管理整个系统。通过这种安排，我们可以在所有资源中应用政策，这有助于我们确信开发环境看起来与生产环境非常相似。
方法 3：适用于生产和非生产的单独队列
在此方法中，我们接受一个“中介”，将预演资源和开发资源结合到非生产队列中，同时将生产资源放入单独的队列中。
为此，我们创建了两个队列宿主项目，其中一个用于生产，另一个用于非生产。我们还直接将资源放入这些项目中，并将 dev 集群本地注册到我们的非生产队列。我们需要将预演资源和开发资源之间的命名空间和服务标准化，以提供明确的功能；例如，我们在预演集群中将 frontend 重命名为 frontend-staging。
此方法的优点是生产环境与非生产环境明显隔离。例如，我们可以使开发服务与预演服务通信，因此开发者 Alice 的 frontend 可以在其开发服务时与预演 backend 通信。
总结
示例 1 中概述的每种方法都是有效的。您的组织选择哪种方法取决于隔离度与一致性（以及易于管理的程度）；换句话说，不同资源类型之间需要多大隔离度以及它们之间需要多高的一致性。较少的队列更易于实现更高的一致性。第三种方法作为可能的折衷方案提供，将生产完全隔离，同时为开发者提供针对预演服务的开发能力。
示例 2：具有不同资源所有者的队列
在本示例中，我们有两个团队：team-a 和 team-b。这些团队拥有并管理自己的集群，并且对其生成的服务都使用了命名空间 frontend 和 backend。但是，team-a 的 frontend 和 backend 实际上与 team-b 都不同。这两个团队想要创建服务网格，以便其服务可以进行交互。
如果不进行某些干预，则无法将这些集群加入同一个网格。一种较好的方法是将集群的所有权转移给集中平台团队，以便在它们之间建立信任关系。或者，如果 team-a 和 team-b 互相信任，他们也可以通过协调来建立此信任关系。下一步是将命名空间使用情况标准化，使 frontend 和 backend 在这两个团队的集群中不再过载。完成此操作后，他们便可以跨所有资源建立单个队列并创建其服务网格。
如果无法建立此信任关系，则 team-a 和 team-b 应该创建使用两个不同队列宿主项目的两个单独队列。此方法的缺点是他们现在需要利用网格联合，这比单个网格更难管理。其好处是，这两个团队都不需要对其部署的命名空间和服务进行标准化，并且只能进行明确的、经过特别授权的通信。
