Паттерны

Многошаговые процессы

Узнайте, как проектировать многошаговые процессы на интервью по System Design

⚙️ Реальные производственные системы должны справляться со сбоями, повторными попытками и длительными операциями, которые могут занимать минуты или часы. Часто они принимают форму многошаговых процессов или саг (sagas), которые включают координацию нескольких сервисов и систем. Это постоянный источник эксплуатационных и архитектурных проблем для инженеров, и существует множество различных вариантов их решения.

Проблема

Многие реальные системы в конечном итоге координируют десятки или даже сотни различных сервисов и систем для выполнения запроса пользователя. Однако построение надежных многошаговых процессов в распределенных системах оказывается действительно сложной задачей. В то время как базы данных часто имеют дело с одной операцией записи или чтения, реальным приложениям часто приходится взаимодействовать с десятками нестабильных сервисов для выполнения задачи, и делать это быстро и надежно - сложная проблема. У Jimmy Bogard есть отличный доклад на эту тему под названием "Six Little Lines of Fail". Основная идея заключается в том, что распределенные системы делают даже простую последовательность шагов на удивление сложной. Если вам не приходилось работать с подобными системами, мы настоятельно рекомендуем его посмотреть.

Рассмотрим процесс обработки заказа в интернет-магазине: списание средств, резервирование товара на складе, создание заявки на сборку, ожидание сборки и упаковки, отправка email с подтверждением и ожидание доставки. Каждый шаг включает вызов различных сервисов или ожидание действий человека, и любой из них может завершиться сбоем или по таймауту. Некоторые шаги требуют обращения к внешним системам, таким как платежная система, и ожидания завершения их работы. Во время оркестрации ваш сервер может упасть или на нем может быть развернута новая версия кода. А возможно, вы захотите изменить порядок шагов или саму бизнес логику. Реальная сложность бизнес-требований и инфраструктуры быстро разрушает нашу, казалось бы, идеальную блок-схему шагов.

Кошмар с обработкой заказа

Конечно, мы можем локально "подлатать" такие процессы. Мы можем улучшить каждый сервис предусмотрев обработку сбоев, добавить компенсирующие действия, такие как возврат средств, если товар не найден, использовать очереди с задержкой и вебхуки для обработки ожиданий и ручных задач. Но в целом каждая из этих вещей делает систему более сложной и хрупкой. Мы смешиваем инфраструктурные проблемы, такие как перезагрузки, повторные попытки и сбои, с бизнес-логикой - что произойдет, если мы не сможем найти товар. Это не самый лучший дизайн.

Workflow-системы и системы надежного исполнения (durable execution) являются решениями этой проблемы. Они часто появляются на собеседованиях по System Design, особенно когда в задаче много состояний, отказов и длительных шагов. Интервьюеры любят такие темы, потому что именно они часто делают дежурства команд болезненными и хорошо показывают, насколько кандидат понимает сложность распределенных систем. В этой статье мы разберем, что это за подходы, как они работают и как использовать их на собеседовании.

Задачи, где важны многошаговые процессы

Перейдите на Premium, чтобы продолжить

Разблокируйте доступ к этой статье и всем остальным материалам с NowInterview Premium

Перейти на Premium