发布/订阅REST-HTTP简单协议Web服务体系结构？

Question

我问你对"架构"场景的看法:

我正在寻找一个最简单的发布/订阅架构,让我们在互联网上讨论两个分离的服务器,共享"稀疏"但"实时"的消息/事件.

让我解释:

• PUBLISHER:是一个生成某种事件的服务器(http://www.server.com)(通过电子商务网站上的例如events == ORDERS数据).

• 订阅者(一个或多个):"客户"是否可以订阅以接收ORDERS事件(http://www.client.com).

在现实生活中,发布者是由第三方开发的服务器(在Rails中).目前,我可以通过简单的"轮询"策略将"订单"与其接口:每隔N秒我调用一次GET/new_orders.

坏!

所以我正在考虑使用REST方法更好的发布/订阅架构,其中Publisher共享EVENTS资源:

• 客户端订阅接收事件,向发布者提供将来要调用的"URL HOOK"(例如:http://www.client.com/orders).

• 发布者,当有新事件(==订单)时,只需将HTTP POST数据发送到客户端之前提供的客户端URL Hook.

合理 ？或者我正在重新发明轮子？

顺便说一下,我用Ruby语言开发,我知道pub/sub消息系统就像Faye.但你怎么看待这个简单的协议(我想简单地使用Ruby/Sinatra实现客户端)？(见图1)

欢迎任何建议.非常感谢

乔治

Answer 1

任何时候您可以让第三方 POST 到您的网络服务，这都是一件好事！很多时候，这不是一个选择，您必须求助于某种低效的轮询架构。我不认为你的架构图有什么问题。

您始终可以使用第三方消息传递系统（Amazon SQS、RabbitMQ 等），但没有太多理由这样做，除非您需要持久的消息传递。

编辑：

如果您担心 HTTP 流量（具体来说，对 Web 服务的调用数量），您还可以鼓励第三方支持批量 POST。也许他们只能每 5 分钟向订阅者发送一次新订单作为批次的一部分。