Camunda zeebe что это

Zeebe

Zeebe is the process automation engine powering Camunda 8. While written in Java, you do not need to be a Java developer to use Zeebe.

With Zeebe you can:

• Define processes graphically in BPMN 2.0.
• Choose any gRPC-supported programming language to implement your workers.
• Build processes that react to events from Apache Kafka and other messaging platforms.
• Use as part of a software as a service (SaaS) offering with Camunda 8 or deploy with Docker and Kubernetes (in the cloud or on-premises) with Camunda 8 Self-Managed.
• Scale horizontally to handle very high throughput.
• Rely on fault tolerance and high availability for your processes.
• Export processes data for monitoring and analysis (currently only available through the Elasticsearch exporter added in Camunda 8 Self-Managed).
• Engage with an active community.

For documentation on deploying Zeebe as part of Camunda 8 Self-Managed, refer to the deployment guide.

Enterprise support for Zeebe​

Paid support for Zeebe is available via either Camunda 8 Starter or Camunda 8 Enterprise. Customers can choose either plan based on their process automation requirements. Camunda 8 Enterprise customers also have the option of on-premises or private cloud deployment.

Additionally, regardless of how you are working with Zeebe and Camunda 8, you can always find support through the community.

Next steps​

• Get familiar with technical concepts.

H Camunda представляет Open Source проект Zeebe для oркестрирования микросервисов инструментами BPMN в черновиках

Как и в оркестре, партитура имеет значение только для музыкантов и дирижёра. Для слушателей важно только само удовольствие от звучания.

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

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

В этом контексте немeцкий производитель open source BPM-фраймворка запустил новый проект для оркестровки распределенных микросервисов под названием Zeebe.

Благодаря Zeebe появилась возможность использования стандарта BPMN 2.0 (Business Process Model and Notation) для визуальной оркерстровки микросервисов.

При обращении к микросервисам Zeebe поддерживает паттерн «Retry on Failure», тем самым, в случае отказа, Service Task будет повторятся до его успешного завершения. При этом Zeebe пишет все события в Audit-Log. Zeebe был спроектирован как система под Big-Data и тем самым может легко оперировать растущим объёмом транзакций.

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

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

Zeebe использует client/server aрхитектуру. Oсновными компонентами является брокер и Zeebe-клиент. Более подробное описание можно прочитать в документации по фраймворку.

Насколько удачная идея применения стандартов BPMN для визуализации партитуры оркестровки микросервисов покажет время. На момент написания статьи проект Zeebe находится в статусе «Tech Preview» и выход версии для продакшина запланировн на начало 2018 года.

Обновления Camunda 8 глазами аналитика

Описываем основные отличия новой Camunda 8 от предыдущей версии на основе работ аналитика. Изменения в тасках, шлюзах и событиях.

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

Олег Саверкин
Аналитик IRLIX

Что такое Camunda: систематизируем сведения из интернета

Мой коллега Сергей, бекенд-разработчик, ёмко и в то же время достаточно точно определил основную суть и назначение этого инструмента:

«Совместное использование BPMN и Camunda приводит к наибольшей степени вовлеченности участников разработки в бизнес-процессы, к более детальному пониманию всех цепочек процессов, и в итоге — к получению командного компаса по лабиринтам процессов».

Camunda — тот самый Low-Code, который дает много готовых решений для автоматизации бизнес-процессов «из коробки». Не буду здесь подробно их расписывать: возможности платформы хорошо описаны на официальном сайте. Важно понимать, что Camunda — это BPMN и Java.

Если использование языка Java дает широкий простор для творчества разработчикам, то BPMN позволяет остальным членам команды лучше понимать друг друга. Почему? — Наличие диаграмм обеспечивают необходимую наглядность, что обеспечивает лучшее понимание логики бизнес-процессов.

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

Что нового и какие вопросы вызывает восьмая версия

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

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

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

Хорошая новость как раз в том, что в восьмой версии Camunda сократили число элементов, доступных для построения диаграмм.

Что же изменилось?

События (Эвенты)

Из новой версии исключили:

1. Стартовые события следующих типов:

• conditional start event;
• signal start event (от сигналов, к слову, вообще отказались).

2. Промежуточные события следующих типов:

• escalation intermediate throw event;
• conditional intermediate catch event;
• link intermediate catch event;
• link intermediate throw event;
• compensation intermediate throw event;
• signal intermediate catch event;
• signal intermediate throw event.

3. Завершающие события следующих типов:

• escalation end event;
• compensation end event;
• signal end event.

4. terminate end event — пожалуй, самая большая потеря, так как «terminate end event» — достаточно удобная штука. На мой взгляд :).

