Должны ли системы переноса состояний, переносимые с помощью события Кафки, использовать GlobalKTable для локальных запросов? - PullRequest
Новая
       41

Должны ли системы переноса состояний, переносимые с помощью события Кафки, использовать GlobalKTable для локальных запросов?

1 голос
/ 06 апреля 2019

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

. Предположим практический случай:

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

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

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

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

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

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

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

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

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

1 Ответ

2 голосов
/ 08 апреля 2019

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

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

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

Относительно ваших индивидуальных вопросов:

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

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

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

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

...