Оркестрация микросервисов помогает выстраивать сложные процессы в продуктах. Чтобы не приходилось прописывать эту механику руками, разработчики могут воспользоваться готовыми фреймворками, которые включают в себя средства управления микросервисами. Мы в True Engineering изучили эту тему и рассказываем про три таких фреймворка.
При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.
Оркестратор микросервисов контролирует выполнение процессов. В результате данные не теряются, поддержке становится проще устранять проблемы, а разработчикам – управлять развитием всей системы.
Можно написать такой модуль с нуля, а можно использовать готовый фреймворк. Если в компании есть несколько команд разработчиков, без таких фреймворков не обойтись. Во-первых, программистам не придётся раз за разом выполнять одну и ту же работу. Во-вторых, когда все используют общие инструменты, у команд появляются единые стандарты работы, и это сразу сказывается на качестве продуктов. Вместо того, чтобы изобретать велосипед, все концентрируются на развитии общего инструмента.
Архитектура фреймворка для оркестрации
![](https://habrastorage.org/getpro/habr/upload_files/1db/ca5/77f/1dbca577f5d325ab703f1665a60e85fb.png)
Фреймворк включает в себя готовые к работе компоненты оркестрации. Это сам оркестратор, который принимает таски и передаёт их рабочим микросервисам на исполнение.
Когда продукт запускает процесс (например, организация путешествия на сайте), оркестратор формирует очередь задач, которые предстоит выполнить микросервисам. В нашем примере это может быть «Покупка авиабилета», «Бронирование гостиницы», «Аренда автомобиля». Микросервисы подхватывают эти задачи и отчитываются о выполнении. Данные сохраняются в собственном хранилище оркестратора, так что если оркестратор вдруг упадёт и процесс прервётся, его можно будет возобновить с того же места.
Теперь о том, как мы подбирали и сравнивали между собой разные фреймворки.
Какие у нас были требования к оркестратору
Простота процессов. Нам нужна удобная среда, в которой будет наглядно показано взаимодействие микросервисов. Дополнительным преимуществом будет автоматическое создание документации, когда описание оркестрации становится описанием всей системы.
Обработка ошибок. На случай сбоя должна быть возможность настроить количество повторных попыток и таймаутов. Кроме того, настройка бизнес-логики и механики самих микросервисов должна идти независимо, чтобы ими можно было управлять отдельно и не захламлять тем самым описанную оркестрацию, не уменьшать ее наглядность. Плюс, поддержка шаблона проектирования Saga – необходимо предусмотреть откатные действия, когда процесс останавливается на каком-то шаге.
Поддержка асинхронных активностей и воркфлоу. Необходимо для более гибкой настройки оркестрируемых процессов. Таким образом отдельные составные части бизнес-процессов могут выполняться асинхронно, чтобы ни пользователь, ни другие активности не ждали их окончания.
Мультиплатформенная поддержка. Желательно, чтобы инструмент могли использовать сразу все команды (например, у нас разработка идёт на Java и .NET).
Сравнение фреймворков
Мы изучили существующие инструменты и подобрали три кандидата, которые соответствуют нашим критериям. Набор возможностей у них схожий, а в реализации есть некоторые отличия.
Conductor от Netflix. Параметры бизнес-процессов и активности описываются в JSON-файлах. В коде микросервисов нужно прописать уникальные строки, по которым оркестратор будет их вызывать.
Zeebe от Camunda. Camunda – это BPMN-движок, который мы давно используем в своей практике (например, для синхронизации своего трекера с трекером заказчика или автоматизации бизнес-процессов). Если знаете Camunda, то интерфейс Zeebe будет вам хорошо знаком. Главное преимущество – выделенный графический редактор, с которым будет просто разобраться не-разработчикам. Данные хранятся в XML-файлах.
Temporal. Использует для оркестрации чистый код. Нет идентификаторов – микросервисы вызываются через код или собственный интерфейс, который надо дополнительно прописывать. Для многих разработчиков это будет проще и привычнее всего.
Результаты сравнения по нашим критериям:
Простота процессов. Zeebe оказался самым наглядным благодаря графическому компоненту. А Temporal – самый привычный для разработчиков за счёт оркестрации через код.
Обработка ошибок. Возможности у всех фреймворков примерно равны, y Zeebe чуть слабее. Из критических параметров он позволяет настраивать только количество ретраев и не поддерживает Saga. Её можно рисовать с помощью диаграмм, но делать это приходится руками каждый раз в каждом процессе.
Поддержка асинхронных активностей. Здесь все одинаково хороши.
Мультиплатформенная поддержка. Все фреймворки развивают Java-клиенты, а .NET-версии поддерживаются силами сообщества.
Вывод
Сравнение показывает, что серебряной пули не существует – каждый фреймворк по-своему хорош. Инструмент нужно выбирать в диалоге с командами – кому-то может быть удобнее работать с JSON, другой оценит визуализацию, а третий захочет использовать чистый код.
Но любой фреймворк, с которым работают все команды, лучше, чем встраивать оркестрацию в код каждого продукта отдельно. Так разработчикам приходится каждый раз заново вникать в логику продукта и перегружать код. А в масштабах всей компании вы получите единые стандарты, которые помогут привести все ваши команды к общей платформе разработки.