Откуда берётся производительность Kora¶

12 сентября 2026

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

Фреймворк Kora интереснее рассматривать как бюджет производительности, а не как результат бенчмарка. Фреймворк намеренно переносит большой класс решений из пути запроса в компиляцию. Разрешение зависимостей, построение графа приложения, сгенерированные репозитории, JSON-кодеки, HTTP-адаптеры и соединение аспектов подготавливаются до запуска сервиса. Во время выполнения получившееся приложение гораздо ближе к обычному скомпилированному коду Java или Kotlin, вызывающему намеренно выбранные библиотеки через относительно тонкие адаптеры фреймворка. Важная идея не в том, что генерация времени компиляции каким-то образом делает каждую отдельную инструкцию быстрее. Идея в том, что работа, выполненная компилятором один раз, не должна повторно обнаруживаться, интерпретироваться, рефлексироваться или синтезироваться во время запуска и обработки запросов.

Полезная высокоуровневая модель:

Бюджет производительности
├── Время компиляции
│   ├── разрешение графа зависимостей
│   ├── генерация соединения
│   ├── JSON- и маппинги данных
│   ├── HTTP-маршруты и адаптеры
│   ├── репозитории
│   └── аспекты
│
├── Запуск
│   ├── предсобранный граф приложения
│   ├── нет обнаружения по всему classpath во время выполнения
│   └── параллельная инициализация компонентов
│
└── Время выполнения
    ├── обычные скомпилированные вызовы методов
    ├── сгенерированные тип-специфичные адаптеры
    ├── тонкие слои интеграции
    ├── меньше категорий работы фреймворка во время выполнения
    ├── выполнение запросов на виртуальных потоках
    └── выбранные высокопроизводительные библиотеки

Остальная часть статьи разбирает этот бюджет. Цель — не утверждать, что каждый сервис Kora всегда превзойдёт каждый сервис, построенный с другим фреймворком; дизайн приложения, поведение базы данных, сетевая задержка, логирование, аллокация объектов, конфигурация GC, качество SQL, формат сериализации и топология развёртывания могут легко доминировать над накладными расходами фреймворка. Более полезное утверждение уже: Kora намеренно сокращает, сколько общих механизмов фреймворка остаётся на критическом пути времени выполнения, и этот архитектурный выбор влияет на время запуска, поведение прогрева, пропускную способность, задержку, давление на память и операционную эффективность.

Производительность — это архитектура, а не режим бенчмарка¶

Документация Kora описывает производительность как следствие решений времени компиляции, сгенерированного кода, тонких абстракций и выбранных высокопроизводительных интеграций. Эта формулировка важна, потому что уводит обсуждение от особого «режима производительности». Нет отдельной философии, в которой обычное приложение Kora использует высокодинамичное время выполнения, а затем продакшн-пользователям приходится отключать возможности, убирать рефлексию, заменять серверы по умолчанию, переписывать репозитории или открывать коллекцию тюнинг-переключателей, прежде чем фреймворк станет эффективным. Те же механизмы, что используются для обычной разработки приложений, и есть механизмы, предназначенные для поддержания низких накладных расходов времени выполнения.

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

Kora атакует эту проблему меньше оптимизацией одного эффектного горячего места и больше устранением или упрощением многих маленьких кусков механизмов времени выполнения. Маршрут может быть представлен сгенерированным кодом, а не обнаруживаться через рефлексию при поступлении запроса. Метод репозитория может содержать сгенерированную типизированную привязку PreparedStatement, а не интерпретировать метаданные о параметрах метода при каждом вызове. JSON-кодек может быть сгенерирован под конкретную форму DTO, а не обнаруживать поля рефлексивно во время выполнения. Аннотация вроде аспекта отказоустойчивости или валидации может быть переведена в обычный сгенерированный класс во время компиляции, а не требовать обобщённого механизма динамических прокси вокруг каждого вызова.

Ни одно из этих решений по отдельности не гарантирует высокую пропускную способность. Вместе, однако, они меняют базовую стоимость фреймворка.

Первая часть бюджета оплачивается на этапе компиляции¶

Центральный архитектурный выбор в Kora — заставить компилятор выполнять работу, которую многие фреймворки внедрения зависимостей и с тяжёлыми аннотациями традиционно выполняют во время выполнения. Процессоры аннотаций Kora для Java и процессоры KSP для Kotlin читают объявления приложения, валидируют их и генерируют исходный код, который компилируется вместе с приложением. Документация явно утверждает, что граф зависимостей, аспекты, HTTP-обработчики, репозитории и другие компоненты становятся обычным скомпилированным кодом без рефлексии времени выполнения.

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

