В первой части своего рассказа я поделился мыслями о том, как ко мне пришла идея создать свой оркестратор. По сути, это естественный итог моих скитаний в поисках священного Грааля - способа систематизировать взаимодействия между разными компонентами системы, который бы обладал запасом прочности к постоянно изменяющимся условиям. Если бы я в друг оказался на приёме у IT–психолога, он бы наверняка сказал, что во мне сидит маленький перфекционист, мечтающий создать идеальный микросервисный мир.
Ну что ж, поехали 🚀
На картинке представлена дорожная карта моего пути к реализации задуманного проекта. Каждая карточка соответствует определенному этапу, а заголовки в них, названия циклов статей, посвященных каждому из пройденных шагов. Глядя на картинку, складывается впечатление, единственная причина задуманного, последний пункт 🤔
Итак, нам необходимо понять, из каких базовых компонентов состоит оркестратор. Моих текущих представлений явно недостаточно, поэтому важно определить, какие готовые решения существуют на рынке. Это поможет нам в нашем исследовании. В первой статье я упомянул Temporal, но считаю, что его одного недостаточно. Это всего лишь один из вариантов реализации. Возьмём ещё два решения - такой диапазон позволит нам выработать оптимальный подход к созданию собственного оркестратора.
Определим критерии выбора:
- Поддержка долгоживущих процессов;
- Управление состоянием workflow;
- Стандартный набор опций (отказоустойчивость, масштабирование, мониторинг и т.д.);
- Внятная документация и активное сообщество;
- Открытый исходный код (язык реализации не важен);
- Возможность установки на локальной машине.
Необходимо пояснить три термина, которые возможно вызовут вопросы:
- Долгоживущий процесс - это возможность оркестратора управлять последовательностью процессов в течение длительного времени: от нескольких часов, месяцев или даже лет. Такие процессы часто включают паузы, ожидание внешних событий и должны быть устойчивы к сбоям;
- Workflow - это последовательность шагов или задач, которые выполняются для достижения цели. Ну например, процесс приготовления моего любимого рафа с солёной карамелью ☕. Мне больше нравиться термин Sequence (sequence diagram) где мы описываем последовательность выполнения шагов процесса;
- Управление состоянием workflow - это механизм, позволяющий оркестратору сохранять и восстанавливать состояние workflow на каждом этапе его выполнения. Он включает в себя хранение данных о текущем шаге, переменных, результатах выполнения задач и другой информации, необходимой для корректного продолжения работы.
Выбираем кандидатов. Исследуя просторы интернета и плотно общаясь с ИИ, я пришел к выводу, что по мимо Temporal, больше к моей задумке подходит Dapr и Zeebe (Camunda), но как говориться, есть свои нюансы. Знающие наверно укажут на Сadence, но поскольку Temporal по сути его реинкарнация, а значит, он по определению унаследовал базовый подход к реализации, по этому его не рассматриваем. Давайте чуток поближе познакомимся с кандидатами:
- Temporal - Мощный оркестратор, специализирующийся на управлении долгоживущими процессами. Он обеспечивает отказоустойчивость, масштабируемость и поддержку stateful-workflow (сохраняя состояние даже после сбоев). Его ключевая особенность - возможность приостанавливать и возобновлять workflow, ожидая внешних событий. Написан на Go, взаимодействие с клиентами осуществляется через SDK поддерживающий большинство популярных ЯП. Для хранения состояния процесса использует БД (MySQL, PostgreSQL, SQLite, Cassandra, Elasticsearch);
- Dapr - Не является полноценным оркестратором, но предоставляет базовое управление состоянием workflow и упрощает микросервисное взаимодействие. Он предлагает набор API для управления состоянием, взаимодействия между сервисами, pub/sub-сообщений. Написан на Go. Взаимодействие с клиентами осуществляется через SDK поддерживающий большинство популярных ЯП, а также, через REST API без необходимости использования SDK. Хоть он и не полноценный, но мне интересно изучить как организован асинхронной обмен через брокеры сообщений. Интеграция с БД осуществляется через компоненты с использованием API;
- Zeebe (Camunda) - Масштабируемый оркестратор workflow, ориентированный на управление бизнес-процессами с использованием BPMN. Высокопроизводительный, отказоустойчив, идеально подходя для сложных и долгоживущих процессов. Интегрируется с различными брокерами сообщений. Из интересного для меня - организация исполнения BPMN и визуальное моделирование в Camunda Modeler. Написан на Java. Для хранения состояний, данных о процессах, историю выполнения и другие метаданные использует собственную реализацию RocksDB.
Определяем сценарий проекта
Среди статей, которые я читал об оркестраторах, основной фокус внимания сосредоточен на их функциональности и обзоре возможностей. Мне же хочется разобраться, как оркестратор работает в контексте реального проекта и на всех этапах внедрения в инфраструктуру распределенной системы, к которой предъявлены высокие требования: высокая доступность, отказоустойчивость и масштабируемость. Чтобы понять это, возьмём сложный сценарий - мультикластерную архитектуру с глобальной балансировкой нагрузки (Active-Active), но в масштабах моего старенького и проверенного временем компьютера 🤘 (надеюсь потянет).
Построение мультикластерной архитектуры в рамках моего ПК, определенно тянет на отдельную статью.
И так, наш проект - Workflow заказа товаров на маркетплейсе.
Стоит отметить, что в рамках проекта не ставится задача создать полноценный маркетплейс, поэтому бизнес процесс оформления заказа максимально упрощен. Возможные упущения в бизнес логике и связанные с ними ошибки сознательно опускаем.
Опишем этот процесс диаграммой последовательности:
Обратим внимание на шаг "Доставка заказа" - это и есть наш долгоживущий процесс, который может выполняться в течении длительного времени.
Далее, используя диаграмму последовательности с workflow оформления заказа, отобразим схему нашей архитектуры. Схема будет включать два кластера Kubernetes, балансировщик для распределения запросов, набор микросервисов с указанием связей между ними:
Из схемы видно, основным ядром маркетплейса является сервис заказов (OrderService), в котором сосредоточена вся логика оформления заказа. Наша задача - интегрировать оркестратор в архитектуру, чтобы понять, как это поможет упростить распределение задач и обеспечить отказоустойчивость.
Подведём небольшой итог того, что нужно сделать, и определим предварительный стек технологий:
- Реализовать шесть микросервисов (Java, Spring Boot);
- Обеспечить сохранение состояния заказа через БД (PostgreSQL);
- Создать мок платежного шлюза для имитации оплаты;
- Организовать балансировщик нагрузки между двумя кластерами (Nginx);
- Подготовить макет двух кластеров с оркестрацией микросервисов (Minikube, Kubectl).
В следующей статье поговорим о подготовке инфраструктуры в масштабах моего ПК.
Ну вот и всё. Статья получилась немного длинной, хотя я старался ужать её настолько, насколько это возможно. Всем спасибо за внимание, и да пребудет с вами сила! 💪