Вопрос или проблема
В наше время REST является стандартным API для всех видов сервисов.
Существует множество технических решений, например, вы можете запустить сервер Tomcat и разрабатывать для него сервисы, используя фреймворк Spring. Это может быть трудоемким и ресурсоемким процессом (если запускать Tomcat каждый раз, когда он нужен).
Интересно, существует ли решение, при котором вы помещаете свои файлы .jar, .gem, .so… в каталог и добавляете настройки в конфигурационный файл, где сопоставляете порт с данным бинарником. Он слушает HTTP-запросы и перенаправляет их.
Цель состоит в разработке REST-сервисов путем реализации только обратных вызовов для любых необходимых URL/глаголов. Я не хочу заморачиваться с техническими слоями: механизмами доставки и управления жизненным циклом сервисов.
Я ищу нечто вроде xinetd для REST-сервисов и, более того, хочу, чтобы REST-сервисы запускались по требованию. Или только процесс “xinetd”-подобного сервиса, который вызывает в новых потоках соответствующие обратные вызовы в установленных бинарных файлах.
Ответ или решение
Концепция, описанная в вашем вопросе, имеет несколько аналогий с подходом, который использовали Unix-подобные системы с демоноподобием, таким как xinetd. Xinetd (Extended Internet Service Daemon) — это суперсервер, который управляет различными интернет-демонами и запускает конкретные программы по запросу. Он заменил inetd и предоставлял более продвинутую функциональность, например, доступ на основе времени, логирование, ограничения на количество процессов и т.д.
Теория
Касаемо REST-сервисов, идея заключается в создании аналогичного механизма, который позволял бы обрабатывать HTTP-запросы через динамически запускаемые службы на основе заранее определенной конфигурации. Это позволяет минимизировать нагрузку на систему, разворачивая только те сервисы, которые в данный момент необходимы. Такой подход особенно привлекателен для систем с ограниченными ресурсами или с требованием к высокой гибкости и управляемости.
Пример
Представьте себе механизмы такие как AWS Lambda или Google Cloud Functions, которые предоставляют возможности "запуска на требование". Однако в вашем случае речь идет о более низкоуровневой реализации, которая бы не полагалась на облачную инфраструктуру. Системы "Function-as-a-Service" в некотором роде уже применяют подобные концепции, запускаюя конкретные функции для обработки веб-запросов без необходимости держать постоянно работающий сервер, что может быть накладно.
Применение
Для реализации подобного подхода, можно обратить внимание на несколько инструментов и технологий, которые придется комбинировать:
-
Конфигурационный Файл: Так же, как и в xinetd, конфигурация будет ключевой составляющей. Вы бы определяли URL-энпойнты и соответствовали их конкретным сервисам, указывая путь к бинарным файлам, которые должны запускаться при получении запроса.
-
HTTP Диспетчер: Вам понадобится интерпретатор HTTP-запросов. Легковесный HTTP-сервер (например, на основе Python как Flask, или Node.js как Express) мог бы играть роль этого уровня, интерпретируя запросы и вызывая соответствующие обработчики на низком уровне.
-
Динамическая Загрузка и Запуск: Вам понадобится механизм, позволяющий загрузить и выполнить бинарный файл (.jar, .so и т.п.) в зависимости от конфигурации. Для выполнения Java-архивов вы могли бы использовать JVM с динамическим запуском java-классов. Для .so файлов, возможно, придется обращаться к системным вызовам вроде
dlopenв Unix. -
Параллелизм: Для обеспечения конкурентности и скорости обработки, вызовы этих бинарных файлов должны быть обёрнуты в потоки или процессы, чтобы не блокировать основной серверный цикл.
-
Управление Ресурсами: Чтобы избежать истощения ресурсов, вы могли бы добавлять ограничения на количество одновременно работающих процессов или активных соединений.
-
Мониторинг и Логирование: Как и в xinetd, встроенный механизм логирования и мониторинга позволит отслеживать производительность, выявлять потенциальные ошибки и хранить статистику использования.
Потенциальные Инструменты
-
gRPC: Хотя это не прямой ответ на данное требование, но gRPC можно использовать для создания высокопроизводительных сервисов с поддержкой множественных языков, тем самым инструментируя некоторые принципы "запуск при запросе".
-
FastCGI/SCGI: Это старые протоколы, которые использовались для взаимодействия веб-серверов с внешними приложениями. Они менее популярны в наши дни, но могли бы служить основой для запуск-сервисов по запросу.
-
системные контейнеры: Использовать Docker-контейнеры или по-другому как "микросервисы в контейнерах", чтобы загружать и выгружать их на запрос, обезопасив основной серверный процесс.
Заключение
Таким образом, подход "xinetd наподобие демона для REST-сервисов" может быть эффективным решением для оптимизации использования ресурсов и упрощения управления REST-серверами. Он может быть реализован на базе существующих технологий, однако потребует значительной настраиваемости и знаний о системном программировании, многопоточности и сетевой архитектуре.