Это не значит, что работа времени компиляции бесплатна или универсально превосходна. Очень большие сгенерированные приложения могут увеличить время компиляции, а обработка символов Kotlin в целом дороже обработки аннотаций Java. Документация Kora даже отмечает, что обработка Kotlin обычно медленнее. Аргумент о производительности поэтому не «генерация не имеет стоимости». Он в том, что стоимость помещается в фазу, где её можно амортизировать за время жизни развёрнутого приложения.

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

Внедрение зависимостей времени компиляции убирает обнаружение графа во время выполнения¶

Внедрение зависимостей — самый фундаментальный пример этого дизайна. Контейнер Kora явно разделён на обязанности времени компиляции и времени выполнения. Во время компиляции Kora обнаруживает компоненты в объявленных областях приложения и подмодулей, разрешает зависимости, обнаруживает ошибки, валидирует отношения графа и генерирует обычный Java-код для запуска приложения. У времени выполнения всё ещё есть работа — объекты нужно инстанцировать, а методы жизненного цикла должны выполняться, — но ему не нужно реконструировать модель зависимостей приложения с нуля.

В высокодинамичном контейнере запуск может включать сканирование classpath, обнаружение аннотаций, рефлексивную проверку конструкторов, построение определений бинов, подготовку прокси, оценку условий и разрешение зависимостей. Разные фреймворки выполняют разные подмножества этой работы, и современные реализации могут агрессивно её оптимизировать, поэтому было бы вводящим в заблуждение утверждать, что «DI времени выполнения всегда медленный». Архитектурное различие тем не менее реально: Kora уже знает граф, потому что построила и проверила его во время компиляции.

Сгенерированный граф также меняет форму установившегося кода приложения. Как только UserService получает UserRepository, логика приложения вызывает объект, который уже держит. Нет причины, чтобы каждый обычный доступ к зависимости выполнял поиск по имени в контейнере или динамически разрешал компонент. Граф объектов приложения ведёт себя как граф обычных объектов, потому что фактически именно это и конструирует сгенерированный контейнер.

У этого есть ещё один косвенный эффект производительности: Kora включает только компоненты, которые являются корнями или фактически требуются другими компонентами, а внешние модули подключаются явно, а не обнаруживаются автоматически из каждой зависимости на classpath. Выгода — не просто философская явность. Избегание ненужных узлов графа означает меньше объектов для инстанцирования, меньше операций жизненного цикла для выполнения и меньше состояния фреймворка для поддержания в живом виде.

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

Производительность запуска приходит от знания графа заранее¶

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

Документация контейнера Kora добавляет ещё одну важную деталь: компоненты инициализируются параллельно настолько, насколько позволяет граф зависимостей, причём инициализация жизненного цикла выполняется на виртуальных потоках. Это возможно, потому что граф уже известен. Если компоненты A, B и C независимы, а компонент D зависит от всех трёх, контейнеру не нужно инициализировать их искусственно последовательно:

A ─┐
B ─┼──> D
C ─┘

Сам граф зависимостей предоставляет ограничения планирования. Независимые узлы могут запускаться вместе, тогда как зависимые узлы ждут свои предпосылки. Время запуска поэтому стремится к критическому пути графа, а не к сумме длительности инициализации каждого компонента.

Это не заставляет медленную инициализацию исчезнуть. Если пулу базы данных нужно несколько секунд на установление соединений, или компонент выполняет дорогую синхронную работу во время init(), Kora не может сделать внешнюю систему быстрее. Что граф позволяет фреймворку избежать — так это ненужную сериализацию между независимыми операциями запуска.

Та же архитектура помогает объяснить, почему у Kora может быть относительно небольшой след прогрева. Время выполнения, которое выполняет меньше обнаружения фреймворка после запуска процесса, имеет меньше кода инициализации для выполнения и меньше метаданных для заполнения до прибытия полезного трафика. JIT-компиляция и специфичный для приложения прогрев всё ещё существуют — Kora всё ещё JVM-фреймворк, — но фреймворк может избежать добавления большой динамической фазы загрузки поверх собственного поведения запуска JVM.

Сгенерированное соединение превращает решения фреймворка в обычный код¶

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

