После некоторой суеты и большого количества воды сервер неявно регистрируется на порту 8080 контейнера. 100
Я был озадачен тем, что могло быть причиной этой проблемы, учитывая, что контейнеры могут связываться через cURL. Я @Autowired EurekaDiscoveryClient и начал копаться в его свойствах, специально ища что-нибудь касающееся услуг.
client.services: возвращает [cairo-service, discussion-service]. Отлично! - первый экземпляр
discussion-service имеет идентификатор fc8feb8bb803:discussion-service, точно так же, как говорит пользовательский интерфейс Eureka! - Проверьте
metadata из этого же экземпляра: возвращает карту {management.port=8080}. Ммм, это звучит актуально.
Где-то посреди всего этого мой разум обнаружил малейшую возможность того, что, возможно, вышеупомянутый «id» также должен представлять свой порт, подобно. И вот, порты как-то задействованы.
На моей локальной машине разработки пользовательский интерфейс Eureka сообщает, что discussion-service зарегистрирован как MY-PC:discussion-service. Здесь важно отметить, что cairo-service зарегистрирован на MY-PC:cairo-service:8081, используя явно определенный порт 8081. Обратите внимание, что в настоящее время я не использую docker для разработки, вместо этого я просто запускаю службы по мере необходимости (на мирных портах ), следовательно, почему MY-PC используется, а не docker имя хоста контейнера. Система функционирует, как упоминалось ранее, cairo-service может достигать discussion-service. Почему? Что ж, получается, что Eureka работает намного лучше при достижении правильного адреса и порта, когда находится в своей собственной сети (или хосте?).
В тот момент, когда сервисы стали изолированными, Eureka не смогла представить правильное соединение на discussion-service, поскольку он не включает подразумеваемый порт по умолчанию 8080 в качестве части URL-адреса, в результате чего потребители ссылаются на URL-адрес, используя HTTP-порт по умолчанию 80, например http://discussion-service:80/discussion/c3f3e424-bc67-4984-b808-e14ddf493766.
Как мы решаем эта проблема?
Оказывается, явная настройка порта сервера заставляет Eureka подобрать его как часть идентификатора службы. Проблема может быть решена различными способами, однако мои предпочтения наименее сдерживающие. Я использую свойство server.port в файле application.properties. В моем случае я использую application.yml
server:
port: 8080
И вот так, головная боль на целый день разрешилась в несколько символов.
Я хочу поблагодарить команду Spring за то, что этот инструмент так прост в использовании. Тем не менее, это также является причиной того, что в рамках фреймворка используется так много инструментов, но также и в моей среде, что затрудняет понимание того, какая именно точка не работает точно