本主题提供有关选择相应的 WCF 适配器或绑定类型和应用各种 WCF 适配器配置选项的指导的建议。
选择要使用的 WCF 适配器或要使用的 WCF-Custom/WCF-CustomIsolated 绑定类型时的注意事项
如果不严格要求，请不要使用消息级别安全性，因为它会增加消息的大小。 这反过来可以最大程度地减少解决方案的整体吞吐量。
选择要使用的 WCF 适配器或要使用的 WCF-Custom/WCF-CustomIsolated 绑定类型 时，请仔细考虑任何应用程序要求，例如兼容性、性能、托管平台、安全性和支持的传输。 下面列出的准则通常适用于 WCF，并不特定于 BizTalk Server：
如果 WCF 服务需要支持旧客户端（如 WebSphere Web 服务或需要 ASMX Web 服务的 .NET 1.1 应用程序），则应使用 BasicHttpBinding。 由于 BasicHttpBinding 默认不实现任何安全性，因此如果需要消息或传输安全性，则应在此绑定上显式配置它。 使用 BasicHttpBinding 公开能够与基于 ASMX 的 Web 服务和客户端以及遵循 Basic Profile 1.1 WS-I 的其他服务通信的终结点。 配置传输安全性时，BasicHttpBinding 默认不使用任何凭据，就像经典 ASMX Web 服务一样。 BasicHttpBinding 允许在 IIS 7.5 或 IIS 7.0 中托管 WCF 服务。
如果 WCF 服务将在 Internet 上被 WCF 客户端调用，则应使用 WsHttpBinding。 对于需要互联网方案的场景，WsHttpBinding 是一个不错的选择，因为它允许您在 IIS 7.5 或 IIS 7.0 中托管 WCF 服务，同时无需支持那些期望使用 ASMX Web 服务的旧客户端。 如果需要支持旧客户端，请考虑改用 BasicHttpBinding。 需要公开 WCF 接收位置或采用支持 WS-* 协议（如 WS-Security 或 WS-AtomicTransactions）的发送端口时，应使用 WsHttpBinding。
如果需要在 Intranet 中支持客户端，NetTcpBinding 是一个不错的选择。 如果传输性能对你很重要，并且可以接受在 Windows 服务而不是 IIS 中托管服务，则 NetTcpBinding 是 Intranet 方案的最佳选择。 如果要为 .NET-to-.NET 跨计算机通信提供安全可靠的绑定环境，请使用此绑定。 请注意，NetTcpBinding 必须托管在 Windows 服务或 IIS 7.5/7.0 中。
如果需要在服务所在的同一台计算机上支持 WCF 客户端，则应使用 NetNamedPipeBinding。 此绑定为跨进程、同计算机通信提供安全可靠的绑定环境。 如果要使用 NamedPipe 协议，请使用此绑定。 请注意，NetNamedPipeBinding 必须托管在 Windows 服务或 IIS 7.5/7.0 中。
如果需要支持断开连接的队列，则应使用 NetMsmqBinding。 队列通过使用消息队列（也称为 MSMQ）作为传输来提供，从而支持断开连接的操作、故障隔离和负载均衡。 当客户端和服务不必同时联机时，可以使用 NetMsmqBinding。 还可以使用负载调配来管理任意数量的传入消息。 消息队列支持故障隔离，其中消息可能会失败，而不会影响其他消息的处理。 请注意，NetMsmqBinding 必须托管在 Windows 服务或 IIS 7.5/7.0 中。
如果需要支持双工服务，则应使用 WsDualHttpBinding。 双工服务是一种使用双工消息模式的服务，可以使服务能够通过回调与客户端进行双向通信。 请注意，WsDualHttpBinding 必须托管在 Windows 服务或 IIS 7.5/7.0 中。
WCF 绑定比较
绑定提供用于配置通道堆栈的机制。 绑定创建一个进程，以使用传输通道、消息编码器和一组协议通道生成通道堆栈。 Windows Communication Foundation 附带许多内置绑定，这些绑定预配置用于解决最常见的通信方案。
| 绑定类名称 | 运输 | 消息编码 | 安全模式 | 可靠消息传递 | 事务流（默认禁用） |
|---|---|---|---|---|---|
| BasicHttpBinding（基本 HTTP 绑定） | HTTP | 文本 | 没有 | 不支持 | 不支持 |
| WSHttpBinding（用于WCF框架中的安全HTTP通信绑定） | HTTP | 文本 | 消息 | 禁用 | WS-AtomicTransactions |
| NetTcpBinding | TCP | 二进制 | 运输 | 禁用 | OleTransactions |
| NetNamedPipesBinding | 命名管道 | 二进制 | 运输 | 不支持 | OleTransactions |
| NetMsmqBinding | MSMQ | 二进制 | 消息 | 不支持 | 不支持 |
| 自定义绑定 | 你决定 | 你决定 | 你决定 | 你决定 | 你决定 |
可以根据通信需求选择特定绑定。 例如：
BasicHttpBinding 旨在实现与简单 Web 服务的互作性。 BasicHttpBinding 将 HTTP 用于传输和文本进行消息编码。
WSHttpBinding 旨在实现与可能利用不同 WS-* 协议的高级 Web 服务的互作性。 WSHttpBinding 还使用 HTTP 进行传输，并使用文本进行消息编码。
NetTcpBinding 和 NetNamedPipeBinding 分别被设计用于跨计算机或在同一台计算机上高效执行与其他 WCF 应用程序的通信。
如果您在运行时通过使用一个或多个自定义协议通道需要最大的灵活性，您可以使用CustomBinding，这样可以让您决定哪些绑定元素构成您的绑定。
注释
绑定在响应时间和吞吐量方面具有不同的特征。 因此，提高性能的一般建议是尽可能使用 NetTcpBindind 和 NetNamesPipeBinding。
使用 TCP 传输和二进制消息编码来最大化 WCF 适配器吞吐量并最大程度地减少 WCF 适配器延迟
尽可能使用 WCF-NetTcp 适配器来最大化吞吐量。 WCF-NetTcp 适配器使用 TCP/IP 传输协议和二进制消息编码，与其他 WCF-* 适配器相比，这同时提高了性能。
或者，可以使用 自定义绑定 类型配置 WCF-Custom 接收位置的适配器（或 WCF-CustomIsolated 适配器）。 然后，添加 binaryMessageEncoding 绑定扩展来实现二进制消息编码和 tcpTransport 绑定扩展，以实现 TCP/IP 作为消息传输协议。 此方法非常灵活，因为它允许你仅选择和配置所需的绑定元素，以及创建自定义通道以扩展 BizTalk 消息引擎的默认行为。 如果使用 customBinding 绑定类型实现 WCF-Custom 适配器，请为绑定扩展配置参数指定这些值，以最大化吞吐量并最大程度地降低延迟。
发送端口配置值：
| 设置 | 默认值 | 建议的值 |
|---|---|---|
| TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint - 获取或设置连接池中缓存的每个终结点的最大出站连接数。 这会限制为每个唯一远程终结点缓存的连接数。 如果活跃的客户端连接超过这个值，服务可能会对客户端无响应，因此应调整此值以适应为每个唯一远程终结点缓存的最大预期连接数。 有关此属性的详细信息，请参阅 MSDN 上的 TcpConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint 属性 （https://go.microsoft.com/fwlink/?LinkId=157737）。 | 10 | 尝试 >= 20 |
接收端口配置值：
| 设置 | .NET Framework 4 的默认值 | .NET Framework 4 的建议值 | .NET Framework 3.5 的默认值 | .NET Framework 3.5 的建议值 |
|---|---|---|---|---|
| TcpTransportBindingElement.MaxPendingAccepts - 获取或设置可用于正在处理服务传入连接的挂起异步接受操作的最大数目。 对于具有较高级别的同时连接启动的方案，此值可能不足，应与 MaxPendingConnections 属性一起进行调整，以处理更高级别的并发客户端连接尝试。 不应将此属性设置为大于托管服务的计算机中存在的处理器数的值。 有关此属性的详细信息，请参阅 MSDN 上的 ConnectionOrientedTransportBindingElement.MaxPendingAccepts 属性 （https://go.microsoft.com/fwlink/?LinkId=157738）。 | 1 | 2*ProcessorCount | 1 | 尝试 >= 20 |
| TcpTransportBindingElement.MaxPendingConnections - 获取或设置等待服务调度的最大连接数。 这会限制同时等待调度的客户端连接数。 如果此值太低，服务可能会拒绝客户端连接尝试。 如果负载过高，服务可能会在负载过大期间出现缓慢或无响应。 此属性应设置为一个值，该值允许服务以完整容量运行，且不会更高。 当堆栈中的较高层调用 AcceptDispatch 时，将从等待调度的连接队列中删除该连接。 有关此属性的详细信息，请参阅 MSDN 上的 ConnectionOrientedTransportBindingElement.MaxPendingConnections 属性 （https://go.microsoft.com/fwlink/?LinkId=157735）。 | 10 | 16*处理器数量 | 10 | 尝试 >= 20 |
| TcpTransportBindingElement.ListenBacklog - 获取或设置可以排队等待的最大连接请求数。 ListenBacklog 是一个套接字级属性，描述待处理的接受请求的队列数量。 确保基础套接字队列不会超过最大并发连接数。 有关此属性的详细信息，请参阅 MSDN 上的 TcpTransportBindingElement.ListenBacklog 属性 （https://go.microsoft.com/fwlink/?LinkId=157734）。 | 10 | 16*处理器数量 | 10 | 尝试 >= 20 |
将 ServiceThrottlingBehavior 服务行为添加到 WCF-Custom 或 WCF-CustomIsolated 接收点，并使用以下设置：
注释
在修改 ServiceThrottlingBehavior 服务行为的任何元素之前，必须先将 serviceThrottling 行为扩展添加到 WCF-Custom* 传输属性对话框的“行为”选项卡。 若要将 serviceThrottling 添加到行为列表，请选择 WCF-Custom* 传输属性对话框的“行为”选项卡，右键单击“行为”下的 ServiceBehavior，单击“添加扩展”，选择 serviceThrottling，然后单击“确定”。 然后单击以选择 ServiceThrottlingElement 下可用的属性，并根据需要更改属性的值。
| 设置 | .NET Framework 4 的默认值 | .NET Framework 4 的建议值 | .NET Framework 3.5 的默认值 | .Net Framework 3.5 的建议值 |
|---|---|---|---|---|
| ServiceThrottlingBehavior.MaxConcurrentCalls - 获取或设置一个值，该值指定在 ServiceHost 中主动处理的最大消息数。 MaxConcurrentCalls 属性指定在 ServiceHost 对象中主动处理的最大消息数。 每个通道都可以有一条挂起的消息，该消息在 WCF 开始处理之前，不会被计入 MaxConcurrentCalls 的值。 有关此属性的详细信息，请参阅 MSDN 上的 ServiceThrottlingBehavior.MaxConcurrentCalls （https://go.microsoft.com/fwlink/?LinkId=157838）。 BizTalk WCF-Custom 和 WCF-CustomIsolated 接收适配器 MaxConcurrentCalls 属性的默认值为每个 CPU 16 。 注意：BizTalk Server WCF 接收 WCF-Custom 和 WCF-CustomIsolated 适配器以外的适配器会在 WCF-* 传输属性对话框的“绑定”选项卡上公开“最大并发调用”属性，以配置此行为。 最大并发调用行为的默认值为 200。 | 16*ProcessorCount | 16*处理器数量 | - BizTalk WCF-Custom 和 WCF-CustomIsolated 接收适配器的 16 个配件。 - 200 用于其他 WCF 接收适配器。 |
- 尝试使用 >= 200 为 WCF-Custom 和 WCF-CustomIsolated 接收器适配器设置。 - 在 BizTalk Server WCF 接收适配器中，除 WCF-Custom 和 WCF-CustomIsolated 适配器以外，请在WCF-* 传输属性对话框的绑定选项卡中尝试设置最大并发调用属性为>。 |
| ServiceThrottlingBehavior.maxConcurrentInstances - 获取或设置一个值，该值指定服务中可同时执行的最大 InstanceContext 对象数。 MaxConcurrentInstances 属性指定服务中 InstanceContext 对象的最大数目。 请务必记住 MaxConcurrentInstances 属性与 InstanceContextMode 属性之间的关系。 如果 InstanceContextMode 为 PerSession，则生成的值为会话总数。 如果 InstanceContextMode 为 PerCall，则生成的值为并发调用数。 如果消息到达时 实例对象 的最大数目已存在，则消息将一直保留，直到 InstanceContext 对象关闭。 有关此属性的详细信息，请参阅 MSDN 上的 ServiceThrottlingBehavior.MaxConcurrentInstances 属性 （https://go.microsoft.com/fwlink/?LinkId=157897）。 WCF-Custom 和 WCF-CustomIsolated 接收适配器 MaxConcurrentInstances 属性的默认值为每个 CPU 116 。 注意： WCF 接收位置是通过 BizTalkServiceInstance 类的实例实现的，该类包含在 Microsoft.BizTalk.Adapter.Wcf.Runtime.dll 程序集中。此外，这个类被标记为 ServiceBehavior（InstanceContextMode=InstanceContextMode.Single，ConcurrencyMode=ConcurrencyMode.Multiple）。 所有传入请求都由同一个单一实例对象管理，此参数将被忽略。 因此，在某些 WCF-Custom 接收位置上设置 maxConcurrentInstances 属性不起作用，因为活动实例数始终等于 1。 | 116*ProcessorCount | 116*处理器数量 | 26 | 尝试 >= 200 |
| ServiceThrottlingBehavior.MaxConcurrentSessions - MaxConcurrentSessions 属性获取或设置 ServiceHost 对象可以一次接受的最大会话数。 请务必了解，在这种情况下，会话不仅限于仅支持可靠会话的通道。 每个侦听器对象可以有一个挂起的通道会话，该会话不计入 MaxConcurrentSession 的值 ，直到 WCF 接受通道会话并开始处理通道会话消息。 在需要使用会话的情景中，此属性最为有用。 当此属性设置为小于客户端线程数的值时，来自多个客户端的请求可能会在同一套接字连接中排队。 来自尚未创建与服务的会话的客户端的请求将被阻止。 如果服务上打开的会话数已达到 MaxConcurrentSessions 指定的值，则它们将保持被阻止状态，直到服务与其他客户端的会话关闭。 未得到服务的客户端请求将超时，然后服务关闭会话。 为了避免这种情况，请考虑从不同的应用程序域运行客户端线程，以便请求消息被不同的套接字连接接受。 有关此属性的详细信息，请参阅 MSDN 上的 ServiceThrottlingBehavior.MaxConcurrentSessions 属性 （https://go.microsoft.com/fwlink/?LinkId=157864）。 | 100*处理器计数 | 100*处理器数量 | 10 | 尝试 >= 200 |
修改端口配置设置时，以方法方式应用更改;分别修改每个参数，并测试更改对性能和整体稳定性的影响。 与往常一样，要应用的正确值取决于特定方案：如果设置的值太低，可减少可伸缩性;如果设置的值过高，则应用程序要求可能会超过计算机上的物理资源容量。 此外，由于这些属性相关，因此应以一致且一致的方式设置它们。 有关使用 ServiceThrottlingBehavior 控制 WCF 服务性能的详细信息，请参阅 MSDN 上使用 ServiceThrottlingBehavior 控制 WCF 服务性能 （https://go.microsoft.com/fwlink/?LinkId=157908）。