Архитектура

                                         ┌───────────────────────┐
                                         │ Spring Boot 2 Service │
                         ┌──────────────▶│  + Axelix Starter     │
                         │               └───────────────────────┘
┌──────────┐         ┌───┴────────┐      ┌───────────────────────┐
│    UI    │─REST───▶│            │─────▶│ Spring Boot 3 Service │
└──────────┘         │   Axelix   │      │  + Axelix Starter     │
                     │   Master   │      └───────────────────────┘
                     │ (UI + MCP) │      ┌───────────────────────┐
┌──────────┐         │            │─────▶│ Spring Boot 2 Service │
│ AI Agent │─MCP────▶│            │      │  + Axelix Starter     │
└──────────┘         └───┬────────┘      └───────────────────────┘
                         │               ┌───────────────────────┐
                         └──────────────▶│ Spring Boot 3 Service │
                                         │  + Axelix Starter     │
                                         └───────────────────────┘

Компоненты

• Axelix Master: отдаёт UI, предоставляет REST API, который потребляет UI, запускает встроенный MCP-сервер, общается с каждым управляемым сервисом по HTTP и хранит реестр сервисов.
• Axelix Spring Boot Starter: отдельные модули стартера существуют для Spring Boot 2, Spring Boot 3 и Spring Boot 4 — выберите тот, что соответствует вашему приложению. Стартер предоставляет эндпоинты, нужные Master (бины, окружение, кеши, запланированные задачи и прочее), и опционально может сам зарегистрироваться в Master при старте.

Коммуникация

• Браузер ⇄ Master: REST/JSON в рамках того же origin, с которого Master отдаёт статический фронтенд.
• AI-агент ⇄ Master: Model Context Protocol поверх HTTP. См. Аутентификация MCP-сервера — там описаны схемы учётных данных.
• Master → управляемый сервис: HTTP к эндпоинтам Axelix Starter на стороне сервиса. Каждое чтение (бины, окружение, запланированные задачи и т.д.) и каждое изменяющее действие (установить уровень логгера, очистить кеш, запустить задачу) — это синхронный HTTP-вызов.
• Управляемый сервис → Master: используется только если включена самостоятельная регистрация. Стартер отправляет запрос на регистрацию при старте и поддерживает heartbeats, в payload передаётся URL, по которому Master должен обращаться к сервису.

Service discovery

Сервис появляется в реестре сервисов Master одним из двух путей:

• Auto-discovery со стороны Master: Master опрашивает API платформы и находит сервисы с подключённым Axelix Starter. На сегодня автоматический discovery доступен только в Kubernetes и включён по умолчанию в официальном helm-чарте Axelix.
• Самостоятельная регистрация со стороны стартера: Axelix Starter отправляет запрос на регистрацию в Master при старте и шлёт heartbeats с определённым интервалом.

Развёртывание и масштабирование

• Master — центральный процесс. Он работает как «мозг», который принимает все входящие запросы от пользовательского интерфейса и затем маршрутизирует их к конкретному сервису.
• База данных — граница долговечности. Axelix Master хранит определённое состояние, и для этого ему нужна БД. По умолчанию используется SQLite. Этого достаточно для небольших установок, но имейте в виду: файл sqlite-БД не переживает рестарт контейнера без подмонтированного тома. PostgreSQL или MySQL — выбор для всего, что выходит за рамки небольшого деплоя — см. Database.
• Сетевая доступность — забота оператора. Master должен иметь возможность вызывать каждый управляемый сервис по HTTP из своей сети — именно по этому каналу идут все чтения и мутации. Heartbeats при самостоятельной регистрации — единственный вызов в обратном направлении.

Multi-master развёртывания

Возможно развернуть несколько сервисов Axelix Master. В этом случае конечные пользователи сами отвечают за организацию общей БД (например, тот же подмонтированный sqlite-файл или общая PostgreSQL):

              ┌──────────────┐                  ┌──────────────┐
              │      UI      │                  │  AI Agents   │
              └──────┬───────┘                  └──────┬───────┘
                     │REST                             │MCP
                     │                                 │
 ┌───────────────────┴─────────────────────────────────┴───────────────────┐
 │                         Load Balancer (K8S Service)                     │
 └──────────┬───────────────────────────────────────────────────┬──────────┘
            │                                                   │
            │                                                   │
 ┌──────────┴──────────┐                             ┌──────────┴──────────┐
 │    Axelix Master    │                             │    Axelix Master    │
 │       pod "A"       │                             │       pod "B"       │
 └──┬─────────────┬────┘                             └─┬─────────────┬─────┘
    │             │                                    │             │
    │             │                                    │             │
    │     ┌───────┴────────────────────────────────────┴────────┐    │
    │     │                      Shared DB                      │    │
    │     │                                                     │    │
    │     └─────────────────────────────────────────────────────┘    │
    │                                                                │
┌───┴──────────────────────┐                       ┌─────────────────┴─────┐
│ Spring Boot Services     │                       │ Spring Boot Services  │
│ (Spring Boot 2 - 4)      │                       │ (Spring Boot 2 - 4)   │
└──────────────────────────┘                       └───────────────────────┘

Модель безопасности

Аутентификация для ИИ-агентов при использовании MCP и для людей при использовании UI возможна либо через Basic-аутентификацию, либо через OAuth2/OIDC. Ниже — лишь краткий обзор. Полная модель учётных данных описана в Аутентификации.

Basic-аутентификация

В этом случае предполагается, что пользователи будут создаваться в той БД, к которой подключён Axelix Master. Профиль пользователя хранится в БД Axelix Master, что вполне подходит для небольших установок.

При входе пользователю или ИИ-агенту будет предложено предоставить учётные данные, которые затем проверяются по БД. В случае входа из UI-формы бэкенд отправит выделенную auth-куки, в которой будет лежать JWT access-token.

В случае использования ИИ-агентами эти учётные данные просто передаются в кастомном заголовке "Basic ...", как описано в RFC 7617.

OAuth2 и OIDC

В современных компаниях SSO (Single Sign-On) — распространённый паттерн IAM. Часто он реализуется через OAuth2 и OIDC.

Axelix Master можно настроить так, чтобы аутентификация пользователя проходила через внешнего OIDC-провайдера. В этом случае Axelix Master доверяет токену OIDC-провайдера и может дополнительно запросить у провайдера информацию о текущем пользователе (например, обратившись к эндпоинту /userinfo, если он доступен).

IAM. Важные нюансы

• Общий ключ подписи JWT. На данный момент и Axelix Master, и Axelix Starter используют симметрично шифрованный JWT. Это означает, что один и тот же signing-key должен быть настроен на Master и на каждом Axelix Starter. Master подписывает токены для вызова эндпоинтов стартера, стартер подписывает heartbeats при самостоятельной регистрации. Расхождение ключей приводит к 401 и отклонённому вызову, а не к тихому рассинхрону.
• TLS — на стороне оператора. По умолчанию Master слушает обычный HTTP. Поставьте его за TLS-терминирующий прокси и выставьте axelix.master.auth.cookie.secure=true для любого нелокального деплоя.