Шаблон хореографии

Децентрализованная логика рабочего процесса и распределение обязанностей другим компонентам в системе.

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

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

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

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

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

Решение

Делегировать логику обработки транзакций между службами. Пусть каждая служба решает и участвует в рабочем процессе коммуникации для бизнес-операции.

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

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

1. Клиентские запросы помещаются в очередь в виде сообщений в брокере сообщений.

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

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

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

Проблемы и рекомендации

Децентрализование оркестратора может вызвать проблемы при управлении рабочим процессом.

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

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

  

• Шаблон подходит для рабочего процесса, в котором независимые бизнес-операции обрабатываются параллельно. Рабочий процесс может стать сложным, когда хореография должна происходить в последовательности. Например, служба D может запустить свою операцию только после успешного выполнения операций службы B и Service C.

  

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

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

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

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

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

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

• Этот шаблон может быть хорошим выбором для обмена данными между ограничивающими контекстами. Для обмена данными внутри отдельного ограниченного контекста может рассматриваться шаблон оркестратора.

• Есть узкие места производительности, представленные центральным оркестратором.

Этот шаблон может оказаться неэффективным в следующих случаях:

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

• Существуют ситуации, когда связь между компонентами является неизбежной.

• Необходимо консолидировать все операции, обрабатываемые подчиненными компонентами, с помощью бизнес-логики.

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон хореографии можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах платформы Azure Well-Architected Framework. Например:

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

Пример

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

В этом примере выполняется рефакторинг реализации доставки дронов, которая заменяет шаблон Orchestrator шаблоном хореографии.

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

Для одной бизнес-транзакции клиента требуется три отдельных бизнес-операций:

1. Создание или обновление пакета
2. Назначение дрона для доставки пакета
3. Обработайте доставку, состоящую из проверки и повышения осведомленности при отправке.

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

Проект

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

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

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

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

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

Если вы планируете развернуть это в другой вычислительной службе, такой как шаблон приложения AKS pub-sub, можно реализовать с двумя контейнерами в одном модуле pod. Один контейнер запускает посла , взаимодействующего с шины сообщений предпочтения, а другой выполняет бизнес-логику. Подход с двумя контейнерами в одном модуле pod повышает производительность и масштабируемость. Посол и бизнес-служба совместно используют ту же сеть, что обеспечивает низкую задержку и высокую пропускную способность.

Чтобы избежать каскадных повторных операций, которые могут привести к нескольким усилиям, бизнес-службы должны немедленно пометить неприемлемые сообщения. Такие сообщения можно дополнить с помощью известных кодов причин или определенного кода приложения, чтобы его можно было переместить в очередь недоставленных писем (DLQ). Рассмотрите возможность управления проблемами согласованности, реализующих Saga из подчиненных служб. Например, другая служба может обрабатывать мертвые сообщения для исправления только путем выполнения компенсации, повторных попыток или сводных транзакций.

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

Связанные ресурсы

Рассмотрим эти шаблоны в дизайне для хореографии.

• Модульная структура бизнес-службы с помощью шаблона проектирования послов.

• Реализуйте шаблон выравнивания нагрузки на основе очередей для обработки пиков рабочей нагрузки.

• Используйте асинхронное распределенное обмен сообщениями с помощью шаблона подписчика издателя.

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

• Сведения об использовании брокера сообщений в инфраструктуре обмена сообщениями см. в параметрах асинхронного обмена сообщениями в Azure.

• Выбор между службами обмена сообщениями Azure