Кафка условного производства / потребления

Question

У меня такая ситуация:

• В микросервисе MS1 есть БД, скажем, с N записями, а внешний источник предоставляет новые данные, которые, если они действительны, следует сохранить

• процесс проверки выполняется микросервисом MS2, который является пользователем темы кафки T1, по которой MS1 отправляет новые данные

• подтверждениеПотенциальная N + 1 запись включает в себя запрос по всем предыдущим N записям. Если проверка прошла успешно, MS2 выдает результат по теме T2, по которой MS1 является потребителем, поэтому она может сохранять новые действительные данные.

Проблема заключается в следующем.

Представьте, что N + 1 действительных новых данных слишком велик и требует много времени для записи на БД: может случиться так, что проверка потенциальной N + 2 записи не удастся, потому что запрос к БДдоступно только N доступных записей вместо N + 1.

Возможно ли, используя каким-либо образом возможности kafka, приостановить процесс проверки до тех пор, пока MS1 не передаст предыдущие действительные данные в БД?

Не используя kafka, единственный способ, который я нашел для обеспечения запросов проверки на актуальную БД, - это сделать вызов покоя между двумя микросервисами, чтобы дождаться ответов друг друга.

Буду признателен за любую помощь или новое решение.

Спасибо!

Answer 1

Исходя из вашей информации, которую вы предоставили здесь, я думаю, что у вас есть 3 варианта, что вы могли бы сделать здесь:

1. Дублируйте логику проверки MS2 в MS1

2. Извлечение логики проверки MS2 в разделяемую библиотеку

3. Вызов микросервиса MS2 из MS1 напрямую с помощью вызова Rest

---

Объяснение опций:

1. Логика валидации является одной из важных частей бизнес-логики и всегда должна быть частью того же микросервиса, который сущности/ Агрегаты проверены. Сначала дублирование звучит странно и, возможно, даже неправильно, но в этом случае оно экономит много накладных расходов по сравнению с наличием в двух микро-сервисах. Для этого вам нужно будет только повторно развернуть MS1 (чтобы ответить на ваш комментарий сверху). Имейте в виду, что в противном случае сетевое взаимодействие между двумя микро-сервисами принесет вам много проблем, таких как: производительность, задержки, сбои в сети, распределенные транзакции и др.

2. Извлечение общего общегопроверка логики для некоторой библиотеки (например, в .NET nuget, в Node.js npm ...) и включение ее в качестве пакета в ваш микросервис MS1 также является опцией. Таким образом, вы не будете дублировать код во всех микро-сервисах, но если ваше бизнес-требование для некоторых проверок изменится, вам нужно будет внести изменения для всех микро-сервисов. Если это произойдет, вам нужно будет переделать библиотеку и / или извлечь часть кода обратно в микросервис инициатора.

3. Вызов MS2 из MS1 напрямую с использованием REST API может быть завершенКомандный или Query подход (пожалуйста, прочитайте этот ответ для объяснения путей взаимодействия между микро-сервисами). Нет ничего плохого в том, чтобы вызывать один микро-сервис из другого через REST, и в некоторых случаях у вас нет другого выбора. Тем не менее, имейте в виду, что у вас будут некоторые задержки при вызове другого API для проверки.

Заключение

Я настоятельно рекомендую вамиспользовать опцию 1. и продублировать логику валидации от MS2 до MS1. Валидация является частью логики домена и должна быть в том же микросервисе, для которого у вас есть логика. Может случиться, что эта или аналогичная логика проверки применима для других микросервисов, но каждая микросервис должна иметь свою собственную реализацию. Вариант 2. в основном используется для некоторых не зависящих от бизнеса вещей, таких как общая тестовая инфраструктура, общий доступ к базе данных (классы репозитория), общий механизм связи и так далее. Вариант 3. лучше, если вы хотите позвонить в другой микро-сервис, чтобы получить некоторую информацию или отправить какую-то команду, например (зарезервируйте этот продукт для меня или аналогичный), но для проверки я бы этого не стал. Абсолютно необходим дополнительный сетевой вызов только для проверки.