🧩 Как встроить Kafka в архитектуру, и главное зачем: разбор на примере проекта #GreenChargeGA 🧩
Ранее мы спроектировали схему архитектуры проекта для станций зарядки электро-авто.
Но если в архитектуре не использовать брокер сообщений, а делать прямые синхронные вызовы между микросервисами (через REST/gRPC), могут возникнуть проблемы:
➖ Каждый сервис должен знать о других сервисах: куда слать запросы, в каком порядке, как обрабатывать ошибки доставки
➖ Если хотя бы один сервис при обработке сложного запроса не отвечает, перегружен или упал, исходный запрос зависает или падает с ошибкой
➖ Сложность в аналитике и аудите
Чтобы решить их, в архитектуру встраивают брокеры сообщений.
Давайте разберём как это работает на примере:
👉 Сценарий обработки события окончания зарядки
👉 Без брокера
1. Сервис Телеметрии отправляет запрос на API Gateway об окончании зарядки
2. API Gateway проксирует его на Сервис Платежей
3. Сервис Платежей регистрирует кол-во израсходованной энергии, определяет цену и списывает средства с банковской карты, привязанной к ЛК пользователя
4. Сервис Платежей вызывает Сервис Программы Лояльности для начисления бонусных баллов
5. Сервис Платежей вызывает Сервис Уведомлений для отправки уведомления
6. Возврат ответа на Сервис Телеметрии об успешной обработке события завершения зарядки
❌ Проблема:
Если Сервис Программы Лояльности или Сервис Платежей недоступны, то....? Начинаем "городить костыли" в алгоритме с ретраями (повторами) и не только... 🥲
👉 С брокером Kafka
1. Сервис Телеметрии отправляет событие (сообщение) charging.finished в Kafka об окончании зарядки, в топик charging-events. ✅ На этом он выполнил свою миссию по зарядке и более ничего не ждёт.
2. Сервис Платежей подписан на топик charging-events и событие charging.finished в Kafka. Он забирает оттуда это событие, когда готов и не нагружен (хоть сразу, хоть через 3 часа)
3. Сервис Платежей обрабатывает это событие:
3.1. Регистрирует кол-во израсходованной энергии, определяет итоговую цену и списывает средства с карты
3.2. Отправляет событие о списании средств charging.paid в Kafka, топик charging-events
✅ На этом Сервис Платежей выполнил свою миссию и более ничего не ждёт.
4. На событие charging.paid в топике charging-events подписаны Сервисы Программы Лояльности и Уведомлений.
Когда они будут готовы, то тогда и заберут в обработку событие, и каждый обработает его по отдельности.
✅ Преимущества:
Даже если сервисы Платежей, Лояльности или Уведомлений будут недоступны или будут реагировать ошибкой, необработанное событие об окончании зарядки / завершении платежа будет храниться в брокере и ожидать обработки.
Обычно обработка происходит очень быстро, что процесс выглядит как-будто синхронно, но на самом деле это не так. За счёт брокера мы организовали фоновую обработку событий (=задач), когда один сервис не ждёт завершения работы другого.
Брокер - как временная БД, гарантирует, что событие рано или поздно обработают.
А сервисам, которые участвуют в сценарии, не надо рассчитывать на его строго-последовательное и синхронное выполнение.
👉 Итого получаем:
Внедренный механизм асинхронной обработки событий с использованием Kafka сделал систему более устойчивой к сбоям и гибкой для масштабирования.
Если ещё не изучали Kafka, то здесь можно найти самые важные материалы:
🔗 ссылка
#АрхитектураGA
Ранее мы спроектировали схему архитектуры проекта для станций зарядки электро-авто.
Но если в архитектуре не использовать брокер сообщений, а делать прямые синхронные вызовы между микросервисами (через REST/gRPC), могут возникнуть проблемы:
➖ Каждый сервис должен знать о других сервисах: куда слать запросы, в каком порядке, как обрабатывать ошибки доставки
➖ Если хотя бы один сервис при обработке сложного запроса не отвечает, перегружен или упал, исходный запрос зависает или падает с ошибкой
➖ Сложность в аналитике и аудите
Чтобы решить их, в архитектуру встраивают брокеры сообщений.
Давайте разберём как это работает на примере:
👉 Сценарий обработки события окончания зарядки
👉 Без брокера
1. Сервис Телеметрии отправляет запрос на API Gateway об окончании зарядки
2. API Gateway проксирует его на Сервис Платежей
3. Сервис Платежей регистрирует кол-во израсходованной энергии, определяет цену и списывает средства с банковской карты, привязанной к ЛК пользователя
4. Сервис Платежей вызывает Сервис Программы Лояльности для начисления бонусных баллов
5. Сервис Платежей вызывает Сервис Уведомлений для отправки уведомления
6. Возврат ответа на Сервис Телеметрии об успешной обработке события завершения зарядки
❌ Проблема:
Если Сервис Программы Лояльности или Сервис Платежей недоступны, то....? Начинаем "городить костыли" в алгоритме с ретраями (повторами) и не только... 🥲
👉 С брокером Kafka
1. Сервис Телеметрии отправляет событие (сообщение) charging.finished в Kafka об окончании зарядки, в топик charging-events. ✅ На этом он выполнил свою миссию по зарядке и более ничего не ждёт.
2. Сервис Платежей подписан на топик charging-events и событие charging.finished в Kafka. Он забирает оттуда это событие, когда готов и не нагружен (хоть сразу, хоть через 3 часа)
3. Сервис Платежей обрабатывает это событие:
3.1. Регистрирует кол-во израсходованной энергии, определяет итоговую цену и списывает средства с карты
3.2. Отправляет событие о списании средств charging.paid в Kafka, топик charging-events
✅ На этом Сервис Платежей выполнил свою миссию и более ничего не ждёт.
4. На событие charging.paid в топике charging-events подписаны Сервисы Программы Лояльности и Уведомлений.
Когда они будут готовы, то тогда и заберут в обработку событие, и каждый обработает его по отдельности.
✅ Преимущества:
Даже если сервисы Платежей, Лояльности или Уведомлений будут недоступны или будут реагировать ошибкой, необработанное событие об окончании зарядки / завершении платежа будет храниться в брокере и ожидать обработки.
Обычно обработка происходит очень быстро, что процесс выглядит как-будто синхронно, но на самом деле это не так. За счёт брокера мы организовали фоновую обработку событий (=задач), когда один сервис не ждёт завершения работы другого.
Брокер - как временная БД, гарантирует, что событие рано или поздно обработают.
А сервисам, которые участвуют в сценарии, не надо рассчитывать на его строго-последовательное и синхронное выполнение.
👉 Итого получаем:
Внедренный механизм асинхронной обработки событий с использованием Kafka сделал систему более устойчивой к сбоям и гибкой для масштабирования.
Если ещё не изучали Kafka, то здесь можно найти самые важные материалы:
🔗 ссылка
#АрхитектураGA