Должны ли системы передачи состояния Kafka быть реализованы с использованием GlobalKTable для локальных запросов?

Передача состояния, переносимого по событию, устраняет необходимость совершать удаленные вызовы для запроса информации от других услуги.

Возьмем практический случай:

  1. У нас есть служба поддержки клиентов, которая публикует CustomerCreated/CustomerUpdated события по теме Kafka для клиентов.

  2. Служба доставки прислушивается к теме заказа

  3. Когда OrderCreated событие считывается службой доставки, ей потребуется доступ к адресу покупателя. Вместо того, чтобы делать REST-вызов в службу поддержки клиентов, служба доставки уже будет располагать информацией о пользователе локально. Он хранится в _3 _ / _ 4_ с постоянным хранилищем.

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

Мы могли бы найти такие сценарии: событие OrderCreated(orderId=1, userId=7, ...) считывается службой доставки, но если она использует KTable для хранения и доступа к информации локального пользователя, userId=7 может не присутствовать, потому что раздел, который обрабатывает этот идентификатор пользователя, мог быть назначен другому экземпляр службы доставки.

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

  1. Это (GlobalKTable) рекомендуемый подход для реализации этого шаблона?

  2. Является ли проблема реплицировать весь набор данных о клиентах в каждом экземпляре службы доставки, когда количество клиентов очень велико?

  3. Можно ли каким-то образом реализовать этот / этот случай с использованием KTable?


apache-kafka apache-kafka-streams event-driven event-driven-design
person codependent    schedule 06.04.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Вы можете решить эту проблему как с GKTable, так и с KTable. Прежняя структура данных реплицируется, поэтому вся таблица доступна на каждом узле (и занимает больше места для хранения). Последний разделен, поэтому данные распределяются по различным узлам. Это имеет побочный эффект, заключающийся в том, что, как вы говорите, раздел, обрабатывающий userId, может также не обрабатывать соответствующего клиента. Вы решаете эту проблему, перераспределяя один из потоков таким образом, чтобы они были совместно разделены.

Итак, в вашем примере вам нужно обогатить события Order информацией о клиенте в службе доставки. Вы можете: a) использовать GlobalKTable информации о клиенте и присоединиться к ней на каждом узле b) использовать KTable информации о клиенте и выполнить ту же операцию, но перед выполнением обогащения вы должны повторно ввести ключ с помощью оператора selectKey(), чтобы убедиться, что данные совместно разделены (т.е. одни и те же ключи будут на одном узле). У вас также должно быть одинаковое количество разделов в темах «Клиент» и «Заказы».

Пример службы инвентаризации в примерах Confluent Microservices делает нечто подобное. Он изменяет ключи потока заказов, чтобы они были разделены по productId, а затем присоединяется к KTable Inventory (также с ключом productId).

По вашим индивидуальным вопросам:

  1. GlobalKTable рекомендуемый подход для реализации этого шаблона? Оба работают. GKTable имеет более длительное время перезагрузки в худшем случае, если ваша служба по какой-либо причине теряет хранилище. У KTable будет немного большая задержка, так как данные должны быть перераспределены, что означает запись данных в Kafka и их повторное чтение.

  2. Есть ли проблема реплицировать весь набор данных о клиентах в каждом экземпляре службы доставки, когда количество клиентов очень велико? Основное отличие - вышеупомянутое время перезарядки в худшем случае. Хотя технически GKTable и KTable имеют немного разную семантику (GKTable загружается полностью при запуске, KTable загружается постепенно в зависимости от времени события, но это не имеет прямого отношения к данной проблеме)

  3. Можно ли это / следует ли каким-либо образом реализовать этот случай с использованием KTable? См. Выше.

См. Также: Примеры микросервисов, Быстрый старт, Сообщение в блоге.

person Ben Stopford    schedule 08.04.2019
comment
Привет, Бен, спасибо за четкое объяснение и все полезные ссылки! - person codependent; 09.04.2019