4. Boundary events следующих типов:

• escalation boundary event;
• conditional boundary event;
• compensation boundary event;
• signal boundary event;
• escalation boundary event (non-interrupting);
• conditional boundary event (non-interrupting);
• signal boundary event (non-interrupting).

А что осталось?

1. Помимо простых событий каждого вида по-прежнему доступны:

• message start event;
• timer start event;
• message intermediate catch event;
• message intermediate throw event;
• timer intermediate event;
• message end event;
• error end event.

2. А также следующий набор boundary events:

• message boundary event;
• timer boundary event;
• error boundary event;
• message boundary event (non-interrupting);
• timer boundary event (non-interrupting).

Шлюзы

Шлюзы следующих типов также не поддерживаются новой версией платформы:

• inclusive gateway;
• complex gateway.

• parallel gateway;
• event based gateway;
• exclusive gateway.

Таски

Набор доступных тасков не изменился. Изменения затронули внутреннюю структуру.

Одно из заметных преобразований — отсутствие блока «Implementation» среди атрибутов сервис-таска. Его заменили на «Task definition», который теперь не содержит предопределенных типов. К примеру, необходимости указывать «JavaClass» больше нет: не таск ссылается на «JavaClass», а сам код обращается к нужному таску. А для сервис-таска достаточно указать атрибут type и число попыток запуска в случае неудачи — атрибут retries (по умолчанию равен 3).

Такое решение по началу сбивает с толку, но по своей сути оно намного ближе к Low-Code по сравнению с тем, что было в предыдущей версии.

Коннекторы

Появились коннекторы, своего рода Low-Code интеграции, которые разделяют на:

1. Входящие — позволяют запустить какой-либо процесс извне (снаружи);
2. Исходящие — позволяют обращаться к сторонним системам.

Выделяют также коннекторы различных уровней — от подключения к брокеру сообщений, к примеру, Apache Kafka, до отправки e-mail и хранения файлов.

Готовый набор коннекторов содержит «Integration Framework», где вы можете найти подходящее решение для вашей задачи.

Modeler

«Cawemo» заменил облачный «Camunda Modeler», у которого также осталось десктопная версия.

В ней по-прежнему можно создавать и редактировать модели седьмой версии, но с переносом их в восьмую могут возникнуть сложности. Официальная документация содержит инструкцию — Migrating from Camunda Platform 7 — по миграции между версиями, но не всегда это возможно. К счастью, поддержка седьмой версии останется на ближайшие 5 лет.

Другие изменения

Да, этот материал преимущественно для аналитиков, но всё же полезно знать и о других важных изменениях. Коротко затронем основные.

Платформа в новой версии разворачивается отдельно. Встраивать движок в приложение через «Springboot» теперь нельзя. Бизнес-процесс и «Workers» разделены. «Workers» интегрируются через коннекторы.

В «Camunda Automate» вошли «Zeebe» (заменил «Engine»), «Tasklist» и «Operate», который заменил «Cockpit».

«Zeebe» теперь обеспечивает возможность одновременной обработки большего числа инстансов, поскольку обновленная версия платформы не содержит узкое место, которым являлась реляционная БД. Её функции выполняют «Zeebe broker» и «Zeebe gateway».

Gateway содержит информацию о «Workers» и знает, какие таски они могут выполнять. Таски привязываются к воркерам через тот самый атрибут type, о которым я упоминал выше. Это также обеспечивает переиспользование воркеров, достаточно указать нужное значение атрибута type. Broker выступает балансировщиком нагрузки и коммутирует инстансы и воркеры между собой. Атрибут retries при этом определяет число попыток вызова.

БД в «семёрке» представляла собой один кластер, «Zeebe» разворачивается в нескольких нодах. Все данные об инстансах хранятся в брокере, а исторические данные пишутся в «Elastic», куда обращаются «Tasklist» и «Operate». В «семёрке» они обращались в БД, что создавало дополнительную нагрузку.

Сам «Tasklist» не сильно изменился. Из интересного — в UI появилась возможность забирать данные прямо из «GraphQL».

«Operate» появился из-за перехода на «Zeebe» и необходимости взаимодействовать с «Elastic». Здесь также обновился интерфейс, который, по заверениям разработчиков, стал более удобным.

Как все это отражается на практике

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

Что происходит, когда бизнес-сторона «может в BPMN»

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

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

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

