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

Что проверяют

Понимаете ли вы, как процесс занимает порт и что меняют контейнеры и прокси. Для тестировщика это не теория: конфликт портов регулярно ломает тестовые стенды и docker compose up. Следом просят объяснить, как тогда достучаться до обоих сервисов снаружи через один порт.

Как отвечать

В классической постановке нельзя. Сокет слушает сочетание адреса, порта и протокола, и второй процесс, который попытается занять то же сочетание, получит ошибку Address already in use (в Java это java.net.BindException). Но у ответа есть важные оговорки:

• разные протоколы: TCP и UDP на одном номере порта не конфликтуют;
• разные адреса: если у сервера два IP, один сервис может слушать 10.0.0.1:8080, другой 10.0.0.2:8080. Не выйдет, если кто-то из них занял 0.0.0.0:8080, то есть все адреса сразу;
• контейнеры: у каждого контейнера своё сетевое пространство, поэтому оба сервиса внутри спокойно слушают 8080. Конфликт переезжает на хост: публиковать нужно разные порты, -p 8081:8080 и -p 8082:8080. В Kubernetes у каждого пода свой IP, и одинаковый порт в подах не проблема;
• обратный прокси или API-шлюз: снаружи открыт один порт, например 443, а nginx или Traefik отправляет запрос нужному сервису по пути (/orders, /users) или по заголовку Host. Это и есть рабочий ответ на «один порт для двух сервисов».

Отдельно есть SO_REUSEPORT в Linux: несколько сокетов на одном порту, ядро раскидывает между ними соединения. Это приём для нескольких копий одного сервиса, а не для двух разных: какой из них получит запрос, решаете не вы.

Для QA полезно назвать проверку: ss -tlnp или lsof -i :8080 показывают, кто держит порт. В тестах через шлюз стоит убедиться, что запрос дошёл до нужного сервиса, а неизвестный путь даёт 404, а не уходит куда попало.

Где спотыкаются

Отвечают «нельзя» и останавливаются. Интервьюер ждёт продолжения про прокси и контейнеры.

Путают порт внутри контейнера и порт на хосте и пишут в docker-compose двум сервисам одинаковое ports: "8080:8080".

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