SAGA — важный шаблон в среде микросервисов, предназначенный для устранения проблем при длительных транзакциях. Продемонстрировать знания по этой теме часто просят на собеседованиях.
Поскольку архитектура микросервисов включает несколько небольших приложений, единый запрос разбивается на несколько составляющих. Поэтому есть вероятность потери некоторых из них. В таком случае становится сложно поддерживать согласованность данных.
Работая в режиме реального времени с данными, например при размещении онлайн-заказа, нужно корректно обработать этот сценарий, чтобы в случае сбоя платежа вернуть в исходное состояние корзину с выбранными товарами.
Разберемся в особенностях шаблона SAGA, а также его плюсах и минусах в микросервисной среде.
Что такое паттерн SAGA и какую проблему он решает?
SAGA (или Saga) — шаблон проектирования микросервисов, обеспечивающий согласованность (синхронизацию) данных в распределенных системах. Он позволяет обрабатывать длительные и включающие несколько этапов транзакции, в которых каждый шаг — отдельная операция, связанная с базой данных.
КРАТКАЯ ИНСТРУКЦИЯ по работе с программой Cross Stitch Saga
Основная идея состоит в том, чтобы зафиксировать в базе данных все этапы транзакции с возможностью ее отката в первоначальное состояние в случае сбоя системы.
Шаблон SAGA позволяет поддерживать согласованность данных в распределенной системе, где трудно гарантировать атомарность (неделимость) операции в транзакции, особенно в случае сбоев.
Популярный случай использования шаблона — транзакции в электронной коммерции. Например, размещение заказа на Amazon, когда оплата списывается со счета клиента, а товары резервируются в корзине.
Если один из этих шагов не выполняется, то все предыдущие «откатываются», обеспечивая согласованность данных. Так в случае сбоя платежа отменяется резервирование товаров. SAGA решает проблему согласованности в этой транзакции, включающей несколько этапов, которые не всегда бывают успешными.
Работу шаблона SAGA демонстрирует диаграмма архитектуры микросервисов:
Преимущества и недостатки SAGA в микросервисной архитектуре
Изучая этот шаблон, всегда следует учитывать его плюсы и минусы, поскольку это поможет лучше разобраться в особенностях инструмента и осознанно принимать решения по его использованию в приложениях.
Преимущества
- Упрощается реализация сложных транзакций через несколько микросервисов.
- Корректно отрабатываются сбои, обеспечивается согласованность данных.
- Повышается устойчивость и надежность системы.
- Предотвращается несогласованность данных и потеря обновлений.
- Обеспечивает понятный и четко определенный процесс компенсации транзакций.
Недостатки
- Шаблон сложно реализовать и поддерживать, а также отслеживать и отлаживать.
- Потребуются дополнительные ресурсы для хранения и управления состоянием SAGA.
- Понизится производительность из-за необходимости управлять транзакциями через несколько микросервисов.
- Увеличатся задержки в приложении из-за множественных прямых и обратных передач между микросервисами.
- Реализация SAGA в разных микросервисах не стандартизирована. Было бы здорово, если бы в будущем этот шаблон поддерживали такие фреймворки, как Spring Cloud и Quarks.
Как реализовать SAGA в микросервисной архитектуре
Шаблон SAGA можно реализовать в архитектуре микросервисов разбивкой сложной бизнес-операции на несколько небольших независимых этапов или сервисов.
Для тех кто только хочет начать пользоваться программой cross stitch saga
Каждый шаг будет связываться с соответствующим микросервисом для завершения части транзакции. В случае сбоя на любом шаге система инициирует компенсирующую транзакцию, чтобы отменить предыдущие шаги.
Координация этих шагов может быть достигнута с помощью базы данных, очереди сообщений и службы координации, чтобы сохранить состояние транзакции и запустить компенсирующие транзакции. Таким образом, система может обеспечивать конечную согласованность и корректно обрабатывать сбои.
А есть ли фреймворк Java Microservice, способный обеспечить поддержку шаблона SAGA? Такого фреймворка, который обеспечивал бы прямую поддержку шаблона SAGA, к сожалению, нет.
Тем не менее есть возможность реализовать SAGA, используя такие библиотеки и фреймворки, как Apache Camel и Spring Integration, а также такие инструменты, как Apache Kafka, Event Sourcing и архитектура Message-Driven.
Заключение
SAGA — это один из наиболее сложных в изучении шаблонов, который играет важную роль в проектировании микросервисной архитектуры. Вопросы по нему часто задают на собеседованиях.
Поскольку управление распределенными транзакциями и согласование данных — реальная проблема, опытный разработчик должен знать, как ее решить в архитектуре микросервисов.
- Совместное использование кода в микросервисах и микрофронтендах: в чем разница
- Можно ли использовать бессерверные технологии для создания микросервисов?
- Бэкенд-разработчик: какие знания нужны для трудоустройства
Читайте нас в Telegram, VK и Дзен
Источник: medium.com
Saga
Сервис для создания и хранения заметок, задач с возможностью структурирования с помощью обратных ссылок.
Похожие на Saga
Описание Saga
Saga — инструмент для фиксирования заметок и их хранения методом Цеттелькастен. С Saga пользователи могут создавать заметки в виде документов, задачи и структурировать их. Инструмент подойдёт маркетологам, фрилансерам, продуктологам, студентам, аналитикам и людям, работающим со знаниями.
В Saga есть две основные сущности — страница и задача. Страница — документ для фиксации знаний, он наполняется при помощи текстового редактора. В редакторе форматируется текст, добавляются заголовки, создаются списки, чек-листы, обрамляется компьютерный код, цитаты, вставляются изображения и таблицы.
Также к документу прикрепляется файлы, но для этого необходимо интегрироваться с Google Диском. Задачи оформляются как списки дел, внутри задача оформляется так же, как и документ. На странице со списком задачи можно выделить и пометить как сделанными. У задач, в отличие от страниц, есть назначенное лицо для выполнения и дата выполнения, также они могут ссылаться на созданную страницу.
Для структурирования страниц и задач в Saga существуют коллекции. Они выполняют роль папки и тега одновременно. Коллекции объединяют в себе документы одной тематики. Для создания связей между документами используются обратные ссылки, они вставляются в документ и привязываются к ранее созданной странице. В Saga создавать и редактировать можно не только в одиночку, но и в команде.
Для работы в команде необходимо отправить приглашение коллегам для присоединения к рабочему пространству.
Особенности Saga
- Создание пространства для хранения заметок и задач
- Структурирование с помощью коллекций и ссылок
- Совместное создание и редактирование заметок
- Использование и создание шаблонов
- Интеграция с облачными сервисами
- Интерактивный поиск и фильтры
- Импорт и экспорт страниц в JSON
Источник: startpack.ru
Redux-saga: обзорная экскурсия
Сегодня я бы хотел рассказать о библиотеке redux-saga. Она уже достаточно давно используется во frontend-программировании, но не является интуитивно понятной, что может помешать начинающим разработчикам освоить её быстро и начать применять в своих проектах. В данной статье я максимально просто постараюсь объяснить максимально основные принципы этой технологии и некоторые полезные возможности. Намеренно отказываюсь от сравнительного анализа в пользу одних либо других технологий, т.к. выбор — это личное дело каждого, но чтобы его сделать, необходимо обладать определёнными знаниями.
В статье используются специализированные термины, поэтому предполагается, что вы имеете общее представление о React, Redux, генераторах и итераторах из ES6.
Из официальной документации следует, что redux-saga — это библиотека, которая ориентирована на упрощение и улучшение работы с сайд-эффектами (side-effects, любыми взаимодействиями с внешней средой, например, запрос на сервер) и облегчение их тестирования. В redux сага — это middleware (слой, работающий с момента диспатча (dispatch) экшена (action) и до обработки его редьюсером (reducer)), который может запускаться, останавливаться и отменяться из основного приложения с помощью обычных действий redux. Библиотека использует такое понятие ES6 как генераторы (Generators), и благодаря этому наши асинхронные потоки выглядят как обычный синхронный код.
Концепция Redux-saga
Технология redux-saga основана на использовании двух типов саг — наблюдатель (watcher saga) и исполнитель (worker saga).
- watcher saga — «прослушивает» задиспатченные экшены, при появлении необходимого запускает обработчик этого экшена (worker saga);
- worker saga — непосредственно выполняет нужный код.
Считается, что самое подходящее место для сайд-эффектов — это action. Рассмотрим простой пример слоя action для отправки запроса на сервер с помощью redux-thunk:
const actionRequestStarted = () => (< type: ‘REQUEST_DATA_STARTED’, >); const actionRequestSuccess = (data) => (< type: ‘REQUEST_DATA_SUCCESS’, data, >); const actionRequestFailed = (error) => (< type: ‘REQUEST_DATA_FAILED’, error, >); const fetchData = (url) => < (dispatch) => < dispatch(actionRequestStarted()); fetch(url) .then((response) =>response.json()) .then((data) => dispatch(actionRequestSuccess(data))) .catch((error) => dispatch(actionRequestFailed(error))) >; >;
Данный код не сложный как для понимания, так и для тестирования (один запрос замокать не проблема). Но что будет, если сайд-эффектов будет больше? Их все необходимо будет «затыкать» подставными данными, что не очень удобно.
Библиотека Redux-saga предлагает перенести всю бизнес-логику и сайд-эффекты в слой саг. Посмотрим как fetchData будет выглядеть, если переписать его на саги — теперь это обычный синхронный action creator:
const actionRequestData = (url) => (< type: ‘REQUEST_DATA’, url, >);
В слое саг определим watcher saga, которая будет наблюдать за отправленными экшенами:
function* fetchDataWatcherSaga()