События и ссылки мы заменили сообщениями. Комплексные шлюзы — совокупным использованием параллельных и исключающих. В итоге совместными усилиями нам удалось достаточно быстро оптимизировать все процессы. Отсутствие части элементов нотации никак не помешало, напротив облегчило восприятие получившихся схем. В своей работы мы в основном полагались на официальную документацию — Overview Components | Camunda Platform 8 Docs.

Заключение

Новая версия Camunda, может и ограничивает «всю мощь» BPMN, но взамен предлагает не меньшее могущество. При этом новый «Modeler» становится ещё более приспособленным, гибким для работы бизнес-аналитика, дает ему всё меньше поводов заглядывать «под капот».

Может сложиться впечатление, что обновление — своего рода попытка вовсе исключить из процесса разработки продукта аналитика как единицу. Но наша деятельность не ограничивается только моделированием диаграмм :).

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

Вот таким стало мое знакомство с обновленной версией платформы Camunda. По мере накопления опыта и набора критической массы, я продолжу знакомить вас с тонкостями работы аналитика с этим инструментом, а пока — делитесь собственными результатами и задавайте вопросы в комментариях :).

Статьи / Подсказки по микросервисной автоматизации процессов

Возможно, ваша компания захочет перейти на архитектуру микросервисов и автоматизировать рабочие процессы (в этом посте блога я не вдаюсь в мотивацию, но вы, возможно, захотите прочитать о 5 Workflow Automation Use Cases You Might Not Have Considered или BizDevOps — the true value proposition of workflow engines). Это ставит вас в ряд со многими нашими клиентами. Как правило, у вас возникнут вопросы:

• Область применения и границы — какой рабочий процесс вы хотите автоматизировать и как он ложится на несколько микроуслуг, или разраниченный контекст в вашем ландшафте. Я ограничен объемом этого поста, поэтому я не затрону эту тему сегодня, но вы, возможно, захотите прочитать Avoiding the «BPM monolith» when using bounded contexts или Real-Life BPMN.
• Стек и инструменты — какой движок процессов я могу использовать?
• Архитектура — я запускаю движок процесса централизованно или децентрализованно?
• Управление — кто владельцы модели рабочего процесса и как ее развертывать?
• Операции — как мне сохранить контроль?

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

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

• Отслеживание или управление — хореография или оркестровка?
• 3 варианта коммуникации: Асинхронная коммуникация с использованием команд и событий, RPC-связь «точка-точка», распределение работы с помощью движка рабочего процесса
• Центральный или децентрализованный движок рабочего процесса
• Владение моделями рабочего процесса

Бизнес пример

Пример, который я использую в этой статье, представляет собой простое приложение для выполнения заказа, доступное в виде flowing-retail примера приложения с исходным кодом на GitHub. Самое интересное в программе flowing-retail то, что она реализует различные архитектурные альтернативы и предоставляет примеры на разных языках программирования. Все примеры используют движок рабочего процесса, будь то Camunda BPM или Zeebe. Но вы можете перенести полученные знания на другие инструменты — я просто знаю инструменты из своей собственной компании лучше всего, и у меня есть много примеров кода, которые легко доступны.

Предположим, вы хотите реализовать некоторые бизнес-возможности (например, выполнение заказа при нажатии кнопки тире на Amazon) с помощью разделенных сервисов:

Отслеживание или управление? Хореография или оркестровка?

Один из первых вопросов, как правило, касается оркестровки или хореографии, при этом последний чаще всего рассматривается как лучший вариант (на основе статьи «Microservices» Martin Fowler). Обычно это сочетается с Event-driven архитектурой.

В такой хореографической архитектуре вы излучаете так называемые доменные события, и каждый заинтересованный может действовать в соответствии с этими событиями. Это трансляция. Идея заключается в том, что вы можете просто добавлять новые микросервисы, которые прослушивают события, ничего больше не меняя. Рабочий процесс как таковой нигде не является явным, но развивается как цепочка событий, которые передаются по кругу. Опасность заключается в том, что вы теряете из виду более масштабный поток, в нашем примере выполнение заказа. Становится невероятно трудно понять поток, изменить его или также управлять им. И даже ответы на такие вопросы, как «Есть ли какие-либо заказы просрочены?» или «Есть ли что-нибудь застрял, что нуждается в вмешательстве?» является проблемой. Я обсуждаю это в своем докладе Complex event flows in distributed systems (записанные, например, в QCon в Нью-Йорке или DevConf в Кракове).

Отслеживание

Легким решением может быть, по крайней мере, отслеживание потока событий. В зависимости от конкретной технической архитектуры (см. ниже), вы, вероятно, можете просто добавить движок рабочего процесса, считывающий все события и проверяющий, могут ли они быть соотнесены с потоком отслеживания. Я обсуждал это в своем докладе Monitoring and Orchestration of Your Microservices Landscape with Kafka and Zeebe (запись с Kafka Summit в Сан-Франциско).

