Распределенные транзакции

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

Монолитное приложение работает с одной базой данных, у каждой транзакции есть начало и конец. Мы можем быть уверены, что данные любого многоступенчатого процесса в такой архитектуре будут согласованы.

Когда мы переходим на микросервисы, эта уверенность пропадает. Каждый микросервис работает сам по себе, записывает свои данные в собственную базу, да и базы эти могут быть принципиально разными. Операции носят асинхронный характер, и чётко проконтролировать их работу в рамках многоступенчатого процесса практически невозможно.

Пара примеров, чем грозит несогласованность данных

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

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

Чтобы в микросервисном продукте не происходили такие конфликты, данные не терялись и были согласованными, мы используем шаблон проектирования Saga.

Как работает Saga

Технически Saga это отдельный микросервис, который через шину ловит сообщения о событиях в других микросервисах. Есть два варианта работы Saga:

• Saga сверяется с шаблоном процесса и отдаёт команду другим модулям.

• Другие модули сами подписываются на события, которые влияют на их активность и при наступлении события действуют по шаблону процесса.

Такой подход применяется как в краткосрочных процессах, так и в длительных, которые могут требовать множества последовательных действий, перехода из системы в систему, и продолжаться несколько дней.

Применение Saga в нашей практике

Пример 1. В системе для работы с медиафайлами класса DAM (Digital Asset Management), пользователи за раз могут загружать десятки фото- и видеоматериалов, каждый из которых при добавлении проходит через несколько микросервисов.

Без Saga пользователям непонятно, когда эти файлы становятся доступны для дальнейшей обработки, а если страница зависает или обновляется, процесс загрузки приходится начинать заново.

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

Пример 2. В системе авансовых отчетов по командировкам сотрудники последовательно указывают различные данные, загружают чеки и документы. Saga координирует весь этот процесс в полном соответствии с внутренними регламентами компании. Архитектура продукта выстроена по образцу бизнес-процесса, который приходилось бы заполнять в офлайне. В результате ИТ-система работает прозрачно для бизнеса.

Альтернативные подходы, или почему мы выбрали Saga

Координатор распределённых транзакций. Принцип похож на Saga, только вместо того, чтобы слушать шину данных и отправлять через неё сообщения микросервисам, оркестратор работает напрямую с БД микросервисов.

Ограничения:

• Этот вариант технически более сложен.

• А если у микросервисов разный тип БД (например, MS SQL и MongoDB), этот метод в принципе не сработает.

Outbox-Inbox. Микросервисы обмениваются сообщениями напрямую, без оркестратора. Если вернуться к примеру с банковским приложением, то при переводе денег один микросервис сохраняет у себя в Outbox сообщение об отправке, второй записывает у себя в Inbox сообщение о получении. Если случается сбой, то можно соотнести между собой их ящики и добиться согласованности данных.

Ограничения:

• Это вполне работоспособный метод, но подходит только для простых процессов если в транзакции участвует три и более сервисов, контролировать их взаимодействие становится слишком затратным.

Здесь и стоит задуматься о Saga.

Оркестрация микросервисов помогает выстраивать сложные процессы в продуктах. Чтобы не приходилось прописывать эту механику руками, разработчики могут воспользоваться готовыми фреймворками, которые включают в себя средства управления микросервисами. Мы в True Engineering изучили эту тему и рассказываем про три таких фреймворка.

При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент это отдельное приложение, возникают трудности.

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

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

Архитектура фреймворка для оркестрации

Фреймворк включает в себя готовые к работе компоненты оркестрации. Это сам оркестратор, который принимает таски и передаёт их рабочим микросервисам на исполнение.

Когда продукт запускает процесс (например, организация путешествия на сайте), оркестратор формирует очередь задач, которые предстоит выполнить микросервисам. В нашем примере это может быть Покупка авиабилета, Бронирование гостиницы, Аренда автомобиля. Микросервисы подхватывают эти задачи и отчитываются о выполнении. Данные сохраняются в собственном хранилище оркестратора, так что если процесс внезапно прервётся, его можно будет возобновить с того же места.

Теперь о том, как мы подбирали и сравнивали между собой разные фреймворки.

Какие у нас были требования к оркестратору

• Простота процессов. Нам нужна удобная среда, в которой будет наглядно показано взаимодействие микросервисов. Дополнительным преимуществом будет автоматическое создание документации, когда описание оркестрации становится описанием всей системы.

• Обработка ошибок. На случай сбоя должна быть возможность настроить количество повторных попыток и таймаутов. Кроме того, настройка бизнес-логики и механики самих микросервисов должна идти независимо, чтобы ими можно было управлять отдельно, а изменение бизнес-процесса не ломало весь продукт. Плюс, поддержка шаблона проектирования Saga необходимо предусмотреть откатные действия, когда процесс останавливается на каком-то шаге.

• Поддержка асинхронных активностей и воркфлоу. Необходимо для сохранения промежуточных данных, упрощения разработки и более стабильной работы как таковой.

• Мультиплатформенная поддержка. Желательно, чтобы инструмент могли использовать сразу все команды (например, у нас разработка идёт на Java и .NET).

Сравнение фреймворков

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

Conductor от Netflix. Параметры бизнес-процессов и активности описываются в JSON-файлах. В коде микросервисов нужно прописать уникальные строки, по которым оркестратор будет их вызывать. Настройка бизнес-логики для каждой отдельной активности есть.

Zeebe от Camunda. Camunda это BPMN-движок, который мы давно используем в своей практике (например, для оркестрации своего трекера с трекером заказчика или автоматизации бизнес-процессов). Если знаете Camunda, то интерфейс Zeebe будет вам хорошо знаком. Главное преимущество выделенный графический редактор, с которым будет просто разобраться не-разработчикам. Данные хранятся в XML-файлах.

Temporal. Использует для оркестрации чистый код. Нет идентификаторов микросервисы вызываются через код или собственный интерфейс, который надо дополнительно прописывать. Для многих разработчиков это будет проще и привычнее всего.

Результаты сравнения по нашим критериям:

• Простота процессов. Zeebe оказался самым наглядным благодаря графическому компоненту. А Temporal самый привычный для разработчиков за счёт оркестрации через код.

• Обработка ошибок. Возможности у всех фреймворков примерно равны, yj Zeebe чуть слабее. Из критических параметров он позволяет настраивать только количество ретраев и не поддерживает Saga без костылей.

• Поддержка асинхронных активностей. Здесь все одинаково хороши.

• Мультиплатформенная поддержка. Все фреймворки развивают Java-клиенты, а .NET-версии поддерживаются силами сообщества.

Вывод

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

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