Juno/Notes/Zaqar

重新审视统一 API 模型

讨论了两种主要的 API 语义，它们的使用场景，以及我们是否可以支持所有当前的语义以满足高吞吐量用例。

考虑从传输的角度进行批量处理。支持更面向流的协议，例如 WebSocket，将允许流水线化请求，并避免为高吞吐量用例进行连接建立/拆除的成本。也许只为消息消费实现？

关于如何更好地支持不易用 JSON 建模的消息的提案。

我们如何定义“风味”？操作员希望为给定的风味设置哪些属性？

我们讨论了 Marconi 如何用于接收 OpenStack 的 RPC 总线火hose，充当聚合器、规范化器和过滤器，为只想订阅特定类型事件的项目提供服务，并具有稳定且一致的消息模式。

通知服务除了队列服务已经提供的功能之外，还需要什么？

如何在不停止服务的情况下将队列迁移到另一个池？

提出的在给定池中的多个节点之间对单个队列中的消息进行分片的实现方案。

计划一个基准测试工具，可以测试端到端场景。该工具还可以提供“第二意见”来验证 Tsung 基准测试。

讨论了在我们的毕业评审中出现的问题，以及我们计划在 Juno 期间处理它们。

Juno 的粗略计划。