Сервисная архитектура

Платформа построена с использованием сервисной архитектуры – набор независимо развертываемых слабо связанных служб, взаимодействующих друг с другом по средствам удаленного вызова. Поэтому для удобного и простого управления Платформой требуется использование специального программного обеспечения.
За счет использования сервисной архитектуры Платформа может быть развернута на один или несколько серверов, имеющих доступ друг к другу по сети. Данные сервера будут образовывать кластер и называются узлами кластера.

Каждая служба Платформы поставляется в виде Docker образа, который затем используется для создания и запуска контейнера. Для того, чтобы объединить несколько узлов с работающими на них контейнерами в единый кластер, требуется оркестратор контейнеров – специальное программное обеспечение для управления кластером. Поддерживаются применение нескольких оркестраторов – Kubernetes и Docker Swarm (поставляются сборки конфигурации платформы как для Kubernetes, так и для Docker Swarm).

Техническая реализация базовых и вспомогательных сервисов

Сервис централизованной аутентификации

Система аутентификации – диаграмма контейнеров

Authentication Service построен на базе Spring Authorization Server, расширенного средствами Spring Security, что обеспечивает реализацию современных протоколов аутентификации и авторизации. В качестве основной базы данных используется PostgreSQL для хранения административной информации, в том числе пользователей и разрешений. Для хранения сессионных данных применяется Redis, что позволяет масштабировать сервис горизонтально и обеспечивать высокую доступность без зависимости от состояния конкретного экземпляра.

Для интеграции с внешними системами и безопасного хранения чувствительных данных используется Hashicorp Vault, предоставляющий надёжный механизм шифрования.
Взаимодействие между сервисами и пользователями реализовано через защищённые протоколы, соответствующие требованиям корпоративной безопасности.

Сервис реализован как stateless-приложение, что позволяет масштабировать его без ограничения на количество пользователей или сервисов, подключающихся к платформе.

Hashicorp Vault является вспомогательным сервисом платформы. Данный сервис предоставляет функциональность для работы с секретными данными, включая их хранение, шифрование и дешифрование.
Функциональность, предоставляемая данным сервисом, используется в платформе при работе с внешними источниками. Данные, указанные пользователем, а также секретные данные платформы для внешнего источника шифруются с помощью Vault и хранятся в базе данных в зашифрованном виде. При использовании этих данных они расшифровываются с помощью Vault.

Система маршрутизации — диаграмма контекста

Маршрутизатор API (API Gateway)

API Gateway построен на базе Spring Cloud Gateway с использованием реактивного стека — Project Reactor и Netty. Такой подход позволяет эффективно обрабатывать большое количество одновременных запросов с минимальными задержками. Компонент взаимодействует с Authentication Service по протоколу OAuth2 для проверки токенов и авторизации пользователей.

Конфигурация маршрутов может задаваться в виде YAML-файлов или через административный интерфейс, что позволяет централизованно управлять логикой маршрутизации. Информация о маршрутах и правилах может храниться в Redis, что обеспечивает быструю загрузку и реакцию на изменения конфигурации.
API Gateway является stateless-компонентом и масштабируется горизонтально, что позволяет достичь высокой отказоустойчивости и надёжной обработки нагрузки при росте числа пользователей или интеграций с внешними системами.

API Gateway — диаграмма контейнеров

Пользовательский интерфейс (Power Desk)

Power Desk реализован как одностраничное приложение (SPA), интегрированное с остальными сервисами платформы через REST и WebSocket-интерфейсы. Авторизация и доступ к функциональности обеспечиваются через Authentication Service. Визуально Power Desk предоставляет оконную модель взаимодействия, где пользователь может запускать приложения платформы параллельно и переключаться между ними без перезагрузки страницы. Поддерживается управление глобальным состоянием сессии пользователя, а также отслеживание активности в открытых окнах для своевременной синхронизации информации и интерфейса.

Power Desk – диаграмма контекста

Сервис реализован как stateless-приложение, что позволяет масштабировать его без ограничения на количество пользователей или сервисов, подключающихся к платформе. Для достижения целевых параметров надёжности и производительности возможно развертывание нескольких экземпляров данной службы.

Для реализации функциональности аутентификации и авторизации использован проект Spring Security. В качестве СУБД использован PostgreSQL.

Сервис Power Desk предоставляет синхронный программный интерфейс по протоколу HTTP как для внешних (пользователи), так и для внутренних (другие службы комплекса) клиентов.

Управление структурированными данными (Power Storage)

Управление структурированными данными — диаграмма контекста

Power Storage реализован как stateless-сервис на базе Spring Boot. В качестве основной СУБД используется PostgreSQL с учётом требований к надёжности хранения, возможности версионирования и логирования изменений.

Модель данных строится динамически: типы объектов, их атрибуты, связи и правила доступа могут быть описаны и загружены в платформу без перекомпиляции. Все обращения к Power Storage проходят через единый контур аутентификации и авторизации, обеспеченный Authentication Service.

Power Storage взаимодействует с брокером сообщений (например, Apache Kafka), публикуя события об изменениях объектов. Это позволяет прикладным сервисам реагировать на изменение состояния данных в реальном времени. История изменений объектов хранится отдельно, что позволяет реализовать аудит и откат изменений при необходимости.

