使用两个WCF服务而不是一个带回调的WCF服务的缺点

本文关键字:WCF 服务 一个 回调 缺点 两个 | 更新日期: 2023-09-27 18:16:19

我有一个客户端/服务器设置,我正在使用WCF服务(NetTcpBinding)实现。设置是这样的,客户机基本上向服务器发送一些命令和指令(主要是单向调用)。但是,服务器可能处于需要非常快速地将大量数据发送回客户机的情况。我已经在主WCF服务上使用回调实现了这一点(服务器经常进行这些回调)。

但是我花了很长时间才让它正常工作。它似乎主要归结为异常/挂起(主要挂起),当客户端调用服务器,而服务器正在发送大量的数据回客户端过程中发生。我已经尝试了几乎所有已经看到的东西,例如将我的大多数呼叫设置为[OperationContract(IsOneWay=true)]并在ServiceBehavior上设置ConcurrencyMode=ConcurrencyMode.Multiple。这减少了挂起的数量,但没有阻止它们。

所以,因为对我来说最重要的是尽快得到一个可行的解决方案(截止日期即将到来),我正在考虑重构为两个WCF服务。第一个就像现在使用命令的所有客户机-服务器调用一样。第二个将在相反的方向上,并且将在客户端连接到服务器之后设置。此服务将用于将数据发送回客户端。

这种方法有什么缺点吗?在两个方向上使用WCF服务有什么问题吗?还有其他建议或技巧吗?还是说我完全错了?

使用两个WCF服务而不是一个带回调的WCF服务的缺点

我觉得这主意不错。第一个服务可以将命令或其他内容添加到第二个服务用于按顺序处理的队列中。

您甚至可以让第二个服务回调到第一个服务,然后第一个服务回调到客户端。这样,客户端只需要与一个服务对话,而这个服务除了接受请求和返回结果之外,并没有做太多的事情。第二种服务可以在自己的时间里做自己的事情。

这是一个有点棘手的情况,我不认为这是可怕的做你概述的方式,虽然可能有一些维护缺点。

服务器需要知道客户端的地址才能调用它们的WCF服务。一开始这可能不是问题,但是如果您添加客户端或升级客户端,您可能会遇到一些挑战。

如果客户端负责所有的调用,那么当你扩展时,它会更容易维护。

根据你上面的评论,如果你追求的是近乎实时的监控,我对WCF的使用提出了质疑。它可能需要更多的时间来设置(因为不是在截止日期之前),但是从长远来看,您可能会有更好的运气来定制系统。

我可能会使用多播队列解决方案,其中您有一个服务器,但有多个侦听器,然后您的服务器不断在队列中推送项目(可能是文本行),客户机读取它。像AMQP(像rabbitmq), MSMQ(没有使用过,但它是由微软),zeromq等

或者即使是简单的套接字通信也会给你更多的性能,并且你不会有一个框架计时你(看看zeromq,它的工作原理几乎像套接字)。这样客户端可以连接,接收更新,当他们不想要的时候断开。