Представьте, что фреймворк знает на этапе компиляции, что контроллеру нужен сервис, сервису нужен репозиторий, а репозиторию нужен JDBC-исполнитель. Kora может сгенерировать код, который конструирует именно эти отношения. Затем JVM видит обычный байткод, получившийся из обычного исходного кода. Это даёт JIT-компилятору знакомый материал для оптимизации: конкретные сайты вызовов, известные классы, обычный поток управления и обычные ссылки на поля.

Это не следует преувеличивать до гарантии, что каждый вызов будет инлайниться или каждая абстракция исчезнет. Оптимизация JVM зависит от профилирования, формы сайта вызова, размера кода, полиморфизма и многих других факторов. Но сгенерированный обычный код в целом дружелюбен к JIT, потому что фреймворк намеренно не спрятал путь выполнения за непрозрачными рефлексивными операциями или сгенерированным во время выполнения обобщённым диспетчером.

Преимущество производительности поэтому столько же в форме, сколько в сыром количестве инструкций. Kora старается представить JVM пути выполнения, напоминающие написанную вручную инфраструктуру приложения. Компилятор выполняет архитектурные рассуждения; время выполнения исполняет результат.

Маршруты подготавливаются до прибытия запросов¶

HTTP-маршрутизация — ещё одно место, где фреймворки могут либо сохранять метаданные для интерпретации во время выполнения, либо генерировать код обработки запросов заранее. HTTP-инфраструктура Kora основана на явных объявлениях контроллеров и маршрутов, со сгенерированными модулями контроллеров и адаптерами, соединяющими параметры запросов, маппинги, перехватчики и методы контроллеров.

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

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

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

Маппинг — большая часть реальной стоимости бэкенда¶

Синтетические бенчмарки простого текста полезны для понимания нижней границы накладных расходов фреймворка, но реальные сервисы тратят значительное время на преобразование данных между представлениями. JSON-байты становятся DTO, строки базы данных становятся доменными объектами, аргументы методов становятся SQL-параметрами, текст конфигурации становится типизированными настройками, а объекты приложения становятся сетевыми полезными нагрузками. Маппинг поэтому — существенная часть бюджета производительности фреймворка.

Kora широко использует генерацию времени компиляции в этой области. Её JSON-модуль может генерировать реализации JsonReader<T> и JsonWriter<T> для конкретных типов. Эти сгенерированные кодеки становятся обычными компонентами графа приложения. Стратегии именования полей, правила nullability, поведение включения, обработка enum и пользовательские мапперы могут разрешаться в сгенерированный тип-специфичный код, а не требовать обобщённого рефлексивного маппера объектов для каждой операции.

Выгода не в том, что разбор самого JSON становится бесплатным; разбор всё равно должен проверять каждый релевантный токен, а запись всё равно должна кодировать вывод. Экономия приходит от сокращения объёма динамического обнаружения типов и обобщённой обработки свойств вокруг этого разбора. Когда кодек уже знает форму DTO, он может выполнять логику маппинга напрямую.

Kora также позволяет маппинг на основе Jackson, когда он нужен приложению, что — важное напоминание, что дизайн производительности не должен становиться догмой. Сгенерированные кодеки — это инструмент, а не требование, чтобы каждая интеграция отказалась от экосистемы. Фреймворк позволяет сгенерированному и Jackson-маппингу сосуществовать, позволяя приложениям выбирать правильный компромисс для конкретной границы.

JDBC-репозитории убирают сантехнику запросов из горячего пути¶

Доступ к базе данных демонстрирует тот же принцип ещё конкретнее. JDBC-репозиторий Kora описывает запрос декларативно, но реализация генерируется. Документация утверждает, что привязка параметров выдаётся как типизированные JDBC-вызовы. Параметр String name, например, может стать сгенерированным кодом, эквивалентным statement.setString(index, name).

Это важно, потому что абстракция репозитория может быть высокоуровневой без требования высокоуровневого интерпретатора времени выполнения. Разработчик пишет:

Java Kotlin

@Repository
public interface UserRepository extends JdbcRepository {

    @Query("SELECT id, name FROM users WHERE id = :id")
    User findById(long id);
}

@Repository
interface UserRepository : JdbcRepository {

    @Query("SELECT id, name FROM users WHERE id = :id")
    fun findById(id: Long): User
}

но времени выполнения не нужно разбирать метаданные метода Java при каждом вызове, чтобы определить, что id должен быть привязан к конкретной позиции оператора. Это отношение было известно во время компиляции и может быть закодировано в сгенерированной реализации.

