Как использовать Strimzi Kafka Bridge в качестве потокового сервиса
Используя мост Strimzi Kafka Bridge от CNCF, я создал небольшой API, который может взаимодействовать с сервером Kafka с использованием протокола HTTP/1.1. Все это хорошо для сценария запрос-ответ. Однако мое требование состоит в том, чтобы передавать события, полученные в теме Kafka, подписанным клиентам (через мост Strimzi), как только я получаю их, желательно через долгоживущее HTTP-соединение (в соответствии с моим пониманием). Постоянно опрашивать мост на предмет сообщений и возвращаться с пустыми руками - пустая трата ресурсов клиента. Я хотел бы, чтобы сервер Kafka передавал эти события клиенту напрямую.
Я немного не уверен в SSE, Websockets или долгом опросе. Я довольно много читал об этих методологиях потоковой передачи данных клиенту. Однако я не могу понять, связаны ли эти изменения на уровне связи, на уровне приложения или на обоих.
Вы просто создаете API (независимо от технологии) с использованием традиционного протокола связи HTTP и каким-то образом модернизируете его для использования веб-сокетов ИЛИ использование веб-сокетов должно быть встроено в библиотеки приложений с нуля?
При необходимости я могу предоставить дополнительную информацию. На веб-сайте моста Strimzi Kafka ничего не упоминается о "потоковой передаче на стороне сервера" ИЛИ, возможно, я неправильно понимаю истинное назначение инструмента.
2 ответа
HTTP-мост Strimzi Kafka предназначен как "переводчик" для HTTP в собственный протокол Kafka и наоборот. Это означает, что HTTP-клиент должен иметь такое же поведение, что и собственный клиент Kafka, поэтому в случае потребителя он должен проводить опрос для получения сообщений, как это работает изначально Kafka. Imho HTTP 1.1 вообще не предназначен для потоковой передачи.Websockets - это совершенно другой протокол, до которого вы можете перейти, конечно, начиная с HTTP-соединения, но он не поддерживается мостом Strimzi. Фактически, протокол AMQP 1.0, который находится в мосте (как POC), может поддерживать этот тип сценария, таким образом устанавливая соединение и заставляя мост нажимать на это соединение вместо опроса со стороны клиента.
@Nick подумал больше, на самом деле вы можете сделать "длинный опрос". GET на конечной точке / records для получения сообщений имеетtimeoutпараметр в строке запроса. Его значение используется как тайм-аут для внутреннего опроса Kafka в мосте. Он каким-то образом обеспечивает поведение длительного опроса, потому что опрос не возвращается, пока не появятся доступные записи или не истечет время ожидания. Если вы установите высокий тайм-аут, вы можете иметь поведение, которое вы хотите избежать повторного опроса, открывая / закрывая для этого больше HTTP-соединений. Подробнее оtimeout параметр здесь: