Как работает обнаружение
Как Axelix Master узнаёт, какие экземпляры Spring Boot-сервисов существуют, и поддерживает их состояние актуальным: находит их в Kubernetes сам или позволяет каждому экземпляру зарегистрироваться самостоятельно.
Master может показывать и обслуживать только те экземпляры, о которых знает. Узнать о них он может одним из двух способов: Master находит их сам (автообнаружение), или экземпляр сам сообщает о себе Master (саморегистрация).
Два способа обнаружения
┌─ Кластер Kubernetes ─────────────────────────────┐
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ orders-service │ │ billing-service │ │
│ └────────▲─────────┘ └─────────▲────────┘ │
│ │ │ │ ┌────────────────────┐
│ └────────────┬───────────┘ │ │ inventory-service │
│ │ │ │ (ВМ, Docker, ...) │
│ │ автообнаружение: │ └─────────┬──────────┘
│ │ Master находит поды │ │
│ │ и опрашивает их │ │ саморегистрация:
│ ┌───────┴───────┐ │ │ сервис регистрируется
│ │ Axelix Master │◀────────────────┼───────────────┘ один раз, затем шлёт heartbeat'ы
│ └───────────────┘ │
│ │
└──────────────────────────────────────────────────┘Каждый сервис на этих схемах — это Spring Boot-приложение, собранное с build-плагином Axelix и запущенное со стартером Axelix.
| Автообнаружение | Саморегистрация | |
|---|---|---|
| Кто инициирует вызов | Master обращается к сервису | Сервис обращается к Master |
| Где работает | Только в Kubernetes | Везде, откуда сервис может достучаться до Master |
| Как включить | axelix.master.discovery.auto.enabled в Master | axelix.sbs.discovery.self-registration в сервисе |
Если Master работает в том же кластере Kubernetes, что и ваши сервисы, автообнаружение не требует настройки на стороне сервиса. Саморегистрация закрывает все остальные случаи: обычные виртуальные машины, Docker Compose или сеть, которую Master не может просканировать.
Оба способа работают одновременно
Способ выбирается для каждого сервиса отдельно, а не для всего парка сервисов. Один Master может автоматически обнаруживать сервисы в своём кластере Kubernetes и одновременно принимать саморегистрацию от сервисов, работающих в других местах. Например, три приложения на виртуальных машинах могут регистрироваться сами, а все сервисы в кластере обнаруживаются автоматически.
Полное состояние один раз, затем небольшие обновления
Начиная с Axelix 1.3.0, оба способа устроены по одному принципу. Полное состояние экземпляра Master получает только
один раз: в запросе на регистрацию при саморегистрации или в первом вызове axelix-metadata при автообнаружении.
После этого экземпляр присылает только небольшие частые обновления: heartbeat при саморегистрации или ответ на
axelix-ping при автообнаружении.
У каждого обновления две задачи. Во-первых, оно сообщает Master, что экземпляр всё ещё жив. Во-вторых, оно несёт то немногое, что меняется со временем: состояние экземпляра, использование heap и статистику транзакций. Так новая проблемная транзакция появляется в Master без повторной регистрации. Схемы ниже показывают именно это поведение.
До 1.3.0 Master получал полное состояние каждый раз: при каждом сканировании в режиме автообнаружения и с каждым heartbeat при саморегистрации.
Автообнаружение
Axelix Master Kubernetes API orders-service
│ │ │
│ какие есть поды? │ │
│─────────────────────────────▶│ │
│◀─────────────────────────────│ │
│ │
│ первое сканирование: axelix-metadata │
│────────────────────────────────────────────────────────────▶│
│◀─────────────────────────────────────── полная регистрация ─│
│ │
│ каждое следующее сканирование │
│ (по умолчанию раз в минуту): axelix-ping │
│────────────────────────────────────────────────────────────▶│
│◀────────────────────────────── состояние, heap, транзакции ─│Первый вызов возвращает полную регистрацию: координаты сборки, версии и инсайты, которые собирает Axelix. После него экземпляр появляется в Master. Master подписывает свои вызовы собственным JWT, поэтому ключ подписи в Master и в сервисе должен совпадать.
Каждое сканирование заменяет весь список автоматически обнаруженных экземпляров. Поэтому под, о котором Kubernetes больше не сообщает, исчезает при следующем сканировании. Под, до которого Master не может достучаться, тоже выпадает из списка и возвращается при следующем сканировании, которое до него достучится.
У экземпляров со стартером старше 1.3.0 эндпоинта axelix-ping нет, поэтому у них Master при каждом сканировании
читает полный axelix-metadata.
Саморегистрация
inventory-service Axelix Master
│ │
│ при старте: регистрация (полное описание, │
│ actuator URL, имя экземпляра) │
│──────────────────────────────────────────────────▶│ экземпляр появляется
│ │
│ каждые 15 с: heartbeat (состояние, heap, │
│ транзакции) │
│──────────────────────────────────────────────────▶│
│──────────────────────────────────────────────────▶│
│ │
│ heartbeat после того, как Master │
│ потерял экземпляр │
│──────────────────────────────────────────────────▶│
│◀────────────────────────── неизвестный экземпляр ─│
│ повторная регистрация │
│──────────────────────────────────────────────────▶│
│ │
╳ сервис остановлен, heartbeat'ов нет │
│ удалён через 45 сСо стартером старше 1.3.0 каждый heartbeat — это полная регистрация.
Master может потерять экземпляр, если перезапустится с пустой базой данных или если сам удалил его после пропущенных heartbeat'ов. В обоих случаях следующий heartbeat заставляет сервис зарегистрироваться заново, поэтому все сервисы снова появляются в Master в пределах одного интервала heartbeat. Регистрация и heartbeat'ы подписаны общим ключом подписи JWT, и при несовпадении ключей Master их отклоняет.
Что нужно Master в обоих случаях
Обнаружение лишь сообщает Master, что экземпляр существует. Каждая страница UI, каждый MCP-инструмент и каждое действие (например, изменение уровня логирования) — это по-прежнему вызов от Master к сервису. Поэтому, каким бы способом сервис ни был обнаружен, Master должен иметь доступ к его actuator-эндпоинтам по HTTP. Если приложение защищает actuator-эндпоинты собственной системой безопасности, см. раздел Часто встречающиеся проблемы, чтобы пропустить вызовы Master.
См. также
Архитектура
В Axelix есть одно центральное приложение — Axelix Master, которое общается с каждым Spring Boot-сервисом, которым вы хотите управлять, через зависимость Axelix Starter на стороне сервиса. Веб-интерфейс и MCP-сервер живут внутри Master, поэтому одни и те же данные отдаются и браузеру, и AI-агенту из одного процесса.
Начало работы
Эта страница описывает рекомендуемый путь внедрения Axelix в организации: с каких окружений начинать, в каком порядке устанавливать компоненты и как безопасно дойти до production. Каждый шаг даёт конкретные команды и минимальную конфигурацию, а за полным справочником отсылает к подробной странице конфигурации соответствующего компонента.