[Микросервисы] Обзор фреймворков для оркестрации микросервисов: Conductor, Zeebe, Temporal
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Оркестрация микросервисов помогает выстраивать сложные процессы в продуктах. Чтобы не приходилось прописывать эту механику руками, разработчики могут воспользоваться готовыми фреймворками, которые включают в себя средства управления микросервисами. Мы в True Engineering изучили эту тему и рассказываем про три таких фреймворка.При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.Оркестратор микросервисов контролирует выполнение процессов. В результате данные не теряются, поддержке становится проще устранять проблемы, а разработчикам – управлять развитием всей системы.Можно написать такой модуль с нуля, а можно использовать готовый фреймворк. Если в компании есть несколько команд разработчиков, без таких фреймворков не обойтись. Во-первых, программистам не придётся раз за разом выполнять одну и ту же работу. Во-вторых, когда все используют общие инструменты, у команд появляются единые стандарты работы, и это сразу сказывается на качестве продуктов. Вместо того, чтобы изобретать велосипед, все концентрируются на развитии общего инструмента.Архитектура фреймворка для оркестрации
Фреймворк включает в себя готовые к работе компоненты оркестрации. Это сам оркестратор, который принимает таски и передаёт их рабочим микросервисам на исполнение. Когда продукт запускает процесс (например, организация путешествия на сайте), оркестратор формирует очередь задач, которые предстоит выполнить микросервисам. В нашем примере это может быть «Покупка авиабилета», «Бронирование гостиницы», «Аренда автомобиля». Микросервисы подхватывают эти задачи и отчитываются о выполнении. Данные сохраняются в собственном хранилище оркестратора, так что если процесс внезапно прервётся, его можно будет возобновить с того же места.Теперь о том, как мы подбирали и сравнивали между собой разные фреймворки. Какие у нас были требования к оркестратору
- Простота процессов. Нам нужна удобная среда, в которой будет наглядно показано взаимодействие микросервисов. Дополнительным преимуществом будет автоматическое создание документации, когда описание оркестрации становится описанием всей системы.
- Обработка ошибок. На случай сбоя должна быть возможность настроить количество повторных попыток и таймаутов. Кроме того, настройка бизнес-логики и механики самих микросервисов должна идти независимо, чтобы ими можно было управлять отдельно, а изменение бизнес-процесса не ломало весь продукт. Плюс, поддержка шаблона проектирования Saga – необходимо предусмотреть откатные действия, когда процесс останавливается на каком-то шаге.
- Поддержка асинхронных активностей и воркфлоу. Необходимо для сохранения промежуточных данных, упрощения разработки и более стабильной работы как таковой.
- Мультиплатформенная поддержка. Желательно, чтобы инструмент могли использовать сразу все команды (например, у нас разработка идёт на Java и .NET).
Сравнение фреймворковМы изучили существующие инструменты и подобрали три кандидата, которые соответствуют нашим критериям. Набор возможностей у них схожий, а в реализации есть некоторые отличия.Conductor от Netflix. Параметры бизнес-процессов и активности описываются в JSON-файлах. В коде микросервисов нужно прописать уникальные строки, по которым оркестратор будет их вызывать. Настройка бизнес-логики для каждой отдельной активности – есть.Zeebe от Camunda. Camunda – это BPMN-движок, который мы давно используем в своей практике (например, для оркестрации своего трекера с трекером заказчика или автоматизации бизнес-процессов). Если знаете Camunda, то интерфейс Zeebe будет вам хорошо знаком. Главное преимущество – выделенный графический редактор, с которым будет просто разобраться не-разработчикам. Данные хранятся в XML-файлах.Temporal. Использует для оркестрации чистый код. Нет идентификаторов – микросервисы вызываются через код или собственный интерфейс, который надо дополнительно прописывать. Для многих разработчиков это будет проще и привычнее всего.Результаты сравнения по нашим критериям:
- Простота процессов. Zeebe оказался самым наглядным благодаря графическому компоненту. А Temporal – самый привычный для разработчиков за счёт оркестрации через код.
- Обработка ошибок. Возможности у всех фреймворков примерно равны, yj Zeebe чуть слабее. Из критических параметров он позволяет настраивать только количество ретраев и не поддерживает Saga без костылей.
- Поддержка асинхронных активностей. Здесь все одинаково хороши.
- Мультиплатформенная поддержка. Все фреймворки развивают Java-клиенты, а .NET-версии поддерживаются силами сообщества.
ВыводСравнение показывает, что серебряной пули не существует – каждый фреймворк по-своему хорош. Инструмент нужно выбирать в диалоге с командами – кому-то может быть удобнее работать с JSON, другой оценит визуализацию, а третий захочет использовать чистый код.Но любой фреймворк лучше, чем встраивать оркестрацию в код каждого продукта отдельно. Так разработчикам приходится каждый раз заново вникать в механику и перегружать код. А в масштабах всей компании вы получите единые стандарты, которые помогут привести все ваши команды к общей платформе разработки.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Java, Kotlin, Gradle, Микросервисы] Шаблон Kotlin микросервисов
- [Анализ и проектирование систем, Микросервисы] Как управлять транзакциями в микросервисной архитектуре
- [Go, Управление разработкой, Микросервисы] Написали 100 микросервисов и не сошли с ума: как мы в Lamoda шарим знания и технологии
- [Java] Использование Google Protocol Buffers (protobuf) в Java (перевод)
- [Системное программирование, Алгоритмы, Go, Микросервисы] Автоматы на службе распределенных транзакций
- [Совершенный код, .NET, API, C#, Микросервисы] Паттерн CQRS: теория и практика в рамках ASP.Net Core 5
- [Программирование, DevOps, Микросервисы] Feature Flags и фабрика ПО
- [Разработка на Raspberry Pi, Умный дом, Интернет вещей, Микросервисы] Первый опыт с Raspberry Pi или микросервисы для дома
- [Развитие стартапа, Микросервисы, 1С] ERP-система — нет, микросервисный подход — да, подойдет для создания маркетплейса. Давайте разбираться, что к чему
- [Программирование, Visual Studio, DevOps, Микросервисы] Шаблон микросервиса: зачем нужен и как его внедрить в разработку
Теги для поиска: #_mikroservisy (Микросервисы), #_mikroservisy (микросервисы), #_orkestratsija_mikroservisov (оркестрация микросервисов), #_raspredelennye_tranzaktsii (распределенные транзакции), #_mikroservisy (
Микросервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 15-Май 00:12
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Оркестрация микросервисов помогает выстраивать сложные процессы в продуктах. Чтобы не приходилось прописывать эту механику руками, разработчики могут воспользоваться готовыми фреймворками, которые включают в себя средства управления микросервисами. Мы в True Engineering изучили эту тему и рассказываем про три таких фреймворка.При автоматизации сложного бизнес-процесса в продукте может быть задействовано сразу несколько микросервисов. И если в монолите выстроить взаимодействие нескольких модулей довольно просто, то в распределённой архитектуре, где каждый такой компонент – это отдельное приложение, возникают трудности.Оркестратор микросервисов контролирует выполнение процессов. В результате данные не теряются, поддержке становится проще устранять проблемы, а разработчикам – управлять развитием всей системы.Можно написать такой модуль с нуля, а можно использовать готовый фреймворк. Если в компании есть несколько команд разработчиков, без таких фреймворков не обойтись. Во-первых, программистам не придётся раз за разом выполнять одну и ту же работу. Во-вторых, когда все используют общие инструменты, у команд появляются единые стандарты работы, и это сразу сказывается на качестве продуктов. Вместо того, чтобы изобретать велосипед, все концентрируются на развитии общего инструмента.Архитектура фреймворка для оркестрации  Фреймворк включает в себя готовые к работе компоненты оркестрации. Это сам оркестратор, который принимает таски и передаёт их рабочим микросервисам на исполнение. Когда продукт запускает процесс (например, организация путешествия на сайте), оркестратор формирует очередь задач, которые предстоит выполнить микросервисам. В нашем примере это может быть «Покупка авиабилета», «Бронирование гостиницы», «Аренда автомобиля». Микросервисы подхватывают эти задачи и отчитываются о выполнении. Данные сохраняются в собственном хранилище оркестратора, так что если процесс внезапно прервётся, его можно будет возобновить с того же места.Теперь о том, как мы подбирали и сравнивали между собой разные фреймворки. Какие у нас были требования к оркестратору
=========== Источник: habr.com =========== Похожие новости:
Микросервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 15-Май 00:12
Часовой пояс: UTC + 5