Kafka в микросервисах: асинхронная развязка

В прошлом уроке табло Отто собиралось из событий о заказах. Но кто пишет эти события? Сервис заказов «Гонца»: он принимает заказ, сохраняет его в свою базу PostgreSQL и сообщает остальным через Kafka. Сегодня разберём, зачем сервисам общаться событиями, и найдём место, где это общение рвётся чаще всего: стык между базой сервиса и Kafka.

Звонок и письмо

Сервис заказов может сообщить о новом заказе двумя способами. Позвонить: набрать биллинг, дождаться ответа «принято», потом набрать уведомления, потом диспетчерскую. Пока биллинг не взял трубку, заказ стоит. Если биллинг в отпуске, заказ не оформится вовсе.

Или написать письмо в общий почтовый ящик: «заказ 41 создан». Сервис отправил письмо и занялся следующим заказом. Биллинг прочитает письмо, когда сможет. Если он лежал полчаса, письма дождутся его в ящике.

Звонок это синхронный вызов, письмо это событие в Kafka. Мы сравнивали их в уроке про события и команды, и для микросервисов разница решающая.

Асинхронная развязка

Микросервисы «Гонца»: заказы, биллинг, диспетчерская, уведомления. У каждого своя база, и чужую базу никто не трогает. Общаются они событиями через Kafka. Такое общение называют асинхронным: сервис заказов не ждёт, пока остальные обработают событие.

Что это даёт «Гонцу»:

• Падение не заразно. Лежат уведомления, а заказы всё равно принимаются. События ждут в топике.
• Каждый работает в своём темпе. В пятницу вечером биллинг отстаёт на минуту, но заказы от этого не тормозят.
• Новый потребитель без правок. Антифрод подключается к топику, сервис заказов про него не знает.

Плату за это мы уже знаем: потребитель видит событие чуть позже и должен переживать повторы. А ещё есть беда на стороне отправителя, и о ней остаток урока.

Двойная запись

Сервис заказов должен сделать две вещи: сохранить заказ в своей базе и отправить событие в Kafka. Это две разные системы, общей транзакции у них нет. Такую ситуацию называют двойной записью.

Порядок шагов можно выбрать, но сбой посередине ломает любой:

• Сначала база, потом Kafka. Сервис упал после записи заказа. Заказ есть, а события нет. Биллинг не спишет деньги, клиент не получит уведомление, курьера никто не назначит.
• Сначала Kafka, потом база. Сервис упал после отправки. Событие есть, а заказа нет. Биллинг спишет деньги за заказ, которого не существует.

Сервисы падают постоянно: выкатка новой версии, перезапуск контейнера, обрыв сети до Kafka. На тысячах заказов в день такой сбой обязательно случится.