Сравнение подходов к реализации распределенных транзакций для микросервисов

Введение в действие хореографий обслуживания

Хореографии обслуживания не выполняются: они вводятся в действие. Хореография службы разыгрывается, когда ее участники исполняют свои роли. То есть, в отличие от оркестровки сервисов, хореографии сервисов не выполняются каким-либо механизмом в сервисной инфраструктуре, но они «происходят», когда выполняются их роли. Это связано с тем, что логика хореографии сервисов определяется с глобальной точки зрения, и таким образом, это не реализуется с помощью одной единственной службы, как в оркестровке служб.

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

Хореогафия

Признаюсь, это более непонятная штука.

Официально-научное определение гласит, что:

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

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

В хореографии раскрывается только видимое извне поведение каждого из участников, но не описываются никакие внутренние операции, которые происходят внутри участников (служб) и которые напрямую не производят видимый эффект. Зачастую хореографию связывают с B2B взаимодействием, выводя независимость участников взаимодействия за пределы одной организации (некоторого домена ответственности). К языкам описания хореографии относят WS-CDL (Web Services Choreography Description Language, хотя, к сожалению, его черновик так и не был завершен), ebXML Business Process Specification Schema (BPSS) и др.

Асинхронная связь по командам и событиям

Эта архитектура основана на центральной шине для асинхронной связи. К этой шине подключаются различные микросервисы. Логика оркестровки и соответствующие потоки оркестровки принадлежат микросервисам. Рабочие процессы могут посылать на шину новые команды («эй оплата, пожалуйста, найди деньги для меня») или ждут, пока произойдут события («кто бы ни заинтересовался, я получил оплату за O42»).

• Типичные инструменты: Kafka, RabbitMQ (AMQP), JMS.
• Что делает движок рабочего процесса: обработка тайм-аута, управление цепочками действий / потоком, поддержка паттернов интеграции предприятия с отслеживанием состояния, таких как агрегатор или повторный упорядочитель, обработка согласованности и компенсации, также известная как Saga pattern, как обсуждалось в моем выступлении «Lost in transaction» (записано, например, на JavaZone Oslo).
• Пример реализации: https://github.com/berndruecker/flowing-retail/tree/master/kafka/java
• За: Временная развязка микросервисов; Правильное применение событийно-ориентированной архитектуры может уменьшить взаимосвязь; многие сценарии сбоев (например, отсутствующие ответные сообщения) прозрачны для разработчика, поэтому он хорошенько продумывает эти ситуации.
• Против: Требуется шина сообщений или событий в качестве центрального компонента, с которым нелегко работать. Отсутствие операционных инструментов для этих компонентов приводит к тому, что усилия направляются в доморощенные «больницы сообщений». Большинство разработчиков не так хорошо знакомы с асинхронной связью.

Мысли и рекомендации

Я лично предпочитаю децентрализованный подход в целом. Он просто совпадает с сутью и ценностью микросервисов.

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

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

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

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

Оркестровка

Иными словами, оркестровка — это принцип построения некоторого набора действий, алгоритм, привлекающий (оркестрирующий) к своей работе операции (функции) других участников.

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

Пример: предположим, у вас есть функция, отправляющая электронные письма с сайта. Эту функцию могут вызывать разные оркестраторы для решения разных задач (регистрация пользователя, изменение статуса заказа и пр.). Сама функция и ее владелец (сервис, программа, шлюз отправки смс и пр.) не знают, зачем они были вызваны. И им, в общем-то, без разницы. У них есть задача, они умеют выполнять ее хорошо. О их возможностях (интерфейсе взаимодействия) известно заранее, уже во время построения алгоритма оркестровки.

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

Грубо говоря: оркестратор — командир, выполняющий только ему известную задачу. Он командует подчиненными, которые ничего не знают. Но задача (алгоритм) хорошо известна и заранее заданна. Подчиненные также помогают другим оркестраторам решать их задачи в пределах собственных компетенций. Компетенции подчиненных (функции участников, операции сервисов) заранее известны.

Языки моделирования, предназначенные для описания оркестровки с целью автоматизации процесса посредством системы управления бизнес-процессами или специализированного «движка» оркестровки, называются языками оркестровки. С этой точки зрения к языкам оркестровки бизнес-процессов можно отнести, например, BPEL, XPDL и, по большей части, BPMN.

С точки зрения программирования, языками оркестровки могут являться любые, поддерживающие парадигму императивного программирования, то есть все те языки, где можно сделать классический алгоритм, решающий определенную задачу за конечное число шагов. Например, C, C++, Python, PHP, Perl, Ruby, C#, Java и пр.

