Помогите решить архитектурный вопрос: если на сервере предполагается несколько сервисов (приложений) которые должны обслуживаться отдельным http сервером, практичнее будет внутри этих сервисов поднимать http сервер, или снаружи приложения  поднимать (и менеджерить) http сервера,  а на них как то сажать приложение (передавать хэндлер приложения)?

из любопытства: а какой юзкейс требует поднятия нескольких веб серверов и именно на одной машине? Клиентские запросы получается всё равно какую-то единую точку входа будут проходить, которая должна решать вопрос роутинга. Или этот "балансировщик" - это аут оф скоуп вопроса?
мне кажется немного контекста и подробностей не хватает

народ, нужна либа по курсу валют и криптовалют

есть варианты? или все ручками?

если http сервер это просто просто точка входа (фасад) дальше нужно понимать его ответсвенность  - если просто проксировать на другие приложения в синхронном формате это одно. это обычный reverse proxy

если нужно получить запрос и дальше коммуникация между сервисами идет в асинхронном режиме (обмен сообщениями через какой-то брокер очередей)  по какому-то определённому флову например  - это другая задача.

зачем либа? юзай какой нибудь api, coinmarketcap например

Я пишу свой сервер приложений, можно сказать фреймворк, типа стартер кита как у Тимура, только разумеется в пределе моих знаний. Пишу для интереса и для обучения, потому и вопросы такие. Http серверов несколько с точки зрения разделения единой точки отказа, так как эти два сервиса оба работают в вебе но прямой связи между ними нет:  1 сервер будет сервать основное web приложение, 2 сервер будет сервать веб приложение мониторинга состояния сервера, то есть это уже встроенный сервис

Та я думал что есть какое то удобное готовое решение

Поэтому я и запариваюсь архитектурным вопросом, чтобы слишком сильно не перемудрить "зазря".

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

звучит как необходимость 1 вебсервера, который будет редиректить на соответствующие приложения в завимости от роута и\или хоста.

Если это сервер приложений, то весь его смысл в том, чтобы абстрагировать приложения, которые на нем работают, от таких деталей, как транспорт.

То есть, нет смысла каждому приложению поднимать свой HTTP сервер. Что тогда делает сервер приложений?

Посмотрите на архитектуру Tomcat для примера.

Вот я об этом и подумал, что приложение ничего не должно знать о сервере. Тогда следует снаружи открывать http порты и как то стикать на них приложение?

Если у меня приложение как-то зафакапит http сервер то я не смогу зайти в сервис мониторинга хотя он мог бы быть вообще не связан с бизнес- приложением

Что такое "HTTP порты"?)

Ваш сервер приложений должен предоставить API для приложений. Приложениям должно быть все равно что там за транспорт - HTTP, WS или еще что-то до тех рпор, пока они работают через API, который предоставляет сервер.

Http порты это я попытался нелепо в два слова уложить смысл что я запустил http сервер на каком то порте)

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

тот же Nginx тяжело положить имхо. приложения ляжет быстрее.
возможно стоит пойти по пути make it work -> make it right -> make it fast, если цель - самообучение. сделать MVP, поштормить его чем-то вроде ab и посмотреть что первое начнёт не выдерживать нагрузки. мне кажется что веб сервер будет последним на выход

Опять же, посмотрите на архитектуру Tomcat и Servlet API.

https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

в конце как раз пример с multiple apps