В предыдущей статье из этой серии я рассказывал про принципы SRP и IoC в мире менеджмента. В этой статье я продолжу перекладывать технические подходы на истории, связанные с управлением разработкой программного обеспечения. Здесь мы рассмотрим подходы оркестровки и хореографии в контексте паттерна Saga , служащего организации взаимодействия частей распределенных систем. А потом попробуем отобразить эти же подходы на менеджмент разработки айтишных систем. Кстати, про то, как мы пришли к этому подходу можно прочитать в статье “Эволюция процессов в фронтовых командах привлечения Tinkoff”.
Оркестровка и хореография
Шаблон хореографии
Каждый компонент системы участвует в процессе принятия решений о ходе бизнес-транзакции, не полагаясь на центральную точку управления.
Контекст и проблема
В архитектуре микрослужб облачное приложение часто делится на несколько небольших служб, которые работают вместе для комплексной обработки бизнес-транзакций. Чтобы снизить взаимосвязь между службами, каждая служба отвечает за одну бизнес-операцию. Некоторые преимущества включают более быструю разработку, меньшую базу кода и масштабируемость. Однако разработка эффективного и масштабируемого рабочего процесса является сложной задачей и часто требует сложного взаимодействия между службами.
Разработка бизнес-процессов в компании
Службы взаимодействуют друг с другом с помощью четко определенных API. Даже одна бизнес-операция может создавать много вызовов типа «точка-точка» среди всех служб. Распространенным шаблоном обмена данными является использование централизованной службы, которая выступает в качестве оркестратора.
Он подтверждает все входящие запросы и делегирует операции соответствующим службам. При этом он также управляет рабочим процессом всей бизнес-транзакции. Каждая служба просто завершает операцию и не знает об общем рабочем процессе.
Шаблон оркестратора сокращает обмен данными между точками между службами, но имеет некоторые недостатки из-за тесной взаимосвязи между оркестратором и другими службами, участвующими в обработке бизнес-транзакции. Для выполнения задач в последовательности оркестратор должен обладать знаниями об обязанностях этих служб. Если вы хотите добавить или удалить службы, существующая логика будет нарушена, и вам потребуется перекрестить части пути связи. Хотя вы можете настроить рабочий процесс, легко добавлять или удалять службы с помощью хорошо спроектированного оркестратора, такая реализация сложна и сложна в обслуживании.
Решение
Позвольте каждой службе самостоятельно определять, когда и как обрабатывать бизнес-операцию, не создавая зависимостей от центрального оркестратора.
Одним из способов реализации хореографии является использование шаблона асинхронного обмена сообщениями для координации бизнес-операций.
Хореографии в BPMN
Клиентский запрос публикует сообщения в очереди сообщений. По мере поступления сообщений они передаются подписчикам или службам, заинтересованным в этом сообщении. Каждая подписанная служба выполняет свою операцию, как указано в сообщении, и отвечает на очередь сообщений успешной или неудачной операцией. В случае успеха служба может отправить сообщение обратно в ту же или другую очередь сообщений, чтобы другая служба при необходимости продолжила рабочий процесс. Если операция завершается сбоем, шина сообщений может повторить операцию.
Таким образом, службы направляют рабочий процесс между собой без зависимости от оркестратора или прямого взаимодействия между ними.
Так как обмен данными между точками не поддерживается, этот шаблон помогает уменьшить связь между службами. Кроме того, он может устранить узкое место производительности, вызванное оркестратором, когда ему нужно работать со всеми транзакциями.
Когда следует использовать этот шаблон
Используйте шаблон хореографии, если вы планируете часто обновлять или заменять службы, а также добавлять или удалять некоторые службы в конечном итоге. Все приложение можно изменить с меньшими усилиями и минимальными нарушениями работы существующих служб.
Рассмотрите этот шаблон, если в центральном оркестраторе возникают узкие места производительности.
Этот шаблон является естественной моделью для бессерверной архитектуры, в которой все службы могут быть кратковременными или управляемыми событиями. Службы могут закручиваться из-за события, выполнять свою задачу и удаляться после завершения задачи.
Проблемы и рекомендации
Децентрализование оркестратора может вызвать проблемы при управлении рабочим процессом.
Если службе не удается завершить бизнес-операцию, ее может быть трудно восстановить после этого сбоя. Один из способов заключается в том, чтобы служба указывала на сбой путем запуска события. Другая служба подписывается на эти события сбоя, выполняет необходимые действия, такие как применение компенсирующих транзакций для отмены успешных операций в запросе.
Неисправная служба также может не вызывать событие для сбоя. В этом случае рассмотрите возможность использования механизма повтора и или времени ожидания, чтобы распознать операцию как сбой. См. пример в разделе «Пример».
Реализовать рабочий процесс очень просто, если требуется параллельно обрабатывать независимые бизнес-операции. Можно использовать одну шину сообщений. Однако рабочий процесс может усложняться, когда хореография должна выполняться в последовательности. Например, служба C может начать свою работу только после успешного завершения операций служб A и B. Один из подходов заключается в наличии нескольких автобусов сообщений, которые получают сообщения в требуемом порядке. Дополнительные сведения см. в разделе Примеры .
Хореографический шаблон становится сложной задачей, если количество служб быстро растет. Учитывая большое количество независимых движущихся частей, рабочий процесс между службами, как правило, усложняется. Кроме того, усложняется распределенная трассировка.
Оркестратор централизованно управляет устойчивостью рабочего процесса и может стать единой точкой отказа. С другой стороны, для хореографии роль распределяется между всеми службами, и устойчивость становится менее надежной.
Каждая служба отвечает не только за устойчивость своей работы, но и за рабочий процесс. Эта ответственность может быть обременительной для службы и трудно реализовать. Каждая служба должна повторять временные, непереходные и временные сбои, чтобы при необходимости запрос был корректно завершен. Кроме того, служба должна тщательно сообщать об успешном или неудачном выполнении операции, чтобы другие службы могли действовать соответствующим образом.
Пример
В этом примере показан шаблон хореографии с помощью приложения «Доставка дронами». Когда клиент запрашивает получение, приложение назначает дрон и уведомляет клиента.
Пример этого шаблона доступен на сайте GitHub.
Для бизнес-транзакции с одним клиентом требуется три отдельные бизнес-операции: создание или обновление пакета, назначение дрона для доставки пакета и проверка состояния доставки. Эти операции выполняются тремя микрослужбами: пакетом, планировщиком дронов и службой доставки. Вместо центрального оркестратора службы используют обмен сообщениями для совместной работы и координации запросов между собой.
Проектирование
Бизнес-транзакция обрабатывается последовательно через несколько прыжков. Каждый прыжок имеет шину сообщений и соответствующую бизнес-службу.
Когда клиент отправляет запрос на доставку через конечную точку HTTP, служба приема получает его, вызывает событие операции и отправляет его в шину сообщений. Шина вызывает подписанную бизнес-службу и отправляет событие в запросе POST. После получения события бизнес-служба может завершить операцию с успехом, сбоем или истекает время ожидания запроса.
В случае успешного выполнения служба отвечает шине с кодом состояния ОК, вызывает новое событие операции и отправляет его в шину сообщений следующего прыжка. В случае сбоя или истечения времени ожидания служба сообщает о сбое, отправляя код BadRequest в шину сообщений, отправив исходный запрос POST. Шина сообщений повторяет операцию на основе политики повтора. По истечении этого периода шина сообщений помечает неудачную операцию и останавливает дальнейшую обработку всего запроса.
Этот рабочий процесс продолжается до тех пор, пока не будет обработан весь запрос.
В структуре используется несколько шин сообщений для обработки всей бизнес-транзакции. Microsoft Сетка событий Azure предоставляет службу обмена сообщениями. Приложение развертывается в кластере Служба Azure Kubernetes (AKS) с двумя контейнерами в одном модуле pod. Один контейнер запускает посла , который взаимодействует с Сеткой событий, а другой — бизнес-службу.
Подход с двумя контейнерами в одном модуле pod повышает производительность и масштабируемость. Посол и бизнес-служба используют одну и ту же сеть, что обеспечивает низкую задержку и высокую пропускную способность.
Чтобы избежать каскадных операций повторных попыток, которые могут привести к нескольким действиям, только Служба «Сетка событий» повторяет операцию вместо бизнес-службы. Он помечает неудачный запрос, отправляя сообщения в очередь недоставленных сообщений (DLQ).
Бизнес-службы являются идемпотентными, чтобы операции повторных попыток не приводили к дублированию ресурсов. Например, служба пакетов использует операции upsert для добавления данных в хранилище данных.
В примере реализуется пользовательское решение для корреляции вызовов во всех службах и прыжках Сетки событий.
Ниже приведен пример кода, демонстрирующий шаблон хореографии между всеми бизнес-службами. В нем показан рабочий процесс транзакций приложения доставки с помощью дронов. Код для обработки исключений и ведения журнала был удален для краткости.
[HttpPost] [Route(«/api/[controller]/operation»)] [ProducesResponseType(typeof(void), 200)] [ProducesResponseType(typeof(void), 400)] [ProducesResponseType(typeof(void), 500)] public async Task Post([FromBody] EventGridEvent[] events) < if (events == null) < return BadRequest(«No Event for Choreography»); >foreach(var e in events) < ListlistEvents = new List(); e.Topic = eventRepository.GetTopic(); e.EventTime = DateTime.Now; switch (e.EventType) < case Operations.ChoreographyOperation.ScheduleDelivery: < var packageGen = await packageServiceCaller.UpsertPackageAsync(delivery.PackageInfo).ConfigureAwait(false); if (packageGen is null) < //BadRequest allows the event to be reprocessed by Event Grid return BadRequest(«Package creation failed.»); >//we set the event type to the next choreography step e.EventType = Operations.ChoreographyOperation.CreatePackage; listEvents.Add(e); await eventRepository.SendEventAsync(listEvents); return Ok(«Created Package Completed»); > case Operations.ChoreographyOperation.CreatePackage: < var droneId = await droneSchedulerServiceCaller.GetDroneIdAsync(delivery).ConfigureAwait(false); if (droneId is null) < //BadRequest allows the event to be reprocessed by Event Grid return BadRequest(«could not get a drone id»); >e.Subject = droneId; e.EventType = Operations.ChoreographyOperation.GetDrone; listEvents.Add(e); await eventRepository.SendEventAsync(listEvents); return Ok(«Drone Completed»); > case Operations.ChoreographyOperation.GetDrone: < var deliverySchedule = await deliveryServiceCaller.ScheduleDeliveryAsync(delivery, e.Subject); return Ok(«Delivery Completed»); >return BadRequest(); > >
Связанные ресурсы
Рассмотрите эти шаблоны в своем дизайне хореографии.
- Модульная структура бизнес-службы с помощью шаблона проектирования ambassador.
- Реализуйте шаблон выравнивания нагрузки на основе очередей , чтобы справиться с пиками рабочей нагрузки.
- Используйте асинхронный распределенный обмен сообщениями с помощью шаблона «издатель—подписчик».
- Используйте компенсирующие транзакции , чтобы отменить ряд успешных операций в случае сбоя одной или нескольких связанных операций.
- Сведения об использовании брокера сообщений в инфраструктуре обмена сообщениями см. в статье Параметры асинхронного обмена сообщениями в Azure.
Источник: learn.microsoft.com
Введение в BPMN
Нотация моделирования бизнес-процессов BPMN (Business Process Model and Notation) — это международный стандарт моделирования бизнес-процессов. Он является одним из важнейших компонентов для достижения согласованности между Бизнес-процессами и ИТ-системами.
Большинство современных компаний сегодня выбирают BPMN в качестве стандарта для моделирования своих процессов. Основные причины этого выбора:
- Поддержка популярными программными продуктами для моделирования бизнес-процессов (Business Studio, ELMA, Bizagi и др.);
- Оптимальный набор графических элементов, который позволяет детально описать любой процесс;
- Возможность автоматизировать бизнес-процессы без необходимости программирования;
- Уменьшение разрыва между моделями «Как есть» и «Как должно быть».
Как пользоваться данным руководством
Благодаря большому количеству примеров настоящее руководство по BPMN можно использовать как самоучитель для освоения нотации «с нуля». Для этого рекомендуется читать все главы по порядку с самого начала. Также это руководство подходит в качестве справочника, в котором опытные специалисты могут найти ответ на вопрос, если что-то забыли.
Руководство по BPMN имеет следующие особенности:
- Все содержимое полностью соответствует последней версии спецификации нотации BPMN;
- Статьи сфокусированы на нотации моделирования, без привязки к какому-либо конкретному программному продукту, что дает возможность применять полученные знания в любых программах, которые поддерживают моделирования в BPMN;
- Диаграммы выполнены в едином стиле и в черно-белом цвете для удобства восприятия материала;
- Мы постарались писать простым, понятным языком, чтобы любой специалист смог легко разобраться в теме;
- Любую статью можно прокомментировать: задать вопрос или высказать пожелание по более подробному описанию отдельных моментов.
Хотите быстро освоить BPMN?
Пройдите обучение в нашем учебном центре!
Источник: www.optimacons.info