Путешествие к управлению

Это неинвазивно, так как вам не нужно ничего менять в своей архитектуре. Но это позволяет вам начать что-то делать, например в случае задержки заказа:

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

Смешивать хореографию и оркестровку

Хорошая архитектура обычно представляет собой смесь хореографии и оркестровки. Справедливости ради надо сказать, что нелегко уравновесить эти две силы, не имея определенного опыта. Но мы видели много доказательств того, что это правильный путь, поэтому определенно стоит инвестировать время. Иначе ваша хореография, которая на доске была изящным танцем независимых профессионалов, обычно заканчивается скорее беспорядочным слэмом:

В flowing-retail примере это также означает, что у вас должен быть отдельный микросервис для наиболее важной бизнес-возможности: заказа клиента!

Роль движка рабочего процесса — три архитектурных альтернативы

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

• Асинхронное взаимодействие по командам и событиям (обычно с использованием шины сообщений или событий)
• Связь по принципу «точка-точка» по запросу/ответу (часто REST)
• Распределение работы по движку рабочего процесса

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

Асинхронная связь по командам и событиям

Эта архитектура основана на центральной шине для асинхронной связи. К этой шине подключаются различные микросервисы. Логика оркестровки и соответствующие потоки оркестровки принадлежат микросервисам. Рабочие процессы могут посылать на шину новые команды («эй оплата, пожалуйста, найди деньги для меня») или ждут, пока произойдут события («кто бы ни заинтересовался, я получил оплату за O42»).

• Типичные инструменты: Kafka, RabbitMQ (AMQP), JMS.
• Что делает движок рабочего процесса: обработка тайм-аута, управление цепочками действий / потоком, поддержка паттернов интеграции предприятия с отслеживанием состояния, таких как агрегатор или повторный упорядочитель, обработка согласованности и компенсации, также известная как Saga pattern, как обсуждалось в моем выступлении «Lost in transaction» (записано, например, на JavaZone Oslo).
• Пример реализации: https://github.com/berndruecker/flowing-retail/tree/master/kafka/java
• За: Временная развязка микросервисов; Правильное применение событийно-ориентированной архитектуры может уменьшить взаимосвязь; многие сценарии сбоев (например, отсутствующие ответные сообщения) прозрачны для разработчика, поэтому он хорошенько продумывает эти ситуации.
• Против: Требуется шина сообщений или событий в качестве центрального компонента, с которым нелегко работать. Отсутствие операционных инструментов для этих компонентов приводит к тому, что усилия направляются в доморощенные «больницы сообщений». Большинство разработчиков не так хорошо знакомы с асинхронной связью.

Связь точка-точка по запросу / ответу

В этой архитектуре вы просто активно вызываете другие микросервисы, чаще всего синхронно, с блокировкой. Самый известный способ сделать это — REST. Конечные точки обычно извлекаются из реестра. Движок рабочего процесса может организовать вызовы REST, а также помочь с проблемами удаленной связи — тему, которую я подробно обсуждал в моей статье о трех проблемах интеграции микросервисов (также доступной в виде выступления, записанной, например, на QCon London).

• Типичные инструменты: REST, SOAP, gRPC; Также может быть реализовано с блокировкой обмена сообщениями с помощью: https://www.rabbitmq.com/tutorials/tutorial-six-java.html
• Что делает движок рабочего процесса: паттерны устойчивости (например, повторные попытки), обработка тайм-аута, управление цепочками действий / потоком, последовательность и обработка компенсаций, так называемый Saga pattern, обсуждалось в моем выступлении «Lost in transaction» (записан, например, в JavaZone Oslo).
• Пример реализации: https://github.com/berndruecker/flowing-retail/tree/master/rest
• За: Простота установки и понятно большинству разработчиков; доступен хороший инструмент.
• Против: Вызовы выглядят как локальные, поэтому разработчики часто забывают о сложности распределенных систем; требует применения паттернов устойчивости (например, Circuit Breaker).

Распределение работы по механизму рабочего процесса

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

• Типичные инструменты: External Tasks (Camunda BPM) или Workers (Zeebe).
• Что делает движок рабочего процесса: канал коммуникации, обработка тайм-аутов, управление цепочками действий / потоком, последовательность и обработка компенсаций, так называемый Saga pattern, о чем я говорил в «Lost in transaction» (записан, например, на JavaZone Oslo).
• Пример реализации: https://github.com/berndruecker/flowing-retail/tree/master/zeebe
• За: Простота установки; доступен хороший инструмент.
• Против: Движок рабочего процесса становится центральной частью архитектуры и должен работать надлежащим образом; связь между микросервисами только через рабочие процессы — или необходимо установить второй способ связи (например, REST или Messaging).

Мысли и рекомендации

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

Например, если у клиента нет опыта работы с Kafka или Messaging, будет очень сложно заложить это на ходу. Поэтому, возможно, им лучше использовать архитектуру на основе REST, особенно если, например, они глубоко погрузились в Spring Boot, что делает некоторые проблемы относительно легко решаемыми. Однако, если они стратегически хотят двигаться в сторону большей асинхронности, я лично поддерживаю это, но я все же хочу убедиться, что они действительно могут справиться с этим. Если заказчик уже принимает Domain-driven design (DDD) и события, или даже использует такие фреймворки, как Akka или Axon, то событийный подход, включающий в себя движок рабочего процесса, может быть лучшим вариантом.

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

Центральный или децентрализованный движок рабочего процесса

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

• Децентрализованные движки, то есть вы запускаете по одному движку на микросервис.
• Один центральнный движок, который обслуживает несколько микросервисов.
• Центральный движок, который используется как децентрализованный.

Хорошим предварительным чтением по этому поводу будет Architecture options to run a workflow engine.

Децентрализованные движки

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

• Пример реализации: https://github.com/berndruecker/flowing-retail/tree/master/kafka/java/order-camunda
• За: Автономия; изоляция.
• Против: Каждая команда должна использовать свой собственный движок (включая накат исправлений); никакого центрального мониторинга «из коробки» (пока).

Обычно в этой архитектуре больше всего обсуждается мониторинг: «Как мы можем следить за тем, что происходит»?

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

Централизованный мониторинг с децентрализованными движками

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

В нашем собственном стеке мы начинаем допускать определенные инструменты для сбора данных из децентрализованных движков, например, Camunda Optimize или Zeebe Operate.

• Пример реализации: Упрощенный пример содержится в https://github.com/berndruecker/flowing-retail/tree/master/kafka/java/monitor

Один центральный движок

Для упрощения операций можно также запустить центральный движок. Это удаленный ресурс, к которому микросервисы могут подключаться для развертывания и выполнения рабочих процессов. Технически это может быть через REST (Camunda BPM) или gRPC (Zeebe).

• Пример реализации: https://github.com/berndruecker/flowing-retail/tree/master/kafka/java/order-zeebe
• За: Простота эксплуатации; централизованный мониторинг доступен сразу после установки.
• Против: менее строгая изоляция между микросервисами с точки зрения данных времени выполнения, но также и с точки зрения версий продукта; центральный компонент более важен с точки зрения требований доступности.

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

Центральный движок, который используется как децентрализованный

Такой подход обычно нуждается в некотором объяснении. Что вы можете сделать в Camunda, так это запустить движок рабочего процесса в виде библиотеки (например, используя Spring Boot Starter) децентрализованным образом в различных микросервисах. Но затем вы подключаете все эти движки к центральной базе данных, где они встречаются. Это позволяет бесплатно осуществлять централизованный мониторинг.

• За: Централизованный мониторинг доступен прямо «из коробки».
• Против: меньшая изоляция между микросервисами с точки зрения данных времени выполнения, но также и с точки зрения версий продукта, но на самом деле это регулируется такими средствами, как Rolling Upgrade и Deployment Aware Process Engine.

Мысли и рекомендации

Я лично предпочитаю децентрализованный подход в целом. Он просто совпадает с сутью и ценностью микросервисов.

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

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

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

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

Право собственности на модели процессов

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

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

В примере flowing-retail есть две модели рабочего процесса:

• Выполнение заказа: Это относится к бизнес-возможностям выполнения заказов и имеет свое начало в микросервисе заказов.
• Платеж: принадлежит платежному микросервису.

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

«Процесс оркестровки»?

Меня часто спрашивают: Но где же «процесс оркестровки»? Это просто: в моем понимании микросервиса, нет такого понятия, как «процесс оркестровки».

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

Говоря «процесс оркестровки», некоторые люди имеют в виду логику области, которая включает только поток, поэтому соответствующий микросервис может не иметь другой логики (без собственных данных, без собственного программного кода,…). Это нормально, но это должен быть микросервис, поскольку даже эта логика требует четких обязанностей. И часто логика со временем все равно растет.

Резюме

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

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

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

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

Отслеживать или управлять — вы должны стремиться к сбалансированному сочетанию хореографии и оркестровки.