Всем привет.
В последние почти 5 лет, довелось поучавствовать в разных ролях над тремя финтех-проектами с микросервисной архитектурой. Работая над последним из них я прочел книгу «Микросервисы. Паттерны разработки и рефакторинга» за авторством Криса Ричардсона и почерпнул оттуда желание реализации транзакционной очереди.
Вопросы:
1 Я уже ознакомился с обеими (`Transaction log tailing` и `Polling publisher`) версиями реализации предложенными Крисом Ричардсоном с использованием таблицы `OUTBOX`. Какие еще альтернативные реализации возможны?
2 Не будет ли это все слишком медленно?
3 Какие реализации/советы возможнны для стека: python, postgres, nats?
4 Я как-то давно видел плагины для postgres с прямой интеграцией толи с Kafka, толи с Rabbit, возможно найду и для nats. Хорошая ли это идея публиковать события в очередь сразу из БД? Я вижу минус в том, что не для каждой БД возможно найти такое решение. У меня в проекте не только postgres, есть и elastic, но пока что в сервисах с ним подобная транзакционность не очень нужна.
UPD
5 Если с паттерном `Polling publisher` все легко и понятно, то паттерн `Transaction log tailing` у меня вызывал и до сих пор вызывает вопросы. Разобравшись, что в случае с postgres речь идет о фоновом чтении из WAL и обработки прочтенных данных я начал искать готовые решения с этим связанные. Казалось что любой информации, кроме теоретической нет, но мне стало часто попадаться на глаза упоминание ETL-паттерна "Захват изменения данных" (Change Data Capture). Я нашел несколько готовых опенсорсных решений (
Debezium,
Wso2), которые реализуют этот паттерн и с одной стороны могут собирать данные из WAL, а с другой - передавать их в nats/kafka и т.д. Мне кажется, что это то что нужно. Теперь сам вопрос: как удалять обработанные данные из таблицы `OUTBOX`, после того как они будут доставлены в брокер CDC-инструментом?
Ниже описание почему я хочу попробовать...
Так или иначе мы во всех проектах использовали паттерны "Повествования" (Saga) и "Порождение событий" (Event Sourcing), которые в процессе своего исполнения вводят всю систему в состояние "отложенной согласованности". Это состояние когда каждый сервис согласован сам по себе, но в масштабах всей системы в части сервисов операция уже исполнена, а в другой - еще нет.
По большому счету это нормально и совершенно не страшно, потому что "в идеальном мире" операция в конечном итоге придет в согласованное состояние если не было ошибок. Если же ошибки возникли, то запустятся компенсируюущие транзакции, которые также вернут систему в согласованное состояние.
Однако, все три проекта не редко впадали в ситуацию, когда они не могли выйти из состостояния состояния отложенной соглассованности сами. Другими словами, иногда для того, чтобы та или иная операция окончательно выполнилась или откатилассь назад, ее приходилось "пнуть". Пинал ее либо автоматизированный механизм `health-check-poller`, который искал такие зависшие операции, либо сотрудник второй линии поддержки. после чего процесс продолжался и приводил транзакцию в согласованное состояние.
Почти всегда проблема была связана с тем, что один сервис обработал свою часть саги, внес правки в БД и не смог уведомить об этом остальную систему, т.е. не опубликовал событие в очередь. Крис Ричардсон утверждает, что оба паттерна "Повествования" и "Порождение событий" должны быть реализованы через транзакционные очереди, тем самым гарантируя, что сервис возмет сообщение из очереди брокера и либо исполнит бизнес логику, информирует остальных участников и пометит сообщение как отработанное удалив его из очереди брокера, либо не сделает ни того, ни другого и вернет сообщение в очередь брокера.
Теперь я убежден, что наличие транзакционной очереди должно сильно увеличить надежность системы и снизить затраты на поиски проблем и поддержку.
Спасибо!
Средний
