Отправка HTTP-ответа после использования темы Kafka - PullRequest
0 голосов
/ 05 февраля 2019

В настоящее время я пишу веб-приложение, в котором есть множество микросервисов.В настоящее время я изучаю, как правильно установить связь между всеми этими службами, и я решил использовать шину сообщений или, в частности, Apache Kafka.

Тем не менее, у меня есть несколько вопросов, которые я не знаю, как концептуально обойти.Я использую API Gateway-сервис в качестве основного входа в приложение.Он действует в качестве основного прокси для пересылки операций на соответствующие микросервисы.Рассмотрим следующий сценарий:

  1. Пользователь отправляет POST-запрос к шлюзу API с некоторой информацией.
  2. Шлюз создает новое сообщение и публикует его в теме Кафки.
  3. Подписанные микросервисы получают сообщение в теме и обрабатывают данные.

Итак, как мне теперь ответить клиенту со шлюза?Что если мне понадобятся данные из этого микросервиса?Похоже, что HTTP-запрос может истечь.Стоит ли вместо этого придерживаться веб-сокетов между клиентом и шлюзом API?

А также, если клиент отправляет запрос GET для получения некоторых данных, как я должен подходить к этому, используя Kafka?

Благодарю.

Ответы [ 2 ]

0 голосов
/ 05 февраля 2019

Допустим, вы собираетесь создать заказ.Вот как это должно работать:

  1. Традиционно у нас было поле с автоинкрементом или последовательность в таблице RDBMS для создания идентификатора заказа.Однако это означает, что идентификатор заказа не генерируется, пока мы не сохраним заказ в БД.Теперь при записи данных в Kafka мы не сразу записываем в БД, и Kafka не может сгенерировать идентификатор заказа.Следовательно, вам нужно использовать какую-то масштабируемую утилиту генерации идентификаторов, такую ​​как Twitter Snowflake, или что-то подобное с тем, чтобы вы могли генерировать идентификатор заказа еще до того, как написать заказ в Kafka

  2. Как только вы получитеID заказа, напишите одно сообщение о событии по теме Кафки атомарно (все или ничего).Как только это будет успешно выполнено, вы можете отправить клиенту ответ об успешном завершении.Не пишите на несколько тем на этом этапе, так как вы потеряете атомарность, если будете писать на несколько тем.У вас всегда может быть несколько групп потребителей, которые пишут событие для нескольких других тем.Одна группа потребителей должна записать данные в некоторую постоянную БД для запроса

  3. Теперь вам нужно обратиться к операции «прочитайте сами», то есть сразу после получения успешного ответа, который пользователь захочет увидетьприказ.Но ваша БД, вероятно, еще не обновлена ​​данными заказа.Чтобы добиться этого, запишите данные заказа в распределенный кэш, такой как Redis или Memcached, сразу после записи данных заказа в Kafka и перед возвратом ответа об успешном выполнении.Когда пользователь читает заказ, кешированные данные возвращаются

  4. Теперь вам нужно обновлять кэш с последним статусом заказа.То, что вы всегда можете сделать с потребителем Kafka, читая статус заказа из темы Kafka

  5. Чтобы гарантировать, что вам не нужно хранить все заказы в кэш-памяти.Вы можете выселить данные на основе LRU.Если при чтении заказа данные не находятся в кеше, они будут считаны из БД и записаны в кэш для будущих запросов

  6. Наконец, если вы хотите убедиться, что заказТовар зарезервирован для заказа, так что никто другой не сможет его взять, например, при бронировании места на самолете или последней копии книги, вам нужен согласованный алгоритм.Для этого вы можете использовать Apache Zookeeper и создать распределенную блокировку для элемента

0 голосов
/ 05 февраля 2019

Есть ли у вас возможность создать больше конечных точек в шлюзе?

Я бы выделил конечную точку POST только для создания сообщения в очередь Kafka, которое будет использовать другой микросервис.И как возвращенный объект из конечной точки, он будет содержать какую-то ссылку или идентификатор для получения статуса сообщения.

И создаст другую конечную точку GET в шлюзе, где вы можете получить статус сообщениясо ссылкой на сообщение, которое вы получили при создании.

...