Три года назад Леруа Мерлен начала масштабную программу ИТ-трансформации с использованием таких прогрессивных течений, как микросервисная архитектура, предметно-ориентированное проектирование (оно же 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) разворачиваем Camunda как отдельный сервис и начинаем наполнять его кастомными Java/Kotlin-реализациями с помощью интерфейса JavaDelegate, итого получается spring-приложение, с которым привычно работать разработчикам. Аналитики рисуют BPMN-схемы флоу-процесса (сам процесс, как правило, привязывается к бизнес-объекту, например, клиентский заказ или процесс оплаты заказа), а разработчики имплементируют логику вызова микросервисов слоя объектных интерфейсов, при этом вызовы могут быть как синхронными (с использованием REST API), так и асинхронным (отправка команд или ожидание ивентов-событий).
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 нас удовлетворяет практически по всем параметрам.
Полезные ссылки:
Bernd Ruecker — Practical Process Automation for Modern Architectures
Leroy Merlin — Платформа для работы в условиях неопределенности