Опять же, доминирующая стоимость реального запроса к базе данных может быть самой базой данных. Круговой сетевой путь в 3 миллисекунды и выполнение запроса затмят десятки наносекунд накладных расходов вызова фреймворка. Тем не менее эффективность фреймворка всё ещё важна при высокой пропускной способности, на очень быстрых локальных базах данных и в бюджете CPU вокруг каждого запроса. Что ещё важнее, тот же дизайн улучшает предсказуемость: меньше скрытых механизмов маппинга, которые могут неожиданно появиться в профилях.

Слой репозитория Kora поэтому — хороший пример «тонкой абстракции». Он даёт разработчикам приложения краткий контракт репозитория, всё ещё производя код, близкий к нижележащей операции JDBC, вместо построения совершенно отдельного рантайма персистентности с собственной моделью выполнения.

AOP времени компиляции избегает обобщённого слоя прокси времени выполнения¶

Аннотации для валидации, кеширования, отказоустойчивости, транзакций, планирования, безопасности и логирования удобны, но фреймворки, ориентированные на аннотации, часто платят за это удобство введением проксирования времени выполнения. Подход Kora другой: аспекты обрабатываются, а исходный код генерируется на этапе компиляции. Главная документация явно описывает продакшн-аспекты как сгенерированные без прокси времени выполнения.

Это не значит, что у аспекта нулевая стоимость времени выполнения. Автоматический выключатель всё ещё должен проверять состояние. Повтор всё ещё должен выполнять логику повтора. Метрики всё ещё должны записывать измерения. Валидация всё ещё должна проверять данные. Транзакция всё ещё нуждается в поведении begin/commit/rollback. Что означает «бесплатные аспекты» архитектурно — так это то, что механизм фреймворка, используемый для прикрепления поведения, не нуждается в дополнительной системе динамических прокси, чтобы решать, как перехватить вызов во время выполнения.

Это различие важно. Предположим, автоматический выключатель защищает метод. Алгоритм выключателя неизбежно добавляет ветви и доступ к состоянию вокруг этого вызова. Kora не может их устранить, потому что они и есть возможность. Что она может устранить — так это избегаемую работу фреймворка, требуемую лишь для обнаружения, что у метода есть выключатель, и маршрутизации вызова через обобщённый рефлексивный перехватчик.

Это повторяющийся принцип производительности Kora: оптимизируйте механизм, а не убирайте семантику. Наблюдаемость, отказоустойчивость, транзакции и валидация — продакшн-требования, и их отключение ради победы в бенчмарке не продемонстрировало бы полезную производительность фреймворка. Цель — реализовать эти возможности с как можно меньшими случайными накладными расходами.

Прямые вызовы методов важнее, чем звучат¶

«Прямые вызовы методов» могут звучать слишком тривиально, чтобы заслуживать раздела. На JVM, однако, архитектура влияет на то, что JIT-компилятор может видеть и оптимизировать. Обычный Java-вызов через стабильный, часто мономорфный сайт вызова — это паттерн, который HotSpot десятилетиями оптимизировал. Он может его профилировать, девиртуализировать во многих ситуациях, инлайнить, когда это выгодно, и оптимизировать код через получившуюся границу.

Фреймворк, который выражает большую часть своего поведения времени выполнения как обычный сгенерированный Java или Kotlin, поэтому выигрывает от модели оптимизации, которую JVM уже понимает. Ему не нужен специальный движок выполнения для кода приложения.

Вот также почему тонкие абстракции и генерация кода усиливают друг друга. Сгенерированный адаптер контроллера вызывает контроллер. Сгенерированный репозиторий вызывает API JDBC. Сгенерированный JSON-писатель вызывает операции парсера или генератора для известных полей. Сгенерированный подкласс AOP вызывает исходный метод плюс требуемую логику аспекта. Каждый слой может оставаться относительно маленьким и явным.

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

Тонкие абстракции сокращают семантическое и временное расстояние¶

Kora намеренно остаётся близко к JDBC, Kafka, gRPC, HTTP и другим нижележащим технологиям. Это обычно представляется как преимущество прозрачности и поддерживаемости, но у этого есть и измерение производительности. Каждая абстракция фреймворка потенциально вводит лишние объекты, слои преобразования, конечные автоматы, очереди, планировщики или семантическую трансляцию. Ни одна из этих вещей не автоматически плоха; некоторые абстракции дают огромную ценность. Проблема появляется, когда фреймворк создаёт параллельный мир, хотя нижележащая библиотека уже раскрывает семантику, нужную приложению.

