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服务本身内部,如何终止与客户端的会话.即.我不希望客户端结束会话 - 我知道我可以相应地修饰我的操作,但我希望服务在满足某些条件时以编程方式终止自身.

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

Answer 1

我认为最终Duplex服务只是微软另一个失败的架构.这是纸上看起来非常好的东西之一,但经过仔细研究就会崩溃.

有太多的弱点:

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

2)对于位于路由器/防火墙/负载均衡器后面的每个客户端,需要创建具有特定端口的新端点.否则,路由器将无法将回调消息正确路由到适当的客户端.另一种方法是使用允许自定义编程的路由器将特定路径重定向到特定服务器.又一个很高的订单.或者另一种方法是让回调的客户端托管自己的数据库并通过数据库共享数据< - 可能在某些情况下工作,其中许可费用不是问题......但它引入了很多复杂性并且如此繁重客户端加上它将应用程序和服务层混合在一起(在某些特殊情况下可能是可以接受的,但不会在巨大的设置成本之上)

3)所有这些基本上都说双工几乎没用.如果你需要回电,那么你最好在客户端设置一个wcf主机.它将更简单,更具可扩展性.此外,客户端和服务器之间的耦合较少.

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