1763479402
2025-11-18 15:11:00
Во время QCon San Francisco 2025 Джереми Эдберг и Цянь Ли от ДБОС представил нетрадиционный архитектурный подход к оркестровке рабочих процессов: рассматривать PostgreSQL не только как хранилище данных, но и как сам уровень оркестрации. В их докладе обсуждалась постоянная проблема распределенных систем: рабочие процессы часто выходят из строя, механизмы восстановления сложны, а видимость состояния рабочих процессов остается сложной.
По словам докладчиков, современные приложения регулярно пишут рабочие процессы, но текущие решения сталкиваются с фундаментальными проблемами. Сбои происходят часто, существующие инструменты оркестрации не обеспечивают адекватного представления о том, что происходит, а логика координации разбросана по нескольким системам. «Ваша база данных — это все, что вам нужно», — отметил Ли, указывая на тот факт, что большинство команд уже имеют большую часть инфраструктуры для самостоятельной реализации поддержки рабочих процессов, учитывая библиотеку «оболочки рабочих процессов» на уровне приложения.
Проблемы внешней оркестровки
Транзакция DBOS подход, доступный в виде библиотеки с открытым исходным кодом под лицензией MIT для Питон, Машинопись, Идтии Яваинвертирует традиционный архитектурный стек. Вместо построения уровней оркестрации поверх баз данных рабочие процессы преобразуются непосредственно в операции с базами данных.
Подход Transact — сервер приложений с библиотекой, выполняющий распределенную оркестровку с использованием базы данных.
Библиотека использует систему контрольно-пропускных пунктов. Перед выполнением любого шага рабочего процесса система записывает входные данные в базу данных и после выполнения каждого шага проверяет выходные данные. При возникновении сбоев рабочие процессы могут возобновиться с последней успешной контрольной точки, а не перезапускаться с нуля. Этот подход использует свойства ACID PostgreSQL, чтобы гарантировать семантику однократного выполнения без необходимости отдельной инфраструктуры оркестрации.
Подход на основе базы данных обеспечивает несколько практических возможностей, позволяющих решать повседневные эксплуатационные задачи. Управление рабочими процессами становится возможным с помощью стандартных запросов SQL, что позволяет командам составлять список, искать, отменять и возобновлять рабочие процессы непосредственно с помощью операций с базой данных. Докладчики также продемонстрировали возможность «разветвления» для отладки производственных проблем: команды могут перезапустить рабочий процесс с определенного шага, скопировав исходные входные и выходные данные до этого шага в новый рабочий процесс, и воспроизвести выполнение с обновленным кодом. Этот процесс значительно упрощает исправление ошибок и воспроизведение событий для применения исправления.
Исправление ошибок с помощью форков в Transact
Выступающие также признали наличие ряда проблем, присущих этому подходу. Конфликт блокировок становится основной проблемой, когда несколько исполнителей извлекают задачи из одной очереди, что потенциально снижает производительность. Команда решает эту проблему с помощью PostgreSQL “ДЛЯ ОБНОВЛЕНИЯ ПРОПУСТИТЬ ЗАБЛОКИРОВАНО“, которое позволяет каждому работнику выбирать и блокировать только незаблокированные строки рабочего процесса, обеспечивая эффективную параллельную обработку.
Децентрализованное планирование cron представляет собой еще одну проблему: вместо поддержки центрального планировщика каждый работник запускает один и тот же планировщик cron и использует запланированное время в качестве уникального идентификатора рабочего процесса для обеспечения идемпотентного выполнения. Чтобы предотвратить массовые проблемы, когда рабочие просыпаются одновременно, библиотека применяет случайный джиттер к интервалам сна, распределяя нагрузку и проверяя наличие рабочего процесса перед выполнением.
В этой модели рабочие процессы тестирования также становятся более простыми. Докладчики подчеркнули, что рабочие процессы работают одинаково в локальной среде разработки и в производственной среде. Рабочие процессы модульного тестирования проще, поскольку механизм контрольных точек упрощает создание макетов и управление состоянием.
Этот архитектурный образец имеет исторические прецеденты. Фонд рабочих процессов Windowsпредставленный почти два десятилетия назад вместе с .NET Framework 3.0, аналогичным образом использовал сохраняемость SQL Server для поддержания состояния рабочего процесса при сбоях. Однако этот подход основывался на определениях рабочих процессов на основе DSL и требовал значительных затрат на настройку, ограничивая внедрение в первую очередь собственными продуктами Microsoft. Подход DBOS отличается тем, что он использует упрощенные аннотации кода на основных языках, а не отдельный язык определения рабочего процесса.
#QCon #оркестровка #рабочих #процессов #на #основе #базы #данных #бросает #вызов #традиционной #архитектуре
Ещё по этой теме
