ruby – 发布/订阅REST-HTTP简单协议Web服务架构？

发布时间：2020-12-16 21:02:23 所属栏目：百科来源：网络整理

导读：我问你对“架构”场景的看法：我正在寻找一个最简单的发布/订阅架构,让我们在互联网上讨论两个分离的服务器,共享“稀疏”但“实时”的消息/事件. 让我解释：出版商：是一个生成某种事件的服务器(http://www.server.com)(例如 events ==电子商务网站上的OR

我问你对“架构”场景的看法：

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

让我解释：

>出版商：
是一个生成某种事件的服务器(http://www.server.com)(例如
events ==电子商务网站上的ORDERS数据).
>订阅者(一个或多个)：
是“客户”可以订阅接收ORDERS事件(http://www.client.com).

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

坏！

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

>客户订阅接收事件,提供给发布者a
将来要调用的“URL HOOK”(例如：http://www.client.com/orders).
>发布者,当有新事件(==订单)时,只需HTTP POST数据
到客户端之前提供的客户端URL挂钩.

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

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

欢迎任何建议.非常感谢

乔治

任何时候你都可以让第三方发布你的网络服务,这是一件好事！很多时候,这不是一个选项,你必须采用某种低效的轮询架构.我认为您的架构图没有任何问题.

您可以随时使用第三方消息传递系统(Amazon SQS,RabbitMQ等),但除非您需要durable messaging,否则没有太多理由这样做.

编辑：

如果您担心HTTP流量 – 特别是对您的Web服务进行的呼叫数量 – 您还可以鼓励第三方支持批量POST.也许他们只能每5分钟向订户发送新订单作为批次的一部分.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!