Оркестровка бизнес процесса это

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

Плюсы

• потребитель реагируют на события по мере их поступления (используя модель подписки и параллельной обработки)
• ускоряется запрос-ответ (ведь уменьшается физическая и временную связь между клиентами и сервисами)
• данные событий могут быть обогащены (посредством потребителя-обогатителя)
• события не требуют ответа и по своей сути асинхронны
• потребитель может работать в режиме брокера (принимать сообщения, но обрабатывать их асинхронно)
• заставляет участников общения, отказаться от распределенных транзакций (обеспечивает лучшую поддержку согласованности между взаимодействием процессов и постоянными переходами между внутренними состояниями)
• состояние системы может быть построено или восстановлено из журнала событий (правда восстановление является очень нетривиальной задачей + нарушает концепцию EDA)
• отвечает на вопросы: что первично, где меняется, куда переносится
• упрощает MDM (англ. master data management — управление основными данными) в информационных системах организаций (как правило — в условиях нескольких информационных систем)
• наводит порядок в процессе миграции данных (где данные появляются, где редактируются, сегментирование и приоритеты)
• помогает менять окружение (замена производителя событий или потребителей событий)
• упрощает подключение нового потребителя / замены старого
• создает единообразное объединение подсистем на различных платформах (легкая замена подсистем)

Минусы

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

Брокер между участниками

Плюсы

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

Минусы

• очередь в брокере может быть переполнена и за этим нужно следить
• брокер сообщений это отдельное решение (которое нужно реализовать / приобрести, настроить и мониторить)

Оркестрация

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

Оркестрация и хореография. Как построить бизнес-процесс в зоопарке микросервисов

✅ Зачем нужны бизнес-процессы? Организация бизнес-процессов

При работе с повествованиями выбирают один из подходов работы (всего мне известно 2 вида подхода):

1. Хореография — распределение принятия решений и упорядочения действий между участниками повествования (в основном которые общаются, обмениваясь событиями).
2. Оркестрация — централизация координирующей логики повествования в виде оркестратора. Оркестратор отправляет участникам повествования командные сообщения с инструкциями, какие операции нужно выполнить.

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

Детали оркестрирации

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

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

Если участник возвращает ошибку, то оркестратор так же знает о том, кого из участников нужно об этом оповестить.

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

Моделирование оркестраторов

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

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

Преимущества на примере

Давайте посмотрим работу на примере появления события в большой системе использующей EDA.

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

Недостатки оркестровки

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

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

Маленький итог

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

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

Data Grid vs Api Service

Есть готовые решения под названием Data Grid — это подход основанный на EDA:

1. DG на базе Tarantool https://www.youtube.com/watch?v=OPB5zvUm6gU
2. DG на базе Apache Ignite https://www.gridgain.com/resources/blog/getting-started-with-apache-ignite-deployment-patterns
3. Др. более простое решение или собственный велосипед (CQRS EventSource приложение)

Однако, небольшому приложению я бы рекомендовал упрощать в угоду синхронного обмена данными между Api приложениями. А вот крупному приложению все же стоит подумать над оркестратором, иначе получится как в Netflix:

Вопросы для принятия решения:

1. собираемся ли мы поддерживать большое кол-во протоколов на вход
2. собираемся ли мы поддерживать большое кол-во протоколов на выход
3. собираемся ли мы поддерживать большое кол-во контрактов на вход
4. собираемся ли мы поддерживать большое кол-во контрактов на выход
5. нужна ли нам гибкость с использованием знакомых технологий/языках или мы не боимся привязки к стороннему ПО и др. языкам (например Lua в Tarantool)
6. с одной стороны готовый DG выглядит быстрее, но с другой стороны нужна экспертиза
7. в силу последних обстоятельств, возможно Apache Ignite теперь не выглядит возможным решением, т.к. не отечественное ПО и поддержку мы возможно никак не получим

Источник: yapro.ru

Введение в BPMN

Нотация моделирования бизнес-процессов BPMN (Business Process Model and Notation) — это международный стандарт моделирования бизнес-процессов. Он является одним из важнейших компонентов для достижения согласованности между Бизнес-процессами и ИТ-системами.

Большинство современных компаний сегодня выбирают BPMN в качестве стандарта для моделирования своих процессов. Основные причины этого выбора:

• Поддержка популярными программными продуктами для моделирования бизнес-процессов (Business Studio, ELMA, Bizagi и др.);
• Оптимальный набор графических элементов, который позволяет детально описать любой процесс;
• Возможность автоматизировать бизнес-процессы без необходимости программирования;
• Уменьшение разрыва между моделями «Как есть» и «Как должно быть».

Как пользоваться данным руководством

Благодаря большому количеству примеров настоящее руководство по BPMN можно использовать как самоучитель для освоения нотации «с нуля». Для этого рекомендуется читать все главы по порядку с самого начала. Также это руководство подходит в качестве справочника, в котором опытные специалисты могут найти ответ на вопрос, если что-то забыли.

Руководство по BPMN имеет следующие особенности:

• Все содержимое полностью соответствует последней версии спецификации нотации BPMN;
• Статьи сфокусированы на нотации моделирования, без привязки к какому-либо конкретному программному продукту, что дает возможность применять полученные знания в любых программах, которые поддерживают моделирования в BPMN;
• Диаграммы выполнены в едином стиле и в черно-белом цвете для удобства восприятия материала;
• Мы постарались писать простым, понятным языком, чтобы любой специалист смог легко разобраться в теме;
• Любую статью можно прокомментировать: задать вопрос или высказать пожелание по более подробному описанию отдельных моментов.

Хотите быстро освоить BPMN?
Пройдите обучение в нашем учебном центре!

Источник: www.optimacons.info

От микросервисного монолита к оркестратору бизнес-сервисов

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

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

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

Этап №1. Монолит

1.1 Характеристики

Обычно монолитную архитектуру можно описать так:

1. Единая точка разработки и деплоя
2. Единая база данных
3. Единый цикл релиза для всех изменений
4. В одной системе реализовано несколько бизнес-задач

1. Pattern: Monolithic Architecture
2. Бизнес-гибкость через микросервисную архитектуру
3. Don’t start with a monolith

1.2 Проблемы

1. Система единая, при этом решает много разных бизнес-задач. Разные бизнес-задачи развивают разные подразделения компании и двигаются с разной скоростью. Отсюда возникает проблема с взаимозависимыми релизами разных подразделений, когда все ждут самого медленного.
2. Сложно масштабировать бизнес-приложения, которые объединяет монолит. Это приводит к тому, что не учитываются особенности каждого приложения, и масштабирование делается неэффективно.
3. При выборе технологического стека для новой бизнес-задачи приходится подстраиваться под среду разработки монолита, хотя этот выбор не всегда является наилучшим.
4. Система уходит в релиз целиком, поэтому должна быть протестирована целиком. Это приводит к сложному регрессионному тестированию, затягиванию процесса тестирования и репотинга багов всем поставщикам изменений, замедлению скорости релизов, и, соответственно, увеличению времени time-to-market.
5. Последнее ведет к тому, что бизнесу тяжело быстро собрать обратную связь от рынка.

1.3 Как перейти на следующий этап

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

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

1. Переход от монолитной архитектуры к распределенной
2. How to break a Monolith into Microservices
3. Command and Query Responsibility Segregation (CQRS) на практике
4. Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы
5. StranglerFigApplication

При создании микросервисной архитектуры полезно периодически проверять себя по чеклисту The Microservice Architecture Assessment, чтобы не упустить какую-то важную деталь.

Этап №2. Микросервисный монолит

2.1 Характеристики

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

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

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

По факту, получился тот же монолит, но с большим количеством новых проблем.

2.2 Проблемы

1. Прямые связи между микросервисами усложняют анализ проблем. Например, запрос может пройти через 5 микросервисов, прежде, чем вернуться с ответом. Что если на третьем микросервисе запрос завис? Что если там была ошибка? Что если на втором шаге должно было создаться сообщение в очередь, но оно не появилось? Возникает сложность с разбором проблем.
2. Предыдущий пункт усложняется, если у микросервиса много экземпляров. Тогда возникает ситуация, что запрос пришел на экземпляр, который завис.
3. Архитектуру сложно понять и, чем больше сервисов вы добавляете, тем запутанней всё становится. В целом, добавление новых сервисов нелинейно повышает сложность архитектуры.
4. Неизвестно, кто потребители вашего API, что добавляет сложности в проектировании API и его изменении.

