Один оркестратор над двумя стеками: как мы построили слой абстракции над Apache Tomcat и WildFly
Программный комитет ещё не принял решения по этому докладу
Целевая аудитория
Тезисы
Заявка 1 Название: Один оркестратор над двумя стеками: как мы построили слой абстракции над Apache Tomcat и WildFly Секция: Архитектура и масштабируемость (приоритетная) Формат: доклад, 30 мин + 15 мин вопросы Тезисы: Проблема гетерогенного ландшафта. В типичном корпоративном Java-ландшафте рядом живут лёгкие веб- и API-сервисы на Tomcat/TomEE и тяжёлые транзакционные системы на WildFly/JBoss. Попытка развернуть всё на одном типе сервера приложений даёт либо избыточно тяжёлую инфраструктуру, либо урезает функциональность там, где она критична. Мы пошли другим путём: построили единый оркестратор, который вводит слой абстракции над обоими стеками и даёт одну точку входа для развёртывания, конфигурирования, мониторинга и безопасности. Четырёхслойная архитектура. Расскажем, как и почему мы жёстко разделили: интерфейсы (REST API и веб-консоль) → ядро оркестратора (состояние, планировщик, безопасность) → адаптеры под конкретные серверы приложений → инфраструктурный слой (отечественные ОС, кластеры VM/Kubernetes). Ядро знает только абстрактные операции «разверни», «перезапусти», «измени конфигурацию», «получи статус», а конкретные протоколы инкапсулированы в адаптерах. Паттерн Adapter в бою. В оркестраторе нет прямых вызовов к Tomcat Manager или WildFly CLI — ядро видит только абстрактный интерфейс ApplicationServerAdapter (deploy / undeploy / start / stop / updateConfig / getStatus). Адаптер для TomEE/Tomcat работает через HTTP(S)-запросы к Tomcat Manager, файловую систему и JMX; адаптер для WildFly — через WildFly CLI/HTTP API, JMX и механизмы управления доменом. Ядру неважно, как адаптер делает deploy — оно ждёт статус выполнения и обновляет модель. Асинхронный конвейер операций. Запрос от API превращается в задачу и попадает в очередь (брокер сообщений), планировщик разворачивает высокоуровневую операцию («обновить группу приложений») в набор подзадач по конкретным серверам, пул исполнителей забирает задачи и вызывает нужный адаптер. Что это дало: UI не блокируется, параллелизм ограничивается и приоритизируется, операции не теряются при временных сбоях — они остаются в очереди до успешного выполнения или явного отказа. Модель данных: «диспетчер сервера приложений». Все управляемые узлы описаны единой сущностью: адрес и порт, тип сервера (TomEE или WildFly), системный сервис, учётные записи администрирования, теги (среда, контур, критичность). Адаптер получает на вход абстрактный диспетчер и сам решает, каким протоколом с ним разговаривать. Состояние хранится в CMDB на реляционной СУБД с репликацией для отказоустойчивости. Сквозной сценарий end-to-end. Разберём на примере развёртывания новой версии приложения: CI-система вызывает один REST-метод POST /deploy → задача уходит в очередь → планировщик раскладывает её по конкретным серверам → адаптер TomEE загружает WAR через Tomcat Manager и переключает контекст, адаптер WildFly выполняет deploy через CLI/HTTP API → оба возвращают статусы, менеджер состояния обновляет CMDB. Снаружи — одна операция, под капотом — два разных стека и два разных протокола администрирования. Безопасность в архитектуре. REST API — единственная внешняя точка входа: TLS, аутентификация через IdP с JWT, авторизация по ролям (RBAC), шлюз безопасности логирует все административные действия. Это позволяет не раздавать прямой доступ к каждому серверу приложений и замкнуть контроль доступа в одном месте. Честные выводы. Что дал такой дизайн: управление смешанным ландшафтом как единой системой, выбор сервера приложений под задачу без усложнения эксплуатации, централизованный контроль конфигураций и развёртывания. Одна и та же архитектура работает on-premise и в Kubernetes (Helm-чарты) — меняется только инфраструктурный слой.
Бизнес-аналитик продуктовых решений для финансового сектора
Мой путь в IT начался с клиентского интерфейса — я видел продукт глазами пользователя, понимал его ожидания и болевые точки. Это дало мне фундаментальное понимание: любой технический проект имеет ценность только тогда, когда он решает реальную бизнес-задачу.
Затем я ушёл вглубь — в разработку и тестирование сложных бэкенд-систем. Став Lead QA, я отвечал за качество микросервисной архитектуры в финтехе и госсекторе. Я научился выстраивать процессы, видеть риски на этапе проектирования и понимать, как технические решения влияют на бизнес-показатели: отказоустойчивость, скорость транзакций, время вывода продукта на рынок.
Сегодня я совмещаю эту экспертизу в роли бизнес-аналитика продукта в Диасофт. Моя задача — не просто фиксировать требования, а проектировать решения, которые будут устойчивы к нагрузкам, безопасны и экономически оправданы.
Один из ключевых проектов — миграция с Oracle WebLogic на платформу Digital Q.AppServer для банка из топ-3 (подробности в статье). На этом проекте я видел всю цепочку: от бизнес-потребности заказчика до архитектурного решения и его реализации. Мы сократили время диагностики инцидентов с часа до минут, а главное — создали продукт, который стал повторяемой моделью для управления критической инфраструктурой ещё в пяти проектах.
Моя суперсила — говорить на одном языке с бизнесом, разработкой и эксплуатацией. Я знаю, как устроен продукт от кода до кошелька пользователя, и умею превращать сложные технические задачи в понятные бизнес-решения.
Видео
Другие доклады секции
Архитектура и масштабируемость