Тонкая абстракция старается добавить только недостающую эргономику: конфигурацию, сгенерированный клей, управление жизненным циклом, наблюдаемость и типобезопасные декларативные API. Она избегает перереализации всей технологии за специфичным для фреймворка рантаймом, если это не решает конкретную проблему.

Этот подход сокращает возможности случайных накладных расходов. JDBC-вызов остаётся узнаваемо JDBC. Интеграция gRPC остаётся построенной вокруг gRPC. HTTP-сервер под модулем сервера Kora всё ещё Undertow. Инженеры поэтому могут рассуждать о производительности, используя знания о нижележащей технологии, вместо того чтобы сначала обратно-инженерить большую модель выполнения фреймворка.

Тонкость также помогает отладке производительности. Когда CPU-профиль показывает время в драйвере JDBC, JSON-парсере, Undertow или бизнес-логике, результат легче интерпретировать, чем профиль, в котором доминируют внутренние адаптеры фреймворка, чьё отношение к нижележащей операции неясно. Производительность — это не только быть быстрым; это также быть диагностируемым, когда что-то становится медленным.

Выбранные библиотеки — часть истории производительности¶

Генерация времени компиляции не может компенсировать плохой транспорт или клиент базы данных. Kora поэтому рассматривает выбор библиотек как часть дизайна фреймворка. Её реализация HTTP-сервера основана на Undertow, лёгком асинхронном NIO-сервере, тогда как Kora диспетчеризует обработку запросов на виртуальные потоки, а не на ограниченный блокирующий пул воркеров. Документация явно отмечает, что нет переключателей blockingThreads или virtualThreadsEnabled, потому что обработка запросов использует эту модель напрямую.

Это иллюстрирует полезное разделение обязанностей. Undertow обрабатывает эффективный сетевой I/O. Виртуальные потоки дают коду приложения простую синхронную модель для блокирующих операций. Kora предоставляет сгенерированную маршрутизацию, жизненный цикл, телеметрию и интеграцию между этими частями. Производительность приходит от композиции специализированных механизмов, а не от требования, чтобы один рантайм фреймворка изобрёл их все заново.

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

Всё ещё нет универсальной «самой быстрой библиотеки» для каждой нагрузки. Конфигурация TLS, поведение HTTP/2, размер полезной нагрузки, версии драйверов базы данных, батчинг Kafka, буферы сокетов, GC и поведение ядра — всё это может изменить результат. Релевантный принцип дизайна Kora в том, что эффективный выбор интеграции рассматривается как ответственность фреймворка, а не оставляется полностью каждой команде приложения для переоткрытия.

Виртуальные потоки меняют накладные расходы конкурентности, а не пределы ресурсов¶

Kora 2 выполняет код приложения синхронно на виртуальных потоках. Контроллеры, клиенты, репозитории и запланированные задачи используют обычные блокирующие сигнатуры, а обработка HTTP-запросов диспетчеризуется на виртуальные потоки. Это центрально для производительности времени выполнения, потому что позволяет Kora сохранять простой код thread-per-operation без требования большого пула платформенных потоков для каждого блокирующего запроса.

Ключевое свойство производительности виртуальных потоков не в том, что они делают CPU-вычисления быстрее. Они делают большие количества блокирующих операций гораздо дешевле в представлении. Когда виртуальный поток ждёт в поддерживаемом блокирующем I/O, его поток-носитель платформы может выполнять другие виртуальные потоки вместо того, чтобы оставаться занятым на время ожидания.

Это позволяет Kora избежать архитектурного компромисса, который доминировал в дизайне JVM-бэкендов годами. Фреймворку больше не нужно выбирать между простым блокирующим кодом приложения с ограниченным пулом платформенных потоков и асинхронной/реактивной моделью приложения, предназначенной для того, чтобы эти платформенные потоки не блокировались. Виртуальные потоки позволяют Kora сохранять прямые синхронные API, всё ещё поддерживая высокую I/O-конкурентность.

Они, однако, не создают неограниченную ёмкость. У сервиса может быть сотни тысяч виртуальных потоков и всё равно только 50 JDBC-соединений, конечное число ядер CPU, ограниченная квота удалённого сервиса и ограниченная пропускная способность сети. Если код приложения агрессивно делает fan-out, виртуальные потоки могут фактически облегчить достижение этих нижестоящих пределов, потому что дефицит потоков больше не действует как случайное противодавление.

