路由方案
虽然路由服务高度可自定义，但从头开始创建新配置时，设计高效路由逻辑可能是一项挑战。 但是，大多数路由服务配置都遵循几种常见方案。 虽然这些方案可能不适用于特定配置，但了解如何将路由服务配置为处理这些方案将帮助你了解路由服务。
常见方案
路由服务的最基本用途是聚合多个目标终结点，以减少向客户端应用程序公开的终结点数，然后使用消息筛选器将每个消息路由到正确的目标。 消息可以基于逻辑或物理处理要求（例如必须由特定服务处理的消息类型）路由，或基于任意业务需求（例如提供来自特定源的消息的优先级处理）。 下表列出了一些常见场景，以及何时会遇到这些场景：
| 场景 | 何时使用 |
|---|---|
| 服务版本控制 | 需要支持多个版本的服务，或者将来可能部署更新的服务 |
| 服务数据分区 | 必须跨多个主机对服务进行分区 |
| 动态更新 | 必须在运行时动态重新配置路由逻辑才能处理更改的服务部署 |
| 组播 | 必须将一条消息发送到多个终结点 |
| 协议桥接 | 通过一个传输协议接收消息，目标终结点使用不同的协议 |
| 错误处理 | 需要提供应对网络中断和通讯故障的复原能力 |
注意
虽然呈现的许多方案都特定于某些业务需求或处理要求，但规划支持动态更新和使用错误处理通常被视为最佳做法，因为它们允许你在运行时修改路由逻辑并从暂时性网络和通信故障中恢复。
服务版本控制
在引入新版本的服务时，必须经常维护以前的版本，直到所有客户端都转换到新服务。 如果服务是一个长时间运行的进程，需要数天、几周甚至数月才能完成，这尤其重要。 通常，这需要为新服务创建新的端点地址，同时保留以前版本的原始端点。
通过使用路由服务，可以公开一个终结点来接收来自客户端应用程序的消息，然后根据消息内容将每个消息路由到正确的服务版本。 最基本的实现包括向消息添加一个自定义标头，用于指示将处理该消息的服务版本。 路由服务可以使用 XPathMessageFilter 检查每个消息是否存在自定义标头，并将消息路由到相应的目标终结点。
有关用于创建服务版本控制配置的步骤，请参阅 如何：服务版本控制。
服务数据分区
在设计分布式环境时，通常需要将处理负载分散到多台计算机上，以便提供高可用性、减少单个计算机上的处理负载或为特定消息子集提供专用资源。 虽然路由服务不替换专用的负载均衡解决方案，但它执行基于内容的路由的功能可用于将其他类似消息路由到特定目标。 例如，你可能要求将来自特定客户端的消息与从其他客户端接收的消息分开处理。
有关用于创建服务数据分区配置的步骤，请参阅 如何：服务数据分区。
动态路由
通常，可能需要修改路由配置以满足不断变化的业务需求，例如将路由添加到服务的较新版本、更改路由条件，或者更改筛选器所路由的特定消息的目标终结点。 通过路由服务，您可以通过 RoutingExtension执行此操作，这样就可以在运行时提供新的路由配置。 新配置会立即生效，但仅影响路由服务处理的任何新会话。
有关实现动态路由的步骤，请参阅 如何：动态更新。
组播
路由消息时，通常会将每个消息路由到一个特定的目标终结点。 但是，有时可能需要将消息的副本路由到多个目标终结点。 若要执行多播路由，必须满足以下条件：
通道形状不得是请求-答复（尽管可以是单向或双工），因为请求-答复机制要求客户端应用程序在请求后只能接收到一个回复。
在评估消息时，多个筛选器必须返回 真。
如果满足这些条件，则与返回 true 的筛选器关联的每个目标终结点将收到消息的副本。
协议桥接
在不同 SOAP 协议之间路由消息时，路由服务使用 WCF API 将消息从一个协议转换为另一个协议。 当路由服务公开的服务终结点使用与将消息路由到的客户端终结点不同的协议时，会自动发生这种情况。 如果正在使用的协议不是标准协议，则有可能禁用此行为;但是，必须提供自己的桥接代码。
错误处理
在分布式环境中，遇到暂时性网络或通信故障并不少见。 如果没有中间服务（如路由服务），处理此类故障的负担就落在客户端应用程序上。 如果客户端应用程序不包括在网络或通信失败时重试的特定逻辑以及备用位置的知识，则用户可能会遇到在目标服务成功处理消息之前必须多次提交消息的情况。 这可能会导致客户对应用程序不满意，因为它可能被视为不可靠。
路由服务尝试通过为遇到网络或通信相关故障的消息提供可靠的错误处理功能来纠正此方案。 通过创建可能的目标终结点列表并将此列表与每个消息筛选器相关联，可以删除只有一个可能的目标而导致的单一故障点。 如果发生故障，路由服务将尝试将消息传递到列表中的下一终结点，直到消息已传递、发生非通信失败或所有终结点已用尽。
有关用于配置错误处理的步骤，请参阅 如何：错误处理。