c# - WCF Duplex 客户端的最佳实践

Question

我不能否认双工异步调用的性能优势，但有些事情让我感到谨慎。

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

谁能告诉我这是否是个好主意？如果不是，为什么不呢？

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

1. 如果上面的虚拟路径是保留的，怎么舍弃呢。我希望客户服务生命周期相当短。 IE 发出请求并接收响应，完成接收后，将其终止。缩短客户端服务生命周期的性能损失与将其合并并保持更长的生命周期相比有多严重。

   这个想法是为了避免超时问题。接收、发送完成后，尽快处理。按照惯例 - 不能传递客户服务。如果您需要信息，请创建一个新的，简单的 - 就像 EF/L2S 等一样。

2. 我如何从 WCF 服务本身内部终止与客户端的 session 。 IE。我不希望客户端结束 session - 我知道我可以相应地装饰我的操作，但我希望服务在满足某些条件时以编程方式自行终止。

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

Answer 1

我认为 Duplex 服务最终只是 Microsoft 的另一个失败架构。这是其中一个在纸面上看起来非常好的东西，但在仔细检查后就会分崩离析。

弱点太多:

1)服务端依赖session建立客户端监听器。这是 session 信息存储在内存中。因此服务器本身不能进行负载平衡。或者，如果它是负载平衡的，您需要打开 ip affinity，但现在如果其中一台服务器受到轰炸，您不能简单地添加另一台服务器并期望所有这些 session 自动迁移到新服务器。

2) 对于位于路由器/防火墙/负载均衡器后面的每个客户端，需要创建一个具有特定端口的新端点。否则路由器将无法将回调消息正确路由到适当的客户端。另一种方法是使用允许自定义编程将特定路径重定向到特定服务器的路由器。又是一项艰巨的任务。或者另一种方法是让具有回调的客户端托管自己的数据库并通过数据库共享数据客户端加上它将应用程序和服务层混合在一起(在某些特殊情况下这可能是可以接受的，但不是在巨大的设置成本之上)

3) 所有这一切基本上表明双工实际上是无用的。如果您需要回电，那么最好在客户端设置一个 wcf 主机。它将更简单，更具可扩展性。此外，客户端和服务器之间的耦合更少。

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