Модель виртуальных потоков Kora поэтому следует понимать как удаление одного узкого места — стоимости ожидающих платформенных потоков, — а не как удаление самого управления конкурентностью.

«Минимальные аллокации» нуждаются в точном определении¶

Заманчиво резюмировать производительность времени выполнения Kora как «минимальные аллокации», но эта фраза требует осторожности. Обычный запрос неизбежно аллоцирует во многих обстоятельствах. Состояние HTTP-запроса существует. JSON может создавать DTO, строки, коллекции и байтовые буферы. Драйверы базы данных аллоцируют объекты протокола и результата. OpenTelemetry может создавать состояние наблюдения. Бизнес-логика приложения конструирует собственные данные. Сериализация ответа может аллоцировать или использовать пулированные буферы в зависимости от пути.

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

Действительно ли это материально снижает уровень аллокаций в конкретном эндпоинте, всё ещё нужно измерять. Поведение аллокаций сильно зависит от нагрузки, и одна небрежная бизнес-операция может аллоцировать больше, чем весь путь фреймворка. Большие JSON-документы, временные коллекции, обработка regex, аргументы логирования, графы сущностей ORM или копирование буферов могут легко доминировать над давлением GC.

Важный инженерный принцип поэтому не «Kora аллоцирует почти ничего». Он в том, что «Kora старается не аллоцировать механизмы фреймворка для решений, которые компилятор уже знает».

Меньше абстракций времени выполнения может улучшить прогрев JIT¶

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

Это не убирает прогрев JIT. Сгенерированные классы Kora, Undertow, драйверы JDBC, JSON-код, бизнес-логика и каждый другой горячий метод всё ещё нуждаются в обычной оптимизации JVM. Утверждение должно быть скромным: меньше динамических слоёв фреймворка в целом означает меньше путей выполнения фреймворка, конкурирующих за внимание профилирования и компиляции.

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

Бюджет производительности: что Kora убирает и что не может убрать¶

Полезный способ рассуждать о Kora — отделить избегаемые накладные расходы фреймворка от неизбежной работы приложения.

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

Kora не может устранить стоимость разбора HTTP-сообщения, копирования байтов, когда этого требует протокол, разбора JSON-токенов, конструирования объектов приложения, выполнения SQL, ожидания удалённого сервера, шифрования TLS-трафика, записи телеметрии, выполнения алгоритма автоматического выключателя, вычисления бизнес-правил или сборки мусора для объектов, которые приложение действительно создаёт. Это внутренние издержки нагрузки или возможностей.

Эта граница важна, потому что предотвращает нереалистичные ожидания. Если эндпоинт тратит 85% своего времени на ожидание PostgreSQL, замена рефлексии уровня фреймворка сгенерированным кодом не может сделать запрос к базе данных в десять раз быстрее. Что это может сделать — так это сократить CPU и задержку, потребляемые оставшимися 15%, снизить накладные расходы на запрос при высокой конкурентности, улучшить поведение запуска и памяти и избежать добавления ещё одного большого источника изменчивости вокруг доминирующей зависимости.

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

Путь запроса через бюджет производительности¶

Рассмотрим репрезентативный эндпоинт Kora, который получает JSON, валидирует его, вызывает сервис, защищённый автоматическим выключателем, выполняет запрос JDBC-репозитория и возвращает JSON. Путь времени выполнения содержит реальную работу на каждом слое, но большая часть конфигурации фреймворка уже преобразована в код:

HTTP-байты
   ↓
сетевой слой Undertow
   ↓
сгенерированный / предсоединённый адаптер маршрута
   ↓
сгенерированный маппинг запроса
   ↓
метод контроллера
   ↓
прикреплённая на этапе компиляции логика валидации / отказоустойчивости
   ↓
метод сервиса
   ↓
сгенерированный JDBC-репозиторий
   ↓
типизированная привязка PreparedStatement
   ↓
база данных
   ↓
сгенерированный маппинг результата
   ↓
сервис / контроллер
   ↓
сгенерированный JSON-писатель
   ↓
HTTP-ответ

Смысл этой диаграммы не в том, что каждая стрелка имеет нулевые накладные расходы. Смысл в том, что фреймворку редко нужно останавливаться и спрашивать систему метаданных времени выполнения: «Что означает эта аннотация?», «Какой конструктор мне вызвать?», «Какому свойству соответствует это JSON-поле?», «Какой параметр метода соответствует этому SQL-плейсхолдеру?» или «Какой перехватчик должен существовать для этого метода?» На эти вопросы в значительной степени ответили раньше.

