场景：
我有几个服务，我希望被不同的客户发现。执行发现是完美的。但是现在由于不同的原因，我有不同版本的服务。
在我的应用程序生命周期中，我可能有3-4个不同的层：生产，分期，测试和开发。
我需要支持我在过去6个月内部署的客户端，因此我可能需要同时运行2-3个版本的服务。不是合同的不同版本，而是实现的略有不同的版本。
我可能还需要按照它们提供的数据类别来分离服务。假设我有一个提供美国数据的服务实例和另一个提供加拿大数据的实例，可能还有提供澳大利亚数据的第三个实例。在某些情况下，该服务可能有多个类别。
因此，从客户的角度来看，如果我要求仅基于合同的服务，我可能会获得9到15个端点，而我真的只想与生产，美国，1.1版的一个服务进行通信。我知道该服务存在范围，但我无法成功创建一系列范围，这些范围允许我在环境中需要的灵活性。
在前面的示例中，我一直在寻找一种非常具体的服务，但我可能也希望看到针对Production的特定合同的所有服务，无论它们是哪个国家/地区或版本。我可能还需要在混合中添加额外的“范围”。总的来说，我可能有4-6个标准被用作“范围”。
问题：
范围是构建这种复杂过滤的正确方法还是我需要做一些自定义的事情？
如果范围是正确的方法，你可以指出我可以看到的样本吗？
如果我需要自定义是否有一种标准的方法来扩展“范围”行为，以便我可以欺骗它做我想做的事情？
源代码：
是的，范围是可行的方法。我想向你推荐一篇由Juval Lowy撰写的精彩文章Discover a New WCF with Discovery（Programming WCF services书的作者）。这是使用范围的直接引用：
范围在定制发现和向应用程序添加复杂行为方面非常有用，尤其是在编写框架或管理工具时。范围的经典用法是使客户端能够区分不同应用程序的多态服务。然而，这种情况有点罕见。在区分同一应用程序中的端点类型时，我发现范围很方便。
例如，假设对于给定的合同，您有多个实现。您具有生产中使用的操作模式以及测试或诊断中使用的模拟模式。使用范围，客户端可以选择所需的正确实现类型，并且不同的客户端不会通过消耗彼此的服务而彼此冲突。您也可以让同一客户端根据调用的上下文选择不同的端点。您可以拥有用于分析，调试，诊断，测试，检测等的端点。
这非常适合您想要解决的问题。
本文还包含有关在配置和代码中声明范围的良好示例。从服务使用者的角度来看，我看到两个选项：如果要在发现阶段过滤服务或者可以获取所有服务并通过以下方式检查其范围，您可以在FindCriteria实例中填充您传递给DiscoveryClient.Find方法的所有所需范围：手。
范围本身是一个Uri对象，因此它可以使用“key = value”表示法在那里放置许多不同的信息。这应该注意“扩展”范围过滤，它不会限制你的前向兼容性。