Комментарии 21
Рад увидеть вашу публикацию на хабре, получился качественный материал.
Я во многом разделяю ваши взгляды на архитектуру, выбор технологий и работу с командой.
К статье лишь хотел бы добавить пару уточнений:
У Cadence есть опенсорсная версия temporal.io.
И cadence, и temporal.io в свободном доступе под лицензией MIT.
Очередей хочется много: по одной очереди на каждого пользователя, на каждый бизнес-процесс, в том числе и на каждый платеж, который еще не завершен. В результате одновременно в системе нужны несколько миллионов очередей. Впрочем, все эти очереди довольно небольшие — каждая не более тысячи событий.
У Kafka до недавнего времени было жесткое ограничение на количество партиций (независимых очередей, для которых сохраняется требование FIFO). Сейчас его сняли, но все равно поддерживать миллион партиций в Kafka очень непросто для эксплуатации.
В Kafka партиция служит, скорее, как единица параллелизма записи/чтения сообщений, и количество партиций определяется по требованию пропускной способности для producer & consumer.
Топик, логическое представление об очереди, по-классике проектируется под один тип сообщения, а идентифицировать принадлежность события к объектам системы целесообразнее in-place из атрибутов ключа/значения сообщения - главное, правильно выбрать стратегию партиционирования для равномерного распределения сообщений и упорядоченной обработки.
А можете в двух словах раскрыть стек ABAC?
С нетерпением буду ждать отдельной публикации про имплементацию ABAC, подписался на вас.
Про Cadence - спасибо за замечание, все правильно. Я слышал, что и внутри Uber потихоньку переходят на temporal, но не знаю, как эти слухи соотносятся с действительностью.
Про kafka.
Для описанных задач каждая из миллионов очередей - это про набор сообщений, которые нужно обрабатывать в порядке их появления, при этом возможность обработки события не гарантирована (и сама обработка не быстра). Например, если взять очередь событий для отправки на клиента, то я не могу взять "верхнее", выяснить что связь с клиентом сейчас отсутствует и выкинуть его, мне нужно или его обработать или остановить выборку всей партиции.
И гарантии последовательности обработки в кафке именно для партиции, так что если нам нужно "10 mln последовательностей обработки", то нужно 10 mln партиций (
Поэтому и пришлось разделить сущности, когда упорядоченный набор событий живет в FDB, а список "нужно что-то обработать из этой очереди" - в kafka (и для событий в kafka порядок обработки уже не важен, поэтому партиции становятся, как правильно заметили, именно единицей параллелизма).
Понятно, что для каждого отдельного кейса (события клиенту, события внутри Haydn, большие задачи типа отчетов) можно придумать какие-то свои специальные решения, но это будет сложнее для разработчиков, нежели "взять событие и обработал". А архитектура - это про управление сложностью )
Интересно узнать как вы тестируете миграции в такой специфичной базе данных?
Зависит, конечно, от миграций.
Если речь идет про "изменили структуру value, нужно избавиться от данных со старой версии структуры" (большинство миграций именно таких), то тут нужно протестировать логику миграции отдельной записи, это достаточно просто (остальное сделает уже migration tool).
Для "добавить индекс" есть уже один раз написанный код, там тоже все довольно просто.
А вот если какие-то сложные преобразования (объединение "таблиц", изменение связей), то для каждого сценария придумываем набор тестов на разных уровнях.
Если честно, не вижу разницы между миграциями на FoundationDB и на PostgreSQL, в любом случае это же будет не update Payments set newPrice = price*2, а обновление небольшими блоками с привязкой к версии структуры.
Много одновременно живущих очередей несложно сделать на PostgreSQL или другой современной СУБД
Подтверждаю) кому нужны очереди на Java для любой из популярных РСУБД добро пожаловать https://github.com/yoomoney/db-queue
?
Только одно но, kafka вы сможете горизонтально смаштабировать до неограниенного кластера, а сервер СУБД - нет, упретесь в ограничение материнки. Особенно такой тупой как postgresql
Ну, не всегда нужно уметь масштабировать (да и далеко не все можно горизонтально масштабировать на kafka - то же число партиций).
На PG вполне нормально получить несколько тысяч message-per-second на недорогом железе и при этом получить хорошие гарантии и избежать необходимости в CDC и прочих тонкостях взаимодействий СУБД и очередей.
Как всегда, все упирается в НФТ
Расскажите как решить задачу отложенного выполнения задач при помощи kafka? Скажем сделать гарантированный возврат платежа через час.
Ну, конкретно решение от Яндекс.Денег меня не всегда устраивает по возможностям, я бы скорее свое сделал (благо там делать особо нечего, два простых запроса и несколько сотен строк кода). Ну и я как-то подробно рассказывал, как делать очереди на Pg или другой БД с skip locked.
Если можно кратко - то чем не устраивает? Я не встречал такого фидбека, он был бы полезен для развития.
Когда я последний раз смотрел (года четыре назад) мне не хватало разных вариантов обработки ошибки (заблокировать топик, отложить топик, переложить событие в конец топика и так далее - там много вариантов бывает) и смущала схема с одной таблицей.
Кстати, интересно, решение от ЯДа когда-то проросло из нашего с Яшей Сироткиным кода или независимо. Но за эти годы оно, конечно, сильно выросло, да и мы делали под Oracle.
В 2020 году Филипп сам очень ярко этот доклад читал. Он и сам по себе удивительный рассказчик. Но сейчас по истечении почти 2 лет печатать эту 'осетрину второй свежести' как то моветон. Рынок сильно ушёл вперед
Это два разных доклада.
Два года назад я рассказывал про предыдущий проект, там как раз PG и персистентные акторы, а эта статья и доклад на HL2021 - про следующий проект, который я делал. Другой контекст, другие требования, другой я - и, как следствие, другой стек и другие арх.решения. Общего - только домен.
Ну и для меня главное в докладе - не про технические детали, а скорее про то, как подходить к архитектуре.
Ведущий специалист по распределенным системам и создатель популярных Jepsen тестов на вопрос о тестировании Foundation DB» ответил: «Haven't tested foundation in part because their testing appears to be waaay more rigorous than mine» (с) Kyle Kingsbury (@aphyr). Сложно придумать рекламу лучше.
Если кому-то интересно, то тесты Jepsen делала стажёр в FoundationDB и написала отчёты об этом:
Кошелек с нуля в 2020 году: технологии, вызовы, решения