Высокоуровневая декларативная модель программирования и низконакладное время выполнения поэтому не противоположности. Генерация кода — мост между ними.

Почему результаты бенчмарков могут отражать архитектуру¶

Главная страница Kora в настоящее время цитирует внешний снимок TechEmpower «Single query», в котором JDBC Repository Kora среди показанных JVM-записей с самой высокой пропускной способностью. Это полезное свидетельство, что архитектура может транслироваться в высокую пропускную способность под контролируемой нагрузкой. Это не доказательство, что каждое продакшн-приложение Kora будет иметь то же относительное преимущество.

Тест Single Query намеренно узок. Он подчёркивает обработку HTTP, один запрос к базе данных, сериализацию и накладные расходы фреймворка. Он не воспроизводит продакшн-топологию с базами данных на сетевом расстоянии, сложной авторизацией, несколькими удалёнными зависимостями, большими полезными нагрузками, логированием, кешами, публикацией событий или существенными бизнес-вычислениями. В реальном приложении эти издержки могут затмить разницу между рантаймами фреймворков.

Это не делает бенчмарк нерелевантным. Узкий бенчмарк полезен именно потому, что раскрывает пол фреймворка. Если два приложения выполняют почти одну и ту же бизнес-операцию и одно тратит материально больше CPU внутри механизмов фреймворка, флот микросервисов в конце концов заплатит за эту разницу. Ошибка — использовать бенчмарк как весь аргумент о производительности вместо трактовки его как одного измерения, согласующегося с архитектурой.

Самая сильная история производительности Kora поэтому не «посмотрите на это число запросов в секунду». Она в том, чтобы «посмотрите, какая работа существует на этапе компиляции, какая остаётся при запуске, какая выполняется на запрос, а затем используйте бенчмарки для проверки следствий».

Пропускная способность — лишь один выход эффективности¶

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

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

Вот почему дизайн производительности Kora тесно связан с её облачно-ориентированным позиционированием. Цель оптимизации — не просто «выиграть бенчмарк на одной машине». Это избежать накладных расходов фреймворка, которые нужно провижинить, запускать, прогревать и оплачивать на каждом экземпляре.

Работа времени компиляции имеет стоимость, и эта стоимость должна быть видимой¶

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

Это может иметь значение в больших монорепозиториях или во время быстрой локальной итерации. Kora смягчает часть проблемы структурно с помощью подмодулей: @KoraSubmodule позволяет обрабатывать области приложения независимо, и документация отмечает, что изменения в одном модуле проекта тогда не заставляют процессоры анализировать всё приложение заново. Инкрементальная компиляция Gradle и кеширование сборки также становятся важными.

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

Инженерия производительности всегда о том, где оплачивается стоимость, а не о том, существует ли стоимость.

Тонкое время выполнения не означает лишённое возможностей время выполнения¶

Распространённый способ сделать бенчмарк быстрым — убрать продакшн-возможности. Отключить трассировку, пропустить метрики, обойти валидацию, избежать отказоустойчивости, использовать написанный вручную маршрутизатор и сравнить получившийся минимальный цикл с полным стеком приложения. Это мало говорит о продакшн-инженерии.

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

Это различие также помогает командам правильно рассуждать об оптимизации. Если трассировка вызывает измеримую стоимость, ответ — не автоматически винить внедрение зависимостей или маршрутизацию. Профилирование может показать, находится ли время в создании спанов, давлении экспортёра, JSON-сериализации, логировании, вызовах базы данных или логике приложения. Тонкие пути фреймворка облегчают эту атрибуцию.

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

Предсказуемость производительности может значить больше, чем пиковые числа¶

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

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

Было бы неверно утверждать, что Kora устраняет выбросы задержки. Базы данных заикаются, сети ретранслируют, GC делает паузы, нижестоящие сервисы деградируют, CPU насыщается, а код приложения всё ещё имеет холодные ветви. Что Kora может сделать — так это избежать того, чтобы динамизм фреймворка стал ещё одним крупным источником непредсказуемости.

Это значимая форма производительности.

Куда перемещается реальное узкое место¶

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

Сервис Kora, использующий JDBC, может быть ограничен пулом соединений базы данных задолго до того, как виртуальные потоки станут проблемой. JSON-тяжёлый эндпоинт может быть ограничен сериализацией и аллокацией. Агрегатор gRPC может быть ограничен удалённой задержкой. Криптографический эндпоинт может быть CPU-ограничен. Kafka-продюсер может доминироваться батчингом и подтверждениями брокера. В этот момент выжимание ещё одного малого процента из DI или диспетчеризации маршрутов материально не изменит сервис.

