2

使用 CNCF 的 Strimzi Kafka Bridge，我创建了一个小 API，可以使用 HTTP/1.1 协议与 Kafka 服务器交互。这对于请求-响应方案来说都是好事。但是，我的要求是，一旦我最好在长期 HTTP 连接上接收到事件（根据我的理解），就将在 Kafka 主题上接收到的事件流式传输到订阅的客户端（通过 Strimzi 桥）。不断地轮询网桥以获取消息并空手而归，这是对客户端资源的浪费。我希望 Kafka 服务器直接将这些事件流式传输到客户端。

我对 SSE 或 Websockets 或长轮询有点不确定。我对这些将数据流式传输到客户端的方法进行了大量阅读。但是，我无法弄清楚这些变化是在通信层还是应用层，还是两者兼而有之。

您是否只是使用传统的 HTTP 通信协议构建 API（无论技术如何）并以某种方式将其升级为使用 Websockets 还是应该将 Websockets 的使用嵌入到您的应用程序库中？

如果需要，我可以提供更多信息。Strimzi Kafka 桥网站没有提到任何关于“服务器端流”的内容，或者我可能误解了该工具的真正目的。

4

2 回答 2

3

Strimzi Kafka HTTP 桥接器是 HTTP 到 Kafka 原生协议的“转换器”，反之亦然。这意味着 HTTP 客户端必须具有与本机 Kafka 客户端相同的行为，因此，对于消费者而言，进行轮询以获取消息，这就是 Kafka 的本机工作方式。恕我直言，HTTP 1.1 根本不适合流式传输。Websockets 是一个完全不同的协议，您当然可以从 HTTP 连接开始升级到它，但 Strimzi 桥不支持它。实际上，桥接器中的 AMQP 1.0 协议（作为 POC）可以支持这种情况，因此建立连接并让桥接器推送该连接而不是从客户端轮询。

于 2019-10-05T09:51:15.213 回答
1

@Nick 想多了，实际上你可以做“长轮询”。/records 端点上用于获取消息的 GET 在timeout查询字符串上有一个参数。它的值用作桥中内部原生 Kafka 轮询的超时。它以某种方式为您提供了长轮询行为，因为在有可用记录或超时到期之前轮询不会返回。如果你设置了一个高超时，你可以有你想要的行为来避免轮询更多次，为此打开/关闭更多的 HTTP 连接。此处参数的更多详细信息timeout：

https://strimzi.io/docs/bridge/latest/#_poll

于 2019-10-07T07:57:02.837 回答