Сервис масштабируется горизонтально, поддерживает работу с большим количеством типов данных и обеспечивает надёжную основу для построения цифровых моделей организаций.

Управление структурированными данными — диаграмма контейнеров

Файловый сервис (File Service)

File Service реализован как stateless-сервис и отвечает за работу с бинарными объектами, хранимыми вне основной базы данных. Для хранения используются внешние файловые системы или объектные хранилища (например, S3-совместимые решения), что позволяет масштабировать систему и эффективно работать с крупными файлами.

Метаданные о файлах, включая ссылки на версионные копии, владельцев, время загрузки и типы связей, сохраняются в Power Storage. Доступ к файлам регулируется через общий контур авторизации платформы. Сервис поддерживает механизмы кеширования и защищённой загрузки, а также может использоваться другими компонентами, такими как Content Management или Image Service.

Дискуссии- диаграмма контекста

Сервис обсуждений (Chat Service)

Дискуссии- диаграмма контекста

Chat Service реализован как stateless-приложение, использующее PostgreSQL для хранения сообщений, привязанных к объектам и контекстам платформы. Каждое сообщение связано с конкретным бизнес-объектом через его уникальный идентификатор.

Сервис обменивается уведомлениями с Notification Service и использует WebSocket Service для доставки сообщений в реальном времени. Поддерживается контроль прав на участие в обсуждениях в зависимости от ролей пользователей и настроек доступа к объектам.

Сервис дискуссий предоставляет синхронный программный интерфейс по протоколу HTTP как для внешних (пользователи), так и для внутренних (другие службы комплекса) клиентов.

Дискуссии- диаграмма контейнеров

Сервис поиска (Search Service)

Сервис реализует федеративную архитектуру организации поиска. Сервис организует поиск по всем источникам данных, зарегистрированным в системе и доступным для пользователя, выполняющего поиск.

В частности, Search Service получает данные из Power Storage и строит индекс по заданным полям объектов. Поиск выполняется с использованием механизма полнотекстового сопоставления по конфигурируемым атрибутам. Сервис работает в том же контуре аутентификации и авторизации, что и другие компоненты платформы, и учитывает права доступа пользователя при отображении результатов. Поддерживается интеграция с Power Desk для запуска поиска в рамках активной пользовательской сессии.

Федеративный поиск- диаграмма контекста

Сервис поиска реализован как stateless-сервис на базе Spring Boot. В качестве основной СУБД используется PostgreSQL. Возможно развертывание нескольких экземпляров данной службы, что позволяет обеспечить целевые показатели надежности и производительности системы.

Сервис поиска предоставляет синхронный программный интерфейс по протоколу HTTP как для внешних (пользователи), так и для внутренних (другие службы платформы) клиентов.  Сервис поиска предоставляет также асинхронный программный интерфейс по каналу брокера сообщений для внутренних клиентов. В качестве брокера сообщений использован Apache Kafka.

Федеративный поиск- диаграмма контейнеров

Сервис уведомлений (Notification Service)

Централизованные уведомления- диаграмма контекста

Notification Service реализован как stateless-компонент, получающий события из других сервисов через брокера сообщений (например, Kafka). Обработка уведомлений включает маршрутизацию, фильтрацию по пользовательским настройкам и передачу в выбранный канал доставки.

Хранение данных о доставленных уведомлениях и пользовательских настройках реализовано на базе PostgreSQL. В веб-интерфейсе уведомления отображаются через WebSocket-соединение или периодический polling, в зависимости от возможностей клиента. Интеграция с внешними почтовыми и push-шлюзами может быть настроена на уровне среды развертывания.

Сервис обмена сообщениями (Websocket)

Сервис вебсокетов предоставляет функциональность для отправки сообщений пользователям по каналам вебсокетов, SockJS и STOMP.

Сервис вебсокетов построен на основе проекта Spring Boot. Для реализации функциональности аутентификации и авторизации использован проект Spring Security.  Для реализации функциональности вебсокетов использована библиотека Spring WebSocket.

Сервис вебсокетов не является горизонтально масштабируемым. Сервис вебсокетов предоставляет синхронный программный интерфейс по протоколу HTTP для внутренних (другие службы комплекса) клиентов.

Обмен сообщениями — диаграмма контейнеров

Реализация отправки сообщений пользователям

Клиенты, желающие получать сообщения по каналу вебсокетов, делают запрос к сервису вебсокетов для создания соединения. Соединения создаются для каждого пользователя, поэтому при запросе на создание соединения должен быть указан идентификатор пользователя.

Предоставляя асинхронный программный интерфейс сервис вебсокетов является мостом между протоколами HTTP и WebSocket. Любой сервис платформы может отправить сообщение сервису вебсокетов выполнив обычный HTTP запрос для отправки сообщения пользователю, указав сообщение, идентификатор пользователя и тему сообщения. Сервис вебсокетов, получив запрос на отправку сообщения, пытается найти существующее пользовательское соединение. Если оно создано, то через данное соединение происходит отправка сообщения.

Пройти пилотное тестирование