что такое оркестрация в ит
От микросервисного монолита к оркестратору бизнес-сервисов
Когда компании решают разделить монолит на микросервисы, в большинстве случаев они последовательно проходят четыре этапа: монолит, микросервисный монолит, микросервисы, оркестратор бизнес-сервисов.
Если вы определите, на каком из этапов находитесь сейчас, это поможет вам понять плюсы и минусы текущего этапа, оценить стоит ли идти на следующий этап и, если стоит, увидеть шаги необходимые для перехода.
В каждом разделе вы найдете ссылки для более глубокого погружения в нюансы конкретного перехода.
Этап №1. Монолит
1.1 Характеристики
Обычно монолитную архитектуру можно описать так:
1.2 Проблемы
1.3 Как перейти на следующий этап
В основе процесса выделения микросервисов лежит вынесение бизнес-задач из монолита в отдельные сервисы. При этом нужно руководствоваться принципом единственности ответственности, который перефразируется так: у микросервиса должна быть только одна причина для изменения. Этой причиной является изменение бизнес-логики той единственной задачи, за которую он отвечает.
Постепенно у вас образуется набор из микросервисов, где каждый отвечает лишь за свою бизнес-задачу:
При создании микросервисной архитектуры полезно периодически проверять себя по чеклисту The Microservice Architecture Assessment, чтобы не упустить какую-то важную деталь.
Этап №2. Микросервисный монолит
2.1 Характеристики
Все части монолита стали независимыми микросервисами и эти микросервисы должны общаться между собой. Если раньше, находясь внутри одного процесса, сервисы вызывали методы друг друга напрямую, то теперь нужно интегироваться.
Из четырех способов интеграции в микросервисной архитектуре обычно не используют обмен файлами и стараются не использовать shared database, зато активно работают с RPC и очередью сообщений.
Получается, что все части монолита распались на микросервисы, а их обратно соединили паутиной синхронных и асинхронных интеграций:
По факту, получился тот же монолит, но с большим количеством новых проблем.
2.2 Проблемы
Если на пути рефакторинга монолита вы остановитесь на этом этапе, то, вполне резонно, сделаете вывод, что с монолитом было лучше и дешевле.
2.3 Как перейти на следующий этап
Основные идеи: локализовать точки интеграции и контролировать все потоки данных. Чтобы этого добиться, надо использовать:
Чтобы избежать типовых проблем и упростить разработку, рекомендую взять на вооружение подходы по повышению отказоустойчивости:
Этап №3. Микросервисы
3.1 Характеристики
Микросервисы ничего не знают о существовании друг друга: работают со своей базой данных, API и сообщениями в очереди. Каждый микросервис решает только одну бизнес-задачу и старается делать это максимально эффективно, за счет выбора технологий, стратегии масштабирования.
Становится заметна главная черта хорошей архитектуры: сложность системы растет линейно с увеличением количества микросервисов.
3.2 Проблемы
На этом этапе сложные технические задачи решены, поэтому начинаются проблемы на уровне бизнес-задач:
3.3 Как перейти на следующий этап
Многие компании не идут дальше, потому что на текущем этапе бизнес-задачи могут решаться уже достаточно быстро и эффективно. Тем, кто решают двигаться дальше:
Этап №4. Оркестратор бизнес-сервисов
4.1 Характеристики
Оркестратор бизнес-сервисов обычно является визуальной платформой, где соединяются сервисы, выставляются триггеры и условия ветвления, контролируются все потоки данных: реализована трассировка запросов, логирование событий, автомасштабирование по условиям. Сам оркестратор ничего не знает о специфике бизнес-процессов, которые на нем крутятся.
На этом этапе можете решить задачу создания продукта в визуальном редакторе. Если нужных «квадратиков» не хватает, то программисты создают микросервис, учитывая правила описания сервиса для оркестратора, публикуют API и «кубик» появляется в визуальном редакторе, готовый соединяться с другими участниками бизнес-задачи.
4.2 Проблемы
4.3 Как перейти на следующий этап
На данный момент я не вижу сформировавшегося пятого этапа. Если вы видели жизнь после оркестратора бизнес-сервисов, буду рад увидеть описание вашего опыта в комментариях.
Заключение
Эти четыре этапа показывают, как мне кажется, естественный ход вещей:
☸️ Первое знакомство с Kubernetes: что под капотом у системы оркестрации?
Что под капотом у оркестратора?
Любой ИТ-дирижер позволяет развертывать приложения, управлять ими и реагировать в реальном времени на происходящие в них изменения. Типичные, задачи которые стоят перед оркестратором:
Примеры оркестраторов
Apache Mesos
Apache Mesos – централизованная система управления кластером. Она объединяет в группы отдельные узлы согласно требованиям, а также обеспечивает их изоляцию от остальных IT-ресурсов. Разработанный в университете Беркли продукт вышел в 2009 г. и имеет нестандартный подход к архитектуре. Apache Mesos отлично подходит для создания очень больших систем и реализации масштабных проектов.
Kubernetes
Самый модный оркестратор основан на разработках Google. В 2014 г. корпорация открыла код Kubernetes и стала распространять систему под лицензией Apache 2.0. В результате началось быстрое развитие продукта сообществом, и на данный момент он используется как в небольших проектах, так и в сегменте Enterprise.
Docker Swarm
Компания Docker (в девичестве dotCloud) одной из первых предложила реализацию контейнеров и систему управления ими. Kubernetes внутри себя обычно использует Docker как среду исполнения контейнеров (Container runtimes). Docker swarm позволяет объединять хосты Docker в общий виртуальный хост. Обычно это решение используют в относительно небольших проектах.
Что под капотом у Kubernetes?
Любой оркестратор позволяет развертывать и масштабировать приложения, а также реагировать на изменения в них. Все эти функции реализуются в Kubernetes слоем Control plane. В предыдущей статье мы рассмотрели простой способ развертывания кластера, а сейчас разберем его компоненты более подробно.
На схеме видно, что внутри кластера есть некоторое количество нод (от англ. node – узел), на которых запущена среда исполнения контейнеров (Container runtimes). В Conteiner runtime живет контейнер, а в нем – наше приложение. Вот такая матрешка получается. Kubernetes управляет этими матрешками, отслеживает их состояние, планирует ресурсы (CPU, RAM, HDD) и осуществляет при необходимости масштабирование.
Control Plane
Мозгом Kubernetes кластера является набор компонентов, которые обычно устанавливаются на Master node (мастер-узел). В разных конфигурациях k8s мастеров может быть несколько – это необходимо, если требуется высокая доступность кластера. На схеме показан набор компонентов мастер-ноды.
Познакомимся поближе с каждым из них.
API server
Этот компонент является endpoint, т.е. точкой контакта, на которую приходят запросы на создание объектов Kubernetes. API Server – единственный компонент, который общается с Сluster store напрямую.
Scheduler
Компонент, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать с учетом запрошенных ресурсов и фактических ресурсов ноды.
Cluster store (etcd)
Этот компонент реализует распределенное и высоконадежное хранилище данных в формате key-value, которое используется как основное для данных кластера Kubernetes. Рекомендуется делать его резервные копии, поскольку если Cluster store разрушится, под угрозой весь кластер k8s.
Controllers
Компонент, осуществляющий контроль на всех уровнях кластера Kubernetes.
Мы разобрали на верхнем уровне, что из себя представляет Control plane. Это своего рода серверная часть, обслуживающая очередь клиентов. Клиентами являются Worker node (рабочие ноды), на которых мы и развертываем наши приложения.
На каждой Worker node есть определенный набор компонентов, представленный на схеме.
Познакомимся с ними.
Kubelet
Самый главный компонент Worker node. Через него происходит обмен данными с API-сервером. Основная функция – слушать сервер на предмет появления новых заданий и выполнять их при необходимости. Также Kubelet отчитывается серверу о проделанной работе.
Container runtime
Для выполнения задач на ноде необходима некая среда исполнения, внутри которой запускаются контейнеры с приложениями: обычно это Docker, но Kubernetes поддерживает и другие варианты. Например containerd, реализующий модель Container Runtime Interface (CRI). Выбор среды исполнения остается за вами.
Kube proxy
Последний компонент Worker node отвечает за локальную сеть. Он гарантирует, что каждый узел получит свой уникальный IP, реализует правила IPTABLES или IPVS для управления маршрутизацией и балансировкой нагрузки трафика во внутренней сети k8s.
Подведем итог. Если соединить компоненты Control Plan и компоненты Worker nodes, получится следующая схема.
Надеюсь, пазл сложился. В третьей публикации цикла мы начнем углубляться в практическую часть и изучим базовые конструкции кластера, а в четвертой перейдем к развертыванию приложений.
Обзор фреймворков для оркестрации микросервисов: Conductor, Zeebe, Temporal
Оркестрация микросервисов помогает выстраивать сложные процессы в продуктах. Чтобы не приходилось прописывать эту механику руками, разработчики могут воспользоваться готовыми фреймворками, которые включают в себя средства управления микросервисами. Мы в True Engineering изучили эту тему и рассказываем про три таких фреймворка.
При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.
Оркестратор микросервисов контролирует выполнение процессов. В результате данные не теряются, поддержке становится проще устранять проблемы, а разработчикам – управлять развитием всей системы.
Можно написать такой модуль с нуля, а можно использовать готовый фреймворк. Если в компании есть несколько команд разработчиков, без таких фреймворков не обойтись. Во-первых, программистам не придётся раз за разом выполнять одну и ту же работу. Во-вторых, когда все используют общие инструменты, у команд появляются единые стандарты работы, и это сразу сказывается на качестве продуктов. Вместо того, чтобы изобретать велосипед, все концентрируются на развитии общего инструмента.
Архитектура фреймворка для оркестрации
Фреймворк включает в себя готовые к работе компоненты оркестрации. Это сам оркестратор, который принимает таски и передаёт их рабочим микросервисам на исполнение.
Когда продукт запускает процесс (например, организация путешествия на сайте), оркестратор формирует очередь задач, которые предстоит выполнить микросервисам. В нашем примере это может быть «Покупка авиабилета», «Бронирование гостиницы», «Аренда автомобиля». Микросервисы подхватывают эти задачи и отчитываются о выполнении. Данные сохраняются в собственном хранилище оркестратора, так что если оркестратор вдруг упадёт и процесс прервётся, его можно будет возобновить с того же места.
Теперь о том, как мы подбирали и сравнивали между собой разные фреймворки.
Какие у нас были требования к оркестратору
Простота процессов. Нам нужна удобная среда, в которой будет наглядно показано взаимодействие микросервисов. Дополнительным преимуществом будет автоматическое создание документации, когда описание оркестрации становится описанием всей системы.
Обработка ошибок. На случай сбоя должна быть возможность настроить количество повторных попыток и таймаутов. Кроме того, настройка бизнес-логики и механики самих микросервисов должна идти независимо, чтобы ими можно было управлять отдельно и не захламлять тем самым описанную оркестрацию, не уменьшать ее наглядность. Плюс, поддержка шаблона проектирования Saga – необходимо предусмотреть откатные действия, когда процесс останавливается на каком-то шаге.
Поддержка асинхронных активностей и воркфлоу. Необходимо для более гибкой настройки оркестрируемых процессов. Таким образом отдельные составные части бизнес-процессов могут выполняться асинхронно, чтобы ни пользователь, ни другие активности не ждали их окончания.
Сравнение фреймворков
Мы изучили существующие инструменты и подобрали три кандидата, которые соответствуют нашим критериям. Набор возможностей у них схожий, а в реализации есть некоторые отличия.
Conductor от Netflix. Параметры бизнес-процессов и активности описываются в JSON-файлах. В коде микросервисов нужно прописать уникальные строки, по которым оркестратор будет их вызывать.
Zeebe от Camunda. Camunda – это BPMN-движок, который мы давно используем в своей практике (например, для синхронизации своего трекера с трекером заказчика или автоматизации бизнес-процессов). Если знаете Camunda, то интерфейс Zeebe будет вам хорошо знаком. Главное преимущество – выделенный графический редактор, с которым будет просто разобраться не-разработчикам. Данные хранятся в XML-файлах.
Temporal. Использует для оркестрации чистый код. Нет идентификаторов – микросервисы вызываются через код или собственный интерфейс, который надо дополнительно прописывать. Для многих разработчиков это будет проще и привычнее всего.
Результаты сравнения по нашим критериям:
Простота процессов. Zeebe оказался самым наглядным благодаря графическому компоненту. А Temporal – самый привычный для разработчиков за счёт оркестрации через код.
Обработка ошибок. Возможности у всех фреймворков примерно равны, y Zeebe чуть слабее. Из критических параметров он позволяет настраивать только количество ретраев и не поддерживает Saga. Её можно рисовать с помощью диаграмм, но делать это приходится руками каждый раз в каждом процессе.
Поддержка асинхронных активностей. Здесь все одинаково хороши.
Вывод
Сравнение показывает, что серебряной пули не существует – каждый фреймворк по-своему хорош. Инструмент нужно выбирать в диалоге с командами – кому-то может быть удобнее работать с JSON, другой оценит визуализацию, а третий захочет использовать чистый код.
Но любой фреймворк, с которым работают все команды, лучше, чем встраивать оркестрацию в код каждого продукта отдельно. Так разработчикам приходится каждый раз заново вникать в логику продукта и перегружать код. А в масштабах всей компании вы получите единые стандарты, которые помогут привести все ваши команды к общей платформе разработки.
Что такое системы оркестрации контейнеров
Для того чтобы быть конкурентоспособными на рынке разработки приложений, IT-компании применяют разные современные методы и инструменты в организации процессов.
Например, чтобы быстрее и дешевле релизить приложения и выкатывать обновления к ним, среди прочего применяют DevOps-подход, микросервисы, контейнеризацию. И системы, чтобы всем этим дирижировать, — о них и расскажем.
Системы оркестрации контейнеров: что это и кому подходит
Мы не зря упомянули термин из музыкальной среды: такие системы, словно дирижеры оркестра, организуют расположение и координируют взаимосвязь инструментов в одном проекте, распределяют задачи между ними и контролируют их выполнение. Поэтому и называются они системами оркестрации или оркестраторами контейнеров. Оркестраторы удобны для управления микросервисными приложениями, поскольку каждый микросервис в кластере имеет свои данные и свою модель, он автономен с позиции разработки и развертывания и поэтому чаще всего помещается в отдельный контейнер. При большом числе сервисов увеличивается и число контейнеров, и этим всем нужно управлять.
То есть программы-оркестраторы управляют жизненными циклами контейнеров микросервисных приложений. Но не только. Так как в разработке приложений все взаимосвязано, то системы оркестрации помогают еще автоматизировать различные производственные процессы, поэтому команды DevOps интегрируют их в CI/CD. Посмотрим, какие задачи берут на себя оркестраторы.
Задачи оркестраторов контейнеров
Это установка приложения и его зависимостей на сервер, включая подготовку этого сервера — установку библиотек, служб и так далее.
Это часть подготовки сервера, а именно его настройка с помощью специальных программ-планировщиков. Их применяют не только для микросервисных приложений, но и для монолитных. Инструменты управления конфигурацией обычно используют «факты», чтобы убедиться в достоверности данных о сервере: например, «убедитесь, что /etc/my.cnf содержит то-то…» или «NGinX должен работать со следующими файлами конфигурации». Оркестраторы содержат в себе такие планировщики, их не надо ставить отдельно.
Для развертывания приложения в продакшен-кластере требуется выделить вычислительные ресурсы сервера для различных процессов: это объемы памяти (RAM) и центрального процессора (CPU). Устанавливаются запрашиваемые и предельные параметры, правила при достижении контейнерами ресурсных лимитов, различные ограничения. Это важно для поддержания приложения в рабочем состоянии и сведения затрат к минимуму.
Простой излишних ресурсов приводит к издержкам, а недостаток — к нестабильной работе приложения. Регулировать объемы используемых ресурсов позволяет масштабирование, основанное на анализе нагрузок, которое может быть ручным или автоматизированным.
Автоматический анализ и распределение рабочих нагрузок на сервер целиком и контейнеры в частности. Балансировка оптимизирует использование ресурсов, увеличивает пропускную способность каналов связи, минимизирует время отклика и помогает избежать перегрузки отдельных ресурсов.
Чтобы приложение было доступно из интернета, нужно настроить правильное распределение трафика из внешней сети по контейнерам и нужным сервисам.
Эта функция позволяет видеть, какие контейнеры и их образы запущены и где, какие команды используются в контейнерах, какие контейнеры потребляют слишком много ресурсов и почему. Автоматический аудит журнала ошибок позволяет вовремя устранять неполадки.
На основе непрерывной оценки кластеров, узлов и реестра контейнеров предоставляются данные о неверных конфигурациях и других уязвимостях, которые могут представлять угрозу, а также рекомендации по устранению выявленных угроз.
Несколько примеров систем оркестрации контейнеров
Оркестраторы контейнеров бывают разные. Одни довольно просты в управлении, но имеют ограниченный набор функций. Другие сложнее и требуют профессиональных навыков, но для них можно, например, использовать Managed-решение от облачного провайдера. Перечислим основные оркестраторы контейнеров с кратким описанием.
Kubernetes
Эта портативная платформа с открытым исходным кодом считается отраслевым стандартом. Поддерживает и декларативную конфигурацию объектов, и автоматизацию. Можно автоматизировать масштабирование, развертывание с помощью шаблонов и управление рабочей нагрузкой и сервисами контейнеров. Поддерживает ОС: Windows, macOS, Linux.
OpenShift Container Platform
Платформа корпоративного уровня в формате PaaS для разработки, развертывания и управления не только контейнерными, но и классическими приложениями и их компонентами в режиме самообслуживания. Позволяет автоматизировать их в физических, виртуальных и общедоступных, частных и гибридных облачных средах. Поддержка ОС: Linux.
Docker Swarm
Это «родная», базовая система кластеризации и оркестровки контейнеров Docker. Использует декларативную модель. Взаимодействие с кластером происходит через команды Docker, а управление действиями — через менеджер Swarm. Поддержка ОС: Windows, macOS, Linux.
Nomad
Легкий в поддержке, гибкий, расширяемый оркестратор для развертывания и управления контейнерными и классическими приложениями в физической или облачной среде. Поддерживает ОС: Linux, Windows, macOS, а также Docker, Java, виртуальные машины. В основном Nomad управляет деплоями и перезапускает контейнеры при обнаружении ошибок. Этого часто оказывается достаточно для небольших независимых проектов.
Rancher
Платформа для управления контейнерами в облачной или физической производственной среде с открытым исходным кодом. Включает в себя использование всех популярных на сегодняшний день фреймворков оркестровки и планирования контейнеров, в том числе Swarm, Kubernetes, Mesos. Помимо них поддерживает и собственную платформу оркестровки и планирования контейнеров — Cattle. Поддерживает ОС: Linux.
Кому пригодятся оркестраторы, а кому нет
В крупных компаниях могут одновременно разрабатываться и поддерживаться несколько масштабных приложений, каждое из которых может состоять из множества контейнеров. Им не обойтись без оркестраторов. Но есть проекты, где контейнеров мало и ими можно управлять вручную либо вообще не используются микросервисы. Таким проектам оркестраторы не нужны. Ведь системы оркестрации контейнеров нужно уметь устанавливать, настраивать и поддерживать, а значит, надо искать знающих и дорогих специалистов. Также нужно покупать и содержать резерв «железа» на случай, если нагрузка будет расти — а это весьма вероятно. Однако можно арендовать систему оркестрации как услугу в облаке с профессиональным обслуживанием кластера от провайдера.
Camunda: автоматизация бизнес-процессов и оркестрация микросервисов
Три года назад Леруа Мерлен начала масштабную программу ИТ-трансформации с использованием таких прогрессивных течений, как микросервисная архитектура, предметно-ориентированное проектирование (оно же DDD) и формирование собственных in-house-команд разработки. Пилотным проектом этой программы стало построение омниканальной платформы продаж, то есть возможность для клиента сделать взаимодействие с компанией удобным и доступным через любой существующий канал продаж, будь то сайт, магазин, колл-центр и т. д., в том числе наша платформа дает возможность взаимодействовать с различными партнерами для получения бизнес-синергии. Этой статьей мы начинаем рассказ об опыте использования open-source-платформы Camunda в Леруа Мерлен.
При построении правильной архитектуры этого решения было важно рассмотреть самый сложный кейс: клиент решил сделать ремонт в своей ванной комнате, он создает проект вместе с сотрудником Леруа Мерлен, далее они планируют основные вехи реализации проекта: доставка товаров для ремонта с разных складов, работа мастера по ремонту и установке сантехники.
Платформа Леруа Мерлен
Когда мы сделали это упражнение, нам стало понятно, что одним из центральных бизнес-объектов должен стать клиентский заказ, который умеет координировать с объектами других доменов: фулфилмент заказа, доставка, оплата, исполнение услуг мастера, коммуникации и т. д. Другими словами, выбранный бизнес-сценарий заказа отправляет команды другим системам (исполнителям), которые, в свою очередь, занимаются своими профильными задачами и отчитываются координатору по ходу исполнения. Пример такого BPMN-процесса может выглядеть так:
Причем дочерние домены-исполнители могут под капотом также иметь свою внутреннюю координацию внутренних партнеров, оставаясь при этом автономными и несвязанными.
Как создать единую точку оркестрации для множества микросервисов в многослойной архитектуре?
В процессе построения микросервисной архитектуры мы пришли к трехуровневой модели данных. Слой микросервисов функционировал поверх этих данных. Нужен был оркестратор для трехслойной модели экспозиции API и типов микросервисов.
Слой объектных интерфейсов (Object API) — набор небольших, линейно независимых функций доступа к данным. На этом слое находятся репозитории CRUD (create, read, update, delete) мастер-данных, унаследованные приложения, лицензионное коммерческое коробочное ПО и части глобальных ИТ-продуктов группы ADEO.
Слой бизнес-процессов и оркестрации (Process API) — функционал единых бизнес-правил компании.
Слой адаптации (Experience API) — средства адаптации к конкретным прикладным задачам: сервисы класса Back-End-for-Front-End; ПО для мобильных и десктоп-приложений; функционал композитных сервисов (mash-up); средства интеграции с партнерами, клиентами и окружающей компанию экосистемой; бизнес-логика приложений, специфичных для конкретных видов бизнеса.
Мы проанализировали квадрант Гартнера, посоветовались с коллегами и выяснили, что рынок таких решений сильно растет, есть и мастодонты типа Pega или IBM. Но все они проприетарные. Для нас же главным критерием выбора был открытый код, возможность самостоятельно его дорабатывать. Соответственно, проприетарные движки отпали автоматически.
Еще было важно, чтобы решение соответствовало нашим требованиям к микросервисной архитектуре — независимый деплой с возможностью работы в cloud-native-режиме. Это значит, что движок может раскатываться в контейнеры в любом baas-решении, которое мы выбираем.
Круг сузился до тех решений, которые поддерживают контейнерную сборку и остаются все еще в тренде с точки зрения квадранта, то есть имеют сильное open-source-комьюнити. В итоге наш выбор остановился на open-source-решении Camunda.
Мы сразу же оценили ряд важных преимуществ.
Open source: платформа активно развивается, все больше и больше компаний начинают использовать этот движок, в интернете можно найти много статей и подробной документации, в том числе блог и книгу Бернда Рюкера — отца-основателя решения. В Москве регулярно проводят митапы, где докладчики рассказывают успешные кейсы применения Camunda на своих проектах.
BPMN, DMN (low-code): разработка процессов автоматизации и оркестрации осуществляется в нотации BPMN, что делает флоу исполнения понятным и прозрачным для всех участников команды. Обычно процессы проектируют системные аналитики.
Java, External tasks: существует два основных паттерна реализации логики для задач BPMN-процесса. Первый способ — это написание java-делегатов внутри движка для каждой задачи на Java/Kotlin, используя Java API движка и Spring. External tasks — исполнение задач процесса внешними сервисами-обработчиками, которые можно написать на любом языке разработки.
Масштабируемость, отказоустойчивость: при правильной конфигурации и хорошей инфраструктуре движок держит высокую нагрузку и горизонтально масштабируется за счет увеличения количества воркеров. На продакшн-среде мы запускали больше 200к активных процессов.
Мониторинг: Camunda из коробки дает удобный UI-cockpit, он позволяет в реальном времени просматривать все запущенные процессы. Провалившись в процесс, можно увидеть точку исполнения, возникшие ошибки. Например, некоторые процессы умеют автоматически генерировать инциденты для службы поддержки, после чего специалист может найти проблемный процесс и посмотреть его состояние для разбора этого инцидента.
Паттерны использования Camunda
C момента запуска в Леруа Мерлен пилотного проекта с использованием Camunda прошло уже несколько лет, за это время основное применение платформа в компании нашла в качестве оркестратора микросервисов. По мере того как количество сервисов в домене увеличивается, команды сталкиваются с необходимостью иметь stateful-оркестрацию вызова этих сервисов, а также им приходится работать с распределенными транзакциями и применять паттерн SAGA с возможностью делать компенсационные операции. Camunda помогает решать эти задачи.
С точки зрения разработки мы используем два основных подхода:
подход №1
1) разворачиваем Camunda как отдельный сервис и начинаем наполнять его кастомными Java/Kotlin-реализациями с помощью интерфейса JavaDelegate, итого получается spring-приложение, с которым привычно работать разработчикам. Аналитики рисуют BPMN-схемы флоу-процесса (сам процесс, как правило, привязывается к бизнес-объекту, например, клиентский заказ или процесс оплаты заказа), а разработчики имплементируют логику вызова микросервисов слоя объектных интерфейсов, при этом вызовы могут быть как синхронными (с использованием REST API), так и асинхронным (отправка команд или ожидание ивентов-событий).
подход №2
2) в паттерне «External tasks» также разворачиваем Camunda как отдельный сервис, но реализация бизнес-логики уже имплементируется на стороне внешних сервисов, стек которых не имеет значения, главное, чтобы они могли выполнять http-запросы к Camunda, для того чтобы получить список активных задач и взять их в работу.
Это решение дает лучшую производительность и подходит для highload-решений, поскольку Camunda выполняет только задачу BPM-оркестратора, а исполнение самих задач ложится на внешние сервисы.
Цепочки по выполнению распределенных транзакций с применением шаблона SAGA мы также реализуем на платформе Camunda, но об этом расскажем в отдельной статье позже.
Иногда мы сталкиваемся с тем, что стейкхолдеры приходят к нам с запросом автоматизации рутинных бизнес-процессов.
Если абстрагироваться от оркестрации микросервисов, основной задачей становится необходимость вовлечь людей в процесс и дать некоторый UI, где пользователи могут исполнять свои задачи, — например, подтверждать/отклонять заявки, заполнять данные в поля, прикреплять документы и т. д. Примером такой реализации в нашей компании выступает процесс онбординга новых провайдеров услуг, где есть разные роли согласующих, анкеты и документы. Camunda позволяет очень быстро автоматизировать процесс «из коробки», поскольку само решение имеет функционал UI работы с пользовательскими задачи (user tasks) и ролевой моделью. Наш опыт показал, что функционал Camunda User tasks подходит для быстрого старта, но по мере развития лучше написать свой менеджер тасков и кастомный front.
В этой статье стоит упомянуть новое решение ZeeBee от команды Camunda, главной особенностью которого является то, что в отличие от Camunda ZeeBe не персистит каждый свой стейт процесса в БД, что дает лучшую производительность. Пожалуй, основным минусом ZeeBee в данный момент является бедная поддержка нотации BPMN и отсутствие DMN. На данный момент в качестве домашнего задания мы уже тестируем ZeeBee, смотрим опыт других коллег и думаем над пилотным внедрением. Хотя будем честными, сейчас Camunda нас удовлетворяет практически по всем параметрам.