Zaqar 的通知语义

从 API 语义的角度来看，Zaqar 的目标之一是提供对推送通知的支持——或者说订阅。在向 Zaqar 的 API 添加所有与队列相关的语义之后，我们可以开始添加支持其他建立在现有语义之上的功能，例如本规范中提到的功能。

https://blueprints.launchpad.net/zaqar/+spec/notifications

其他参考资料：- https://etherpad.openstack.org/p/marconi-notifications-brainstorm - https://etherpad.openstack.org/p/juno-marconi-notifications-on-marconi - https://etherpad.openstack.org/p/IcehouseMarconiNotificationService - https://www.dropbox.com/s/d2q1viz4ejebg24/marconi-notifications.png

问题描述

Zaqar 支持队列语义，允许用户发布和消费消息到服务以及从服务获取消息。这些语义涵盖了几个用例，但它们遗漏了其他用例，例如“监听”消息。除了生产者/消费者场景之外，还有许多需要支持的发布/订阅用例。一些例子包括：移动推送通知、支持事件触发、计量等。

为了涵盖上述场景，Zaqar 需要提供一个 API，允许用户订阅特定的队列并从那里获取消息，而无需轮询。这将允许客户端更好的架构，在连接管理方面提供 Zaqar 和客户端之间更可靠的交互，并且也为支持其他场景打开了大门。

提议的变更

建议扩展 Zaqar 的 API 以支持订阅，而无需添加单独的服务——请参阅下面有关合并两项服务的章节。本提案介绍了实现此功能所需的高层更改，但详细的 API 规范尚未编写。

以下是支持通知所需的资源列表（非详尽）

订阅 (Subscriptions)：订阅定义了订阅者想要监听的内容。它包含队列/主题的数据、路由参数、最大重试次数以及正确过滤消息和保持高层保证所需的其他配置。

订阅者使用订阅来监听内容。非持久订阅者——例如 Webhooks、短信、移动推送协议——在订阅本身中配置，而使用持久连接的其他订阅者可以加载他们想要监听的特定订阅。

订阅由一个对象组成，其中包含有关来源、目标、过期时间和通知者有用的自定义字段的信息。

POST /v2/queues/{queue_name}/subscriptions

{
    'subscriber': 'http://trigger.me',
    'ttl': 3600,
    'options': {}
}

  • 来源 (source)：通知的源队列

  • 订阅者 (subscriber)：订阅者 URI。它可以是任何受支持的订阅者 URI，并且实现必须基于 stevedore 以允许外部贡献。

  • TTL (ttl)：此订阅的生存时间。它是一个正数，以秒为单位表示订阅应该存在多长时间。如果省略，订阅将不会过期。

  • 选项 (options)：发布者特定的选项。

发布者 (Publishers)：发布者是向通知端点发布消息的用户和/或第三方资源。向 Zaqar 发布消息的用户不需要为此使用任何专门的端点。消息必须通过正常的且已实现的的消息发布 API。但是，第三方发布者需要特定的配置。第三方发布者从其他服务消费消息并在 zaqar 的队列中发布它们。

工作者 (Workers)：发布任务需要在分布式（或节点本地）方式下执行，它们需要可靠、容错和原子性。为此，我评估了 taskflow 作为这项工作的有效库。Taskflow 支持本地/分布式、阻塞/并发任务执行。它提供对多种执行模型、持久性层（包括 sqlite、mysql 和 zookeeper）的支持，并且支持重试。Taskflow 的替代方案是编写我们自己的实现来完成这项工作，但目前看来不值得。

推送协议

可以支持几种类型的推送技术，因此实现必须足够通用，以便轻松进行新的实现，并且也可以作为外部插件进行实现。

尽管如此，本规范建议首先只从下面提出的插件开始

  • Webhooks

  • Email

  • 移动推送

  • 短信

为什么不使用两个服务

Zaqar 从一开始就声明它为其他云服务（如 AWS）在两个单独的服务中拥有的东西提供一个通用的 API。尽管如此，我认为将这两个 API 置于同一服务下的真正动机是

  • 维护：维护和扩展一个服务类型比一组不同的服务更容易。

  • 一致性：这将有助于减少实现通知 API 所需的代码，因为它们都将在相同的结构下运行，并且用户将知道在哪里可以找到服务。

  • 性能：在单独的服务中实现通知 API 将需要该服务与队列服务之间的通信。至少，它需要后端不断轮询（如果它本身不支持推送）。通过将所有内容置于同一服务下，我们可以随着消息的到来触发通知。

未来改进

  • 支持订阅确认

备选方案

  • 将上述内容拆分为两个不同的服务。如前一节所述，两个服务似乎不是此问题的理想解决方案。

实现

负责人

主要负责人

flwang

次要分配人

flaper87

里程碑

完成目标里程碑

Kilo-2

工作项

  • 完成详细的 API 规范

  • 编写通知的存储代码

  • 在存储代码之上实现 API。

  • 处理发布者

依赖项

无

注意

本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode