Искренняя благодарность Бернду Рюккеру (Bernd Rücker) за его отзывы в процессе написания этого поста.
Это часть 1 из 2.
Мы создаем Zeebe как движок для рабочих процессов нового поколения для таких новых сценариев, как оркестрация микросервисов — сценариев, которые могут требовать от движка обработки сотен тысяч (или миллионов) новых экземпляров рабочих процессов в секунду.
Для этого мы используем графический стандарт моделирования, который существует уже почти 15 лет: BPMN (Business Process Model and Notation).
Хотя BPMN — это проверенный временем стандарт ISO, возможно, многие из вас никогда не работали с ним или, возможно, даже не слышали о нем.
Или, что еще хуже, вы слышали о BPMN, но отвергли его как устаревшую технологию, которая актуальна только в мире монолитов или SOA.
В прошлом месяце мы наткнулись на эту цитату одного из комментаторов на Hacker News (которого мы обещаем, что он не является инкогнито-членом команды Zeebe):
"BPMN is the most underappreciated technology in our field IMO."
Мы не можем не согласиться, и в этом духе мы публикуем двухчастную серию блогов о BPMN и оркестрации микросервисов, а точнее, о том, почему BPMN — отличное решение для перспективных сценариев в мире рабочих процессов.
В этой части 1 мы:
Представим краткое введение в BPMN
Докажем, почему хорошо зарекомендовавший себя стандарт, который был успешным в прошлом, может быть успешным и в будущем
Рассмотрим общие паттерны оркестрации, поддерживаемые BPMN
Обсудим текущее состояние и планы на будущее для BPMN в Zeebe
В части 2 мы:
Углубимся в графические модели BPMN (и другие способы определения рабочих процессов)
Посмотрим на примеры, где использование графической модели вместо модели на основе кода значительно упрощает определение рабочих процессов
Краткое введение в BPMN
BPMN – это широко используемый стандарт моделирования для определения и исполнения бизнес-процессов. Впервые выпущенный в 2004 году (а современная спецификация BPMN 2.0 появилась в 2011 году – именно её использует Zeebe), BPMN стал стандартом ISO с 2013 года.
BPMN используется для определения графической модели и так называемой семантики исполнения. Другими словами, визуальная модель сохраняется в виде XML-файла, который можно напрямую выполнить на движке, поддерживающем персистентное состояние выполняемых экземпляров рабочих процессов.
Для примера: модель ниже представлена в этом XML.
Важно отметить, что BPMN не требует генерации кода и преобразований! XML-файл сам по себе является исходным кодом. BPMN описывает только поток выполнения – для всех остальных аспектов вашего решения можно использовать обычный код.
Это ключевой момент для оркестрации микросервисов, где внешние воркеры выполняют задачи в вашем рабочем процессе. В сочетании с правильным движком BPMN упрощает соотнесение задач в рабочем процессе с микросервисами таким образом, чтобы не нарушать принципы слабой связанности и независимости сервисов.
Расширяя приведённый выше пример процесса обработки заказа, мы можем создать три отдельных микросервиса для обработки платежей, управления запасами и доставки. Движок рабочего процесса отвечает за отправку работы в нужный сервис в нужный момент процесса.
Наконец, о зрелости BPMN. BPMN является популярным и хорошо зарекомендовавшим себя стандартом, доказавшим свою ценность во многих проектах по автоматизации рабочих процессов в компаниях любого размера.
По этой причине на рынке уже имеется множество специалистов с опытом работы с BPMN, а также обучающие материалы и книги, которые позволяют новичкам легко освоить этот стандарт.
Но сможет ли BPMN поддержать новую архитектуру?
Давайте на минуту перейдём к метафорам.
Хотя история появления автомобиля вызывает споры, многие считают, что Карл Бенц построил первую машину и проехал на ней по Мангейму (Германия) в 1886 году. За последние 130 лет возможности автомобилей, а именно их «двигателей», значительно эволюционировали.
Однако «поток» (flow) остался практически неизменным. Дорожная инфраструктура, знаки и правила, которые помогают нам безопасно добираться из точки А в точку Б, следуют тем же шаблонам, что были внедрены много десятилетий назад. Возможно, это изменится (например, Hyperloop, дроны), но суть в том, что определённый «шаблон потока» способен поддерживать значительные изменения в «двигателе».
Поэтому, оценивая такой устоявшийся стандарт, как BPMN, важно различать «требования к потоку» и «требования к движку».
BPMN выделил ряд паттернов потоков, которые являются вневременными. Выполнение серии действий последовательно или параллельно применяется как к традиционным задачам BPMN (например, управлению человеческими задачами), так и к вызову serverless-функций в AWS. Ожидание поступления подписанных бумажных документов по своей структуре аналогично корреляции нескольких сообщений в архитектуре потоковой обработки событий.
Что действительно меняется — это пропускная способность (количество экземпляров процессов), а также производительность и масштабируемость. Эти проблемы решаются за счёт нового движка, выполняющего тот же язык потоков. Именно этот подход реализован в Zeebe, который может обрабатывать миллионы новых экземпляров рабочих процессов в секунду.
Альтернативный путь — создать новый движок и одновременно изобрести новый язык потоков. Но разрабатывая собственный язык, вы неизбежно потратите время на решение проблем, которые уже были решены в BPMN. При этом ваши решения могут оказаться менее эффективными и более сложными для понимания всех заинтересованных сторон.
Мы подробнее разберём этот вопрос во второй части серии, где сравним реальный сложный бизнес-процесс, смоделированный в BPMN и Amazon States Language.
А пока давайте рассмотрим примеры распространённых шаблонов бизнес- процессов, чтобы показать, почему мы уверены, что BPMN — это лучший язык потоков для оркестрации микросервисов и других современных сценариев автоматизации.
Определение шаблонов оркестрации в BPMN
Мы не будем предоставлять полный учебник по BPMN в этом посте. Наша цель — познакомить вас с некоторыми основными строительными блоками и показать несколько примеров их применения.
Это не должно останавливать вас от более глубокого изучения BPMN, если вам интересно. Учебник по BPMN от Camunda, который мы упоминали ранее, — хорошее место для начала, как и наш справочник по BPMN.
Вы также можете попробовать наш графический инструмент моделирования, адаптированный для Zeebe, а во второй части серии мы подробно поговорим о графических моделях.
Перейдём к паттернам.
Последовательные потоки, условия и параллельная обработка
В основе BPMN лежит последовательный поток, который определяет порядок выполнения шагов в рабочем процессе.
Как можно представить, ограничение рабочего процесса простой последовательной последовательностью задач оставляет без внимания множество аспектов реальной бизнес-логики. Помимо задач (единиц работы), BPMN-процессы включают шлюзы (которые направляют поток) и события (которые представляют собой происходящие события, на которые процесс может реагировать или уведомлять о них другие системы).
BPMN предоставляет конструкции для маршрутизации экземпляра рабочего процесса по единственному потоку на основе связанных данных (исключающий шлюз) и для одного или нескольких потоков, которые должны выполняться параллельно (параллельный шлюз).
Корреляция сообщений с тайм-аутом
Задача получения сообщения (receive task) в BPMN — один из способов, с помощью которого стандарт поддерживает корреляцию сообщений, очень мощную функцию, которая позволяет продвигать ожидающий экземпляр рабочего процесса вперёд или выполнять другое действие только тогда, когда сообщение может быть правильно сопоставлено («сокоррелировано») с конкретным экземпляром процесса, который его ожидает, используя общий идентификатор.
Эта функция особенно сложна для самостоятельной реализации и последующего масштабирования, но с BPMN в сочетании с подходящим движком она доступна из коробки.
Поддержка BPMN как отправки, так и получения сообщений означает, что модели могут беспрепятственно интегрироваться с архитектурой, управляемой сообщениями, которая особенно распространена в мире микросервисов.
Рабочие процессы могут запускаться определёнными типами сообщений, а также отправлять сообщения для использования в последующих системах. Кроме того, экземпляр рабочего процесса может завершаться на основе полученного сообщения.
Например, выполняющийся экземпляр процесса — такой как процесс выполнения заказа в компании электронной коммерции — может быть прекращён в ответ на входящее сообщение об отмене заказа, связанное с конкретным заказом.
Как вы увидите (и мы будем часто повторять), гибкость комбинации различных элементов делает BPMN столь мощным инструментом.
Например, задачу получения сообщения можно объединить с событийным таймером так, что если нужное сообщение не поступит в течение 4 часов, задача «истечёт по тайм-ауту», и экземпляр рабочего процесса последует по другому пути.
Корреляция нескольких сообщений
Сопоставление одного сообщения с экземпляром рабочего процесса полезно, но что, если нужно сопоставить два, три или даже десять?
BPMN поддерживает и этот шаблон. Вы можете ожидать два или более сообщений, синхронизировать их и объединять их данные, прежде чем продвигать экземпляр рабочего процесса вперёд, комбинируя задачу получения сообщения (receive task) с параллельным шлюзом (parallel gateway).
Давайте сделаем ещё один шаг вперёд и объединим этот шаблон с тайм-аутом.
Опять же, добавление таймера и подпроцесса в приведённой ниже диаграмме — это всего лишь один из примеров того, как различные элементы BPMN можно комбинировать для моделирования сложного потока.
Хотя, конечно, существуют сочетания, которые не будут логичны, по сути, нет ограничений на то, как можно соединять символы BPMN для определения рабочих процессов.
Ожидание произвольного количества сообщений
В некоторых случаях мы не можем точно знать, сколько сообщений нам нужно будет ожидать, связанных с данным экземпляром рабочего процесса.
Рассмотрим пример, когда нам необходимо получить сообщение itemAvailable для каждого товара в заказе, прежде чем продолжить выполнение рабочего процесса. Количество товаров в каждом заказе может значительно варьироваться, и мы можем учесть это в нашей модели с помощью многоэкземплярной активности BPMN.
Обработка ошибок
Могут быть определенные "ошибки бизнес-логики", которые необходимо учитывать при проектировании рабочих процессов. Здесь речь идет не о случаях, когда сервис не работает по техническим причинам, а о случаях, когда рабочий процесс не может продолжиться из-за бизнес-проблемы, которую можно предсказать заранее. Для такого случая была в BPMN разработан элемент "прикрепленное событие ошибки".
В этом примере мы пытаемся списать деньги с кредитной карты клиента. Если списание отклонено из-за недостаточности средств на счету клиента, мы уведомим клиента о возникшей проблеме.
Мы могли бы продолжать...
Когда речь идет о паттернах, поддерживаемых BPMN, мы лишь слегка коснулись поверхности. Мы надеемся, что теперь у вас есть представление о том, сколько различных вариантов использования можно выразить только с помощью этих символов BPMN.
То, что мы показываем в этих примерах, не предназначено для того, чтобы навязать вам конкретный способ использования BPMN. Скорее, наша цель — вдохновить вас на создание различных моделей, которые вы можете построить.
Состояние BPMN в Zeebe
Надеемся, что к этому моменту вы уже понимаете возможности BPMN для определения и выполнения сложных рабочих процессов.
Но настоящий вопрос заключается в следующем: сколько символов BPMN мы поддерживаем в Zeebe?
В долгосрочной перспективе Zeebe будет поддерживать все символы, которые имеют смысл для автоматизации рабочих процессов, как это было сделано в движке рабочих процессов Camunda BPMN.
Что касается текущего момента, то версия Zeebe 0.11 (последний релиз) поддерживает:
Конечно, это ограниченный объем, и до этого момента мы в первую очередь фокусировались на движке Zeebe, то есть на обеспечении масштабируемости и производительности для обработки высоконагруженных сценариев.
Однако в этом квартале мы активно инвестируем в поддержку BPMN для Zeebe, и в ближайшем будущем будем готовы поддерживать корреляцию сообщений:
Когда мы подготовим Zeebe к выходу в продакшн в 2018 году, мы планируем добавить поддержку большего числа символов, таких как:
• Таймеры,
• Области (подпроцессы), и
• Параллельное выполнение.
В 2019 году мы расширим поддержку символов, опираясь на отзывы пользователей и на то, что мы знаем о сценариях, которые Zeebe будет обрабатывать.
Мы подошли к концу первой части нашей серии о BPMN. Есть один очень важный аспект BPMN, который мы упомянули лишь вскользь в этом посте: факт того, что модели могут быть определены графически, а затем напрямую выполняться движком.
Мы вернемся с частью 2, где подробно расскажем о множестве преимуществ графических моделей в BPMN, особенно по сравнению с другими языками потоков, предназначенными для сценариев оркестрации. Мы также рассмотрим вопросы разработчиков, которые имели негативный опыт с графическими моделями.
Подписывайтесь на Telegram канал BPM Developers.
Рассказываем про бизнес процессы: новости, гайды, полезная информация и юмор.
