Мы запускаем среду на основе Spring Boot с примерно 15 микросервисами и пограничным шлюзом Zuul, зарегистрированным в Eureka. В настоящее время я настроил все микросервисы для вызова других микросервисов через шлюз Zuul (например, если serviceA необходимо вызвать serviceB, свойство конфигурации URL-адреса будет serviceB.baseUrl=http://zuul.mydomain.com:7001, где zuul.mydomain.com - это наш сервер разработки на AWS, а все остальные микросервисы будут работать за ним. Это). Zuul, в свою очередь, прокси-серверы к микросервисам через поиск в реестре Eureka.
Одним из преимуществ такого подхода является то, что разработчику, работающему локально на своей машине, ему просто нужно запустить свой сервис, а все другие зависимости от других сервисов доступны через шлюз Zuul на AWS (а в нашей экосистеме много таких зависимостей между службами).
Теперь мне бы очень хотелось использовать весь потенциал Eureka / Ribbon и совершать вызовы напрямую к одноранговому микросервису через его имя службы и @LoadBalanced RestTemplate, но я обнаружил, что это довольно сильно налагает на разработчика необходимость воссоздавать целую экосистему. на его машине. Как минимум, ему нужно будет запустить Eureka, свою собственную службу и любые другие службы, от которых зависит его служба. Это делает барьеры для входа в развитие излишне высокими.
Я действительно рассматривал возможность регистрации локального экземпляра разработчика в нашем сервисе Eureka на AWS, но проблема в том, что все сервисы на AWS регистрируются с использованием частного IP-адреса экземпляра EC2, который в основном недоступен с машины разработчика. Если я заставлю службу регистрироваться с использованием ее общедоступного IP-адреса, это будет означать, что мне придется использовать больше ресурсов, выделенных для каждой службы, или менять IP-адрес при каждой перезагрузке экземпляра EC2.
Я мог бы запустить локальную среду микросервисов Eureka + в локальной сети, но это означает, что мне нужно создать одну такую среду для каждого офиса, в котором мы работаем, а это просто означает больше накладных расходов. В дополнение к этой проблеме это, вероятно, означало бы, что разработчик A может вызывать разработчика B наполовину готовую, еще не совсем готовую версию службы зависимостей, которая просто сбивает с толку всех, если возникает проблема (службы, которые быть развернутым в нашей среде AWS, по крайней мере, сначала проходит проверку кода перед развертыванием).
Если есть кто-нибудь, кто придумал способ упростить настройку разработчика, имея при этом возможность использовать возможности вызова одноранговых служб Feign / @LoadBalanced RestTemplate клиентов, я хотел бы получить несколько указателей в правильном направлении.
