.net - 互联网上基于客户端/服务器消息的架构

Question

问题

当消息传递的 channel 之一包括互联网时，我一直在思考基于消息的架构的复杂性。

我对在客户端上排队消息的概念很好，当处理这些消息时，会导致通过 Internet 进行 Web 服务调用，然后将这些相同的消息在服务器上排队以根据业务规则进行处理。我目前不知道的是一种发送消息的机制返回 告诉客户发生了什么事。

这个例子

对于这个例子，考虑一个桌面仓库管理应用程序，它希望从服务器接收消息，而不是轮询以查看是否有任何消息。

例如。

用户在具有严格 SLA 的网站上创建紧急订单，以便在几分钟内进行拣货，因为有人已经在去取货的路上。

OrderCreated消息在服务器上发布。

魔术恰好发送OrderCreated向在仓库中的 PC 上运行的客户端软件发送消息。

客户端软件在屏幕上显示新订单(并且可能在重新启动等情况下缓存到磁盘)。

仓库团队挑选元素以完成订单。

上面的第 3 点是我正在寻找填补空白的技术。

一些可能的解决方案

定期和经常(分分钟)轮询服务器以查看是否有消息，并将它们下载到本地队列进行处理。

在 WCF 中使用双向通信之类的东西，尽管这需要 channel /套接字/端口等在客户端和服务器之间保持永久打开，因此它不会优雅地扩展。

实际上，在本地站点中打开端口并配置端口转发和防火墙等，以启用 MSMQ(或其他一些技术，如 WCF，这可能意味着在客户端硬件上托管 IIS 或类似技术)将消息推送到客户端。当然，这里的部署和支持成本是天文数字。

有没有人有使用我未在此处列出的解决方案来实现此目的的经验？我不一定要寻找细节，我只是在这个空间里四处寻找，看看它是如何完成的。

提前谢谢了。

Answer 1

我在自动化领域有很多经验，我会说轮询和双向通信是最常见的。

在这两者中，我一直更喜欢双向通信。它确实可以很好地扩展到某个点 - 只要服务器使用异步 API(特别是不使用“每个连接一个线程”设计可憎)，数万个套接字/WCF 连接是可能的。

轮询方法确实会产生更多不必要的网络流量，但如果您正在扩展单个服务器，它可能会更好。在我看来，您可以使用现有技术相当容易地扩展到网络场，如果您使用轮询方法，这种扩展(我认为)会更容易。不过，我从来不需要扩展那么远。

我没有使用 MSMQ 进行这种类型的通信，但使用了 IBM 的 WebSphere(一种类似的技术)。消息队列有其自身的一系列自动化问题，例如处理死信队列等。如果您希望服务器停机一段时间(或者如果您在客户端和服务器之间有不可靠的“中间件”)，这很有用)，但总的来说，我更喜欢通过套接字或 WCF 进行双向通信。