Event-Driven Business Process Orchestration
Рассмотрим очередной популярный подход к проектированию систем для управления и координации выполнения бизнес-задач или процессов на основе событий. В общем случае это микс Хореографии и Оркестрации. Рассмотрим их подробнее.
Хореография
Хореография — разработка систем, где взаимодействие между компонентами или службами происходит без необходимости в центральном контроллере (организаторе, дирижёре — как вам ближе). В таких системах каждый компонент отвечает за понимание своей роли и координацию общения с другими компонентами системы. Чем-то похоже на балет, где у каждой балерины своя роль, но в сумме получается выступление, а не соло программа со случайными столкновениями участниц на сцене.
Можно выделить основные стороны архитектуры:
Децентрализованное управление: система распределяет управление между участвующими компонентами. Каждый из них самостоятельно решает, как реагировать на события или сообщения, которые он получает.
Автономность: компоненты в отлаженной системе должны работать автономно, не полагаясь на внешнюю координацию (как балерины: у них нет суфлера или человека, бегающего за ними с криками: «Куда ты, Света!!!»). Они отвечают за интерпретацию входящих сообщений и запуск соответствующих действий на основе своей внутренней логики.
Слабая связь: данный подход способствует слабой связи между компонентами, позволяя им взаимодействовать без сильной зависимости от реализаций друг друга. Этот аспект повышает гибкость системы и облегчает обслуживание и масштабируемость.
Асинхронная связь: связь между компонентами в хореографических системах обычно асинхронная. Компоненты обмениваются сообщениями или событиями, не требующими немедленного реагирования, что обеспечивает лучшую масштабируемость и отказоустойчивость.
Управляемые события: компоненты реагируют на события или изменения состояния системы. События запускают действия внутри отдельных компонентов, и поведение системы определяется коллективными реакциями этих компонентов.
Хореография обычно используется там, где системы должны быть масштабируемыми, устойчивыми и адаптируемыми. Для примера — абстрактная архитектура микросервисов, где каждая служба выполняет определенную функцию и взаимодействует с другими службами посредством асинхронного обмена сообщениями. Каждый сервис знает только свою маленькую часть, и нет жестких рамок на выполнение определенной, четко поставленной, ограниченной временем, глобальной задачи.
Оркестрация
Вообще считается (правда, не знаю, кем), что эволюция обезьяны в человека началась с того, что одна из них взяла палку в руки и заставила других работать.
В нашем же случае оркестрация — разработка систем, где взаимодействие между компонентами или службами происходит при координации центральным контроллером или оркестратором — дирижёром — который координирует выполнение различных задач или процессов, направляя их к соответствующим участникам или системам на основе заранее определенных правил и условий. В контексте программирования и архитектуры систем это означает централизованное управление потоком задач и действий в системе. Пример из реального мира: оркестр под управлением дирижёра. Благодаря его командам мы слышим прекрасную музыку (интересно, есть ли выступление моргенштерна с оркестром? Если да, то этот принцип работает не всегда), а не какофонию.
Можно выделить основные стороны архитектуры:
Централизованное управление: оркестратор или центральный контроллер определяет порядок выполнения задач и управляет их распределением между участниками системы.
Жестко заданные процессы: порядок выполнения задач заранее определяется и настраивается в рамках оркеструемого процесса. Это может включать в себя последовательность шагов, условия выполнения и прочее.
Управление состоянием: дирижёр может отслеживать состояние выполнения процесса и реагировать на изменения, например, перераспределяя задачи или принимая решения на основе текущего контекста.
Управление ресурсами: оркестрация также может включать в себя управление ресурсами, такими как выделение вычислительных мощностей, доступ к данным и другие аспекты, необходимые для выполнения процесса.
Оркестрация часто используется в распределенных системах, микросервисной архитектуре и облачных вычислениях для координации выполнения сложных задач, например деплой, управление контейнерами, автоматизация документооборота.
Событийно-ориентированная оркестрация бизнес-процессов
В нашем случае это смесь подходов, так как только ситхи возводят все в абсолют. А если серьезно, то сложно добиться использования одного подхода, чаще всего это вопрос акцентов.
Это подход к проектированию, используемый для управления и координации выполнения задач или процессов на основе асинхронных событий. Он предполагает использование принципов событийной архитектуры(Event‑Driven) для организации потока действий внутри системы.
Можно выделить основные стороны архитектуры:
Децентрализованное выполнение: в то время как центральный контроллер управляет логикой оркестровки, выполнение задач обычно децентрализовано. Потребители событий работают автономно, выполняя назначенные им действия в ответ на события без прямых инструкций от контролера. Децентрализация обеспечивает большую масштабируемость, гибкость и отказоустойчивость системы.
Асинхронная связь: события создаются и потребляются асинхронно без необходимости немедленного реагирования. Такая асинхронная природа позволяет системам обрабатывать большие объемы событий и поддерживать оперативность реагирования даже при различных нагрузках.
Динамическая адаптация: данный подход обеспечивает динамическую адаптацию рабочих процессов на основе изменяющихся условий или требований. Рабочие процессы могут эволюционировать с течением времени по мере возникновения новых событий или изменения состояния системы, что обеспечивает оперативное и гибкое управление процессами.
Для лучшего понимания рассмотрим также ключевые компоненты:
Потребители событий — компоненты или службы в системе, которые отслеживают события и реагируют на них. Эти потребители отвечают за обработку событий и инициирование соответствующих действий или рабочих процессов. Они подписываются на определенные типы событий и выполняют задачи на основе данных о событиях.
Брокеры событий — очереди сообщений или системы публикации‑подписки, облегчают взаимодействие между производителями (компонентами, генерирующими события) и потребителями событий. Они действуют как посредники, которые направляют события соответствующим потребителям на основе критериев подписки.
Контроллер (Дирижёр) — это центральный компонент, ответственный за координацию потока действий на основе полученных событий. Он анализирует входящие события, определяет последовательность задач или действий, которые необходимо выполнить, и делегирует выполнение соответствующим компонентам или службам. Организатор может поддерживать состояние текущих рабочих процессов и управлять общей логикой выполнения.
«Хорошо, но это even driven orchestration, — возразите вы, — какие плюсы от бизнес-процессов?» Ниже рассмотрим основные плюсы:
Централизация процесса принятия решений: инструменты для организации процессов, такие как Camunda, предназначены для принятия решений о том, что должно происходить в бизнес‑процессе, а затем — для выполнения соответствующих действий. Поэтому ответственность за принятие решений может быть удалена из мест, которым она не принадлежит. Кроме того, легче вносить изменения в соответствии с меняющимися техническими и/или бизнес‑требованиями.
Использование BPMN (Business Process Model and Notation) диаграмм в разработке: процессы описываются с помощью визуальных диаграмм, это автоматически и документация, и легкий способ внести изменения в процессы, провести быстрый аудит системы, оперативно находить логические ошибки в процессах, напрямую использовать опыт людей, понимающих в бизнес‑процессах, но не знающих ничего о программировании или UML-диаграммах. Кроме того, BPMN предоставляет отличный набор способов обработки «плохих сценариев».
Микро-пример: «Доставка еды»:
*Для простоты пример реализует только поток успешного выполнения.
Ключевые Компоненты:
Служба-Дирижер (Моя доставка) — это микросервис SpringBoot, включающий Camunda (Community edition) в качестве встроенного движка процессов BPMN. Camunda добавляется как библиотека приложений и может запускаться, останавливаться и масштабироваться вместе с нашим микросервисом.
Бизнес‑модель в нотации BPMN
Компоненты модели:
Сервисные задачи используются для вызова или запуска бизнес‑логики. У нас это проверка наличия продуктов, готовка еды, поиск доставщика и непосредственно доставка.
Событие перехвата промежуточного сообщения (Intermediate Message Catch Event): этап процесса, на котором соответствующий экземпляр процесса ожидает входящего сообщения перед началом потока.
События «Старт» и «Стоп»: думаю, тут объяснение будет лишним.
Параллельный шлюз позволяет запускать процессы параллельно, мы предполагаем, что поиск доставщика и приготовление еды можно делать параллельно, и отдавать на доставку, только если оба процесса завершены.
Для простоты и уменьшения количества кода (написанного левой ногой сегодня) сторонние микросервисы представлены как слушатели событий в нашем же приложении (com.delivery.camunda.listeners). В реале этот будут приложения, где повар или доставщик будет реагировать на получение заказа. Обработчики процессов: com.delivery.camunda.delegates. В нашем случае для упрощения они просто перенаправляют сообщение.
https://github.com/kain64/deliveryexample/tree/main
Вообще интересная это штука, камунда, надо будет... вообще про BPMN и Camunda много раз писали, поэтому не надо. Так что концовка скомкана. Надеюсь, не утомил того, кто осилил, своими рассуждениями.
