코드에서 먼저 살펴볼 것은 DiscoveryClient 클래스다. 이 클래스를 사용하여 스프링 클라우드 로드 밸런서와 상호 작용한다. 그다음 유레카에 등록된 조직 서비스의 모든 인스턴스를 검색하려면 getInstances() 메서드를 사용하고, ServiceInstance 객체 리스트를 얻어 오기 위해 찾으려는 서비스 키를 전달한다. ServiceInstance 클래스는 호스트 이름, 포트, URI 같은 서비스의 인스턴스 정보를 보관한다.
코드 6-12에서는 리스트에서 첫 번째 ServiceInstance 클래스를 사용하여 서비스를 호출하는 데 쓸 수 있는 대상 URL을 만든다. 대상 URL이 만들어지면 표준 스프링 RestTemplate으로 조직 서비스를 호출하고 데이터를 조회할 수 있다.
Discovery Client와 현실
어떤 서비스와 서비스 인스턴스가 등록되어 있는지 확인하기 위해 로드 밸런서에 쿼리해야 할 때만 Discovery Client를 사용해야 한다. 코드 6-12에는 다음 몇 가지 문제가 있다.
• 스프링 클라우드 클라이언트 측 로드 밸런서를 이용하지 못한다: Discovery Client를 직접 호출하면 서비스 리스트를 얻게 되지만, 호출할 서비스 인스턴스를 선정할 책임은 사용자에게 있다.
• 너무 많은 일을 한다: 코드에서 서비스를 호출하는 데 사용될 URL을 생성해야 한다. 이것은 작은 일이지만 코드를 적게 작성하면 디버그할 코드가 줄어든다.
눈치 빠른 스프링 개발자는 코드에서 RestTemplate 클래스를 직접 인스턴스화했다는 것을 알아챘을 것이다. 이것은 일반적인 스프링 REST 호출과 대립되는데, 보통 스프링 프레임워크는 @Autowired 애너테이션을 통해 RestTemplate을 주입하기 때문이다.
코드 6-12에서 볼 수 있듯이 우리는 RestTemplate 클래스의 인스턴스를 생성했다. @EnableDiscoveryClient를 통해 애플리케이션 클래스에서 스프링 Discovery Client를 활성화했다면, 스프링 프레임워크가 관리하는 모든 REST 템플릿(template)은 해당 인스턴스에 로드 밸런서가 활성화된 인터셉터(interceptor)를 주입한다. 이렇게 되면 RestTemplate 클래스로 URL을 생성하는 방식이 변경되는데, 직접적으로 RestTemplate을 인스턴스로 만들면 이 변경을 피할 수 있다.