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

Question

问题

一段时间以来，我一直在思考基于消息的架构的复杂性，当消息传递的一个渠道包括互联网时。

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

这个例子

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

例如

1. 用户在具有严格SLA的网站上创建紧急订单，以便在几分钟内进行拣选，因为有人已经开始收集物品。
2. OrderCreated消息在服务器上发布。
3. Magic恰好将OrderCreated消息发送到仓库中PC上运行的客户端软件。
4. 客户端软件在屏幕上显示新订单（如果重新启动等，可能会缓存到磁盘）。
5. 仓库团队挑选物品以完成订单。

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

可能的解决方案

1. 定期和经常轮询服务器（小时）以查看是否有消息，并将它们下载到本地队列进行处理。
2. 在WCF中使用类似双向通信的东西，虽然这需要在客户端和服务器之间永久保持通道/套接字/端口等，因此它不会优雅地扩展。
3. 实际上在本地站点中打开端口并配置端口转发和防火墙等，以启用MSMQ（或其他一些技术，如WCF，这可能意味着在客户端硬件上托管IIS或类似的东西）将消息推送到客户端。 当然，这里的部署和支持成本是天文数字。

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

提前谢谢了。

Answer 1

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

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

轮询方法确实会产生更多不必要的网络流量，但如果您通过单个服务器进行扩展可能会更好。 在我看来，您可以使用现有技术相当容易地扩展到Web场，如果您使用轮询方法，这种扩展（我认为）会更容易。 不过，我从来没有必须扩大规模。

我没有使用MSMQ进行此类通信，但使用了IBM的WebSphere（类似的技术）。 消息队列有自己的一系列自动化问题，例如处理死信队列等。如果您希望服务器关闭一段时间（或者如果您在客户端和服务器之间有不可靠的“中间件”），这将非常有用），但一般来说，我更喜欢通过套接字或WCF进行双向通信。

Answer 2

也许在JMS之后构建一些东西（甚至只是为现有的.net服务器构建一个JMS适配器，然后直接使用JMS）？ 在中，您可以让客户端维护与通知服务器的持久套接字连接（如果您正在考虑每分钟多次轮询服务器，那么为什么不保持套接字打开？）。 当建立套接字时，连接客户端可以订阅/注册它有兴趣接收的任何事件（例如“我只想要与仓库A中的产品相关联的事件”）。 然后，当在服务器上发布OrderCreated消息时，服务器可以查看其客户端列表以查看谁为该消息注册，并立即通过相应的套接字连接向客户端发布通知。

Answer 3

这是我之前使用（3或4年前）创建即时消息程序的简短代码段。 它创建一个可以接受来自服务器的消息的TcpListener ，以及一个NetworkStream和TcpClient来向服务器发送消息。 它可能不是一个完整的答案，但它可能有助于指导您。

Answer 4

我会使用TCP和回调的WCF服务。

是什么让你说它不规模？

Answer 5

我目前正致力于一些非常相似的事情，需要通过互联网及时将消息传递到DSL路由器/调制解调器后面的客户端软件，并可能绑定到动态IP地址。 频繁的轮询是我们选择的解决方案，在性能和简单性之间取得平衡。

Answer 6

看看WebSockets - 它还没有，但它的目的是成为Comet / long-poll技术的继承者。 它旨在实现Web浏览器，但没有理由不能在其他类型的客户端中使用。