В статье приводится схема протоколов и портов общения между отдельными серверами всего приложения. Она же является принципиальной схемой масштабирования и построения отказоустойчивого кластера для приложения ELMA365.
Отдельные узлы сервисов хранения и обработки данных (PostgreSQL, MongoDB, RabbitMQ, Redis, MinIO S3) имеют свои правила масштабирования и построения отказоустойчивой схемы. Подробнее об этом читайте в разделе «Отказоустойчивая архитектура серверов» технических требований.
Приложение ELMA365 состоит из множества сервисов в изолированных контейнерах и работает в среде управления Kubernetes (в текущей поставке On-Premises для этого используется реализация MicroK8s).
Список сервисов внутри кластера приложения ELMA365
auth |
Сервис авторизации и управления группами, пользователями и оргструктурой. |
balancer |
Сервис управления мультитенантностью в редакции Private Cloud. |
calculator |
Сервис для расчёта формул в элементах приложений. |
chat |
Сервис приватных и групповых сообщений чатов. |
collector |
Чтение и фильтрация элементов приложений. |
convertik |
Конвертация документов в формат PDF. |
deploy |
Управление миграциями данных и конфигурации при обновлении платформы. |
diskjockey |
Работа с файлами и директориями. |
docflow |
Работа с листами согласования, ознакомления и документооборотом. |
event-bus |
Сервис отслеживания и обработки событий системы. Работает с шиной событий. |
feeder |
Работа с лентой пользователя и в приложениях, работа с каналами. |
front |
Клиентская часть ELMA365. Статика, стили, скрипты. |
integrations |
Сервис работы с внешними интеграциями и пользовательскими модулями. |
mailer |
Отправка почты из системы. |
main |
Основной АПИ-шлюз, который перенаправляет запросы к другим внутренним сервисам. |
messengers* |
Сервис работы с внешними чатами и линиями. |
notifier* |
Уведомления и работа с веб-сокетами. |
processor |
Управление исполнением бизнес-процессов. |
picasso |
Сервис управления слепками ЭЦП. |
scheduler* |
Сервис расписания, отложенного запуска заданий, учёта рабочего времени. |
settings |
Сервис настроек компаний и пользователей. Для сохранения и получения настроек компаний, а также слияния настроек компании и пользователя – чтобы получить результирующие настройки. |
templater |
Шаблонизатор текста и офисных документов, управление шаблонами. |
vahter |
Единый центр аутентификации системы. |
web-forms |
Управление публичных форм для вставки во внешние веб страницы. |
widget |
Управление low-code виджетами. Хранение и жизненный цикл. |
worker |
Валидация, компиляция и выполнение пользовательских сценариев на сервере в процессах, виджетах и модулях. |
* - сервис не может работать в нескольких экземплярах.
Отказоустойчивость и масштабирование отдельных сервисов
Распределённая сервисная архитектура позволяет масштабировать решение более гибко, в зависимости от профиля нагрузки на систему. По умолчанию все сервисы кластера (кроме scheduler, notifier, messengers) в кластере Enterprise выполняются в 2-х экземплярах (в Standard — в единичном экземпляре). Когда в кластере подключено несколько серверов, то оркестратор microk8s пытается равномерно распределить экземпляры сервисов между серверами. При выходе из строя одного из серверов, оркестратор определяет упавшие сервисы и пересоздает их на оставшихся серверах.
Для функционирования отказоустойчивого кластера ELMA365 требуется минимум 3 сервера. Между ними производится постоянное взаимодействие и отслеживается жизнеспособность каждого сервера. Кластер может посчитать сервер “мёртвым”, если он недоступен по сети определённое время. Таким образом вся система в кластере продолжит работать пока есть хотя бы 2 (два) рабочих сервера.
Добавление большого количества серверов в кластер не решит автоматически задачу масштабирования для более высоких нагрузок. Если не вносить дополнительных изменений в конфигурацию кластера, то добавление новых машин только уменьшит вероятность полного отказа всего сервиса. Для увеличения пропускной способности кластера (одновременные пользователи, транзакции в час) можно наращивать ресурсы каждого сервера довольно долго (примерно до 10000 одновременных пользователей на одном сервере).
Однако, часто можно выявить определённое узкое место в нагрузке на систему и масштабировать только этот отдельный сервис. Например, сервис исполнения сценариев worker. Он является довольно ёмким по ресурсам и при этом очень хорошо работает в нескольких параллельных экземплярах. И если профиль нагрузки в вашей конфигурации активно использует серверные сценарии, то можно установить для этого сервиса свой фактор репликации (больше 2). Тогда оркестратор будет создавать дополнительные экземпляры этого сервиса для более быстрой параллельной обработки исполнения сценариев.
Таким же образом можно управлять параллельными экземплярами исполнения и в других сервисах. Однако, для понимания того, какие сервисы следует масштабировать, нужно проводить исследование профиля нагрузки конкретной конфигурации в конкретное время.