Как выбрать стратегию распределенных транзакций

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

Рисунок 12: Характеристики шаблонов двойной записи

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

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

Рисунок 13: Характеристики относительной согласованности данных и масштабируемости шаблонов двойной записи

В качестве хорошей отправной точки мы могли бы оценить различные подходы — от наиболее масштабируемых и высокодоступных до наименее масштабируемых и доступных.

Высокий уровень масштабирования и доступности: параллельные конвейеры и хореография.

Если ваши шаги временно изолированы, тогда имеет смысл запустить их в методе параллельных конвейеров. Скорее всего, вы можете применить этот шаблон к определенным частям системы, но не ко всем. Далее, предполагая, что между этапами обработки существует временная связь, и определенные операции и службы должны выполняться раньше других, вы можете рассмотреть подход “хореография”. Используя хореографию сервисов, можно создать масштабируемую, управляемую событиями архитектуру, в которой сообщения перетекают от сервиса к сервису через децентрализованный процесс оркестровки. В этом контексте реализации шаблона “Исходящие” с Debezium и Apache Kafka (например, Red Hat OpenShift Streams для Apache Kafka ) особенно интересны и набирают обороты.

Средний уровень масштабирования и доступности: оркестровка и двухфазная фиксация

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

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

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

Параллельные конвейеры

В шаблоне хореография нет централизованного места для запроса состояния системы, но есть последовательность сервисов, которые распространяют состояние через распределенную систему. Хореография создает последовательный конвейер сервисов обработки, поэтому мы знаем, что когда сообщение достигает определенного шага бизнес-процесса, оно уже прошло все предыдущие шаги. Но что, если бы мы могли ослабить это ограничение и обработать все шаги независимо? В этом сценарии служба B может обработать запрос независимо от того, обработала его служба A или нет.

В подходе с параллельными конвейерами мы добавляем службу маршрутизатора, которая принимает запросы и перенаправляет их в службу A и службу B через брокера сообщений в одной локальной транзакции. Начиная с этого шага, как показано на рисунке 10, обе службы могут обрабатывать запросы независимо и параллельно.

Рисунок 10: Обработка через параллельные конвейеры

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

Слушай себя

Существует более легкая альтернатива этому подходу, известная как шаблон «Слушай себя» , в котором одна из служб также действует как маршрутизатор. При этом альтернативном подходе, когда служба A получает запрос, она не будет записывать изменения в свою базу данных, а вместо этого опубликует запрос в системе обмена сообщениями, где конечными потребителями являются служба B, и сам сервис А. Рисунок 11 иллюстрирует этот подход.

Рисунок 11: Шаблон «Слушай себя»

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

Преимущества и недостатки параллельных конвейеров

В таблице 5 приведены преимущества и недостатки использования параллельных конвейеров.

Преимущества	Простая масштабируемая архитектура для параллельной обработки.
Недостатки	Требуется временный демонтаж на независимые события; трудно понять глобальное состояние системы.
Примеры	Многоадресная рассылка и разделитель Apache Camel с параллельной обработкой.

Отслеживание или управление? Хореография или оркестровка?

Один из первых вопросов, как правило, касается оркестровки или хореографии, при этом последний чаще всего рассматривается как лучший вариант (на основе статьи «Microservices» Martin Fowler). Обычно это сочетается с Event-driven архитектурой.

В такой хореографической архитектуре вы излучаете так называемые доменные события, и каждый заинтересованный может действовать в соответствии с этими событиями. Это трансляция. Идея заключается в том, что вы можете просто добавлять новые микросервисы, которые прослушивают события, ничего больше не меняя. Рабочий процесс как таковой нигде не является явным, но развивается как цепочка событий, которые передаются по кругу. Опасность заключается в том, что вы теряете из виду более масштабный поток, в нашем примере выполнение заказа. Становится невероятно трудно понять поток, изменить его или также управлять им. И даже ответы на такие вопросы, как «Есть ли какие-либо заказы просрочены?» или «Есть ли что-нибудь застрял, что нуждается в вмешательстве?» является проблемой. Я обсуждаю это в своем докладе Complex event flows in distributed systems (записанные, например, в QCon в Нью-Йорке или DevConf в Кракове).

Вы можете найти рабочий пример чистой хореографии здесь: https://github.com/berndruecker/flowing-retail/tree/master/kafka/java/choreography-alternative

