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

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

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

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

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

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

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

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

Решение

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

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

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

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

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

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

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

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

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

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

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

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

  

  Блок-схема показывает логику обработки ошибок и компенсации в шаблоне хореографии с последовательными зависимостями службы. На верхнем уровне начальный узел указывает на службу A. Служба A соединяется с ромбом, который указывает на службу B слева и службу C справа. Стрелки от каждой из этих служб указывают на ромб решения, который спрашивает, проваливается ли запрос. Путь, помеченный 'да', ветвится вверх и возвращается в петле к ромбу, соединяющему все три сервиса. Путь, обозначенный как "нет", ведет к блоку, где написано "обе службы успешно завершены". Из этого успешного состояния поток продолжает движение к службе D, которая подключается к решающему ромбу, чтобы спросить, завершается ли запрос сбоем. Путь "да" от этого ромба возвращается вверх, чтобы снова войти в поток перед службой D, а путь "нет" продолжается вниз к конечному узлу.

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

  

  На схеме показан поток сообщений в шаблоне хореографии, в котором операции обработки служб выполняются параллельно и последовательно. В верхней части находятся пять компонентов, расположенных по горизонтали: служба A, брокер сообщений, служба B, служба C и служба D. В левом углу пользователь отправляет запрос на обслуживание A. Служба A преобразует запрос в сообщение m1_a и публикует его в брокер сообщений. Под брокером сообщений по вертикали показано, как каждая служба обрабатывает сообщения. Внутри затенённой области с меткой для параллельной обработки брокер сообщений отправляет m1_a как к службе B, так и к службе C одновременно с помощью пунктирных стрелок. Служба B обрабатывает сообщение и возвращает m1_b брокеру сообщений. Служба C обрабатывает сообщение и возвращает m1_c брокеру сообщений. В правой части схемы два небольших поля представляют условия ожидания для службы D. Первое условие указывает на то, что служба D не сможет продолжить работу до m1_b и m1_c, пока она не получит оба сообщения. Второе условие гласит: ждать до m1_b. После завершения параллельной обработки и ответа службы B и service C брокер сообщений отправляет m1_c в службу D, а затем m1_b. Служба D обрабатывает эти сообщения и возвращает m1_d брокеру сообщений. Под схемой условные обозначения объясняют каждую нотацию. Запрос ссылается на исходный HTTP-запрос, отправленный в общедоступную конечную точку. M1_a http-запрос, преобразованный в сообщение. M1_b это сообщение обрабатывается и отправляется брокеру сообщений из службы B. M1_c сообщение обрабатывается и отправляется обратно брокеру сообщений из службы C, а m1_d указывает, что m1_b и m1_c обрабатываются и отправляются обратно в качестве окончательного подтверждения брокеру сообщений. Сплошные стрелки указывают на публикацию сообщений и дефисированные стрелки указывают на подписки.

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

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

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

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

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

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

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

Используйте этот шаблон, когда:

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

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

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

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

• Центральный оркестратор представляет узкие места в производительности.

Этот шаблон может быть не подходит, если:

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

• Обмен данными между компонентами неизбежен.

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

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

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

Столп	Как этот шаблон поддерживает цели основных компонентов
Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды.	Распределенные компоненты в этом шаблоне являются автономными и предназначены для замены, поэтому вы можете изменить рабочую нагрузку с меньшим общим изменением в системе. - Инструменты и процессы OE:04
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Этот шаблон предлагает альтернативу при возникновении узких мест производительности в централизованной оркестрационной топологии. - Планирование емкости PE:02 - Pe:05 Масштабирование и секционирование

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

Пример

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

На схеме показана реализация хореографии на основе событий для системы доставки дронов, использующая службы Azure. В крайнем левом углу стрелка, представляющая запрос клиента, направлена от значка пользователя к блоку с надписью "ingestion", который является точкой входа в среду Azure Container Apps. В среде Container Apps стрелки связывают службу приема, микросервис пакета, планировщик дронов и микросервис доставки через Azure Service Bus. Другая стрелка ведет от микросервиса пакета к прямоугольнику с надписью Azure Cosmos DB в среде "Приложения контейнеров". Стрелка с меткой "отправлено" идет из службы доставки вверх к Azure Event Grid. Под полем с меткой служебной шины стрелка указывает вниз на очередь недоставленных букв (DLQ), представленную значком круга.

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

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

• Создание или обновление пакета.

• Назначьте беспилотный летательный аппарат для доставки пакета.

• Обработка доставки, включая проверку и отправку уведомления при отправке пакета.

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

Проектирование

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

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

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

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

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

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

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

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

Дальнейшие действия

• Централизованное управление схемой событий с помощью реестра схем в Центрах событий Azure для обеспечения совместимости по мере развития служб.

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

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

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

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

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

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

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

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