Расширение ответа Константина:
TLDR;
Хвост / майнинг журнала транзакций должен быть скрыт от других.
Это не совсем событие- поток, так как вы не должны получать к нему доступ напрямую из других сервисов.Обычно он используется при постепенном переходе от устаревшей системы к микроуслугам.Поток может выглядеть следующим образом:
- Служба A фиксирует транзакцию в БД
- Платформа или служба опрашивает журнал фиксации и отображает новые коммиты в Kafka как события
- Служба B подписана на поток Kafka и получает события оттуда, а не из БД
Более длинная история:
Служба B не видитчто ваше событие происходит из БД и не имеет прямого доступа к БД.Данные фиксации должны быть спроецированы в событие.Если вы изменяете БД, вам следует только изменить свое правило проекции, чтобы сопоставить коммиты в новой схеме со «старым» форматом событий, поэтому нельзя менять потребителей.(Я не знаком с Debezium, и может ли он делать эту проекцию).
Ваши события должны быть идемпотентными, так как публикация события и фиксация транзакции атомарно - это проблема в распределенном сценарии, и инструменты гарантируют- по крайней мере один раз с семантикой обработки ровно один раз, а часть с одним разом встречается реже.Это связано с тем, что источник события (журнал транзакций) не совпадает с потоком, к которому будут обращаться другие сервисы, то есть он распространяется.И это все еще часть производителя, та же проблема существует с Kafka-> потребительским каналом, но по другой причине.Кроме того, Кафка не будет вести себя как хранилище событий , поэтому вы достигли очереди сообщений.
Я рекомендую вместо этого использовать выделенное хранилище событий, если это возможно, как у Грега Янга: https://eventstore.org/. Это решает проблему путем интеграции хранилища событий и брокера сообщений в единое решение.Сохраняя событие (в JSON) в потоке, вы также «публикуете» его, так как потребители подписаны на этот поток.Если вы хотите дополнительно разделить сервисы, вы можете написать прогнозы, которые отображают события из одного потока в другой поток.Использование этого события также должно быть идемпотентным, но вы получите хранилище событий, которое разделено на агрегаты и довольно быстро читается.
Если вы тоже хотите сохранить данные в БД SQL, прослушайте эти события и вставьте / обновите таблицы на их основе, просто не используйте свою БД SQL в качестве хранилища событий, потому что это будет сложноправильно реализовать (безошибочное).
Для упорядочивания: упорядочить чтение событий из одного потока.Прогнозы, которые объединяют несколько потоков событий, могут гарантировать только упорядочение между событиями, происходящими из одного потока.Обычно этого более чем достаточно.(кстати, вы можете при необходимости переупорядочить сообщения на основе некоторого поля на стороне потребителя.)