Смешивать хореографию и оркестровку

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

В flowing-retail примере это также означает, что у вас должен быть отдельный микросервис для наиболее важной бизнес-возможности: заказа клиента!

Децентрализованные движки

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

• Пример реализации: https://github.com/berndruecker/flowing-retail/tree/master/kafka/java/order-camunda
• За: Автономия; изоляция.
• Против: Каждая команда должна использовать свой собственный движок (включая накат исправлений); никакого центрального мониторинга «из коробки» (пока).

Обычно в этой архитектуре больше всего обсуждается мониторинг: «Как мы можем следить за тем, что происходит»?

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

Контекст и проблема

В микросервисной архитектуре бывает так. что cloud-base приложение делиться на несколько  небольших сервисов работающих вместе для комплексной обработки бизнес-транзакции. Для снижения «coupling» между сервисами, каждый сервис отвечает за единую бизнес-операцию. Некоторые преимущества включают более быструю разработку, меньший code base и масштабируемость.

Шаблон Orchestrator сокращает point-2-point коммуникацию между сервисами, но имеет ряд недостатков из-за тесной связи между Orchestratorом и другими сервисами, участвующими в обработке бизнес-транзакции. Для выполнения задач в очереди, оркестратору нужно иметь некоторые доменные знания про эти сервисы. Если вы хотите добавить или удалить сервисы, существующая логика будет нарушена, и необходимо будет заново «вклинивать» в процесс новые сервисы.

Языки хореографии обслуживания [ править ]

В рамках спецификаций, касающихся веб-сервисов , следующие спецификации сосредоточены на определении языков для моделирования хореографии сервисов:

• Язык описания хореографии веб-сервисов (WS-CDL) — это основанная на XML спецификация от W3C для моделирования хореографии с использованием конструкций, вдохновленных исчислением Пи.
• Web Service Хореография интерфейс (WSCI) является спецификация XML на основе , которая была выдвинута в W3C по , Sun Microsystems , BEA Systems и SAP AG , и служил в качестве входных данных для Web Service Description Language Хореография (WS-CDL)

Более того, спецификация OMG BPMN версии 2.0 включает диаграммы для моделирования хореографии сервисов.

Академические предложения по языкам служебной хореографии включают:

• Давай потанцуем
• BPEL4Chor
• Чор

Кроме того, был предложен ряд формализмов хореографии обслуживания на основе:

• Сети Петри , например, интерактивные сети Петри и открытые сети рабочих процессов
• Конечные машины
• Охраняемые автоматы
• Временные автоматы
• Исчисление Пи
• Расчет процесса

Хореография веб-сервисовредактировать

Хореография веб-сервисов ( WS-Choreography ) — это спецификация консорциума W3C, определяющая язык моделирования бизнес-процессов на основе XML, который описывает протоколы сотрудничества взаимодействующих участников веб-сервисов , в которых сервисы действуют как одноранговые узлы, а взаимодействия могут быть долгоживущими и с отслеживанием состояния. ( Оркестровка — это еще один термин с очень похожим, но все же другим значением.)

Основная попытка получить хореографию, Рабочая группа по хореографии веб-сервисов W3C, была закрыта 10 июля 2009 года , оставив WS-CDL в качестве кандидата в рекомендацию.

«Многие презентации на семинаре W3C по веб-сервисам 11–12 апреля 2001 года указывали на необходимость в общем интерфейсе и языке композиции, чтобы помочь решить хореографию

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

Проблема хореографии вызвала большой интерес в индустрии в то время; такие проекты, как WSCL (язык общения веб-служб) и WSCI (интерфейс хореографии веб-служб), были представлены в W3C и опубликованы в виде технических заметок. Кроме того, были предприняты дополнительные усилия:

• BPML , теперь BPMN
• BPSS от ebXML
• WSFL от IBM
• XLANG от Microsoft
• BPEL4WS от IBM, Microsoft и BEA

«В июне 2002 года Intalio , Sun, BEA и SAP выпустили совместную спецификацию под названием Web Services Choreography Interface (WSCI). Эта спецификация также была представлена ​​в W3C в качестве примечания в августе 2002 года. С тех пор W3C сформировал новую рабочую группу под названием Web Services. Рабочая группа по хореографии в рамках деятельности веб-сервисов. Спецификация WSCI является одним из основных входов в рабочую группу по хореографии веб-сервисов, которая 9 ноября 2005 г. опубликовала Рекомендацию кандидата по WS-CDL версии 1.0 » . «XLang, WSFL и WSCI больше не поддерживаются какой-либо стандартной организацией или компаниями. BPEL заменил Xlang, а WSFL WSCI был заменен WS-CDL » .

