Ssylka

Когда саги уместны и как их правильно готовить?

Саги — это способ реализации распределённых транзакций, особенно полезный в микросервисной архитектуре. Существует два основных подхода: хореография, когда сервисы обмениваются событиями, и оркестрация, когда один сервис управляет всеми остальными. Оркестрация предпочтительнее, если необходимо меньшее количество изменений в существующей системе, так как позволяет использовать привычную схему «запрос-ответ», а также упрощает дебаг.
Когда саги уместны и как их правильно готовить?
Изображение носит иллюстративный характер

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

При написании саг возникает выбор между "Plain Go", где все управляется условными операторами, и "Structured Go", где шаги саги описываются как структуры с полями для действия и компенсации. Структурированный подход, хотя и более сложен при написании, имеет существенные преимущества: он делает поток управления более явным, снижает вероятность ошибок при использовании механизма компенсации и облегчает тестирование каждого шага отдельно.

Саги не только подходят для операций изменения данных, но и для GET-запросов, когда требуется параллельный сбор данных или повторные запросы. Они хорошо сочетаются с асинхронными API, предоставляя возможность отслеживать статус выполнения. Создание собственной реализации саг — это отличная практика для повышения навыков в архитектуре и разработке, позволяющая учитывать специфику проекта и избежать vendor lock, опираясь на философию Go.


Новое на сайте