Если на пути рефакторинга монолита вы остановитесь на этом этапе, то, вполне резонно, сделаете вывод, что с монолитом было лучше и дешевле.

2.3 Как перейти на следующий этап

Основные идеи: локализовать точки интеграции и контролировать все потоки данных. Чтобы этого добиться, надо использовать:

1. API Gateway для локализации синхронных взаимодействий и мониторинг/логирование трафика между микросервисами. В идеале, надо иметь визуализацию трассировки любого запроса.
2. Service Discovery для отслеживания работоспособности экземпляров микросервиса и перенаправление трафика на «живые» экземпляры.
3. Запретить прямые вызовы между микросервисами.

Чтобы избежать типовых проблем и упростить разработку, рекомендую взять на вооружение подходы по повышению отказоустойчивости:

1. Circuit Breaker
2. Tolerant Reader
3. Embracing Failure
4. The Timeout AntiPattern
5. Graceful Degradation
6. Use versioning only as a last resort

Этап №3. Микросервисы

3.1 Характеристики

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

Становится заметна главная черта хорошей архитектуры: сложность системы растет линейно с увеличением количества микросервисов.

1. Pattern: Microservice Architecture
2. Microsoft Dev School — Микросервисы, чистый PaaS и конкурс мисс Россия
3. Microservices, a definition of this new architectural term

3.2 Проблемы

На этом этапе сложные технические задачи решены, поэтому начинаются проблемы на уровне бизнес-задач:

1. Среди сотен микросервисов и разных API бизнес не может понять, какие инструменты есть у него в руках. Пазл складывается в стройные картинки только у энтерпрайз архитекторов, а их, как известно, очень мало на Земле.
2. Бизнес хочет увидеть лес за деревьями, чтобы понимать, какие есть детали и как из них можно собирать новые продукты, не прибегая к разработке.
3. Сборку новых продуктов из существующих кубиков, хочется совместить с продуктовой разработкой, чтобы Владелец продукта сам ориентировался, какие ему доступны ресурсы.

3.3 Как перейти на следующий этап

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

1. Изучите концепцию Citizen Integrator. Для наглядного примера заведите себе пару процессов в Zapier.
2. Опишите микросервисы в виде блоков, решающих бизнес-задачу, и сделайте из них конструктор. Это можно сделать: 1) на готовых инструментах, 2) обернуть BPM-движки типа Camunda, 3) написать всё самим с нуля. Все три подхода жизнеспособны. Выбор подхода зависит от стратегии вашей компании и наличии у вас ИТ-архитекторов и хороших программистов.

1. The Microservices Workflow Automation Cheat Sheet
2. Clouds, iPaaS, Citizen Integrator and Why India’s Outsourcing Is Losing Money

Этап №4. Оркестратор бизнес-сервисов

4.1 Характеристики

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

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

4.2 Проблемы

1. Создание, внедрение и развитие оркестратора бизнес-процессов является дорогим удовольствием.
2. Если ослабить архитектурный контроль, оркестратор может превратиться в узкое место систем, созданных на нем.
3. Чем больше систем создается на оркестраторе, тем больше бизнес зависит от этого решения. В целом, это начинает напоминать проблемы монолита.

4.3 Как перейти на следующий этап

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

Заключение

Эти четыре этапа показывают, как мне кажется, естественный ход вещей:

1. Вначале приложение небольшое и решает одну бизнес-задачу. Со временем в него добавляют много всего и оно превращается в неповоротливый монолит.
2. При первой попытке разделить монолит многие команды не готовы к возрастающей сложности. Монолит делится на много микросервисов, но из-за большого количество взаимосвязей получается тот же монолит, только с новыми проблемами: простейшие задачи типа трейсинга запроса или мониторинга инфраструктуры становятся вызовом для команды разработки.
3. Когда сложности решаются, получается стройная и масштабируемая архитектура. Добавление новых микросервисов линейно повышает сложность.
4. На последнем этапе приходит бизнес и резонно говорит, что раз есть готовые решения бизнес-задач, то давайте делать новые продукты без разработки. Будем соединять готовые независимые блоки в новые бизнес-процессы через оркестратор.

• микросервисы
• микросервисная архитектура
• архитектура по

• Анализ и проектирование систем
• Микросервисы

Источник: habr.com