Предстоящая версия 2.0 Business Process Modeling Notation представит диаграммы для определения хореографии сервисов.

Академическая область выдвинула другие языки хореографии сервисов, например Let’s Dance, BPEL4Chor и MAP.

Пример сильного и слабого связывания

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

Предположим, вы часто ездите на междугородних поездах. Для того чтобы покупать билеты вы, начиная с конца 90-х годов, использовали сестру своей мамы — тетю Галю, которая работала кассиром на вокзале. Вы звонили тете Гале, называли параметры своей поездки, а она на следующий день покупала вам подходящий билет. Тетя Галя использовала свою корпоративную скидку, покупала вам билет дешевле общего ценника, но разницу забирала себе. Вам же доставался билет за полную стоимость, но не нужно было стоять в очередях в кассы вокзала. Тетя Галя сделала все за вас по звонку.

А теперь представьте себе такую ситуацию. Проходит 10 лет и нескольких сотен ваших безмятежных поездок. В очередной раз вы звоните любимой тете. Но вдруг узнаете, что тетя Галя по не зависящим от вас причинам недавно уволилась с работы кассиром (оказалось, что она нарушала правила использования корпоративной скидки). Что теперь делать?! Вы бросаетесь в панику. Начинаете узнавать у знакомых, как покупать билеты. Бежите на вокзал. Покупаете сначала не туда. Потом не на то время. Страдаете, бегаете сдавать билеты и в конечном итоге пропускаете необходимый поезд и командировку.

Вот вся эта ситуация — это сильное связывание. Вы напрямую зависели от тети Гали. Вы соорудили с ней взаимоотношения не на общих правилах и независимых принципах, а на основе родственных отношений и некоторых личных удобств. Вы знали телефон тети Гали, а не касс вокзала. Вы знали, как правильно покупать билет у нее, а не общие правила всей системы РЖД. И в тот момент, когда тетя Галя не смогла купить вам билет, вся ваша «идеально» работающая схема развалилась.

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

Кассир может делать несколько четко заданных функций. Но эти же функции может делать любой кассир, хотя они все — разные люди. И вы, зная только список и способы работы этих функций, можете взаимодействовать с любым кассиром. Можете их даже не запоминать. Любой кассир все равно будет выполнять эти функции.

Знакомая ситуация?

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

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

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

Оркестровка

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

Реализация архитектуры оркестровки

Самыми популярными реализациями техники оркестрации являются реализации спецификации BPMN, такие как проекты jBPM и Camunda . Потребность в таких системах не исчезает из-за чрезмерно распределенных архитектур, таких как микросервисы или бессерверные архитектуры, а, наоборот, увеличивается. В качестве доказательства мы можем обратиться к более новым механизмам оркестровки с отслеживанием состояния, которые не соответствуют спецификации, но обеспечивают аналогичное поведение с отслеживанием состояния, например, Netflix Conductor, Uber Cadence и Apache Airflow. Бессерверные архитектуры с отслеживанием состояния, такие как Amazon StepFunctions, Azure Durable Functions и Azure Logic Apps, также относятся к этой категории. Кроме того, существуют библиотеки с открытым исходным кодом, которые позволяют реализовать поведение координации и отката с отслеживанием состояния, такие как реализация шаблона Apache Camel Saga и функциональность NServiceBus Saga . Многие встроенные реализации паттерна «Saga» также относятся к этой категории.

Рисунок 5: Организация распределенных транзакций между двумя сервисами

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

Преимущества и недостатки оркестровки

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

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

Преимущества	Координирует состояние разнородных распределенных компонентов. Нет необходимости в транзакциях XA. Известное распределенное состояние на уровне координатора.
Недостатки	Сложная модель распределенного программирования. Может потребоваться идемпотентность и компенсационные операции от участвующих служб. Конечная последовательность. Возможны неисправимые отказы при компенсациях.
Примеры	jBPM Camunda MicroProfile Long Running Actions Netflix Conductor Uber Cadence Amazon StepFunctions Azure Durable Functions Реализация паттерна Apache Camel Saga Реализация паттерна NServiceBus Saga Спецификация CNCF Serverless Workflow Встроенные реализации паттерна Saga

Заключение

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

В конце концов, неважно, какую стратегию вы выберете; что имеет значение, так это осознанный выбор стратегии и правильная ее реализация