Оркестрация микросервисов помогает выстраивать сложные процессы в продуктах. Чтобы не приходилось прописывать эту механику руками, разработчики могут воспользоваться готовыми фреймворками, которые включают в себя средства управления микросервисами. Мы в True Engineering изучили эту тему и рассказываем про три таких фреймворка.
При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.
Оркестратор микросервисов контролирует выполнение процессов. В результате данные не теряются, поддержке становится проще устранять проблемы, а разработчикам – управлять развитием всей системы.
Можно написать такой модуль с нуля, а можно использовать готовый фреймворк. Если в компании есть несколько команд разработчиков, без таких фреймворков не обойтись. Во-первых, программистам не придётся раз за разом выполнять одну и ту же работу. Во-вторых, когда все используют общие инструменты, у команд появляются единые стандарты работы, и это сразу сказывается на качестве продуктов. Вместо того, чтобы изобретать велосипед, все концентрируются на развитии общего инструмента.
Архитектура фреймворка для оркестрации
Фреймворк включает в себя готовые к работе компоненты оркестрации. Это сам оркестратор, который принимает таски и передаёт их рабочим микросервисам на исполнение.
Когда продукт запускает процесс (например, организация путешествия на сайте), оркестратор формирует очередь задач, которые предстоит выполнить микросервисам. В нашем примере это может быть «Покупка авиабилета», «Бронирование гостиницы», «Аренда автомобиля». Микросервисы подхватывают эти задачи и отчитываются о выполнении. Данные сохраняются в собственном хранилище оркестратора, так что если процесс внезапно прервётся, его можно будет возобновить с того же места.
Теперь о том, как мы подбирали и сравнивали между собой разные фреймворки.
Какие у нас были требования к оркестратору
Простота процессов. Нам нужна удобная среда, в которой будет наглядно показано взаимодействие микросервисов. Дополнительным преимуществом будет автоматическое создание документации, когда описание оркестрации становится описанием всей системы.
Обработка ошибок. На случай сбоя должна быть возможность настроить количество повторных попыток и таймаутов. Кроме того, настройка бизнес-логики и механики самих микросервисов должна идти независимо, чтобы ими можно было управлять отдельно, а изменение бизнес-процесса не ломало весь продукт. Плюс, поддержка шаблона проектирования Saga – необходимо предусмотреть откатные действия, когда процесс останавливается на каком-то шаге.
Поддержка асинхронных активностей и воркфлоу. Необходимо для сохранения промежуточных данных, упрощения разработки и более стабильной работы как таковой.
Мультиплатформенная поддержка. Желательно, чтобы инструмент могли использовать сразу все команды (например, у нас разработка идёт на Java и .NET).
Сравнение фреймворков
Мы изучили существующие инструменты и подобрали три кандидата, которые соответствуют нашим критериям. Набор возможностей у них схожий, а в реализации есть некоторые отличия.
Conductor от Netflix. Параметры бизнес-процессов и активности описываются в JSON-файлах. В коде микросервисов нужно прописать уникальные строки, по которым оркестратор будет их вызывать. Настройка бизнес-логики для каждой отдельной активности – есть.
Zeebe от Camunda. Camunda – это BPMN-движок, который мы давно используем в своей практике (например, для оркестрации своего трекера с трекером заказчика или автоматизации бизнес-процессов). Если знаете Camunda, то интерфейс Zeebe будет вам хорошо знаком. Главное преимущество – выделенный графический редактор, с которым будет просто разобраться не-разработчикам. Данные хранятся в XML-файлах.
Temporal. Использует для оркестрации чистый код. Нет идентификаторов – микросервисы вызываются через код или собственный интерфейс, который надо дополнительно прописывать. Для многих разработчиков это будет проще и привычнее всего.
Результаты сравнения по нашим критериям:
Простота процессов. Zeebe оказался самым наглядным благодаря графическому компоненту. А Temporal – самый привычный для разработчиков за счёт оркестрации через код.
Обработка ошибок. Возможности у всех фреймворков примерно равны, yj Zeebe чуть слабее. Из критических параметров он позволяет настраивать только количество ретраев и не поддерживает Saga без костылей.
Поддержка асинхронных активностей. Здесь все одинаково хороши.
Мультиплатформенная поддержка. Все фреймворки развивают Java-клиенты, а .NET-версии поддерживаются силами сообщества.
Вывод
Сравнение показывает, что серебряной пули не существует – каждый фреймворк по-своему хорош. Инструмент нужно выбирать в диалоге с командами – кому-то может быть удобнее работать с JSON, другой оценит визуализацию, а третий захочет использовать чистый код.
Но любой фреймворк лучше, чем встраивать оркестрацию в код каждого продукта отдельно. Так разработчикам приходится каждый раз заново вникать в механику и перегружать код. А в масштабах всей компании вы получите единые стандарты, которые помогут привести все ваши команды к общей платформе разработки.
