WCF双工客户端的最佳实践

Question

我不能否认使用双工异步调用的性能优势，但有一些地方让我感到担忧。

我的担心是，如果给定一个实例化的客户端对象，WCF是否能够确定哪个特定的客户端服务实例将接收回调参数？

有人能告诉我这是否是一个好主意吗？如果不是，为什么不是？

new DuplexChannelFactory<IServerWithCallback>(
   new ClientService(), 
   new NetTcpBinding(), 
   new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid()))

1. 如果上面的虚拟路径是保留的，那么如何废弃它？我希望客户端服务的生命周期很短，即发出请求并收到响应后立即终止。将客户端服务的生命周期设置短与保持其长时间运行并池化相比，性能损失有多严重？

   这样做是为了避免超时问题。在接收、发送完毕后尽快销毁。按照惯例 - 不能传递客户端服务。如果需要信息，请创建新的服务，就像 EF/L2S 等一样。

2. 从 WCF 服务内部，如何关闭与客户端的会话。例如，我不想让客户端结束会话 - 我知道可以相应地装饰我的操作，但是当满足某些条件时，我希望服务能够自己编程地终止。

3. 我可以附加端口并相应地转发以解决任何防火墙问题，但我担心的是如果客户端位于负载均衡器后面。该服务如何知道调用哪个特定服务器？

- Alwyn

Answer 1

我认为Duplex服务最终只是Microsoft的另一个失败的架构。这是那种看起来在纸面上非常好，但仔细检查后就会崩溃的事情之一。

有太多的弱点：

1）依赖于会话以通过服务器建立客户端监听器。此会话信息存储在内存中。因此服务器本身无法负载平衡。或者如果它被负载平衡，您需要打开ip亲和力，但现在如果其中一个服务器受到攻击，您不能简单地添加另一个服务器并期望所有这些会话自动迁移到新服务器上。

2）对于每个位于路由器/防火墙/负载均衡器后面的客户端，都需要创建具有特定端口的新端点。否则，路由器将无法正确路由回调消息到适当的客户端。另一种方法是拥有允许自定义编程以将特定路径重定向到特定服务器的路由器。再次要求过高。或者另一种方式是使用带有回调的客户端主机自己的数据库，并通过数据库共享数据<--在某些不涉及许可费用的情况下可能有效...但它引入了很多复杂性，而且对客户端来说非常繁琐，还将应用程序和服务层混合在一起（这在某些特殊情况下可能可以接受，但不适用于巨大的设置成本之上）

3）所有这些基本上都说明了双工协议几乎是无用的。如果需要回调，则最好在客户端端设置wcf主机。它将更简单，可扩展性更强。此外，客户端与服务器之间的耦合较少。

可扩展架构的最佳双工解决方案最终不使用其中之一。

- Alwyn

---

这个答案适用于NetTcpBinding还是只适用于Dual Http绑定？ - Yaniv

Answer 2

1. 这将取决于您需要客户端新建的时间以及它们持续的时间。如果您需要每次都使用新的客户端，则无法使用池，但如果客户端一直在执行相同的操作，为什么不拥有一个等待使用的客户端池呢？如果它们发生故障，请重新创建相同的客户端。

2. 实际上，在回调场景中，如果服务正在回调到客户端（实际上是在客户端上调用函数）以传递信息，则服务现在是客户端，反之亦然。您可以让进行回调的服务.Close()连接，但它将保持打开状态，直到GC处理它，根据我的经验，这可能比预期的时间更长。因此，简而言之，客户端应该负责（即发起调用的一方）关闭自身或断开连接，服务只应返回答案或从客户端获取数据。

3. 在双工回调中，现在调用客户端的服务将获得抽象在duplexchannelfactory后面的客户端地址。如果服务无法回调到客户端，则我认为没有什么可以做的，您必须确保客户端调用服务的端口已打开以接收回调。

- Mark W