WCF双工客户端的最佳实践

本文关键字：最佳 客户端 WCF | 更新日期: 2023-09-27 18:22:15

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

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

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

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

  1. 如果上面的虚拟路径是保留的，怎么可以丢弃它。我希望客户的服务寿命相当短。IE发出请求并接收响应，完成接收后将其终止。与池化并延长客户端使用寿命相比，缩短客户端使用寿命会带来多大的性能损失。

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

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

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

WCF双工客户端的最佳实践

我认为Duplex服务最终只是微软的另一个失败的体系结构。这是一个在纸上看起来很好，但仔细检查就会分崩离析的东西。

有太多的弱点：

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

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

3） 所有这些基本上说明双工实际上是无用的。如果你需要回拨，那么你可以在客户端设置一个wcf主机。它将更简单，可扩展性更强。此外，客户端和服务器之间的耦合更少。

可扩展体系结构的最佳双工解决方案最终是不使用双工解决方案。

  1. 这将取决于你需要新客户多长时间，以及他们能持续多久。如果你每次都特别需要一个新的客户端，那么池化就不是一种选择，但如果客户端一直在做同样的事情，为什么不让一个池等待使用呢？如果他们出现故障，再次重新创建同一个客户端。

  2. 事实上，在回调场景中，如果服务正在回调客户端（实际上是在客户端上调用函数）以传递信息，那么服务现在就是客户端，反之亦然。您可以使用正在进行回调的服务。Close（）连接，但它将一直打开，直到GC可以处理它，根据我的经验，这可能需要比预期更长的时间。因此，简而言之，客户端应该负责关闭自己或断开连接（客户端是对某个事物进行调用的客户端），服务应该只返回答案或从客户端获取数据。

  3. 在双工回调中，现在回调到客户端的服务将获得在双工通道工厂后面抽象的客户端地址。如果该服务无法回电给客户，我认为没有什么可做的，你必须确保你的客户呼叫该服务的端口是打开的，才能接收回电。

相关文章：