Работа фреймворка — уйти с дороги настолько, чтобы профили указывали на эти подлинные издержки. Работа приложения тогда — масштабировать пулы, выбирать планы запросов, проектировать кеширование, контролировать конкурентность, сокращать полезные нагрузки, эффективно батчить и выбирать подходящие структуры данных.

Вот также почему синхронную модель виртуальных потоков Kora не следует интерпретировать как «производительность без инженерии». Она убирает один класс сложности. Планирование ёмкости, закон Литтла, противодавление, масштабирование пулов, анализ хвостовой задержки и защита нижестоящих систем всё ещё применимы.

Как измерить, помогает ли архитектура Kora вашему сервису¶

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

Измеряйте запуск отдельно от установившейся пропускной способности. Измеряйте p50, p95, p99 и максимальную задержку, а не только среднюю. Записывайте потребление CPU для фиксированного уровня пропускной способности вместо тестирования только максимальных запросов в секунду. Отслеживайте уровень аллокаций и поведение пауз GC. Наблюдайте RSS и занятость кучи после запуска и под нагрузкой. Проверяйте насыщение пула базы данных, поведение пула удалённых соединений и здоровье потоков-носителей. Запускайте с включённой продакшн-телеметрией, потому что это система, которой вы будете фактически управлять.

Профили особенно ценны. Если дизайн Kora работает как задумано, большая часть CPU должна быть объяснима конкретной технологией и работой приложения: Undertow, обработкой JSON, драйвером JDBC, криптографией, телеметрией и бизнес-логикой. Сгенерированные классы Kora могут появляться, но они должны в целом представлять полезный клей, а не большой движок интерпретации времени выполнения.

Хороший бенчмарк фреймворка поэтому отвечает на два вопроса. Во-первых, «Сколько работы может сделать этот стек?» Во-вторых, и что важнее, «Куда ушли CPU, аллокации и задержка?» Второй вопрос объясняет, обобщится ли результат на другую нагрузку.

Бюджет производительности в одном взгляде¶

Полную модель производительности Kora можно резюмировать, не сводя её к лозунгу.

На этапе компиляции фреймворк разрешает граф приложения, валидирует зависимости, генерирует соединение, строит тип-специфичные маппинги, генерирует репозитории и HTTP-адаптеры и применяет аспекты через сгенерированный исходный код. Время сборки становится местом, где фреймворк рассуждает о структуре приложения.

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

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

На границе инфраструктуры Kora всё ещё зависит от реальных библиотек и реальных ресурсов. Undertow должен обрабатывать сокеты, PostgreSQL должен выполнять SQL, пул JDBC должен предоставлять соединения, OpenTelemetry должен записывать наблюдения, а JVM должна аллоцировать и собирать объекты приложения. Дизайн производительности Kora не отрицает эти издержки; он старается избегать добавления ненужных издержек фреймворка вокруг них.

Это гораздо более полезное объяснение, чем «Kora быстра, потому что у неё нет рефлексии». Рефлексия — лишь один видимый симптом более крупного архитектурного решения.

Заключение¶

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

Результат — не нулевые накладные расходы, нулевые аллокации или автоматическая производительность независимо от дизайна приложения. Сервис Kora всё ещё может быть медленным из-за плохого SQL, чрезмерной аллокации, огромных полезных нагрузок, неограниченного fan-out, насыщенных пулов соединений, дорогой трассировки, блокирующего нативного кода или неэффективных бизнес-алгоритмов. Никакая архитектура фреймворка не может убрать эти издержки.

Что Kora пытается убрать — так это другую категорию издержек: работу фреймворка, которой в первую очередь не нужно происходить во время выполнения.

Это различие — ключ к пониманию её модели производительности. Вместо того чтобы спрашивать только, сколько запросов в секунду произвёл бенчмарк, проверьте бюджет:

Время компиляции
├── разрешить
├── валидировать
├── сгенерировать
└── скомпилировать

Запуск
├── инстанцировать известный граф
└── инициализировать независимые узлы параллельно

Время выполнения
├── получить запрос
├── выполнить сгенерированные адаптеры
├── вызвать бизнес-код напрямую
├── вызвать тонкие интеграции
└── платить только за фактически используемые возможности и реальную работу

Бенчмарк — это измерение в конце этой цепочки. Архитектура — объяснение.